Support Stratux.

[Determinant]

This PR enables using dump1090-fa in Stratux.

I like this project and appreciate the effort made by FlightAware to continuously improve the well-known dump1090 code base. I hope that I can use it as the drop-in replacement on my Stratux build, because the patched version of dump1090 repo shipped in stratux is very out of date.

[mutability]

Where's the code that processes this data? Is there some documentation of the format it expects?

[Determinant]

Stratux's go implementation processes the data generated at port 30006, in the given format that I implemented. One contributor already did some preliminary test and reported that it works fine: cyoung/stratux#811.

Stratux is a very popular system used by pilots to build their own ads-b/gnss/ahrs device that could feed real-time data to apps like Foreflight. It is considered extremely useful by pilots.

https://github.com/cyoung/stratux/blob/master/main/sdr.go is the file that invokes the dump1090 binary.

https://github.com/cyoung/stratux/blob/master/main/traffic.go#L77 is the specification for the JSON format accepted by stratux, which corresponds to the content the TCP output function generates using sprintf.

EDIT: the code in this PR is based on the stratux official one here: https://github.com/stratux/dump1090/tree/9a4fb850937565cfeadd1e5889cddbf93f45faf5

[mutability]

30006 has historically been used for other formats (I believe Basestation uses it) so probably this should default to off (i.e. you must pass --net-stratux-port to enable it)

[Determinant]

Changed the implementation to use NULL as default value for the port string, so net_io.c will not serve stratux requests by default (by checking the port string pointer).

[VirusPilot]

As mentioned above, I have been testing this proposed PR in some Stratux implementations - in fact my own Pi4 Stratux build script is including it as well (see my repo) - it works fine so far so I strongly support this PR.

[mutability]

Haven't forgotten about this one, I'm just trying to find time to review & merge it.

[Determinant]

I'll work on the required changes and test it again on my device when I get time (hopefully this month). (Sorry that I've been kinda busy these days...)

Made the changes according to the review.

[b3nn0]

@Determinant
I'm not a participant of dump1090-fa, but I'm the guy maintaining Stratux Europe Edition. So you don't have to follow my request, but it would be awesome anyway ;-)
Stratux Europe will contain a nice map view in the next version, displaying all traffic from the different sources (1090ES, Flarm, PAW, FANET, UAT). This makes an awesome tool for operators of small airfields.
To even improve this use-case, it's fairly simple to run mlat-client as well to also get mlat traffic. However, the current implementation will not forward the mlat traffic to Stratux.

Would you mind - if @mutability agrees - to remove these few lines from your PR?

    // Don't ever forward mlat messages via Stratux output.
    if (mm->source == SOURCE_MLAT)
        return;

[mutability]

The reason that mlat output is suppressed for some formats is that historically there have been problems with synthesized mlat messages being forwarded in a form where there is nothing to identify them as originating from mlat. Then they end up getting fed back into systems that are expecting off-the-air ADS-B messages and are incorrectly treated as messages from the aircraft, not synthetic positions.

I'd be OK with forwarding mlat to the Stratux format if the messages are unambiguously identified as being sourced from mlat, not off-the-air.

That said, a better approach is to skip the whole synthesize-ADS-B-position-messages step and just feed mlat results directly from mlat-client to stratux (e.g. using the pseudo-basestation output that mlat-client can generate)

[b3nn0]

That said, a better approach is to skip the whole synthesize-ADS-B-position-messages step and just feed mlat results directly from mlat-client to stratux (e.g. using the pseudo-basestation output that mlat-client can generate)

From a technical standpoint, probably. I just don't want to really get into parsing this stuff for such a niche usecase - and since achieving it by just forwarding to the Stratux-output-port is so simple, that was my recommendation.

I don't mind adding an "IsMlat" key to the JSON output. That's the beauty of JSON I guess - so easily extensible without breaking compatibility.

If @Determinant is willing to add this, I'm happy. If not, I might do a pull request with this change separately later on.

[Determinant]

I have the same question as @mutability -- does this introduce additional messages (types) that could confuse Stratux? (i.e. by only removing the if check) Or there is additional change that is required? I'm not an expert in Stratux parsing so could you elaborate on what exact changes you'd like to make? I'm happy to do that.

[b3nn0]

@Determinant no, that shouldn't be a problem.
In a "normal" Stratux setup, it doesn't make a difference at all, because there is no mlat client running anyway.
It just gives the possibility to make use of mlat if someone wants to use Stratux as a base station and manually sets up mlat. Not really applicable for the upstream Stratux, but it is for EU Stratux.

Stratux handles these mlat messages well and displays them accordingly in the web interface (upstream and EU):

Darker blue=ADS-B, light blue is mlat.

[Determinant]

@mutability removed the lines according to @b3nn0 's suggestion and tested it on my device.

[mutability]

I merged this after:

• resolving conflicts and bringing some of the code up to date with recent networking changes
• reverting the mlat change, as there doesn't seem to be a mlat identifier in there yet. This can be reapplied when there's a mlat message identifier included.
• fixing some bugs and hardening the output code to use safe_snprintf / jsonEscapeString

One notable change is that message timestamps are now emitted as UTC; previously they used an ISO8601 format that claimed UTC time (with a trailing Z) but the emitted timestamp was actually local time. I assume the intent here was for it to really be UTC.

I did some basic testing and it seems to emit plausible data but I don't have a real stratux set up to plug it into. Can you try it out and check that it's working OK?

[b3nn0]

Seems to work fine here. Will do some more testing, but I think it's good.