Improve filtering of crosstalk duplicates

[wiedehopf]

It seems you can rather easily get some duplicates when monitoring multiple frequencies.

As in i'm getting a message on 131.725 with -7 dBFS and then get a duplicate on 131.850 with the same timestamp and -39 dBFS

This of cours would mean you need to hold messages before emitting them and then within some timeframe check for duplicates and maybe just chose the one with the least errors / highest RSSI.

[wiedehopf]

Most of the people at sdr-E are using acars_router to deal with messages.

dumpvdl2 seems to have similar dupes.
So we might try and add some deduplication in acars_router to deal with both.

[f00b4r0]

It seems you can rather easily get some duplicates when monitoring multiple frequencies.

As in i'm getting a message on 131.725 with -7 dBFS and then get a duplicate on 131.850 with the same timestamp and -39 dBFS

Yes I'm well aware. That's IMO a consequence of an inadequate filtering on the radio signal which I still mean to improve.
This is a problem inherited from the original codebase.

This of cours would mean you need to hold messages before emitting them and then within some timeframe check for duplicates and maybe just chose the one with the least errors / highest RSSI.

Not the right way to deal with that, as it would increase memory and CPU load and be prone to runaway: these signals must be eliminated at the demodulation stage, by adequate filtering.

The main issue here is that I haven't yet fully wrapped my head around the MSK demodulation code so I'm hesitant to make changes there. I'll get to it eventually.

[DickvanNoort]

In dumpvdl2 the message from the wrong frequency always has a much higher PPM than the real/correct one.
So as a quick/dirty and 'cheap' fix you might ignore messages with a PPM that is much higher than the average one.

Just a thought.

Cheers,
Dick

[dcwar]

Hello! As an additional data point on this issue: with acarsdec 3.7, duplicate messages are almost exclusively aircraft pings (both air-to-ground and vice versa). When I recently tested v4.3, I noticed similar behavior.