NOTE: as of this writing (2019-7-7) the raspberry pi image we generate is not compatible with the RPi 4, and the gr-satnogs package we generate is not compatible with buster. This is a compatibility testing report, not a howto.
That said - this weekend I’ve tested SatNOGS on a Raspberry Pi 4 (2GB), running buster, and it pretty much all works fine. It is currently running on #300 but I’m not sure how long I will leave it in that config as I’m concerned about heat between the pi 4 and the airspy I have with it in the enclosure.
I ran the ansible scripts, minus the gr-satnogs install which is pinned to the older gnuradio dependencies. Everything else works fine.
I built gr-satnogs, no issues there either. In fact, the build time dropped from 4:35 on a rpi3b+ to 2:30 on the 4.
As you can see the rpi4 is pretty bored with the MSK script. The BPSK script will cause it to churn however.
Unfortunately its still not enough to take the full sample rates of the airspy or hackrf, however in my testing I’ve discovered that the overruns are occurring only once the doppler correction block kicks in (prior to that, there are no drops). I set the update frequency very high in the code and it didn’t fix the issue. Something to maybe look into @surligas? With USB 3.0, spyserver on the rpi4 handles the 10M rate just fine.
Don’t let the poor results on #300 reflect on the pi, I’ve been messing with gain settings and the antenna is not ideal at the moment.
So - I think we need to update the gnuradio dependencies pinned in gr-satnogs-package to 3.7.13, and update pi-gen to buster and everything else should run fine! /cc @Acinonyx
I haven’t tried this setup in the rpi3 yet to see if anything breaks, that will come another day.
thanks for the info. I had previously success with the airspy at 10 MSPS with the tinkerboard. I think that the RPi4 is superior, so it should work. Have you done the firmware upgrade on the aisrpy that packs the 12-bit samples?
The other issue that concerns me is the MSK high CPU usage. The BPSK should be more intensive… Can you please run with
top -H to spot the blocks that contribute more to that usage?
The output should be something like:
Threads: 1125 total, 9 running, 1116 sleeping, 0 stopped, 0 zombie
%Cpu(s): 75.3 us, 7.9 sy, 0.0 ni, 16.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 15799.30+total, 926.297 free, 7388.918 used, 7484.086 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 7139.785 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13642 surligas 20 0 3350248 267576 138240 R 99.90 1.654 0:17.23 python2
13679 surligas 20 0 3350248 267576 138240 R 83.33 1.654 0:13.32 fir_filter_ccc9
13681 surligas 20 0 3350248 267576 138240 R 83.33 1.654 0:13.27 fir_filter_ccc8
13666 surligas 20 0 3350248 267576 138240 R 55.56 1.654 0:09.20 fir_filter_ccf7
13668 surligas 20 0 3350248 267576 138240 R 55.56 1.654 0:08.74 dc_blocker_ff14
13661 surligas 20 0 3350248 267576 138240 R 38.89 1.654 0:06.30 quadrature_dem3
13663 surligas 20 0 3350248 267576 138240 S 33.33 1.654 0:05.14 vco_c15
13667 surligas 20 0 3350248 267576 138240 S 22.22 1.654 0:04.54 quadrature_dem3
@surligas Yes, unless there’s another firmware you are referring to:
Firmware Version: AirSpy NOS v1.0.0-rc10-3-g7120e77 2018-04-28
Sorry, I may have mis-represented - the BPSK script was for certain more intensive, the MSK script barely broke 0.5 load
fiewwww! Ok, the BPSK has some serious stuff under the hood. I will try to relax them, while i am trying to increase the sensitivity a bit. Can you please check that
top -H for the BPSK at the Rpi4?