stop sample loss on low power hardware

[rtlsdrblog]

As discussed in #600 I noticed that Satdump V1.x wasn't working properly with Elektro-L on the Orange Pi 5, but Satdump 0.0.39 worked fine (actually 1.0.0-alpha works fine too). On other more powerful x64 any version worked fine.

I traced the problem back to two commits. First 9f18f56 where the MAX_SPS value was increased, and secondly to eb4b831 where the rtlsdr_read_async buffer size was changed.

Changing these two values back to what they were before fixes the sample drop issues I'm seeing, and I'm now able to get perfect images on the latest code.

[Aang23]

Thanks for looking into it. I didn't have enough time to dig into your recent updates on L4 yet as I've been busy investigating another (potential) major issue.

This is very interesting - and makes total sense as well. I won't merge it straight away, I'll do some testing today to dig into this further. Does leaving MAX_SPS to 4 still work however?

[rtlsdrblog]

Has to be both changed. MAX_SPS appears to affect the amount of decimation used. I did notice when testing with my workaround involving rtl_tcp, that using rtl_tcp helped tremendously, but setting the decimation value to about 4-5 was required to get perfect images.

The MAX_SPS change is the least disruptive one. But with the buffer problem fixed, It's still impossible to get perfect images with MAX_SPS set to 4.0. But they are mostly minor image glitches, not a fully corrupted image with the wrong buffer size set.

[Aang23]

Could you try with MAX_SPS at 4 and a bigger buffer size? Such as 2 x 16384?

This is mostly to diagnoze the issue. I can't safely set MAX_SPS to 4 everywhere, but I will most likely be making this configurable on the fly and set it for all GEO downlinks. The buffer size issue is a very good find, easily going un-noticed on x86 hardware. However instead of having it static at 16384 I'll likely change the math to not be so inefficient for low-power platforms.

It all makes sense though. A very small buffer => Less SIMD utilization and more memory copy. I'm gonna investigate how much things can be improved.

[rtlsdrblog]

Just tested with MAX_SPS= 4, and 32768 and 65536 for the buffer_size, but I still get a glitched image sometimes. I think it is less often than with 16384 though.

[Aang23]

Ok. Thanks for the information! I'll fix this. Might not merge this, but I'll do a similar patch.

[rtlsdrblog]

Thanks!

[Aang23]

@rtlsdrblog everything related to this should be fixed - see the 2 last commits.

Would you mind testing and perhaps showing me how CPU Usage looks in htop during reception? I'm just curious to see, in case it gives me other ideas.

[rtlsdrblog]

Thanks, seems to be working well now, getting perfect images like on V0.0.39.

Attached is a htop screen. This is on an Orange Pi 5, and aarch64 OS.

Would be curious if these buffer fixes solve the problems @pluggerlockett was having on his Pi 3 with the satdump CLI too. I plan on testing a Raspberry Pi 4 and Raspberry Pi 5 with Satdump soon as well. Previously I was able to get Satdump GUI running on a Raspberry Pi 4 but it was quite sluggish, so probably still need the CLI there. But on the Raspberry Pi 5 the GUI should be fine like it is on the Orange Pi 5.