Geoid Separation

[VirusPilot]

Hi @moshe-braner , I just played around with some of my spare TTGOs and successfully installed the MB111 version. I also added the appropriate geoidsep to the config.json but it remains "0" both on the web interface and on the OLED screen. Any ideas?

[moshe-braner]

Hi @VirusPilot - thanks for reporting. I have never looked at this. The code says it is copied into the fields that are then displayed on the OLED and the web interface, so there are bugs there to investigate. But, now I see that the geoid separation is not used for reporting, that would be the more important issue. Although I never understood why it is supposedly important. The reported traffic altitude, not station altitude, is the important part. I gather that OGN stations in Europe (close to each other) try and correct the traffic altitudes based on the station altitudes and geoid separation and who knows what else, so as to avoid a jump in altitude as the reporting of an aircraft switches from one station to another. I think that is backwards. Instead, simply leave the traffic altitude as reported by the aircraft?!

[VirusPilot]

I guess you have seen this good summary from @b3nn0: https://github.com/b3nn0/stratux/wiki/Altitudes-in-Stratux-EU

[moshe-braner]

No I have not seen that. Good article. Thank you. But, my question is: why worry about the STATION altitude, when it's only purpose is to report the altitude (and position) of airborne traffic. And I still think that it should report the "GNSS altitude" (whatever that means) of the aircraft, as reported by the aircraft. My perspective is as a glider pilot, and we use FLARM, which reports GNSS, not barometric, altitude. If a geoid correction is desired, the aircraft should do that, the OGN station should not have to worry about that.

In SoftRF the reported altitude sent out is: (this_aircraft->altitude + this_aircraft->geoid_separation); and for incoming data from other aircraft it is: alt = pkt->alt ; / relative to WGS84 ellipsoid / followed by: fop->altitude = (float) alt - this_aircraft->geoid_separation; and all this is based on the estimated geoid_separation from the GNSS. The collision warnings (FLARM and SoftRF's main job) are based on comparing the altitude of this aircraft with that of the other aircraft, once they are converted into comparable definitions.

So why should OGN station mess any of that up? Let alone worry about barometric pressure? Perhaps this has something to do with other data sources (ADS-B, etc) that use some other definition of "altitude" than FLARM?

FLARM itself perhaps also needs to deal, internally, with other definitions of altitude, since it (PowerFLARM) also gives collision warnings about ADS-B traffic. And FLARM has a barometric sensor too.

[moshe-braner]

OGNbase code, like SoftRF, subtracts its own geoid-separation from the incoming reported (by FLARM) altitudes. That is supposedly converting from ellipsoid altitude to MSL, although I am confused about the +- on that. (The article you mentioned says you subtract the geo-sep to convert the other way.) I assume it uses "this aircraft" geo-sep on the assumption that any aircraft we are hearing from is nearby and the same geo-sep should be about right. What type of "altitude" OGN wants reported I am not sure either, but OGNbase sends the altitude resulting from that subtraction. All of these details came from the original OGNbase code from Manuel Rosel, and I am not familiar with them, hopefully it is correct :-)

Anyway, in OGNbase you enter the geo-sep in the config file, or, alternatively, it can get it from the GNSS module. Either way, it should be stored in both the global variable ogn_geoid_separation and in ThisAircraft.geoid_separation, and should appear on the OLED and in the web interface. You are saying it remains "0" both on the web interface and on the OLED screen. So there is a bug, perhaps. (Or perhaps your edited config.json has an error in the JSON syntax? That happens easily.) I will try and check that here, will let you know. Happy holidays!

[moshe-braner]

In my recent version I added serial.print()s to the OLED display code, and last time I saved some of that output (from version 126 on a T-Beam) I got: "OLED page: 3 POSITION DATA LAT: 51.6809 LON:: -0.5571 ALT: 128.00 GEOID: 48.00 GPS-FIX: true Single-Station"

(No that's not my location, I was running a test checking out somebody's config which was not working for him.)

I haven't run any tests on a TTGO in some time, version MB111 (the latest one I compiled for the TTGO) is from August. I now looked around and found the TTGO I was using for 2-station tests. It still has version MB103. Turned it on and it reports the geoid separation on the OLED.

So I suspect a problem in your config file. Or perhaps an issue with using the TTGO (without GNSS) to run OGNbase on its own, although I have tried to make that possible - in Europe (only two frequencies) can skip the frequency hopping and still receive half the packets, so can manage without the exact GNSS time. Let me know if it works for you!

[VirusPilot]

Maybe it is simply related to the TTGO. I can try a T-Beam instead ...

[moshe-braner]

T-Beam is better, but this should work on a TTGO. Can you send me your config.json file? So I can test it here.

[VirusPilot]

config.json

[moshe-braner]

I updated the TTGO here to version MB111, and uploaded your config.json. It shows the geoid separation on both the OLED and the web page. So not sure why you are seeing something else.