Working ... almost ... on RPI4, getting funny glitches about 1/s

[sludtke42]

First, really have to thank the authors for this excellent program. It's a great replacement for GQRX! I had a Lime Mini and a RPi4 with a 7" touchscreen laying around and had the idea to set it up as a portable SDR system. I got the Lime working with the Pi pretty easily, and I got sdrangel compiled and running pretty easily as well, even with a 5-10 MB data rate, but...

As a simple test, I tuned to a local FM radio station and set it up for WFM decoding. Waterfall looks great, but about once a second there is a ~50ms pause in the waterfall and a corresponding glitch in the audio. Roughly every 3 seconds I get a report of overflow with a few lost packets. The Pi4 (which has 4 cores) reports ~230% CPU when it's running, so clearly it's doing a lot of work in threads, but isn't fully saturating the CPU. Even if I drop the read rate to 2 MB, the problem is the same.

So, I'm trying to track down where this once a second glitch is coming from. It's possible that it's something happening at the OS/board level. Some sort of NMI which is blocking the USB input or something, but it could also be some sort of timer-triggered event in sdrangel. So before I go digging through the complete source code, I thought I'd see if anyone had any ideas.

TIA! -- steve (N0EEK)

[sludtke42]

Ok, I may have found the solution myself, but will throw it out there for comments. I had been running on a 4k display and didn't even notice that there was a clock in the lower right corner of the status bar in the GUI. This clock was tied to a 1s timer event, and due to the way Qt works, this was throwing off the 'high precision' timer. As a test, I just disabled the 1 second timer in the c++ code, and voila, a smooth waterfall and good sound decoding! The caveat is that the highest bandwidth I can achieve without overflows, with 1k FFTs seems to be about 3.5 MS/s, but I'm not too disappointed by that. That's a pretty decent bandwidth to cover with SDR on a RPi!

Anyway, I'd ask the developers to consider adding a compile-time option to remove the clock display from the status bar, or maybe just flat out remove it. I think everybody probably has other clocks...

cheers

[ON7KGK]

