Altitude reference

Hello Tristan,

Thanks for your e-mail to me concerning a recent system upgrade for converting 1013 referenced altitudes to WGS84.
However, surely you got your conversion the wrong way round?

Shouldn’t you be converting SafeSky GPS (WGS84) data to a reference based on 1013hPa?.

The reason I am suggesting this is due to use of navigation apps like SkyDemon and its comprehensive collision avoidance algorithms.

I am transponder equipped, so send my altitude referenced to 1013.

My ADS-B/FLARM receiver is a SkyEcho 2, which also contains a baro sensor to send my aircraft altitude to SkyDemon referenced to 1013.

The SkyDemon collision avoidance algorithms will only work if all altitude data (my aircraft and ADS-B/FLARM “targets”) are based on the same reference.

According to your e-mail to me SafeSky “targets” will be on a GPS based reference so SkyDemon collision avoidance algorithms will not work properly, especially when we have very high or low area pressures.

Your comments?

2 Likes

Hello @tnowak ,

Welcome to the wonderful world of altitude references :slight_smile:

Indeed, it is imperative that aviation systems use the same altitude references. SafeSky aggregates data from multiple sources and uses WGS84 as the internal reference.

When using the SafeSky app, it is important for pilots to see altitudes that correlate with their local QNH altitude. If the app was to use a standard pressure of 1013 hPa, pilots could become disoriented due to differences of up to 500 feet caused by variations in pressure.

When the SafeSky app shares traffic data over GDL90, it should convert altitudes to 1013 hPa to comply with GDL90 specifications. However, it is not currently doing so to also avoid differences between what you see in SafeSKy App and navigation softwares. As long as all traffic originates from SafeSky only, it is acceptable because we are still comparing apples to apples. Collision avoidance algorithm works seamlessly. However, when other external devices such as Stratux or SkyEcho are introduced, a discrepancy arises.

We are addressing this issue in our upcoming release, ensuring that WGS84 traffic from SafeSky will be converted to 1013 hPa over GDL90. Only needs a bit of thinking what to display on SafeSky App itself.

I highly appreciate your feedback and suggestions for improvements. Thanks for that.

I will keep you posted.

Fly Safe,

Tristan

2 Likes

Hi, I will follow this topic. Yesterday I did some tryout with Safesky on Smartphone, Stratux, and Skydemon running on tablet without internet connection.
Everithing work as expected, with SD showing the most recent position of the traffic received both from Safesky and Stratux ( Prooved by the first two letters changing from SY (Safesky) and EA(Stratux) ) but also I’ve seen the altitude reference changing when changing the source.
If I understood, GDL90 requires that altitude is with 1013 reference, and to convert WGS84 altitude to 1013FL, Safesky must know the local QNH of the aircraft. Am I right?
I have Stratux and Rosetta, both are equipped with a baro sensor. May Safesky read the inflight pressure value from them?
Many of smartphone also have a barometric sensor, may Safesky read it, if present?
Sharing with your server a local difference between QNH and WGS84 may help to resolve this issue?

I have reported this issue to SafeSky previously and believe they are still working on a fix.
For pilots that have ADS-B and FLARM receivers, and use SkyDemon for traffic awareness/avoidance, it is important that SafeSky “transmitters” send their altitude with reference to 1013 hPa. Or, SafeSky altitudes somehow converted (in the “cloud”?) to the aviation standard of 1013.
Regards
Tony

The altitude is a WGS84 altitude (GPS) transmits by the phone or tablet.
Normally, the altitude with a local QNH should be the same…

The challenge for us is to be sure that all altitude received are translated in the same system.
For the 1013 ADS-B altitude, we are working with local QNH to transform it correctly

Best regards,

Hello xtof,
Sorry for the very long delay in replying, but I still have some questions on how I can use SafeSky with my small Android smartphone, SE2 ADS-B in receiver (configured for receive mode only) and SkyDemon.

  1. I am transponder equipped so my own height is always with reference to 1013.2 hPa.
  2. I can detect ADS-B Out and FLARM equipped aircraft/gliders with my SE2. Those aircraft heights are, again, referenced to 1013.2 hPa.
  3. If I add the SafeSky app to my smartphone, can SafeSky simply act as a “communicator” that supplies received SafeSky data to SkyDemon alongside the data received from my SE2?
  4. That is, apart from the initial configuration when I purchase SafeSky, I don’t want to have to configure and/or monitor the SafeSky app each time I go flying. I would just want it working “in the background”. My smartphone screen is too small to have split mode displays.
  5. Can you please confirm that ALL aircraft/glider/paraglider etc. “data” received from SafeSky, and sent to my SkyDemon, always has the height element referenced to 1013.2 hPa. That interoperability/standardization would be essential for the excellent SkyDemon collision avoidance algorithms to work properly. All received “target” data needs to have the same altitude reference.

Regards

Tony

1 Like

I also believe that uncertain of vertical separation is a issue to be resolved.
Barometric altitude can be read from onboard receiver (Skyecho, Rosetta, stratux, other GDL90…) or from smartphone/tablet pressure sensor.

Hello @tnowak ,

It’s a little more complicated than that.
A transponder transmits a position at 1013. However, an ADS-B signal contains GPS altitude information. In addition, ground stations share traffic information, sometimes in 1013 and sometimes with a GPS altitude.
At SafeSky we have done a lot of work managing altitudes in order to reference them all in the same way. In this case we use WGS84.

But all this @Tristan will be able to explain to you much more precisely than I can, as he developed the whole procedure for correcting altitudes.
As for SE2, @tristan also uses it in conjunction with SafeSky and SkyDemon. It works perfectly well with no altitude correction problems. For information, SkyDemon, like SafeSky, works in WGS84 GPS altitude. By default, this is the closest to the altitude transmitted by a QNH altimeter.

Best regards,