|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 8K,
Visits: 9K
|
I don't see us integrating anybody else's service in this way, no.
|
|
|
|
|
David
|
|
|
Group: Forum Members
Posts: 7,
Visits: 2
|
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.  
|
|
|
|
|
Daniël Klijnsma
|
|
|
Group: Forum Members
Posts: 11,
Visits: 13
|
+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!
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 8K,
Visits: 9K
|
Does ADS-L even exist, beyond a published standard and dream of EASA?
|
|
|
|
|
trettum
|
|
|
Group: Forum Members
Posts: 12,
Visits: 1
|
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.
|
|
|
|
|
grahamb
|
|
|
Group: Forum Members
Posts: 565,
Visits: 27K
|
+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?
|
|
|
|
|
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."
|
|
|
|
|
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
|
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)
|
|
|
|
|
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).
|
|
|
|