LXNav V7 vs Butterfly vario?

On Monday, January 7, 2013 3:34:34 AM UTC-5, Max Kellermann wrote:

Another vario that works extremely well with XCSoar is the CAI302. Cambridge has published extensive and excellent protocol documentation before they (unfortunately) disappeared.



Its declared successor from ClearNav has no XCSoar support, and I suppose there will never be. ClearNav did not publish protocol documentation. I asked for documentation, but Richard Kellerman (who I'm not related to) rejected, saying his business is not interested in interoperability with XCSoar. Don't buy if you want to connect it to XCSoar (or any other free software)..



Cambridge is still around, although they are no longer doingany product development that I know of. I had my 302 repaired a couple of weeks ago.

While it is true that ClearNav is not interested in working with XCSoar, we will, as previously mentioned, support the CAI dataport communications standard for our upcoming CNv XC, so the XCSoar community, as well as everybody else already has our protocol. All CNvs sold to date may be software upgraded to XC version with dataport capability. See our website for more information or for more questions, please join our forum.

Evan Ludeman for ClearNav Instruments

http://www.clearnav.net

On Monday, January 7, 2013 12:24:10 PM UTC+1, Evan Ludeman wrote:
While it is true that ClearNav is not interested in working with XCSoar, we will, as previously mentioned, support the CAI dataport communications standard for our upcoming CNv XC, so the XCSoar community, as well as everybody else already has our protocol.

That's a trap. It sounds like "buy ClearNav, and it will work with XCSoar", but it will not. Without cooperation, there _will_ be problems[*].

([*] = it will work only if you emulate all CAI302 firmware bugs, bit by bit, and all timings are identical. The thing is, the CAI302 does not follow its own dataport communication standard. Not a big deal for XCSoar, we have workarounds, but a standards-compliant device will not work.)

We already know that ClearNav is not interested in XCSoar, and therefore I am mutually not interested in ClearNav. Connecting a ClearNav vario to XCSoar is explicitly not supported.

Though I hope ClearNav changes their minds. (It's up to their customers to highlight the importance of connectivity to them, or to choose a vendor that is open enough for one's personal taste.)

On Monday, January 7, 2013 8:52:39 AM UTC-5, Max Kellermann wrote:
On Monday, January 7, 2013 12:24:10 PM UTC+1, Evan Ludeman wrote:

While it is true that ClearNav is not interested in working with XCSoar, we will, as previously mentioned, support the CAI dataport communications standard for our upcoming CNv XC, so the XCSoar community, as well as everybody else already has our protocol.



That's a trap. It sounds like "buy ClearNav, and it will work with XCSoar", but it will not. Without cooperation, there _will_ be problems[*].



([*] = it will work only if you emulate all CAI302 firmware bugs, bit by bit, and all timings are identical. The thing is, the CAI302 does not follow its own dataport communication standard. Not a big deal for XCSoar, we have workarounds, but a standards-compliant device will not work.)



We already know that ClearNav is not interested in XCSoar, and therefore I am mutually not interested in ClearNav. Connecting a ClearNav vario to XCSoar is explicitly not supported.



Though I hope ClearNav changes their minds. (It's up to their customers to highlight the importance of connectivity to them, or to choose a vendor that is open enough for one's personal taste.)

"Trap". Okay... one more time....

We aren't, and won't be making a 302 replacement. We will be using the CAI developed and published dataport standard and with any luck at all we'll be doing a much better job of it than CAI ever did. If users have issues with our products, they should contact us and I have no doubt they will. Where the problems are with our products, we'll do our best to solve them. Hope that's clear?

Third party developers are of course free to integrate their products with CNv based upon the aforementioned standard. That's the point of using an open standard. If there are issues that come up, you should contact us. If the issues are our issues, I expect we'll fix them.

Evan Ludeman for ClearNav Instruments
http://www.clearnav.net

Note that LXNAV and LX Navigation are different companies; this cannot be pointed out often enough, as many people mix the two. LX Navigation has donated a MiniMap a few years ago, but getting technical information about the LX160/LX1600 product family was impossible for me, no reply to my emails. Therefore, no good XCSoar support.

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.

Butterfly was very interested in XCSoar support, and has promised to donate a Vario to us, but that has not happened yet. XCSoar has no driver for the Butterfly Vario yet. If you're looking for a Vario to connect to XCSoar, wait until we are able to promise good interoperability. I'm positive that this will happen soon.

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.

Its declared successor from ClearNav has no XCSoar support, and I suppose there will never be. ClearNav did not publish protocol documentation. I asked for documentation, but Richard Kellerman (who I'm not related to) rejected, saying his business is not interested in interoperability with XCSoar. Don't buy if you want to connect it to XCSoar (or any other free software)..

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.

On Monday, January 7, 2013 11:18:32 AM UTC-5, Tobias Bieniek wrote:
Note that LXNAV and LX Navigation are different companies; this cannot be pointed out often enough, as many people mix the two. LX Navigation has donated a MiniMap a few years ago, but getting technical information about the LX160/LX1600 product family was impossible for me, no reply to my emails. Therefore, no good XCSoar support.



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.



Butterfly was very interested in XCSoar support, and has promised to donate a Vario to us, but that has not happened yet. XCSoar has no driver for the Butterfly Vario yet. If you're looking for a Vario to connect to XCSoar, wait until we are able to promise good interoperability. I'm positive that this will happen soon.



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.



Its declared successor from ClearNav has no XCSoar support, and I suppose there will never be. ClearNav did not publish protocol documentation. I asked for documentation, but Richard Kellerman (who I'm not related to) rejected, saying his business is not interested in interoperability with XCSoar. Don't buy if you want to connect it to XCSoar (or any other free software).



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.

I suggest you treat CNv as the all-new device it is and plan that it will conform to the CAI dataport standard as written, not as implemented over a decade ago by others. I expect we'll have more to say about this when we're closer to product release.

Evan Ludeman for ClearNav Instruments

On Monday, January 7, 2013 5:18:32 PM UTC+1, Tobias Bieniek wrote:
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.

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. Why buy such an expensive vario, when a CAI302, Vega or LX will do the same?

"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.

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.

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'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.

On Monday, January 7, 2013 6:44:02 PM UTC+1, Tobias Bieniek wrote:
I've heard from one user also that the Vega driver can also be used for reading IGC files and writing tasks

Impossible. The Vega is not a logger. Its protocol cannot be used for any of that.

Why not implement the driver according to the protocol documentation without any workarounds and assuming no bugs.

Because ClearNav refuses to cooperate with us, that's why. There will not be a ClearNav driver in XCSoar because nobody will write it.

I clearly don't see the problem here, besides ClearNav missing the point of being an open vendor.

Why would they care? They would care if it turns out to be important for their (potential) customers. What you wrote makes people think openness doesn't matter, because, uh, you wrote that it will likely work anyway, and if not, we will disable some workarounds, and then it may work (or not?), yadda yadda. But it will not work, and nobody will figure it out. What you wrote is misleading and only distracts from the real problem. You make it worse, because your post seems to approve ClearNav's behaviour, instead of explaining why openness matters.

I admit you didn't explicitly write that, in fact your posts don't say anything, it's only speculation and rumor, devoid of facts. But it's rhethorically suggstive to people who have less insight into this big problem than we do.

I've heard from one user also that the Vega driver can also be used for reading IGC files and writing tasks

Impossible. The Vega is not a logger. Its protocol cannot be used for any of that.

Seems I got confused there. It might have been the Altair Pro/RU driver instead.

Why not implement the driver according to the protocol documentation without any workarounds and assuming no bugs.

Because ClearNav refuses to cooperate with us, that's why. There will not be a ClearNav driver in XCSoar because nobody will write it.

I think if there is a high demand for it, someone will step up and do it. Whether it will be me or someone else, I don't know yet.

I clearly don't see the problem here, besides ClearNav missing the point of being an open vendor.

Why would they care? They would care if it turns out to be important for their (potential) customers. What you wrote makes people think openness doesn't matter, because, uh, you wrote that it will likely work anyway, and if not, we will disable some workarounds, and then it may work (or not?), yadda yadda. But it will not work, and nobody will figure it out. What you wrote is misleading and only distracts from the real problem. You make it worse, because your post seems to approve ClearNav's behaviour, instead of explaining why openness matters.



I admit you didn't explicitly write that, in fact your posts don't say anything, it's only speculation and rumor, devoid of facts. But it's rhethorically suggstive to people who have less insight into this big problem than we do.

To be honest, I don't know how much more open they need to be. They gave the information on the protocol and they created a forum to discuss the implementation. All they did not do yet was lending or donating hardware, but I don't expect every vendor to do that. If they don't they will simply have to wait until someone steps up to do the driver.

I think this has started to be a rather pointless off-topic discussion since the original thread was about the quality of the vario itself, and not the connections to external devices. Sorry about that!

On 8/01/2013 00:52, Max Kellermann wrote:
On Monday, January 7, 2013 12:24:10 PM UTC+1, Evan Ludeman wrote:
While it is true that ClearNav is not interested in working with
XCSoar, we will, as previously mentioned, support the CAI dataport
communications standard for our upcoming CNv XC, so the XCSoar
community, as well as everybody else already has our protocol.

That's a trap. It sounds like "buy ClearNav, and it will work with
XCSoar", but it will not. Without cooperation, there _will_ be
problems[*].

([*] = it will work only if you emulate all CAI302 firmware bugs, bit
by bit, and all timings are identical. The thing is, the CAI302 does
not follow its own dataport communication standard. Not a big deal
for XCSoar, we have workarounds, but a standards-compliant device
will not work.)

We already know that ClearNav is not interested in XCSoar, and
therefore I am mutually not interested in ClearNav. Connecting a
ClearNav vario to XCSoar is explicitly not supported.

That sounds very much like pure, bloody-minded sour grapes, Max. XCSoar
will not work with Clear Nav because xcsoar will make sure it won't! I
love it when the lovey-dovey world of the open-source hot-gospellers
meets the slightest opposition to their world view. No more Mr Nice Guy!

Evan said CN was the same as Cambridge. Max says the Cambridge protocol
works well with XCsoar. It appears the only problem is that CN won't
grovel. Good for them!

I'm also interested that Max morphs here from just 'someone who's worked
on XCSoar' (earlier post) to 'I am mutually not interested'. It is
clear that XCSoar's salvation was Max imposing control and leadership on
a loose, woolly and dying project. A very commercial model. Similarly,
LK8000 is a tribute to Paolo's management skills as well as his code
writing talent.

Though I hope ClearNav changes their minds. (It's up to their
customers to highlight the importance of connectivity to them, or to
choose a vendor that is open enough for one's personal taste.)

'NOT very open' is generally my taste. There is some lovely open source
software but I believe that's in spite of the model rather than because
of it. There is also a vast wasteland of sloppy, bloated, unfinished
and buggy projects. Most open source people in my experience are rather
too intolerant of different views and obsessive and evangelical about
their preferred software model - as Max has demonstrated here and the
earlier threats and disparagement of Flarm showed.

I know this is all a bit off-topic but I resent open source's totally
unjustified claim to the moral high ground and I'll write against it
every time they push it. It's all just code and doing it for prestige
and reputation is no more praiseworthy than doing it for money.

Cheers,
GC