BPSK and FSK AX.100 Mode 5 1200 failed decodes - lost samples

SatNOGS Software
1

Hi!
I’m trying to get observation from Greencube to work - FSK AX.100 Mode 5 1200.
For example this observation:
https://network.satnogs.org/observations/7749140/

But the status is Failed. I have set the debug level to DEBUG but I see no errors at all after the observation. So I’m kind of lost. Not sure where to start looking. I would be nice to see some error in the log…

/Lars SM0TGU

2

The failed status comes from the difference between the audio artifact duration (10min 33s) and the scheduled duration (12min). When this difference is more than 1min, network automatically mark the observation as failed.

This difference usually happens when there are lost samples, samples that the cpu can not handle. The reason behind that tends to be a high sample rate or high cpu temperature that force cpu to run in lower frequency and lose samples or not good power supply which has the same effect as the high temperature on cpu.

3

Thank you Fredy.
I have finally found something in the logs:
SoapyAirspy::rx_callback: ringbuffer write timeout

Yes, I’m using the SoapyAirspy driver. It seems to happen on some odd modes and for “FSK AX.100 Mode 5 1200”. All other modes seams OK.

1 Like
4

I had a look at one of my GREENCUBE observation to see if I experience the same.

This is with an Airspy R2 running at 2.5msps and I don’t see any ringbuffer errors.

Log:

Jun 22 13:13:48 exomars satnogs-client[299447]: gr-satellites: Observation: 7741229, Norad: 53106, Name: 0_MT-CUBE-2, Script: satnogs_fsk.py
Jun 22 13:13:48 exomars satnogs-client[299447]: gr-satellites: Starting observation 7741229
Jun 22 13:13:49 exomars satnogs-client[299447]: gr-satellites: running at 48000 sps
Jun 22 13:13:49 exomars satnogs-client[569]: rig_init: rig does not have rx_range!!
Jun 22 13:13:49 exomars satnogs-client[569]: network_open: hoststr=127.0.0.1, portstr=4535
Jun 22 13:13:51 exomars satnogs-client[299484]: [INFO] Using format CF32.
Jun 22 13:25:48 exomars satnogs-client[569]: netrigctl_close: done status=Command completed successfully
Jun 22 13:25:51 exomars satnogs-client[299717]: gr-satellites: Observation: 7741229, Norad: 53106, Name: 0_MT-CUBE-2, Script: satnogs_fsk.py
Jun 22 13:25:51 exomars satnogs-client[299717]: gr-satellites: Stopping observation 7741229
Jun 22 13:26:31 exomars satnogs-client[299736]:   adding: iq_48000_7741229.raw (deflated 58%)
Jun 22 13:26:32 exomars satnogs-client[299736]: test of /export/raw/iq_48000_7741229.raw.zip OK

Are you still using the experimental Sopay Airspy drivers?

1 Like
5

Correct, I’m using the experimental Soapy Airspy driver.

1 Like
6

Look at this observation. No problem at all with BPSK 1200 (Funcube)

7

I have scheduled a couple of high passes on your station, lets see if we can get some better SNR

8

Sorry I have the station connected to a disconne antenna so for UHF there will be very low signal levels. On VHF it performs very good. Several good Funcube passes with decodes since yesterday.

I have scheduled a couple of high passes on your station, lets see if we can get some better SNR

9

So the initial obs mentioned in this post is connected to a disconne ?

image
image855×362 75.6 KB

10

No. I switched to 13 element tracking yagi for that observation. But the “ringbuffer write timeout” should be present (or not present) regardless of what antenna to use, or?

1 Like
11

I’m continuing this thread as I have this problem with many of my BPSK 1200 observations (and also some other decoders) - lost samples that results in failed status, but the waterfall is uploaded. I’m running a RPI 3 and Airspy Mini with 3.000 MSPS.

I have tried a lot, for example the following:

  • Switched power cable and supply for the RPI.
  • Changed USB ports
  • Tested the speed for the Airspy Mini with airspy_rx and it shows 3.000 MPPS without any problem
  • Removed the new soapy Airspy driver and satnogs_gr-satellites - result is the same (no improvement)
  • Has run the volk_profile
  • Has tried Airspy packing

I also checked the CPU load during an observation with htop and I see that one CPU core is always at 100% during an observation with satnogs_bpsk.py.

So I do not know what to do now. Should I changed my Raspberry PI v3 to a Raspberry PI v4 to get better performance?

12

Did you also run volk_profile as satnogs user ?

sudo -H -u satnogs volk_profile

As suggested in another posting, did you try the airspy packing?

13

sudo -H -u satnogs volk_profile
As suggested in another posting, did you try the airspy packing?

Yes, I have tested packing and run the volk_profile. No improvement.

14

did you run volk_profile as the satnogs user ?

15

Yes, i run sudo -H -u satnogs volk_profile

1 Like
16

I have upgraded to a RPI 4 and no problems at all now with lost samples.

2 Likes
17

Just would like to add one thing - the old RPI3 I put a RTL-SDR v3 with sample rate 2.048e6, same installation as before. Now it’s working perfect, for example this observation with Funcube-1
https://network.satnogs.org/observations/7932761/

2 Likes