Welcome to an issue that’s been ongoing for a while…
Yep, the latest versions of the demodulators are returning a lot of false positives. Whether this is because we’re getting valid hits on the frame CRC (which is a CRC16) or for some other reason I’m not sure, but its certainly a pain.
The fact that observations are being marked good by default when packets are received, without any validation of those packets results in confusion. (Note - I’ve marked this particular observation as bad)
Callsign validation won’t really help, since there are many other packet formats that don’t use callsigns in any useful way.
What needs to happen is for all the packets to be immediately run through a corresponding decoder, and then if they fail to decode, either flag them, or delete them. This is something that needs to be fed from the packet decoding stage back into network, and this isn’t happening at the moment.
Unfortunately, the above requires there to be a decoder for the satellite in question… I’m unsure how the above would be handled if there was no decoder available. We don’t have packet formats for every satellite in the DB…
I am still very surprised at the amount of false positives we are seeing in the new decoders.
I haven’t run the numbers to work out how often we would statistically expect to get false positive packets if we feed the packet decoding code and CRC16 with noise (which I guess is what is happening here).
Maybe @surligas or @EA4GPZ can run the math on that one.
But AX.25 requires callsigns to be specific characters. This can be exploited. For example bad or invalid data might have “)” in the call sign. There are still might be false positives, but this would be a huge improvement.