ADS-B over WiFi

[bspatz]

I've written an Android App called fixGDL that acts as a software-only shim that enriches the Dynon HDX GDL90 stream by adding the missing Heartbeat and Ownship messages, making the resulting stream usable for EFBs/clients expecting compliant GDL90. I've tested this using FltPlan Go, Avare, AvareX, my GDL90 tester, Peter's TrafficAssist, and even my panel IFD440 (after some minor Avidyne IP/Capstone configuration).

fixGDL can run on the same device as the EFB (e.g. listening port 4000 and sending to localhost:43211 for FlightPlan Go and the Lynx:43211 option), or forwarding to a separate device/IP (e.g. IFD440 port 4000). This seems to work well, and with my IFD440, enough to appreciate the 440's winds aloft depiction at selectable altitude capability and wonder why this isn't offered with HDX.

If you are interested in trying this out, and are comfortable with side-loading an Android app, DM me with your email.

This app is actually written in Flutter so in theory it's multi-platform. I'm using Linux (ubuntu) for development but also build for Android on my tablets. There are some corner cases with multiple apps on the same device listening to the same port, and partially depends on the specifics of the EFBs socket semantics (e.g. SO_REUSE{ADDR,PORT}). but I'm studying this. It uses unicast for the relay, but I may try a broadcast option.

Despite additional conversations with Dynon, they seem committed to the status quo. :-( I will share that Avidyne at SnF was very helpful to suggest configurations of my IFD440 for GDL90 over WiFi as part of the Skyview network.

Blue Skies!

 

[ve0kog]

Android App called fixGDL that acts as a software-only shim that enriches the Dynon HDX GDL90 stream by adding the missing Heartbeat and Ownship messages

This is pretty amazing and at the same time disappointing that @Dynon forced you go this far to find your way around the obvious and carefully reported bug.

 

[bleighty]

Just curious is hooking up to a navigator the main use case for this or do not all EFBs have access to the 8384 port data? I'm working on an iOS app and could potentially eventually build in something similar to bspatz's fixGDL but still trying to understand the main pain point this is solving.

 

[kurtfly]

I flew with bspatz fixGDL today and was able to get the skyview ADSB data to display on the IFD.

Thank you Bradley!

 

[bspatz]

Just curious is hooking up to a navigator the main use case for this

The use case is for any EFB or client expecting a compliant GDL90 stream. My use case was for various EFBs like Fltplan Go or Avare[X] that do not work using the native Dynon GDL90 feed, as described throughout this thread. By compliant, I mean with your tax dollar funded Capstone-derived spec per:

https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/adsb/archival/GDL90_Public_ICD_RevA.PDF

But BradThePilot (others) specifically mentioned wanting to use their IFD navigators as the GDL90 client to display traffic and weather. If you have a 5xx series, that extra glass is pretty capable. And I think Avidyne did a good job with their traffic and weather depictions, including winds aloft (missing from Dynon), So the IFD was a good test case, but it's just another GDL90 client to me.

or do not all EFBs have access to the 8384 port data?

Depends what you mean by "access." The data is there on port 8384, but you'll need the proprietary Dynon spec to decode it most likely. And the Google Protobuf spec as well. Regardless, this is not standard like GDL90; see above. I don't know for sure what EFBs like FF, etc. are doing, but they are somehow rectifying the Dynon feed internally -- as I have done with AvareX. But this is a per-client solution at the edge; I wanted a general solution for any GDL90 use case. And, I wanted to know for sure I understood the deficiencies -- and the effort required to fix it -- before pressing Dynon to fix it. No joy.

trying to understand the main pain point this is solving.

As described throughout this thread, the native Dynon GDL90 is missing the Heartbeat and Ownship messages, and most who read the spec consider them required. Many GDL90 clients look for the Heartbeat as a condition to decode the other messages, and Ownship provides the high-quality position of your ship. fixGDL simply rectifies these deficiencies.

I'm also discovering some GDL90 clients may depend on the Ownship Geometric Altitude message as well, as there is diversity in how clients are interpreting and using altitude (pressure vs. GPS-derived), including how they compute "relative altitude" for depicting traffic targets. I've seen diversity even within an EFB. This may be addressed by fixGDL in the future.

Blue Skies!

 

[bleighty]

The use case is for any EFB or client expecting a compliant GDL90 stream. My use case was for various EFBs like Fltplan Go or Avare[X] that do not work using the native Dynon GDL90 feed, as described throughout this thread. By compliant, I mean from your tax dollar funded Capstone-derived spec per:

https://www.faa.gov/sites/faa.gov/files/air_traffic/technology/adsb/archival/GDL90_Public_ICD_RevA.PDF

But BradThePilot (others) specifically mentioned wanting to use their IFD navigators as the GDL90 client to display traffic and weather. If you have a 5xx series, that extra glass is pretty capable. And I think Avidyne did a good job with their traffic and weather depictions, including winds aloft (missing from Dynon), So the IFD was a good test case, but it's just another GDL90 client to me.



Depends what you mean by "access." The data is there on port 8384, but you'll need the proprietary Dynon spec to decode it most likely. And the Google Protobuf spec as well. Regardless, this is not standard like GDL90; see above. I don't know for sure what EFBs like FF, etc. are doing, but they are somehow rectifying the Dynon feed internally -- as I have done with AvareX. But this is a per-client solution at the edge; I wanted a general solution for any GDL90 use case. And, I wanted to know for sure I understood the deficiencies -- and the effort required to fix it -- before pressing Dynon to fix it. No joy.



As described throughout this thread, the native Dynon GDL90 is missing the Heartbeat and Ownship messages, and most who read the spec consider them required. Many GDL90 clients look for the Heartbeat as a condition to decode the other messages, and Ownship provides the high-quality position of your ship. fixGDL simply rectifies these deficiencies.

I'm also discovering some GDL90 clients may depend on the Ownship Geometric Altitude message as well, as there is diversity in how clients are interpreting and using altitude (pressure vs. GPS-derived), including how they compute "relative altitude" for depicting traffic targets. I've seen diversity even within an EFB. This may be addressed by fixGDL in the future.

Blue Skies!

That makes sense. Thanks for the explanation. I'll definitely look to try and include this in my iOS at some point in the future. Regarding winds aloft, I could be wrong but I believe those are shown if you go into an airports info.