Debugging tips

[n1ai]

'Discussions' may be a good place to discuss debugging tips, and perhaps better ones can move into the wiki.

As mentioned in an earlier discussion, I was able to get hackrf work well enough to receive FM stereo broadcasts. Next I installed a Radioberry, erased the HDD, re-installed the OS, and rebuilt sdrberry for RDB and DSI.

Some tips on debugging things I ran into when doing this:

• I think it's safe to say most of the Radioberry devices made in China are going to be C016 not C025 FPGA parts. You need to know which one you have at install time. If you look closely enough at the device the first few characters of the part number below Intel Cyclone should be C016 or C025. Mine was C016.
• I found radioberry is definitely one of the devices that needs you to run 'sudo sdrberry' not just 'sdrberry'.
• It might be worth debugging why we need to be root to run radioberry since I did not need it for hackrf.
• One bad side effect of root is that it probably eliminates the ability to use pulseaudio since it starts as the non-root user so connections by root are refused.
• I suppose if you google enough you can figure out how to make a root user to avoid that problem, but it'd be nice if it just worked without needing to become root
• I very much recommend starting with as simple a configuration as possible. Set up 'ssh' so you can start sdrberry from another computer and you won't need a local keyboard. Look at 'lsusb' to see what things are on the USB bus and ask yourself if you need them or not. Take off anything you don't need. Once you get things working then you can add things in one by one and verify they work before you proceed
• I say this because I had two pointing devices, my mouse and my (non-standard) touchscreen. The code picked the touchscreen for its 'mouse' selection. Unfortunately the non-standard touchscreen isn't working with sdrberry though it does work with the standard desktop. No problem for now, I just edited $HOME/sdrberry_config.txt and changed the mousexx string to match my USB mouse.
• With the default setting of 384 kHz bandwidth the signal at 14.074 MHz was really choppy. I suppose some AGC would have helped, but I didn't know how to do that
• I decided to run the radio in 48 kHz bandwidth mode and that got rid of a lot of the choppy behavior. I had to give the spectrum and waterfall settings in $HOME/sdrberry_config.txt more gain to see them on the screen ( Spectrumgain = "60"
  Waterfallgain = "40" ). 96 kHz mode is also decent.

After all this, am having good FT8 and SSB reception.

[paulh002]

Hi, Thanks for your debugging tips. I will try to respond to a number of them.

• Root access is necessary because the device /dev/radioberry created by the radioberry device driver is not made accessable for the pi user. When using the "firmware" from PA0GSB that emulates a hermes light 2 it will access the device driver with root access. You can simply update the access to the device with:

sudo chmod 666 /dev/radioberry

Even a better approach would be to create a access group , but when you use crontab to start sdrberry on boot it will directly run with root user.

• The use of pulseaudio I do not recommend, I tried hard to keep the latency as low as possible and with the radioberry you can get a very short latency time. Pulseaudio add a number of milliseconds to this time. So on my installation I even remove pulseaudio.
• It is possible to use both hackrf and radioberry on the same setup, however the installation script only assumes 1 sdr radio type. But to add hackrf you can execute the hackrf steps manually. Later maybe I can add some option to combine SDR installations. But in general to have a good fool prove installation script is a challenge with all the different SDR's out there
• The choppy behaviour of the radioberry can have a number of causes. First the CPU of the pi need cooling. Linux will reduce the clock speed when the temperature increases. A large passive cool block which covers all components works good. Be sure to select one that has a low profile and use a gpio adapter / connector to increase the hight of the gpio connector. This fixed the issue for me. The 2nd option is to use a patched radioberry driver. In my github I have a optimised driver for sdrberry which performs better with radioberry. But lately I only used the cooling to fix the choppy issue.
• On the touchscreen, please open an issue and share the sdrberry.log file (capture the console output of sdrberry) then I should be able to fix it for you. Not all touchscreens behave correctly but I can give it a try.

Hope this clarifies some items.

73,
Paul

[n1ai]

Thanks for your rapid and thorough feedback. I really want to encourage you. I have used liquid-dsp on an earlier project and I like it very much. I do not know anything about how to make a spectograph or a waterfall. I'm really glad you have published your code. A few different friends at my local maker space have been giving your code a try, with various levels of success.

You can simply update the access to the device with: sudo chmod 666 /dev/radioberry

I have tried this and it is a good workaround.

Maybe we should make a radioberry wiki page just like hackrf has and we can put in some of these tips?

