By BJS - 9/30/2021 8:19:07 AM
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.
|
By Cheeseman1112 - 9/30/2021 9:11:46 AM
+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. |
By 177 - 10/1/2021 5:09:43 PM
I'm also interested in this
|
By PaulSS - 10/1/2021 6:05:20 PM
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  |
By BJS - 10/3/2021 7:52:38 AM
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.
|
By b3nn0 - 10/3/2021 9:12:52 AM
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).
|
By trettum - 7/17/2023 9:25:27 AM
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)
|
By giannisd - 9/29/2021 5:14:06 PM
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
|
By trettum - 2/10/2024 11:56:35 AM
+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."
|
By grahamb - 2/10/2024 5:49:01 PM
+x+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." How does Safesky integrate Mode S which only contains a 1013hPa based altitude? |
By trettum - 2/13/2024 9:57:03 PM
You have to ask Safesky that.
My dream scenario is if there was an built in function in Skydemon, with a push of a button you have full TX/RX ADS-L into SD.
Just imagine the benefits how powerfull the SD app could have been with this enhanced situational awareness.
|
By Tim Dawson - 2/14/2024 10:25:21 AM
Does ADS-L even exist, beyond a published standard and dream of EASA?
|
By Cheeseman1112 - 2/14/2024 11:09:10 AM
+xHave 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 Going back to the initial question, I believe this question is indeed resolved with the possibilities we see between SD and SafeSky now, using the GDL90 protocol. Running both apps on an iPad Mini 3 in portrait mode due to my cockpit layout, I find it difficult to still have sufficient real estate on my screen to make decent use of SD. Therefore, I am now using SafeSky on my iPhone SE3 in radar mode, have that as a separate device in my cockpit on a magnetic holder, and use SD on the iPad fullscreen and I simply love this setup. My iPad has built-in GPS, so whenever the GDL90 signal fails due to loss of signal, I still have my own GPS fix - and hence my own flight data - active which is the right solution for me. The only thing around SafeSky integration into SD would be to make it built native into SD so one does not need to run 2 apps. This could replace the virtual radar currently in SD that is working so-so compared to the very comprehensive radar mode of SafeSky.
As far as signal reception and system reliability is concerned, below 5000ft I do not have long periods without phone network connection flying in Belgium, The Netherlands, France, Hungary and Germany; the warnings I receive compared to the outside view, scanning for other traffic, is mostly off less than 2 seconds and that is enough to me. If this would not be enough during a VFR flight in VMC conditions, I believe you are doing something not quite to the expectation of any pilot that flies under these conditions. In the end we all need to look outside and consider any trafic awareness tool - even ATC warning you - as a backup, not as a primary means to know where traffic is situated around you.
The times I fly higher than 5000ft are quite rare. I also believe that traffic above 5000ft - outside of high mountains of course - becomes less dense and is more prone to carry Mode S on board and be in contact with ATC. And yes, one can always identify exceptions (hang gliders around Mont Blanc for example, at 10.000ft), but when you venture out into those areas, I assume you look outside, not rely on some display to tell you what traffic is a potential danger, no matter what type of aircraft you are flying in.
As always, happy landings!
|
By davidagr - 9/19/2024 7:54:45 AM
Hi, I am an avid user of SkyDemon and enjoy its many many features. However, I note that the iPad applications ‘SDVFR’ and ‘AirNav Pro’ have both recently integrated the app ‘SAFESKY’ as a native app and in doing so makes it so easy to have available on screen, rather than have to separately link to my iphone etc etc.
Is it posible for SkyDemon to have the same integration.
|
By Tim Dawson - 9/24/2024 10:04:03 AM
I don't see us integrating anybody else's service in this way, no.
|
By tnowak - 7/22/2023 4:50:36 PM
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
|
|