Hello Steve, I would like to run with the same setup (rpi4,screen 7",limemini,sdrangel). It would be helpful if you could give me how do you install sdrangel and os version My aim is to monitor a new 10 GHz beacon 50 kms away. Thank you 73's from ON7KGK Michaël Belgium

[f4exb]

The GUI version is not supposed to run on RPi any version so no changes for me.

[ON7KGK]

Thank you for you reply about the GUI support. What is the best setup to run the server version on the rpi4 so no GUI. A Docker image ?

[f4exb]

Yes Docker is the way to go. Since armv8 has no variants I have published some images that can be pulled from docker.io: https://hub.docker.com/r/f4exb06/sdrangelsrv/tags

If you want to build an image yourself which is entirely feasible on a RPi4 with 4 GB RAM you can check this repositioy: https://github.com/f4exb/sdrangel-docker

[sludtke42]

While you may not have intended to enable GUI support directly on the Pi, on a Pi4 it is, indeed, possible. Certainly it doesn't perform as well as it does on a desktop, and I might not try and use the video module, but for basic viewing of the waterfall and AM or FM decoding it really seems to work quite well up to 3.5 MS/s. That is, as long as the clock display is disabled :^)

I decided setting up Docker on the pi would be more trouble than simply compiling the dependencies myself, so I went that route. There are really only 5 of them you can't get via apt-get. Took a couple of hours to sort out, but not nightmarishly difficult or anything. I'll add that my Pi4 has only 2G, and seems fine for my purposes.

Steven Ludtke, Ph.D. <sludtke@bcm.edu mailto:sludtke@bcm.edu> Baylor College of Medicine Charles C. Bell Jr., Professor of Structural Biology Dept. of Biochemistry and Molecular Biology (www.bcm.edu/biochem http://www.bcm.edu/biochem) Academic Director, CryoEM Core (cryoem.bcm.edu http://cryoem.bcm.edu/) Co-Director CIBR Center (www.bcm.edu/research/cibr http://www.bcm.edu/research/cibr)

On Dec 11, 2019, at 4:35 PM, f4exb notifications@github.com wrote:

Yes Docker is the way to go. Since armv8 has no variants I have published some images that can be pulled from docker.io: https://hub.docker.com/r/f4exb06/sdrangelsrv/tags https://hub.docker.com/r/f4exb06/sdrangelsrv/tags If you want to build an image yourself which is entirely feasible on a RPi4 with 4 GB RAM you can check this repositioy: https://github.com/f4exb/sdrangel-docker https://github.com/f4exb/sdrangel-docker — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel/issues/453?email_source=notifications&email_token=ACPKF2SQTPX6CR5P3RRZW7LQYFTKHA5CNFSM4JZHY7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGUZ5JA#issuecomment-564764324, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPKF2RLYZJFJP4QTUAS7ZTQYFTKHANCNFSM4JZHY7CQ.

[f4exb]

If you think docker pull f4exb06/sdrangelsrv:v4.12.1 is a complex operation then I cannot say more... Sure you have to install Docker and know a few commands but this is not difficult really. There is a run.sh script that does the launching for you with defaults that let you run it without many options in most cases.

You say that the CPU is ~230% that is slightly over 50% total on a 4 CPU core. Well this is a lot because you have to account for some headroom to keep the CPU reactive enough for a near real time application like SDRangel. Then I am not surprised that a 1s timer becomes an issue. Issue is with the hardware setup and not with the code.

Another few things:

• Do you run on a armv8 (aka aarch64) O/S? There is a ~2x difference in performance btw the software running on an armv7 O/S (like Raspbian) and an armv8 O/S (like Ubuntu)
• Are you sure the GPU acceleration is active and not emulated? The server variant in a simple configuration like 1 Rx and 1 channel would run at ~30% CPU compared to the ~230% you report. This is a huge difference just to run graphics.

[sludtke42]

Please don't get me wrong. I'm not complaining at all! I absolutely agree that running the sdrangel GUI on a RPi is a borderline in terms of RPi capabilities, and I was pleasantly surprised how well it did work!

I am also not suggesting that there is anything 'wrong' with the code. The bits I've looked at are extremely well coded, and I found it unusually easy to follow. To a large extent I suspect the minor issue I encountered is related to how Qt5 event loop works (I've been doing Qt programming for 15+ years). It really wasn't ever designed for real-time activities, and can only handle them with significantly over-powered CPUs. The timer event really just triggers an entry into the event loop, so I suspect what's happening (though I clearly haven't read all of the code) is that the 1 second event is taking more than 50 ms to complete on the RPi, which causes it to miss the next 'high precision' event, since the event loop is single threaded. The fact that updating a clock display could take more than 50ms, definitely says something about the Pi's capabilities :^)

Of course this also means that other more 'demanding' tasks, like pressing a button in the GUI will also cause 50ms timer glitches on the Pi, but when you're pressing a button you don't really notice the glitch. When it happens once/second the issue is clear. Obviously it doesn't happen at all on my desktop machine.

The only reason for my interest in this project was to have a portable (hand carried) system for using the Lime-Mini to explore antenna placement issues. While I could buy a cheap laptop and do something similar, it seems like that would be a much more awkward setup to carry around, and if the RPi can do it with a 3-D printed case, well, why not...

Regarding docker, I'm just old school. I generally prefer to see how all of the pieces and dependencies are put together, in case I have to debug anything. Note that I didn't ask any questions about my non-docker installation process. I've actually been a little curious about how well Docker would do on something like a Pi with a real-time application, where even a little latency could cause big issues. Maybe I'll give Docker a try as well and see whether there is any difference at runtime. I realize that in general it provides very nearly native performance. However with a real-time system, the extra layer of context switching may have an impact? Anyway, if I see anything interesting I'll report back.

---

Steven Ludtke, Ph.D. sludtke@bcm.edu Baylor College of Medicine Charles C. Bell Jr., Professor of Structural Biology Dept. of Biochemistry and Molecular Biology (www.bcm.edu/biochem) Academic Director, CryoEM Core (cryoem.bcm.edu) Co-Director CIBR Center (www.bcm.edu/research/cibr)

On Dec 12, 2019, at 12:30 AM, f4exb notifications@github.com wrote:

If you think docker pull f4exb06/sdrangelsrv:v4.12.1 is a complex operation then I cannot say more... Sure you have to install Docker and know a few commands but this is not difficult really. There is a run.sh script that does the launching for you with defaults that let you run it without many options in most cases.

You say that the CPU is ~230% that is slightly over 50% total on a 4 CPU core. Well this is a lot because you have to account for some headroom to keep the CPU reactive enough for a near real time application like SDRangel. Then I am not surprised that a 1s timer becomes an issue. Issue is with the hardware setup and not with the code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel/issues/453?email_source=notifications&email_token=ACPKF2TACI7LFZSCTCY327LQYHK7FA5CNFSM4JZHY7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGVTVHY#issuecomment-564869791, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPKF2WFWPMLJ636IO5YZB3QYHK7FANCNFSM4JZHY7CQ.

[f4exb]

To be honest depending on where you look in the code the cleanliness and readability can vary. After a few years of development over an existing base it has passed through a few layers of design and redesign. Hopefully in the next version the channel plugins code will be improved by reworking some bad design around the ThreadedBasebandSampleSink class that is going to disappear. I don't have your experience with Qt but I have acquired some familiarity with it in time which was obviously not the case when the thing was originally designed. Threading with Qt is I think one of the most difficult things to grasp.

Back to the clock thing it is indeed a bit surprising that a simple action to draw some string on the screen takes more than 50ms. It would also be possible to use a single timer and trigger the clock update every 20 occurences of the 50ms timer thus getting rid of the second 1s timer in the case this second timer would cause trouble. The clock display does not need to be sharp down to the millisecond. It is just convenient to get a clock when running full screen. I am not sure about the positive, negative, neutral consequences however.

Regarding docker the point is that the compilation instructions in the Wiki are updated manually however I routinely build images using the Dockerfile thus this one is more reliable. You also save a lot of manual operations basically you run the docker build and get an image. This is really convenient. Also with Docker you are running in a well defined environment where bad things if they happen are easily reproducible. This makes problem tracking much easier for me. In fact I have given up on issues that obviously originate from a user specific configuration. There are also many reports of build issues that do not target a real issue with the code and are just noise.

[f4exb]

Issue can be closed.