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.
Welcome to the wonderful world of altitude references
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.
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
