PiAware 5 listening port list for Dump978-fa?

I finally added the 2nd dongle and antenna to add 978 mhz capability to my existing 1090 system. (presentlly PiAware 5). Set the serial numbers and configurations so the correct daemon finds the correct dongle, rebooted, and a few hours later some VFR traffic appeared, although far less in volume than on 1090.

I presently have a logging script running on a different computer in the network, saving whatever comes out of port 30003. This is 1090 mhz data in what looks like .csv style formatting. Several months ago I wrote another little tool to parse these for specific aircraft and then output .csv files with proper headers that could be fed to GPSBabel to convert them into locally generated KML linestrings or GPX files.

Is there an equivalent output from dump978-fa with data similar to port 30003 from dump1090?
So far, picking through assorted posts and some googling yesterday, dump978 seems to have 2 ports it is listening on - 30978 which looks like a whole bunch of hexadecimal characters representing binary (some day I’ll wade into decoding that); and 30979 which puts out a .json format looking block of data per packet received and decoded.

While I probably could just write something to convert the .json fields into a .csv table per specific aircraft decoded, I’m kind of lazy (or is that efficient?) and would really like to find a port that outputs all the fields in a comma separated value format (.csv) from the 978 mhz side of the system.
It really doesn’t matter too much if the fields are in the same order or the same fields as port 30003 from 1090, as GPSBabel (and QGIS) can digest it quite nicely as long as it has consistent headers.

The desire would be to have some kind of standardized format (less coding on my end) from both 978 and 1090 (and empty fields are fine for data not supported by one or the other) that is more compact than the .json style output, so it will take a lot longer to fill up a hard drive or other storage.

Whie zipping .json data on the fly or at intervals when the log files are rotated (on the external computer) does save a lot of space, the uncompressed .csv type data is far easier to work with and archive to look for interesting events weeks or months later.

I probably could set up something like a Python script or even a C++ program to run on the Pi that would just internally connect to port 30979 and translate to .csv cmpatible lines on the fly, then make that available on some port that is unlikely to conflict with future PiAware releases or other stuff (31978 comes to mind as something easy to remember) and just have a “roll your own” .csv output. But I really don’t want to end up with something that turns into a maintenance headache whenever PiAware does future updates.

Any other ideas? Maybe added to a future release? Or is this already implemented but just not documented in a way that is easily searchable?

Finally - is there a “master port list” of all the ones used by all of the PiAware modules - a merged list of all the dump1090 and dump978 ports being used? I found a dump1090 port list from several years and versions of PiAware ago but none dated in 2021, and something about wanting something for dump978 like port 30003 that was posted at least 4 or 5 years ago, but I never found any follow-up since beyond 30978 and 30979.

tl;dr: no. The port 30003 format is extremely limiting (and I got lots of complaints last time I made any changes there - software that uses it tends to be intolerant of any extension to the format) and UAT messages can’t really be mapped to it.

Those are the raw messages (deinterleaved and with error correction applied, but with no further decoding)

This is the closest you’re going to get to port-30003 output, it is as you worked out one json message per decoded message.

Storage is cheap and UAT data rates are low…

30978 and 30979 are the canonical formats. You can rely on 30978 not changing significantly in the future, and 30979 might add fields but I don’t expect existing ones to change.

dump978-fa has a fairly clean separation between the demodulator and the decoder, and already has library code to ingest data from port 30978, so that might be a good starting point if you want to transform the 30978 data into whatever other form. Both skyaware978 and faup978 use this sort of approach.