Naviter Support Forum

Reposting this in hopes of getting a response from SeeYou.  Thanks.

I recently went to a setup with a Cambridge 302A feeding its GPS signal to a Borgelt B50, with that combined 302A/B50 signal then going to an Ipaq 3900 with mCU.  When you turn the MacCready knob on the B50 to a higher number, the B50 speed to fly changes (faster) and mCU shows a decrease in arrival height.  When you turn the bugs knob on the B50 to a higher number, the B50 speed to fly changes (slower), but nothing happens to the arrival altitude on the mCU.  Shouldn't an increase in bugs reduce the L/D and cause the arrival height to decrease?

When I change the B50 knob to 30% bugs, doesn't that mean that the L/D should decrease by 30%, and thus reduce the arrival height?  However, it seems to have no effect on arrival height.  It would seem that mCU is not correctly measuring the effect of bugs on the wings.

I am trying to determine if this is a problem with my B50, or is a problem with mCU

It's not a problem of either - there is no problem.

It would seem that mCU is not correctly measuring the effect of bugs on the wings.

Is there a way to measure the effect of bugs on the wing? How do you account for the size of bugs? What if I hit 3 bees and 12 flyies per 10 centimeters of the leading edge and you get a spider's nest with a squashed bug's interior etc.

Frankly - There is no way to measure the bugs and therefore each software designer (counting also the ones writing software for devices such as B50 and similar) found its own way around accounting for the effect of bugs on the wings.

is mCU designed to use the bug information coming from the B50, or does it ignore that information?

That's implicit from my statement above that we don't use anyone else's polar and therefore are not interested in how any manufacturer has accounted for the effect of bugs on the wings.

You'll have to admit that there a bit of magic (or personal feeling) involved in setting up the percentage of bugs which is then somehow used in the polar equasions.

I made a habit of avioding magic on final glides. I therefore always compare my current L/D with the required L/D to reach the finish. My current L/D includes my wing's polar, each and every bug on the wing just the way it changes my polar, it includes water, the current wind and my inability to fly straight. If inspite of all these things I still think that I have a fair chance of keeping the current L/D above the required L/D I continue with the final glide.

Andrej,

In that case why does the Hardware - Settings page include "Bugs" in the labels for the "receive and send to and from the device" check boxes (as in "MacCready, Ballast, Bugs")?

John

I am evaluating your software but what Andrej says does not make sense since on Mc & Alt dialog there is an entry for Bugs %. In the simulator I changed the % and arrival altitude changes as well. Could someone else explain this. Are you parsing all B50 data including Bugs, if so what is wrong here?

Exactly.  If there were no way to change the bugs setting (either by turning the B50 knob or by changing the setting in mCU), Andrej's position would at least be internally consistent (but still wrong since 30% bugs just means your L/D goes down by 30%, and it is up to the pilot to enter the number he thinks is appropriate -- it has nothing to do with polars or the size of bugs).  However, since you can change the bugs setting in mCU, it makes no sense that you can't achieve the same result by turning the B50 knob.  It is, in fact, much easier to turn the B50 knob. 

If Andrej's argument were right, mCU should have no bugs setting.

I don't think I am going to say anything I have not already stated above:

We do not use anyone else's bugs settings simply because we do not know in what "units" those settings are. They may well be in percent but percent related to what exactly? Glide ratio at current IAS? Best glide ratio? Any combination of the above?

There is only one way to know that. Ask each manufacturer to deliver their code or write a description about how they use the bugs settings in their devices. Then create conversion functions from each manufacturer's way of dealing with bugs to the one way that SeeYou Mobile is using. Am I sarcastic if I say that we are not even remotely interested in doing that?

I have to admit one thing though - johngalloway is right that the label in Settings > Hardware is misleading. It's something we wished we would do in 2001 but as it is now it is simply unrealistic.

We do send McCready, Volume and a small subset of data to a few selected devices that support these features unambiguously.
We do receive IAS, TAS, Vario, Pressure altitude from a wide range of devices.

Therefore the label "McCready, Ballast, Bugs" will be changed to "Proprietary non-NMEA data". (unless you guys have a better idea about how to name this feature).

I'm not saying that we will be changing software, just a label which is now misleading. Bugs in SeeYou Mobile will stay where they are. We don't send or receive bugs from other devices though. And we won't receive them at any time in the future to cut the story short.