Hi,
from where does the SafeSky app take it’s own height?
I have a gap between the height in SafeSky and in SkyDemon/Stratux.
Thanks.
Kai
Hi,
from where does the SafeSky app take it’s own height?
I have a gap between the height in SafeSky and in SkyDemon/Stratux.
Thanks.
Kai
How big is the difference?
Are both apps running on the same device or different ones?
Yes, both apps on one device.
The difference is 400 ft.
Is it possible that SafeSky uses the GPS height instead of the barometric height?
SafeSky is using GPS altitude for all traffics, except for some ADS-B that unfortunately sometimes only contains standard altitudes (1013 hPa). We are working on a fix to re-ajust the altitude in those cases based on the local QNH, so that every traffic will be precisely on the same reference.
SateSky team
I think ADS-B is always barometric height.
You are right ADS-B is always 1013.25hPa, or 29.92inHg ¶. Look at your Transponder … you will see the „value“ in feet transmitted into the network.
If you are wondering about the term „value“ … I use it because FL are based on std.Pressure¶ 1013 /29.92 and Altitude ((A)MSL) is related to QNH-/Altimeter setting depending on regional forecast/ local area Pressure.
Hello,
I am ADS-B Out equipped in my aircraft, so my reported altitude is always referenced to 1013.2 hPa.
I use an uAvionix SkyEcho 2 to receive ADS-B In and also provide “my position and altitude” information to my EFB (SkyDemon). This is for the SkyDemon collision avoidance algorithms to function correctly so all altitudes are referenced to 1013.2.
If I load the SafeSky app onto my phone, I presume my phone’s GPS will report my altitude with reference to GPS altitude.
How does SafeSky convert GPS received altitude to altitude referenced to 1013.2?
This is important to ensure all aircraft are using the same altitude reference.
Thanks
Tony
SafeSky Team,
Have you now included a “fix” so that smartphone GPS derived height is adjusted so it is relative to 1013.2 hPA?
If not, how is this height discrepancy between devices using a 1013.2 reference and GPS derived height to be resolved?
Regards
Tony
Dear @tnowak ,
Thanks for your message; and sorry to come back so late but this item is very interesting and not yet completely resolved.
All of you are right, transponder and ADS-B out gives a barometric altitude 1013,2. BUT the transponder able to send an ads-B out signal transforms a GPS altitude of course. That’s why you need to connect your transponder to your GPS to be able to transmit your ADS-B out.
In another hand, you fly considering a local QNH giving you an altitude very similar (in theory) of the GPS altitude.
Most of the data we integrate is in GPS altitude, a small part is in 1013.2. This means that today, with a significant difference in pressure, we can have differences in altitude with some of the traffic informed by SafeSky.
We have been working for a long time to try and find the best solution but it is not easy. Be sure that we don’t forget it or underestimate it.
If you have any ideas or recommendations, please shoot. It can be very helpful.
Fly safe.
ATC relies on a standard atmosphere model, implemented in all altimeters.
The pressure is measured and a flight level (pressure altitude) is derived from that, based on the standard altmosphere model.
ATC does not rely on real (geometrical) altitude, but a QNH correction is taken into account in both altimeters and ATC radar screens. That is why QNH is always communicated by the ATCO when a pilot initiate a contact with ATC (below transition level).
The problem is that SafeSky (and FLARMS) use the GPS altitude, while ADS-B and Mode S transponders (designed for ATC) broadcast the pressure altitude.
QNH correction is not enough to get a “true altitude” from the pressure altitude: you also need the temperature distribution below the aircraft.
Good news is that ADS-B equiped transponder have both GPS and the transponder’s pressure detector: ADS-B messages contain both “Pressure-altitude/FL” and a “GNSS Height” field.
Unfortunately, I observed that sources like FR24 only show the pressure altitude.
SafeSky could look for ground servers delivering also the “GNSS Height” for ADS-B targets.
FLARM (OGN) is another matter: some FLARM devices are IGC certified (to validated FAI sport performances) and have both GPS and pressure sensor, but many FLARMs only have a GPS, no pressure sensor.
As you see, getting an accurate vertical difference assessment between two targets using different devices is a complicated matter.
I would advice to rely on horizontal “low separation” warnings from SafeSky, but look below as well as above to spot the other plane.
The only way to get a reliable vertical assessment would be to have both planes using the same reference, like in TCAS.
Rosetta is equipped with a barometric sensor, to correct pressure altitude in GPS altitude (GPS altitude is usually nearly the same of QNH altitude).
Stratux can be equipped with a barometric sensor or, otherwise, if no pressure sensor is present or readable, the software check for near ADSB sources trasmitting both GPS and Pressure altitude and adopt the difference to calculate their own pressure altitude. It is not very funcional and don’t make very sense to run a Stratux without equipping it with a 2€ BMP280 pressure sensor, but this solution may be a good idea for Safesky.
Also, many of smartphone are equipped with a barmometric sensor. May safesky read the local pressure from it?