Observation 2968725: BUGSAT-1 (40014)

Satellites & Observations Observations
1

Regarding Observation 2968725 …

My data shows 21 packets but none of them look like the packets from other receivers and the waterfall shows no data. Could this been caused by activating the experimental settings ?

Thanks,
Ben

2

Hi Ben,

for me it looks like the signals are not from Bugsat-1. The signals should always be visible around the 0 kHz centerline, just because of the doppler correction.

Look at my observation https://network.satnogs.org/observations/2967380/

Here https://network.satnogs.org/observations/2970912/ you can see the effect of doppler correction by the curved lines, obviously local qrm.

73, DL8LAQ

3

Those packets are all clearly garbage from the demodulator. There have been changes in the flowgraphs or gr-satnogs which have made the demodulator more ‘sensitive’, but this has resulted in a lot of false-positive packets. I’m unsure what exactly the changes are.

What I’m still not 100% sure about is if these packets are actually passing the AX.25 Frame Check (CRC16), and the amount we are seeing in a typical observation of the new decoder lines up with what we would expect from pushing random noise into the decoder. @surligas might be able to explain more.

There’s been a lot of discussion on IRC around how to deal with these packets. A few thoughts include:

  • Look into some way of thresholding bits out of the demodulator based on estimated SNR, since there is a theoretical SNR threshold at which is is extremely unlikely a FSK/PSK demodulator is going to work at anyway (Unsure if this is possible with the way the current demod works).
  • Check the CRC calculations are correct. They probably are… but I’d really like to know if those ‘garbage’ packets are actually passing the CRC16.
  • Accept all garbage packets, but pass them through additional checks when they go into the db (running them through the related decoder) and flag them as invalid if they do not decode correctly. The problem here is if we get a garbage packet that passes the Frame Check, is the ‘expected’ packet length, and does not have any other checksum within it, we may end up with bogus data in the db.
1 Like
4

Thanks Mark, just my thoughts that I was indeed filling the database with bogus.

But could this been started after enabling Xperimental in the satnogs-setup or has is nothing to do with that ? I had it disabled last night, now cleaned the /tmp/cache and rescheduled some passes to check.

73’

Ben