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

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.

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.

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