I realized the METEOR M2 is not supported in the standard setup. Why is the reason of that? There are several tutorials to add meteor decoding to SatNOGS so there is plenty of experience to support that out of the box.
The decoder presently relies upon post-processing of the data received. The SatNOGS architecture relies on processing in real-time. It feels like there’s not quite enough horsepower in a Pi to process in real-time but it’s worth analysing:
During Observation 2387319 this morning, I recorded the following CPU load on my Pi 4 just for the flowgraph processing down to soft-symbols:
top - 08:51:52 up 18:08, 3 users, load average: 0.89, 0.29, 0.12
Tasks: 135 total, 1 running, 133 sleeping, 1 stopped, 0 zombie
%Cpu(s): 17.9 us, 4.2 sy, 0.0 ni, 77.4 id, 0.1 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 1939.4 total, 1006.2 free, 285.3 used, 647.9 buff/cache
MiB Swap: 1939.4 total, 1939.4 free, 0.0 used. 1480.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28825 satnogs 20 0 369560 105472 53292 S 72.2 5.3 0:25.63 satnogs_lrpt_de
22736 pi 20 0 57480 13472 9796 S 7.0 0.7 0:18.21 satnogs-monitor
324 hamlib-+ 20 0 26956 6092 2896 S 2.6 0.3 0:21.91 rigctld
22707 pi 20 0 12236 3520 2732 S 2.0 0.2 0:01.21 sshd
22787 root 20 0 0 0 0 I 1.0 0.0 0:01.08 kworker/u8:2-events_unbound
28586 root 20 0 0 0 0 I 1.0 0.0 0:00.21 kworker/u8:3-events_unbound
23319 root 20 0 0 0 0 I 0.7 0.0 0:00.99 kworker/u8:1-brcmf_wq/mmc1:0001:1
10 root 20 0 0 0 0 I 0.3 0.0 0:03.17 rcu_sched
16 root 20 0 0 0 0 S 0.3 0.0 0:00.50 ksoftirqd/1
81 root -51 0 0 0 0 S 0.3 0.0 0:18.69 irq/36-mmc1
332 satnogs 20 0 360668 148036 18228 S 0.3 7.5 2:44.13 satnogs-client
22895 pi 20 0 8884 2564 1276 S 0.3 0.1 0:05.90 bash
23060 pi 20 0 10300 3056 2548 R 0.3 0.2 0:11.19 top
...
Note: this is with 180kHz bandwidth, and the IQ being recorded.
My (well @vk5qi’s) post-processing script failed due to finger-trouble on my part, but running manually it obviously uses as much CPU as it can:
top - 09:41:45 up 18:58, 3 users, load average: 0.41, 0.16, 0.11
Tasks: 133 total, 2 running, 130 sleeping, 1 stopped, 0 zombie
%Cpu(s): 24.2 us, 1.7 sy, 0.0 ni, 74.1 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 1939.4 total, 695.5 free, 347.2 used, 896.8 buff/cache
MiB Swap: 1939.4 total, 1939.4 free, 0.0 used. 1215.8 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6706 satnogs 20 0 101076 100848 152 R 100.0 5.1 0:20.19 medet_arm
6703 pi 20 0 10296 3048 2548 R 0.3 0.2 0:00.08 top
That being said it doesn’t run for long to process a 5m35 pass.
pi@pinog:~/satnogs/meteor $ time sudo -u satnogs ./process_meteor.py
Waiting for 5 seconds before processing.
Attempting to process: /tmp/data_2387319_2020-06-16T08-51-18.s
Total: 55.876305
Processing: 6.691829
Correlation: 0.444239
Viterbi: 45.528801
ECC: 3.202699
Remainder: 0.008737
Packets: 2891 / 2903
Elapsed time: 00:05:27.480
convert-im6.q16: length and filesize do not match `/tmp/meteor_image_temp_vis.bmp' @ warning/bmp.c/ReadBMPImage/839.
Total: 6.691481
Processing: 6.687521
Correlation: 0.000000
Viterbi: 0.000000
ECC: 0.000000
Remainder: 0.003960
Packets: 2891 / 2891
Elapsed time: 00:05:27.480
convert-im6.q16: length and filesize do not match `/tmp/meteor_image_temp_ir.bmp' @ warning/bmp.c/ReadBMPImage/839.
VIS processing successful!
IR processing successful!
real 1m14.571s
user 1m2.550s
sys 0m7.144s
I was initially confused by the medet times, but of course they’re the elapsed time of the pass, not the processing runtime. Read the time values, and note that this covers processing the IR image as well which always seems to be blank so could be suppressed.
So:
-
Flowgraph: 70% CPU. This could possibly be minimised by reducing the bandwidth a little. I increased it to 180 KHz whilst having trouble, but it could probably be dropped back to ~156.25 KHz or even less. Not sure how much difference that will make. Turning off the IQ recording would also likely make a difference, and I can do that now that the flowgraph has a valid output.
-
Decoder: 100% CPU for about 75 seconds of a 335 second pass works out at about 33% CPU. The medet_arm code is in Pascal. I have no idea whether it’s possible to optimise that at all with multithreading, native instructions, etc. I haven’t really looked at it.
Sounds plausible but close to capacity and likely to cause overruns. It doesn’t leave a lot of headroom to run anything else like satnogs-monitor (7% CPU).
How many other signals will need similar post-processing? Is it better to optimise this to run in real time, or to maintain an add-on module that nicely post-processes a few seconds later?
).
, were they generated automatically?