ADS-B over WiFi

[BradThePilot]

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?

 

[SV_Classic]

Good on you for figuring this stuff out!

 

[chriscalandro]

You did this in wireshark? Can you share the data?

 

[BradThePilot]

You did this in wireshark? Can you share the data?

Wireshark is a great tool, but no - this was done using custom software that can also unicast ADS-B data back out. Code is not shareable.

 

[chriscalandro]

Your saying the software captures the multicast then just retransmits it as a unicast?

I can write that in about 10 minutes. I’m not interested in your code.

I’m interested in your pcap.

 

[BradThePilot]

Your saying the software captures the multicast then just retransmits it as a unicast?

I can write that in about 10 minutes. I’m not interested in your code.

I’m interested in your pcap.

It does more than that. But honestly, running WS and capturing the data is trivial and if you could write something yourself so quickly, why not just do that?

 

[chriscalandro]

Because it’s 8degrees here and it sounded like you already had the data I wanted.

Which like you said is easily available. So why go freeze?

 

[BradThePilot]

Because it’s 8degrees here and it sounded like you already had the data I wanted.

Which like you said is easily available. So why go freeze?

Well, it's -11 degrees here .

The code is running on an embedded board for prototyping. Later this week or early next after I finish a work trip, it's going to start passing all the UDP port 4000 data to my IFD540 while injecting heartbeat messages at the appropriate time. I pretty strongly suspect that will show ADS-B data on the IFD. We will see.

 

[chriscalandro]

Well that’s exactly what I was going to do….

My understanding of the problem was the extended format. The Avidyne only wants the standard format (or something along those lines)

That’s why the sentry also doesn't work.

 

[BradThePilot]

Well that’s exactly what I was going to do….

My understanding of the problem was the extended format. The Avidyne only wants the standard format (or something along those lines)

That’s why the sentry also doesn't work.

Not sure where talk of the "extended" format comes from, nor have I seen anything official on such a thing. Stratux has their own custom packets, and ForeFlight does it's multicast to tell anything listening that it exists, but I'm not aware of anything else. Do you have a reference?

The only thing I've found to be "non-standard" coming out of the Dynon is the missing message types. Otherwise, the rest of it appears to be plain old GDL-90. If it turns out that such is not the case, it shouldn't be hard to tweak it and re-send it.

 

[chriscalandro]

The ifd only accepts standard capstone and none of the extended versions. (I don’t remember where I read this, maybe Avidyne support told me).

You need to capture the data and reshape it into the standard capstone.

 

[BradThePilot]

The ifd only accepts standard capstone and none of the extended versions. (I don’t remember where I read this, maybe Avidyne support told me).

You need to capture the data and reshape it into the standard capstone.

Well, as I mentioned, Dynon's traffic report and uplink messages appear to be standard capstone/GDL-90. It doesn't appear that there is anything "extended" about what Dynon is putting out, only a couple of missing pieces that are required by the capstone/GDL-90 protocol.

 

[chriscalandro]

Well let me know what you find. It’s been cold and I have a bunch of esp32s and stm32 variants. I was going to try to put something together.

My plan was to just output standard capstone with variables shaped from the incoming Dynon data

 

[ve0kog]

The code is running on an embedded board for prototyping. Later this week or early next after I finish a work trip, it's going to start passing all the UDP port 4000 data to my IFD540 while injecting heartbeat messages at the appropriate time

this is great. I remember using socat in 2012 to modify a UDP network stream on the fly by passing it through a perl script. no specialiazed hardware required. example:

socat -u UDP4-RECV:50000,reuseaddr,ip-add-membership=238.255.0.2:192.168.123.132 exec:/home/v/strip.nth.byte.pl | socat -b 2048 -u - UDP4-SENDTO:localhost:50002

I'd probably update the Dynon to the latest versions of everything first. Who knows if the format of the packets has changed or the GDL missing pieces were already added..

 

[BradThePilot]

this is great. I remember using socat in 2012 to modify a UDP network stream on the fly by passing it through a perl script. no specialiazed hardware required. example:


I'd probably update the Dynon to the latest versions of everything first. Who knows if the format of the packets has changed or the GDL missing pieces were already added..

I already have the latest versions of everything for my hardware. Upgrading to an HDX a month or so, but there has been no published changes there (and potentially a step backwards with respect to WiFi).

Your socat example might not have required custom hardware, but if I move forward with this approach I'm not going to have a laptop or even a SBC doing it. I'll custom design a board around a microcontroller to minimize space/weight/power/etc.

 

[BradThePilot]

The code is running on an embedded board for prototyping. Later this week or early next after I finish a work trip, it's going to start passing all the UDP port 4000 data to my IFD540 while injecting heartbeat messages at the appropriate time. I pretty strongly suspect that will show ADS-B data on the IFD. We will see.

As suspected, simply adding the heartbeat message while passing everything else through works - both traffic and weather shows up on my IFD. The notion of some kind of "extended" protocol is simply incorrect.

 

[chriscalandro]

As suspected, simply adding the heartbeat message while passing everything else through works - both traffic and weather shows up on my IFD. The notion of some kind of "extended" protocol is simply incorrect.

That was based on what the Avidyne rep told me. I never looked myself.

Does it not send a heartbeat at all? Or just irregular intervals?

 

[kurtfly]

That is great news Brad. I would be interested in this also. I have a HDX and a IFD 540. Could not get the SV ADSB data on the IFD.

kurt

 

[chriscalandro]

I don’t think this is a hardware need or a problem that needs a hardware solution.

We just need @Dynon to fix their ADSB WiFi implementation.

 

[ve0kog]

I don’t think this is a hardware need or a problem that needs a hardware solution.

if all you have is a hammer... it is a pretty impressive problem solving effort! Dynon mentioned that they are not necessarily computer networking experts so I'm sure they will appreciate the details on how to address the issue.