flightaware / dump978

FlightAware's 978MHz UAT demodulator
BSD 2-Clause "Simplified" License
39 stars 16 forks source link

Feature request: support for `--net-heartbeat <secs>` #19

Open kx1t opened 1 year ago

kx1t commented 1 year ago

In areas with low UAT traffic, the data stream dump978 (raw) -> uat2esnt -> readsb will disconnect when there's no traffic after a while. This is causing a lot of connects / disconnects that are visible in the logs.

Would it be possible to add a heartbeat option that keeps the data connection open? Ideally, this would be exposed through a command line option like --net-heartbeat <secs>, where the heartbeat is off if this is not included on the command line.

Tnx!

mutability commented 1 year ago

Which connection is disconnecting?

YipYup commented 1 year ago

I'm not any expert by any means, and perhaps kx1t can help clarify, but here's the issue I logged on the downstream project.

https://github.com/sdr-enthusiasts/docker-dump978/issues/65

mutability commented 1 year ago

The reason that I ask is that

a) I'm not clear how exactly your pipeline is working (legacy uat2esnt operates as a pipe, how are you turning that into network connections); b) if it's the uat2esnt -> readsb connection that is reconnecting, then that's where the heartbeat needs to be, i.e. dump978 changes wouldn't do anything

kx1t commented 1 year ago

Sorry for the delay… the reason is that we upgraded our pipeline (took bit of time) and that we are now connecting straight from dump978 using that program’s raw output to Wiedehopf’s branch of readsb using the (new) uat_in net-connector option of that branch of readsb. No more uat2esnt. Works great, except for the connection time-outs in no-traffic hours :)

So the heartbeat should be implemented in dump978.

mutability commented 1 year ago

Okay. What's your proposed message format for a heartbeat (readsb will obviously need to handle this too)

kx1t commented 1 year ago

the same message format that is used in W's readsb fork -- see https://github.com/search?q=repo%3Awiedehopf%2Freadsb%20heartbeat&type=code

(I think the message format is here: https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L105-L107 but the rest of the search shows you how it's implemented in readsb)

Thanks :)

mutability commented 1 year ago

Those heartbeats are for other protocols - AVR, Beast, SBS. They won't directly work with the dump978 raw-UAT format.

I could just pick something, but then readsb would likely break when it hears it. This needs coordination between the two ends to agree on what the heartbeat should look like.

kx1t commented 1 year ago

eh... line 106...

static const char raw_heartbeat_msg[] = "*0000;\n";

Isn't that for raw?

mutability commented 1 year ago

That is the AVR-style "raw" connection for 1090MHz data: https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L947

UAT is here (note "no_heartbeat" currently, but that's actually a red herring anyway since IIRC it is output-side-only): https://github.com/wiedehopf/readsb/blob/c4a0e401d12b7e0c545eee20794abf940b5893bd/net_io.c#L964

wiedehopf commented 1 year ago

readsb has the same code as uat2esnt ;)

Pretty sure nothing will break readsb and i can implement whatever you think is best.

wiedehopf commented 1 year ago

In doubt just propose something here and i'll look at the readsb code ... or maybe upload a sample output from the network and i can feed it in with socat and test.