fa-mlat-client 0.2.4 crashes when connecting to local airspy_adsb

[jester-xbmc]

i've confingured piaware to connect to a locally running airspy_adsb (r-pi version 1.1 serving an AVR stream)

02/17/2016 17:56:45 mlat(5300): fa-mlat-client 0.2.4 starting up 02/17/2016 17:56:45 mlat(5300): Using UDP transport to 70.42.6.198:5110 02/17/2016 17:56:45 mlat(5300): Listening for Basestation-format results connection on port 31003 02/17/2016 17:56:45 mlat(5300): Input connected to localhost:30005 02/17/2016 17:56:45 mlat(5300): Unexpected exception on connection to localhost:30005 02/17/2016 17:56:45 mlat(5300): Traceback (most recent call last): 02/17/2016 17:56:45 mlat(5300): File "/usr/lib/python3.2/asyncore.py", line 83, in read 02/17/2016 17:56:45 mlat(5300): File "/usr/lib/python3.2/asyncore.py", line 449, in handle_read_event 02/17/2016 17:56:45 mlat(5300): File "/tmp/buildd/piaware-2.1/debian/venv/lib/python3.2/site-packages/mlat/client/receiver.py", line 129, in handle_read 02/17/2016 17:56:45 mlat(5300): ValueError: Lost sync with input stream: expected a 0x1A marker at offset 0 but found 0x2a instead 02/17/2016 17:56:45 mlat(5300): Lost connection to localhost:30005

[mutability]

Both piaware and fa-mlat-client expect a beast-format stream, not an AVR stream.

[jester-xbmc]

Understood, is there a way you could add reading an AVR stream using piaware-config or otherwise, this would mean people can use their airspy running from a pi to push data to flightware

[mutability]

Newer mlat-clients understand AVR. faup1090 is a bit trickier. You can't produce a Beast stream?

[mutability]

Actually, looking at that error more closely, it is a plain AVR stream with no timestamps, not the avrmlat format, so even with an updated mlat-client it will be no good for mlat.

[jester-xbmc]

Uhm, strange i'm running : airspy_adsb v1.1 with -e (Enable the extended output (MLAT and RSSI))

ping @bvernoux and @touil

[mutability]

The decoder is complaining that the first byte of the stream is 0x2A - this is '*', the standard format with just the message data. The format which has RSSI and timestamp would start with '<'.

Beast-format data is pretty much the de-facto standard these days, I am surprised airspy_adsb can't generate it. If the source for airspy_adsb was available, I would take a look, but a quick search doesn't find it so I suspect it's just another closed-source thing.

[jester-xbmc]

uhm, indeed that seems to be the case,

@bvernoux and @touil can you add beast output ?

[jester-xbmc]

In the mean time, is there a way to tell piaware to connect to a remote dump1090/VRS port ?

[mutability]

Not on the current version of piaware. It's in the next version.

[jester-xbmc]

Perfect, thanks

[jester-xbmc]

btw is this hardcoded? faup1090 --net-bo-ipaddr localhost I can just change it to connect elsewhere ?

[touil]

The software is still experimental but fully usable with PlanePlotter. Currently we use this extended format: *;<32bit MLAT>;<8bit MLAT Frequency>;<16bit RSSI>;

The <8bit MLAT Frequency> tag is the oversampling multiplier: 1 => 2MHz; 2 => 4MHz; … 10 => 20MHz; etc. Zero is an invalid value.

[mutability]

Yep, sure, you can tweak that directly. The change in the next piaware version is just to hook that argument up to the config system so it's easy to change. See https://github.com/flightaware/piaware/blob/dev/programs/piaware/faup1090.tcl#L144

[mutability]

Frankly I doubt I'm going to support yet another format in mlat-client if it's only generated by one piece of closed-source software.

[touil]

Your call.

[mutability]

OK, so airspy_adsb is unsupported for mlat at the moment.

[jester-xbmc]

fast support by @touil , new version with beast support, https://t.co/XwKelfwuL9 (-f beast) however mlat(7442): Problem reading receiver messages: Out of range timestamp seen (last 4142366797, now 553222221) maybe issue like : https://github.com/mutability/mlat-client/issues/1

[mutability]

I think it is generating the timestamps as little-endian; they should be big-endian.