Add support for Planefinder's proprietary protocol (port 30054)

[mikeage]

This PR adds support for Planefinder's device, which outputs a custom protocol on port 30054 (tcp). The protocol wraps Mode S and Mode A/C messages in their own header, which adds a nanosecond accurate timestamp.

The format itself is documented in the comments.

The following tasks are still outstanding:

• [ ] Decide if we should parse the nanosecond field (the device has a GPS receiver, so it's clock should be very precise)
• [x] Understand the CRC field
• [ ] Add runtime switchable debug prints (I need an example of a function that has a proper level of debug traces to know what prints to include)
• [ ] Cleanup the git commits (unless you plan to squash instead of merging)

[mikeage]

Regarding the CRC, and message parsing in general, I have this comparison. I have two devices with antennas side by side; the planefinder device, and a flightfeeder. If I run for 10 seconds, with the --stats option, this is what I see (these tests were done sequentially, not simultaneously, so there may be some small differences):

Flightfeeder, for reference (using beast_in):

  5972 Mode S messages received
    57 with bad message format or invalid CRC
    2074 with unrecognized ICAO address
    3841 accepted with correct CRC
    0 accepted with 1-bit error repaired

Planefinder, parsing everything (this code):

  12699 Mode S messages received
    4590 with bad message format or invalid CRC
    4055 with unrecognized ICAO address
    4036 accepted with correct CRC
    18 accepted with 1-bit error repaired

Planefinder, if I drop every message that doesn't have the CRC bit set:

  1480 Mode S messages received
    0 with bad message format or invalid CRC
    0 with unrecognized ICAO address
    1480 accepted with correct CRC
    0 accepted with 1-bit error repaired

So it looks like the CRC bit guarantees good data, but even without it, there are many messages that are parsed correctly. I don't know enough about how the Mode S parsing looks to be able to say what to do.

Tracks from both devices look similar, and the antennas are side by side (about 40cm apart), so I would expect very similar performance, or at least within 20% or so.

[mikeage]

They asked me not to check in the spec document that they sent via email, but they didn't ask for an NDA or anything like that, and I assume it's not a problem for me to forward you the email if you'd like.

[gvanem]

This PR looks interesting. How can I test it? Is it this API that it uses: https://planefinder.net/commercial-services Looks expensive....

[wiedehopf]

it's for ppl with the planefinder receiver boxes not for some API

[gvanem]

So this binary protocol comes out of this box only? Is it the same data that goes to PlaneFinder's servers?

[mikeage]

The traffic to PF is TLS encrypted, and, IIRC, they use SSL certificate validation, so it's hard to say what it is.

(though if you want to poke around at it, if you live in an area they don't cover, they will send free receivers, just like FA and FR24... https://planefinder.net/coverage/free-receiver )

[gvanem]

Okay, thanks for the info.