ADS-B over WiFi

[SwedeFlyer]

I flew around for a while today, capturing all UDP packets sent by SkyView via wifi to port 4000 on my laptop. While still investgating the results, what I've found is that SkyView (as of v16, anyway) sends GDL90 'traffic report' and 'uplink' packets, but never sends the 'heartbeat' or 'ownship' messages that are part of the GDL90 spec. This was for a flight that lasted over an hour, and the heartbeat is supposed to be sent once per second so I would have thought I would have seen something.

I'm wondering if this is why (or at least part of the why) some clients don't work with SkyView's WiFi ADS-B - those missing messages are mandatory in the GDL specification but they ain't coming out of SkyView's ADS-B feed over wifi. It's reasonable to expect that a client (EFB app, Avidyne IFD, etc.) written to the GDL spec would be expecting the heartbeat message, at a minimum, and if it doesn't see it doesn't listen for the other items.

Thoughts?

Interesting... I am the author of TrafficAssist (An Android App using ADSB for Traffic) I solved the issue of not getting ownship messages, even during initialization. There are other ADSB-In devices that also lack this e.g. PingUSB. This all comes down to orienting and properly display traffic in relationship to OwnShip (Altitude, location, speed and direction). If not available then I back-calculate from Geodetic (gps) altitude and location and direction. And when the 978 data comes in I use that instead of the gps, by having the Ownship Mode S code. Just one must be aware that the 978 data lags a second or 2 behind let's say 1090 data. Cool stuff and important for flight safety.
Peter

 

[BradThePilot]

I've already been in touch with Dynon and provided the details. In the me

Interesting... I am the author of TrafficAssist (An Android App using ADSB for Traffic) I solved the issue of not getting ownship messages, even during initialization. There are other ADSB-In devices that also lack this e.g. PingUSB. This all comes down to orienting and properly display traffic in relationship to OwnShip (Altitude, location, speed and direction). If not available then I back-calculate from Geodetic (gps) altitude and location and direction. And when the 978 data comes in I use that instead of the gps, by having the Ownship Mode S code. Just one must be aware that the 978 data lags a second or 2 behind let's say 1090 data. Cool stuff and important for flight safety.
Peter

Lack of ownship isn't really a big deal, just a minor inconvenience. I solved it just by swapping out the message ID if I see my configured address (which includes recalculating the CRC) as the traffic report payload and ownship payload are the same - essentially what you describe as 978 data. I wrote similar code for a custom version of Stratux a few years ago that has been driving my IFDs ever since.

The bigger deal is the lack of a heartbeat message, for without it, the IFDs will not display data from subsequent traffic report or uplink messages. And I'd argue that they shouldn't - without the heartbeat, there is no way to differentiate between lack of traffic (or uplinks) and a failed sensor.

 

[ve0kog]

I am the author of TrafficAssist (An Android App using ADSB for Traffic)

wish I saw this before I switched to GDL 50 and Garmin Pilot (TargetTrend). Garmin traffic view is really good, but it sounds like your app has even more features. Are you planning to make an IOS version by any chance?

 

[SwedeFlyer]

wish I saw this before I switched to GDL 50 and Garmin Pilot (TargetTrend). Garmin traffic view is really good, but it sounds like your app has even more features. Are you planning to make an IOS version by any chance?

Sorry,
I just don't have the mental bandwidth to learn the Apple stuff. I'll tell you though, I am using a Stratux device, and am using a few Lenovo 9" tablets for about $79/Tablet and $350/Stratux. With that you will get a TCAS-II facsimile, with Assisted Visual Separation. I have tested this app for over a year, especially the FAA NextGen initiative with CAVS CDTI-Assisted Visual Separation. Basically this feature allows you to hone in on a target you are following, and it will give you just the essential info to keep a safe distance during approach/landing. I am not the bragging type but this has been a game changer for me. Btw, Ian Twombly at AOPA wrote an article about it (Oct 2024 issue pg 44). He looked at the older version without Visual Separation. Anyway what is the goal? To have any pilot be able to take use of this technology without a major investment.
I did contact Garmin to maybe get their proprietary format for their GDl 39/50/51/52 ADSB-In devices without success.
If you're interested ping me at SwedeFlyer@gmail.com
Cheers,
Peter

 

[SwedeFlyer]

