Re: [gpsd-users] New client and ADS-B question

[Cédric]

Hello again Eric,

Thanks to a rainy day, I've been able to answer most of my "unknowns" about ADS-B.

ADS-B data are embedded either in the data stream of Universal Access Transceivers (UAT) or Extended Squitter 1090MHz Mode-S Transponders. As of today, it seems the latter is the most common implementation. In the ES Mode S "squitter" stream, the Downlink Format (DF) n° 17 "container" is the one that holds ADS-B data. The following PDF gives a good overview of the protocol:

    http://www.ssd.dhmi.gov.tr/getBinaryFile.aspx?Type=3&dosyaID=123 ("ADS-B for Dummies")

The binary format of the DF17 container is - I think - relatively easy to interpret, save for the Compact Position Record (CPR) encoding used to transmit longitude/latitude coordinates. Between the two following documents, it should be feasible though:

    http://www.dtic.mil/dtic/tr/fulltext/u2/a402100.pdf ("Encrypted Mode-S ADS-B for Tactical Military Situational Awareness")
    http://adsb.tc.faa.gov/WG3_Meetings/Meeting30/1090-WP30-21-Appendix_A%20Mods.pdf ("Extended Squitter and TIS-B Formats and Coding Definitions")

Based on some research already done on the miniADSB (not to be mistaken with the microADSB) and GNS 5890 receivers, it would seem the output we have on the serial line are raw ADS-B frames:

    www.sprut.de/electronic/pic/projekte/adsb/adsb_en.html
    ("The PC-software receives ADS-B-frames from the decoder (via a virtual COM-port) and decodes the data")

Unless I missed something, I think we have everything we need to crack ADS-B down from the protocol point of view.

I guess that from the coding point of view, a new "adsb_t" type would be needed, constructed much the same way as the "ais_t" type, "unioning" the various Downlink Format (DF) and Type Codes (TC) potentially of interest (though I guess only for DF17 to start with)

Based on that information, would you still be interested in giving it a try from GPSD point of you?
(if yes, I'm more than willing to help you)

Best regards,

Cédric

On 30/09/12 12:33, Cédric wrote:

Hello Eric,

Thanks for answering my question personally!

I personally don't have an ADS-B receiver yet. But if I can be of help
and progress could be made for GPSD, then I might look forwards into
buying one.

The question I haven't succeeded answering yet is what kind of (serial
line) protocol ADS-B devices use, and most importantly, if it is a
standard protocol or if each brand has its own proprietary protocol.
Also, from what I'v been reading here and there, I have the feeling that
we're not talking of anything as "simple" as a NMEA0183-like protocol.

On their blog, the manufacturer of the apparently very cool GNS 5890 USB
receiver claims that they're open to the community
(http://www.blog-ads-b.gns-gmbh.com/?page_id=5#comment-4) but I could
not fight any relevant information on the link they point to
(http://www.5890.gns-gmbh.com/Service.html). The fact that (Windows)
common ADS-B application seem to support it may point to some "de facto"
common protocol (SBS-1?).

Besides, FlightRadar24 just announced a Linux version of their "feed"
software
(forum.flightradar24.com/threads/4270-Linux-feeder-software-for-Flightradar24),
but it is yet unclear with what devices/protocols it will work... and
unfortunately, it seems closed-source (...).

Going through the latest posts about the latter, I stumbled on
http://www.homepages.mcb.net/bones/SBS/Article/Barebones42_Socket_Data.htm
, which details the basics of the (Kinetic Avaiation's) SBS-1 "socket"
protocol.
From which I stumbled on http://www.kinetic-avionics.com/, which says
that their latest SBS-3 is able to decode data both to ADS-B and AIS
mode, from which I (maybe erroneously) conclude: 1. ADS-B seems a
standard message protocol in itself; 2. ADS-B data can somehow be fitted
in the AIS protocol (though I fear with serious limitations)

I also went through:
http://www.hamradioscience.com/the-rtl-2832u-sdr-and-ads-b/
https://github.com/bistromath/gr-air-modes
Which seem the most low-level yet most interesting links on the subject.

Finally, googling for "ADS-B + Linux" raises many mentions of the
microADSB receiver. I haven't suceeded yet in finding relevant
information on that device.

So:

Do you have any idea at which "level" we should try to get into ADS-B?
(I mean should be try at the "lowest" possible level, based on what
could be "contributed" by https://github.com/bistromath/gr-air-modes or
should be satisfy ourselves with "higher" - maybe manufacturer-dependent
- level like SBS-1)

Do you think its worth my investing in a MicroADSB or a GNS 5890 ADS-B
receiver and that we try to get something out of it along with GPSD?

Best,

Cédric


On 29/09/12 20:25, Eric S. Raymond wrote:

Cédric <address@hidden>:

Now, I see ADS-B support has been mentioned in
http://lists.nongnu.org/archive/html/gpsd-dev/2012-06/msg00038.html but
could not find any further information in this regards. May I inquire
what is the status and your plans in regards with ADS-B support?

It's something we'd like to do someday.

What we'd need to go from wish to code is ADS-B test pairs.  A test pair
would consist of 

(a) A sequence of ADS-B packets in whatever native format they use - binary 
blob, AIVDM/AIVDO-style armored packets, whatever.

(b) A known-good decoding of that sequence into an annotated textual form
that I could massage into some sort of conformable JSON.

We'd also need a pointer to the specification for the format used in (a).

With these things, I could probably go from zero to a testable ADS-B 
driver in time on the close order of a week.