SkyDemon Forums

GDL90 implementation/Stratux Bugs

http://forums.skydemon.aero/Topic26899.aspx

By b3nn0 - 9/9/2018 12:23:43 PM

Sorry for the double post, but I can't seem to be able to edit the original one.
Just wanted to add.. what's also quite interesting:
The GDL90 Implementation on Windows seems to be much more tolerant.. I connected the Android device AND a Windows PC to the same Stratux. While to Android one keeps disconnecting/stopping navigation from time to time, the Windows one seems to be quite stable.
By Tim Dawson - 9/10/2018 12:11:25 PM

I doubt there is an implementation of GDL90 more stable than ours. There are no known problems with it; parsing such a datastream is commonplace in SkyDemon and offers no particular engineering challenge.

UDP is the method of communication of GDL90 messages in most popular commercial traffic receivers (iLevil, SkyEcho etc) and I am unaware of any such popular devices which use Bluetooth for GDL90.

SkyDemon declares that a UDP based connection has been lost when no GDL90 "heartbeat" message have been received for fifteen seconds. That is actually quite forgiving, and if that situation is ever reached, there is definitely a connectivity problem. "Waiting for Device" occurs when no position data has been received for five seconds.

It is possible that something to do with the setup you have created is causing buffering of messages, which could lead to the timeouts discussed.

It is interesting that you note the Windows implementation of GDL90 appears to be more stable. They are exactly the same code.
By b3nn0 - 9/10/2018 6:52:00 PM

Tim Dawson - 9/10/2018 12:11:25 PM
I doubt there is an implementation of GDL90 more stable than ours. There are no known problems with it; parsing such a datastream is commonplace in SkyDemon and offers no particular engineering challenge.

UDP is the method of communication of GDL90 messages in most popular commercial traffic receivers (iLevil, SkyEcho etc) and I am unaware of any such popular devices which use Bluetooth for GDL90.

SkyDemon declares that a UDP based connection has been lost when no GDL90 "heartbeat" message have been received for fifteen seconds. That is actually quite forgiving, and if that situation is ever reached, there is definitely a connectivity problem. "Waiting for Device" occurs when no position data has been received for five seconds.

It is possible that something to do with the setup you have created is causing buffering of messages, which could lead to the timeouts discussed.

It is interesting that you note the Windows implementation of GDL90 appears to be more stable. They are exactly the same code.

Hmm, that's rather strange, but good to know. Thank you for the insight, I'll do more trial and error. On my flights today (2*40min) I didn't have a single disconnect.. Let me see how this develops.
By b3nn0 - 9/6/2018 2:36:16 PM

Hi,
I'm new to Skydemon and still in my 30 days trial. I really love the app so far and I'm thinking about buying it. The best feature, IMO, is the GDL 90 support with traffic warnings, so it can interface with my Stratux.

However, I've found the GDL90 implementation to be quite buggy. I'm a software developer myself, so I've been doing some trial and error and noticed this:
1) It's quite annoying that GDL90 is only supported via UDP and not via Bluetooth. However, I managed to work round this by using a bluetooth-to-UDP app. So it's not too bad.
2) When connecting to my Stratux directly, the connection is quite unstable. Sometimes "Waiting for device" pops up for several seconds and then the connection works again, sometimes there is a timeout and I'm thrown out of flying-mode. As soon as I hit the "Fly" button, the connection is immediately established again. I used a UDP sniffer to evaluate if it's a problem on the Stratux side. However, there is a constant stream of data without any hickups, so it seems to be a problem with Skydemon.
3) Missing traffic: When connecting via Wifi/UDP, in many cases I don't see any traffic at all (yes, the limit is set to 50000ft), while on the Stratux website, there is quite a lot of ADS-B traffic. This is clearly a Skydemon issue, because:
4) As noted above, I implemented a layer between Stratux and Skydemon, so I can send the traffic via Bluetooth. The layer parses the GDL90 messages and simply sends them out via Bluetooth. On Android, there is another app that received the data via Bluetooth and sends them to 127.0.0.1:4000 via UDP. What I noticed: If I put a delay between each GDL90 message - e.g. 20ms - suddenly, all the traffic appears in Skydemon (even though it sometimes vanishes for a sec and then reappears). When I remove the delay, it vanishes completely again.

To me, this kind of looks like unstable serial data stream parsing (i.e. not correctly separating out the individual messages if they are received too fast).
Are these issues known? Is there anything in the pipeline to make the GDL90 implementation more stable in the future?
For reference, I tried with another App that supports ADS-B parsing - just to test my bluetooth translation layer. In that app, I can see all the traffic flawlessly. It doesn't disappear, it's all there, I don't need delays (but they don't harm either)... The only problem: the other app is - by far - not as good as Skydemon in any other respect.
So basically, the worst connection method is the "default" one (Wifi). Missing traffic and unstable connection.
With my bluetooth+delay hack, the connection is usually stable, traffic is at least sometimes visible but vanishes from time to time.

If I can be of any assistance to debug this issue, I'd be happy to do so.

EDIT: Another issue might be the lifetime of other airplanes. Stratux sends out a traffic report once per second, which only contains the traffic that was received in this second. Other apps seem to have a lifetime of about 30 seconds. So if a target is missing from a report, it will not be removed from the map immediately. For Skydemon, this lifetime seems to be only about one second?

Thanks,
Adrian

By Cubyte - 12/31/2018 2:41:48 PM

Just like to say I've been using Skydemon for over a year now and because I'm a newly qualified microlight pilot it gives me the confidence to fly to other airfield without worrying about flying into restricted airspace. Over the Christmas break I thought I would build a Stratux  unit and test it next time i go flying but  I also have noticed issue with this unit not showing aircraft on Skydemon. My setup is using direct wifi to Stratux and doesn't suffer from any loss of communication (given some losses will be there due to udp protocol ) my issue is i cannot see other aircraft the Stratux software list them and nothing appears on the skydemon screen i'm sure this is due to the height of the aircraft above 30,000ft. Is this the case and can you force Skydemon to show all aircraft ? 
By b3nn0 - 12/31/2018 2:49:35 PM

You can only see aircraft when you are in Flying mode. And yes, you can change the height limits in Setup->Nav options, scroll down to "Other Traffic"
By Paul_Sengupta - 9/13/2019 3:55:19 PM

I'm having the same issue with Stratux and Sky Demon. When I go back to Stratux V1.4 it seems to be ok, but with the latest Stratux V1.5 I don't get any traffic. I don't know what the difference is between the implementations. This is on two separate Android tablets connected using GDL90 (I've tried both "GDL90" and "Sky Echo 2").

By TouchTheSky - 9/13/2019 5:33:06 PM

Paul_Sengupta - 9/13/2019 3:55:19 PM
I'm having the same issue with Stratux and Sky Demon. When I go back to Stratux V1.4 it seems to be ok, but with the latest Stratux V1.5 I don't get any traffic. I don't know what the difference is between the implementations. This is on two separate Android tablets connected using GDL90 (I've tried both "GDL90" and "Sky Echo 2").


Did you use the following: Stratux Europe Edition?

If so, it is recommended to use the FLARM NMEA protocol with SkyDemon, do you know how to do that? Here are more details:

By MarkusM - 9/13/2019 8:25:28 PM

The EU fork including Flarm is really nice, but my advice is to use the GDL protocol, as that is more towards a kind of professionell implementation ...