Sorry,
I just don't have the mental bandwidth to learn the Apple stuff. I'll tell you though, I am using a Stratux device, and am using a few Lenovo 9" tablets for about $79/Tablet and $350/Stratux. With that you will get a TCAS-II facsimile, with Assisted Visual Separation. I have tested this app for over a year, especially the FAA NextGen initiative with CAVS CDTI-Assisted Visual Separation. Basically this feature allows you to hone in on a target you are following, and it will give you just the essential info to keep a safe distance during approach/landing. I am not the bragging type but this has been a game changer for me. Btw, Ian Twombly at AOPA wrote an article about it (Oct 2024 issue pg 44). He looked at the older version without Visual Separation. Anyway what is the goal? To have any pilot be able to take use of this technology without a major investment.
I did contact Garmin to maybe get their proprietary format for their GDl 39/50/51/52 ADSB-In devices without success.
If you're interested ping me at SwedeFlyer@gmail.com
Cheers,
Peter

BTW here's a screenshot of TrafficAssist with the Assisted Visual Separation:

 

[ve0kog]

I did contact Garmin to maybe get their proprietary format for their GDl 39/50/51/52 ADSB-In devices without success.

Peter, you may be interested in this https://web.archive.org/web/20221006165540/http://www.chartbundle.com/tech/gdl39/
and https://github.com/cyoung/stratux/issues/75

I believe the protocol contains the target's relative vector to own ship's vector already computed on the GDL device, so that may a shortcut for a large section of code in your app, if you are able to take advantage of it.

 

[SwedeFlyer]

Peter, you may be interested in this https://web.archive.org/web/20221006165540/http://www.chartbundle.com/tech/gdl39/
and https://github.com/cyoung/stratux/issues/75

I believe the protocol contains the target's relative vector to own ship's vector already computed on the GDL device, so that may a shortcut for a large section of code in your app, if you are able to take advantage of it.

I'll take a look at it, thanks

 

[RayH]

I flew around for a while today, capturing all UDP packets sent by SkyView via wifi to port 4000 on my laptop. While still investgating the results, what I've found is that SkyView (as of v16, anyway) sends GDL90 'traffic report' and 'uplink' packets, but never sends the 'heartbeat' or 'ownship' messages that are part of the GDL90 spec. This was for a flight that lasted over an hour, and the heartbeat is supposed to be sent once per second so I would have thought I would have seen something.

I'm wondering if this is why (or at least part of the why) some clients don't work with SkyView's WiFi ADS-B - those missing messages are mandatory in the GDL specification but they ain't coming out of SkyView's ADS-B feed over wifi. It's reasonable to expect that a client (EFB app, Avidyne IFD, etc.) written to the GDL spec would be expecting the heartbeat message, at a minimum, and if it doesn't see it doesn't listen for the other items.

Thoughts?

I have a skyview touch with wifi dongle and use iFLY efb and cannot get the heartbeat to move off of zero and I get no traffic alerts on my efb.
I have been talking with Dynon and iFlY to help me figure this out. Dynon has said that the problem isn't on their end. It seems like with your comments it probably is.

 

[BradThePilot]

I have a skyview touch with wifi dongle and use iFLY efb and cannot get the heartbeat to move off of zero and I get no traffic alerts on my efb.
I have been talking with Dynon and iFlY to help me figure this out. Dynon has said that the problem isn't on their end. It seems like with your comments it probably is.

If iFLY efb needs the heartbeats, then it's absolutely a Dynon issue. GDL90 requires the heartbeat message per the spec and Dynon (as of 17.1 anyway) never sends it. The issue I opened with them on this topic is request # 150700 and in it I detailed the exact issue along with how to replicate and resolve it. I was also called by Dynon asking for details about the matter, so it's possible they might do something with it eventually.
But yes, bottom line is that not sending the heartbeat packets per the GDL90 data specification is 100% a Dynon shortcoming.

 

[Rhino]

Other people get traffic on iFly, so I doubt it's a heartbeat issue.

 

[RayH]

Other people get traffic on iFly, so I doubt it's a heartbeat issue.

What are the other people using for their ADSB feed to link their iFLY to?

 

[Rhino]

Not sure. I haven't seen it mentioned in a while (or my memory stinks). But a search here can give you some older threads about it.

 

[ve0kog]

I searched and don't see too many iFly references. had some problems with the Dynon relayed traffic as well and bit the bullet and bought GDL50 and a GP subscription to have an independent and more informative TargetTrend (tnx @RV8JD ) traffic view from what's already shown on the Dynon screen. Solved all of the problems at once for approx 1 aviation unit. I really like the TrafficAssist idea as well - may be Dynon could license the code and build a dedicate traffic page. that is a long shot though.

 

[Rhino]

There aren't that many, but there are some there. At the very least, they might identify members who could be contacted with more direct questions.