|
giannisd
|
|
|
Group: Forum Members
Posts: 94,
Visits: 134
|
Have you consider an integration with SafeSky running on the same iPad that is open on Sydemon or from a smart phone via bluethoot ? Since SafeSky receive all traffic, would be possible to see these traffics on the SD map similar to other system (Flarm, GDL90....) regards, Gianni
|
|
|
|
|
BJS
|
|
|
Group: Forum Members
Posts: 47,
Visits: 149
|
I guess it was discussed already here and abandoned by good reason. SafeSky does not help for collision avoidance, due to the time lag it is a tool for traffic surveillance, thus controller not pilots.
|
|
|
|
|
Daniël Klijnsma
|
|
|
Group: Forum Members
Posts: 11,
Visits: 13
|
+xI guess it was discussed already here and abandoned by good reason. SafeSky does not help for collision avoidance, due to the time lag it is a tool for traffic surveillance, thus controller not pilots. Even though I am not a product specialist, I did see the full integration of SafeSky into Skydemon at work. And there is no time lag at all. SafeSky uses the GDL90 protocol to connect and the data is realtime. As long as you have a proper connection of course. I saw it working during a Safety Day for ULMs in Belgium on an iPadPro and integration is very smooth.
|
|
|
|
|
177
|
|
|
Group: Forum Members
Posts: 72,
Visits: 757
|
I'm also interested in this
|
|
|
|
|
PaulSS
|
|
|
Group: Forum Members
Posts: 89,
Visits: 3.2K
|
And there is no time lag at all. SafeSky uses the GDL90 protocol to connect and the data is realtime. As long as you have a proper connection of course.
I'm sure there is no delay in getting the data to SkyDemon but it is the delay in getting the data to the aircraft that will be the problem. It's all very well seeing it demonstrated on, for instance, a sales stand with good Internet connection but quite something else (as you pointed out) when in the air and the connection may not be quite so reliable. Also, what information has been published about the latency of the data being obtained and re-broadcast? Is it really just a fancy FR24 that is being beamed into the cockpit via 4G?
The likes of Pilot Aware went into great detail to ensure their data suffers almost no latency and has the advantage of being broadcast and received over the radio waves and not relying on airborne data.
My opinion is that 4G etc may work well for receiving weather data etc (that's not going to change in seconds) but traffic data just has too many holes lining up for it to be considered reliable enough. I would much rather have no data than something that is out of date before it appears on my iPad.
Good gadget though and who doesn't love shiny things 
|
|
|
|
|
BJS
|
|
|
Group: Forum Members
Posts: 47,
Visits: 149
|
Everything transferred via internet does have an unknown time component. There is no quality of service, neither for data even being transported, nor when it may be delivered. We often no longer notice because we got used to go brut force with so much bandwidth that latency does not matter. But things are different in the air. The mobile net is not meant for aircraft, still not, and I remember times when the provider cut your connection when they found out you were using internet in flight - as the tower could not handle the quick handover . and you had to call them and apologize later.
No, do not use a source with unknown age of information in flight.
|
|
|
|
|
b3nn0
|
|
|
Group: Forum Members
Posts: 42,
Visits: 3.4K
|
Not really caring about it, but testing it a bit, these are my observations: - Delay of the infrastructure, at least for ADS-B is quite small, 1-2 seconds (compared directly ADS-B received aircraft position to the one received by SafeSky. For OGN/Flarm it doesn't seem to be noticeably more - Arbitrary additional delay can of course come from the mobile network connection - "I remember times when the provider cut your connection when they found out you were using internet in flight" - but that's a thing of the past, i.e. not relevant for the discussion - "No, do not use a source with unknown age of information in flight." This is not a valid point either, since there is a simple solution for it. It is called a timestamp. SafeSky does know the age of a received traffic message (and could show a warning and/or extrapolate its position. Don't know if it does though, or how old data can be to be "acceptable").
At least when flying lower, I tend to get a decent internet connection with acceptable latency in Germany - higher up it's gone of course.
I guess a direct receive is still preferable whenever possible, but it's not like it doesn't work at all. And the direct receivers have their limitations, too (e.g. no Mode-S only traffic).
|
|
|
|
|
trettum
|
|
|
Group: Forum Members
Posts: 12,
Visits: 1
|
I would like to bumb this thread and make a request to fully integrate Safesky into SkyDemon, like AirNavPro have done > https://www.safesky.app/devices/safesky-and-air-navigation-pro)
|
|
|
|
|
Tony N
|
|
|
Group: Forum Members
Posts: 335,
Visits: 2.4K
|
One thing to bear in mind is that SafeSky aircraft "transmit" their GPS derived altitude and not one referenced to1013.2 hPa, which is what devices like Mode S ES transponders and SkyEcho 2 use. This will mean that SkyDemon's collision avoidance algorithms won't work that well if you are receiving both SafeSky positions and ADS-B Out positions. I believe that SafeSky is aware of this issue and is trying to figure out how to ensure that SafeSky altitudes are compatible with ADS-B Out (1013.2) referenced altitudes. Tony
|
|
|
|
|
trettum
|
|
|
Group: Forum Members
Posts: 12,
Visits: 1
|
+xOne thing to bear in mind is that SafeSky aircraft "transmit" their GPS derived altitude and not one referenced to1013.2 hPa, which is what devices like Mode S ES transponders and SkyEcho 2 use. This will mean that SkyDemon's collision avoidance algorithms won't work that well if you are receiving both SafeSky positions and ADS-B Out positions. I believe that SafeSky is aware of this issue and is trying to figure out how to ensure that SafeSky altitudes are compatible with ADS-B Out (1013.2) referenced altitudes. Tony See the information from SafeSky.
SkyDemon does not convert or correct altitudes received by SafeSky.
We took the time to check and test the scenarios.
Today, SafeSky sends its GPS position and altitude to SkyDemon using WGS84. Traffic is therefore sent using the WGS84 datum.
SkyDemon does not convert or correct the altitudes received by SafeSky, which is a good thing because our location and other traffic are all at the same level.
In theory, GDL90 states that altitudes should be based on 1013hPa. We’ve just tested SkyEcho, using both “Generic GDL90” and “SkyEcho”, and the altitude appears as WGS84 on SkyDemon. So either SkyEcho isn’t following the specification or it knows it should be sending WGS84.
The good news is that when we combine SkyDemon, SafeSky and SkyEcho, our position remains WGS84 and all combined SafeSky and SkyEcho traffic is based on the same datum. The smallest differences are due to rounding during conversion and recovery of the different technologies.
SafeSky remains a Traffic Awareness solution, and informs you of the position of other traffic, but this in no way removes the need to look outside to validate the traffic announced by SafeSky, or other devices, and then manoeuvre to avoid a collision."
|
|
|
|