XCSoar + GPSout = no altitute readings

[Hawkey]

Ok Peter, you win.

Moral of the story is pack, a compass when you use a GPS system, mostly(VTG?).

The VTG sentence does not work for headings with XCSoar or VisualGPSce(at least very good at all with this one).

For me the v2.6.0.1 still gives bad altitude readings in XCSoar.

For me the v2.6.01 gives good readings in VisualGPScd(this one does not care which dll is used)

Good news is my BT308 gives good altitudes with XCSoar and VisualGPSout.

The bad news is the XCSoar people may have to review their code, which at this point

I am growing weary tracking down the nitty gritty, unless I decide to fly with their software.

For FS2002 and FS2004 I will fly virtually with v2.6.0.7 until the cat or dog eats it or

I lose it first or I work something out with XCSoar people or move on to something else.

rww

[Pete Dowson]

Ok Peter, you win.

LOL! I didn't think it was a competition! ;-)

For FS2002 and FS2004 I will fly virtually with v2.6.0.7 ...

I'll make the same changes in FSUIPC4, in case you ever move to FSX!

Pete

[jwharington]

XCSoar ignores the VTG since no current glider instrumentation provide this data in a reliable way to use it for heading information.

Even if a GPS source (e.g. garmin eTrex) produces the data, we cannot assume that the device is properly aligned with the horizon (especially so in gliders anyway because of the high level of banking when circling).

So as a result, we rely on GPS track. Internally we calculate the heading inferred from wind speed and the GPS resolved speed over the ground, and this heading is used as the aircraft's symbol's orientation.

I can't understand from your posts what the problem with altitudes and field elevations are. Except I can comment that the elevation data we use from our terrain generator is finished SRTM, but depending on the resolution you set when you create the terrain file, you may end up with loss of accuracy due to a coarse grid.

Various GPS units handle altitudes differently, some do it above the WGS ellipsoid, some above MSL. Some provide the ellipsoid offset to MSL. We also model the ellipsoid offset and apply it when we think the GPS device isn't handling it correctly; this could be the cause of what you're experiencing.

Also bear in mind XCSoar can use both barometric altitude and GPS altitude, and it's configurable as to which it uses for navigation. Maybe you need to check these things also (and/or whether your QNH is set correctly).

[Pete Dowson]

So as a result, we rely on GPS track. Internally we calculate the heading inferred from wind speed and the GPS resolved speed over the ground, and this heading is used as the aircraft's symbol's orientation.

Hmm. Interesting. I thought navigational instruments derived wind speed and direction data from the difference between heading and track over time. Where do you get wind data from?

I can't understand from your posts what the problem with altitudes and field elevations are. Except I can comment that the elevation data we use from our terrain generator is finished SRTM, but depending on the resolution you set when you create the terrain file, you may end up with loss of accuracy due to a coarse grid.

GPSout simply supplies the altitude given by Flight simulator, which is based on whatever terrain the user has installed. The problems in XCSoar appeared to be that the altitude it displayed was NOT the one being provided, but one modified by some value. As an experiment instead of omitting the "height of Geoid above WGS84 ellipsoid" field in the GGA sentence I supplied an explicit 0.0. that seemed to fix it. It looks as XCSoar applies some "correction" if the GPS supplying it isn't explicit. I thought omitted values should be taken as zero, but maybe this isn't so.

Some provide the ellipsoid offset to MSL. We also model the ellipsoid offset and apply it when we think the GPS device isn't handling it correctly; this could be the cause of what you're experiencing.

Exactly. But is omitting a value not supported by the GPS really "not handling it correctly"? It hasn't been a problem with any other moving map or GPS devices which accept simulated input.

Also bear in mind XCSoar can use both barometric altitude and GPS altitude, and it's configurable as to which it uses for navigation. Maybe you need to check these things also (and/or whether your QNH is set correctly).

That's totally irrelevant in this case as it is the true AMSL in the simulator which is provided and this was being modified by XCSoar to an incorreect, fictitious value. GPSout does not supply the QNH value nor the altimeter read-out -- I don't support any NMEA sentences which include such information.

Regards

Pete

[jwharington]

Powered aircraft do indeed derive wind speed from compass heading and GPS speed and airspeed, but gliders generally do not. They can in some circumstances, but usually not.

Wind is estimated from a variety of algorithms, including estimating drift when circling (we do that a lot!), and zigzag methods that may or may not use compass information. Estimating wind accurately is of critical importance in gliders so a lot of attention is placed on this aspect of the program.

Supporting devices that do not conform to standards is always tricky, as a workaround for one device may not work with another device. I guess this ultimately is what's causing the issue here. We've applied geoid correction where we think the device isn't doing it properly, and for whatever reason that is inappropriate for the way you do it.

I'm not familiar with your program so I don't know what you output. The garmin NMEA sentence for baro altitude is pretty common and lots of other devices use this, I assumed you might also; hence my comment about how XCSoar can be configured to use one or the other.

[jwharington]

Having a look at the source code, I can confirm that if the "height above geoid" part is blank, then XCSoar assumes the GPS is dumb and doesn't have an internal geoid model and therefore the height it is reporting is relative to the ellipsoid. This is a logical assumption because if a GPS manufacturer has provided that function, they would surely produce the full sentence.

Setting the "height above geoid" part to "0.0" rather than leaving it blank should sort it out for you.

[Pete Dowson]

We've applied geoid correction where we think the device isn't doing it properly, and for whatever reason that is inappropriate for the way you do it.

"Did it" you mean -- I've changed it to make your program report the altitude correctly now.

As I said some time back, if I supply a GeoId correction value of 0 then you report the correct altitude. If I simply omit it, as is allowed according to the NMEA standard, then you are applying your own. Hence you are treating "omission" as "incorrect". I'm not sure whether that's right or wrong, but yours is the only program we've come across in the 10 years or so of GPSout which does such a thing.

I don't think there's much point in pursuing this discussion -- I've updated my program so yours reports altitude correctly, and this does not muck up anything else, so it's all okay.

Regards

Pete

[jwharington]

OK that's great. As time marches on, the number of GPS units out there in the wild that don't supply the geoid correction will get less and less and maybe we can eventually change XCSoar to handle this better. But for the time being, I think we're kind of forced to do things the way we currently are.

Anyway, glad we've found a fix that suits us both. I'm only posting here because I do care about trying to make XCSoar available to the widest possible audience, and whilst it is specifically designed for use in gliders in real life, I hope that FSX gamers do find it useful also.

Johnny