The use of pulseaudio I do not recommend, I tried hard to keep the latency as low as possible and with the radioberry you can get a very short latency time. Pulseaudio add a number of milliseconds to this time. So on my installation I even remove pulseaudio.

I agree, especially on the Pi 4. On the Pi 5 on some other projects I do get away with using pulseaudio.

It is possible to use both hackrf and radioberry on the same setup, however the installation script only assumes 1 sdr radio type. But to add hackrf you can execute the hackrf steps manually. Later maybe I can add some option to combine SDR installations. But in general to have a good fool prove installation script is a challenge with all the different SDR's out there

I agree keeping the install script simple is a good idea.

I think having multiple choices on radios will need testing. I think one needs to test the case where there are multiple radios known to soapy, but only one of them is connected. I saw a problem when I tried this, but since I reinstalled since then I no longer have the logs. I had first installed for rtlsdr then later added hackrf to soapy. If I did not keep rtlsdr connected then there was a crash when I started sdrberry. My workaround was to simply rename the rtlsdr soapy library, then everything worked.

A related suggestion is to change install script from:

wrkdir='/home/pi'

to:

wrkdir="$HOME/sdrberry"
if [ ! -d "$wrkdir" ]; then
  mkdir -p "$wrkdir"
fi

This is because a friend of mine tried to build the code on a pi he had installed that did not have 'pi' as the default user.

The choppy behaviour of the radioberry can have a number of causes. First the CPU of the pi need cooling. Linux will reduce the clock speed when the temperature increases. A large passive cool block which covers all components works good. Be sure to select one that has a low profile and use a gpio adapter / connector to increase the hight of the gpio connector. This fixed the issue for me. The 2nd option is to use a patched radioberry driver. In my github I have a optimised driver for sdrberry which performs better with radioberry. But lately I only used the cooling to fix the choppy issue.

Very good point. Maybe the wiki debug page should discuss CPU throttling as a cause of choppiness? Also it might suggest reducing the sample rate to reduce the workload and avoid any underruns.

I checked my CPU temperature. It pretty much stays around 59 degrees C. The Rpi will throttle at 80 degrees C. I currently have it in a case that has a fan to cool it. If I make a more portable package I would put some sort of big passive cooler or maybe a small active cooler as you suggest.

I note that at rate 384 kHz I do see 'underrun' messages:

underrun resamplerate 0.130170 -0.003000
Buffer queue 10 Radio samples 504 Audio Samples 66 Passes 7258 Queued Audio Samples 1024 droppedframes 0 underrun 5
agc [rssi:     -60.0000 dB, output gain: 0.000 dB, bw:   1.0000e-03, locked: no, squelch: disabled]:
  squelch disabled
rms 0.000000 db -164.576366 envelope 0.008356 suppression 1.870750 db
RF samples 3658032 Af samples 476167 ratio 0.130170 
multi-stage resampler
    composite rate      : 0.1304955482
    type                : decim
    num halfband stages : 2
    halfband rate       : 1/4
    arbitrary rate      : 0.5219821930
    stages:
    [ 0, r=  0.5000000] : halfband,  r=  0.5
    [ 1, r=  0.2500000] : halfband,  r=  0.5
    [ 2, r=  0.1304955] : arbitrary, r=  0.52198219
underrun resamplerate 0.130496 -0.002500

These underrun messages go away with rate 192 kHz and temp stays around 59C.

Unfortunately I don't have time to investigate further. I'm really happy with the output at 48 and 96 kHz. I have a Hermes Lite 2 and I typically run it at these rates, not 384 kHz.

On the touchscreen, please open an issue and share the sdrberry.log file (capture the console output of sdrberry) then I should be able to fix it for you. Not all touchscreens behave correctly but I can give it a try.

I think I should spend more time to narrow down the exact issue before asking for you to look at it. I am thinking that the issue might not be the touch screen, it might be that the keyboard I was using was falsely advertising itself as a mouse and/or touchscreen. So, let's not worry about it now.

[paulh002]

If underruns are detected sdrberry will adjust the resample factor. thresholdUnderrun determines the threshold. The acquired resample rate is also saved for next startup. The same applies for overruns. I am still looking if there is a more elegant solution but for now this works well. I had to customize the resampler of liquid-dsp to minimize the delay during adjustment. Because it will generate clicks in de audio. Indeed liquid-dsp is a great library and good documented.
On the touch screen just share the log it will display the name of of the driver. I can add it to the list, or you can add it to the settings file, that should also work