View Single Post
  #27  
Old January 7th 13, 05:44 PM posted to rec.aviation.soaring
Tobias Bieniek
external usenet poster
 
Posts: 74
Default LXNav V7 vs Butterfly vario?

I've contacted LX Navigation about their LX1606 vario and they replied with the documentation in a matter of days. No problems on my side.

There is no problem on your side because you did not consider the pass-through bug.


I am not aware of "the pass-through" bug. I consider these pass-through modes a hack anyway and would not encourage the use of such a mode. IMHO it makes more sense to connect all the devices independently to each other.

The Butterfly vario apparently can be configured to behave like either an LX, a CAI302 or a Triadis Vega vario. Since XCSoar supports all those devices there really shouldn't be many problems in connecting the two.


You are talking only about the NMEA extensions, only a very small part of the protocol. And anyway, the NMEA extensions you named are not capable of the advanced Butterfly features.


Yes, I was only talking about the NMEA extensions, since what is documented so far. I've heard from one user also that the Vega driver can also be used for reading IGC files and writing tasks, but I haven't verified that yet. It might be useful to not that the logger of the Butterfly vario is a separate component with a separate interface that uses the Vega protocol. That part doesn't even need an CAN-NMEA converter.

Why buy such an expensive vario, when a CAI302, Vega or LX will do the same?


Because they don't do the same. Butterfly is not passing all the data on to the PDA, but it does very well use the data for its internal calculations.

"Not many problems" is not a desirable state of affairs for glider electronics. We can do better than that. I want us to do better. Therefore, I will only promise that Butterfly works after I have confirmation that it does.


Sure, I agree. I never said that I promise it, only that it is very likely to work as expected.

As Evan stated already the ClearNav will use the CAI protocol, so I see no need to publish any protocol documentation from their side. We might just have to disable those workarounds for the ClearNav vario.


You don't understand, and your post is misleading. This is about a vendor who explicitly says he is not willing to support XCSoar. The vendor will not tell us which workarounds shall be disabled, which new bugs may be in the firmware, and how to detect the ClearNav vario in the first place. You don't even know where to start.


Indeed, I don't understand. Why not implement the driver according to the protocol documentation without any workarounds and assuming no bugs. If the ClearNav vario is not following that then that is not our problem. It is in any case better than having no support at all. I clearly don't see the problem here, besides ClearNav missing the point of being an open vendor.

I find it very problematic that you implicitly suggest that problems with ClearNav interoperability will magically be solved. That is a promise to (potential) ClearNav customers. Will you take responsibility for it? Because I won't.


I was actually thinking about buying a ClearNav vario in the future and I know some people that have already done that. Again, I never said anything about promises, just that it is quite likely to work as expected as the driver is already there or that it might be possible to support it with just minor changes.