Problems with the Raspberry Pi OS (64-bit) version.

[righthalfplane]

Today, I created new version of the recommended Raspberry Pi OS (64-bit) port of Debian Bookworm and installed it on my Raspberry Pi 4. The first problem is that it had compiler errors and then "SoapySDRUtil -i" did not find any devices. The two pull request that are waiting solved both of those problems. I then was then able to run it with SdrGlut. It ran in S1G mode and was working to the extent that it could receive some near transmissions, but the HiF mode say that 462.7125 MHZ was not an acceptable frequency. Although, the range returned by soapy was Rx freq ranges: [1e+06 Hz -> 6e+09 Hz] - that was wrong for the device that I have - it only goes up to 3e9 hz and nowhere near down to 1e6 Hz. To make things simple I grabbed the example from the Soapy website to use for testing -

https://github.com/pothosware/SoapySDR/wiki/C_API_Example

and make the few changes need to make it work with these devices.

SoapyExample.c.txt

I have also include the results of running it with each device -

example-output.txt

The simple program showed the same error message about the HiF not liking 462 MHZ as SdrGlut, but that should be a good frequency - shouldn't it ?

[righthalfplane]

Not having much luck -

Raspberry Pi OS (32-bit) - did not work. Missing "/dev/smi"

DragonOS_Pi64_Beta32 - is a joke it will not even update or upgrade

Ubuntu 22.04 64 bit - had to give the script sudo password. "SoapySDRUtil -i" would only run using sudo. Missing "/dev/smi".

I have found four setups that do not work - how about a list of setups that do work.

[great9]

Raspberry Pi OS (32-bit) - did not work. Missing "/dev/smi"

if /dev/smi is missing then it's not enabled in the kernel's boot config. Check DragonOS boot config filepath (this differs in many distros) and enable it there.

[K7MDL2]

Below is my /boot/config.txt relevant settings I use for PiHPSDR and CaribouLite. I tend to recompile after most OS updates.

I am running Raspberry PI (64-bit) OS. Details: arm64 "bullseye" kernel 6.1.21-v8+ on a RPi4B booting off a USB3 SSD and 8GB RAM.

I may have also modified the install.sh slightly, have to look what I changed but I can get a clean compile and run SoapySDRServer without error. To get to this point I walked through a bunch of dependency chains updating them, particularly SMI related libs. I am not sure install.sh gets everything (dependencies of dependencies). I posted in another recent issue much of went I did.

At this point I can run CubicSDR and it works properly, audio is proper. I do get a very few SMI reading operation failed errors over time but nothing I can hear or see. Other SoapySDR compatible apps I tried SparkSDR, SDR++, GQRX SDR, Quisk) can talk to the device without error, spectrums show, but the audio is severely chopped up. SparkSDR, SDR++, GQRX SDR, Quisk. In months past I had success with SDR++ server mode though that is not working at the moment.

[K7MDL2]

I also have, at times, been able to run openwebrx.

Looking back through my .bash_history file I noted I set gpio pins 14 and 18 hi and lo testing something. (raspi-gpio set 14 op dh (and dl) for example along with i2cdetect -y 1 commands. I do not recall why I did that but it appears a few times followed by cariboulite build commands. Pin 18 is used by default for cooling fan control, perhaps it clashed with the needs of cariboulite.

If I do a lsmod | grep smi here is what I get:

Pretty sure there was a smi lib I had to install or some smi manual device config intervention but I see no record of it in the history file. I was surprised by that since last spring I had all this working decent. Since then, major OS updates and new SDR apps were installed. Feels like I had lost SMI related libs in the process. I do see I installed/updated i2c-tools, python3-smbus, libi2c0 and libi2c-dev.

When I have some major hours to kill it would be interesting to see if I can start over with a clean system and get it working gain like I have it now. The exiting system has been though a lot over the last year.

While typing all of this I noted some small bit of chop starting in the FM radio audio. Changing the sample rate from 4MHz to 2MHz solved it. Then going back to 4Mhz the sound was fine again.

I run SoapySDRServcer --bind on the commanbd line so I can easily see the error, if any. Be sure to try the test and util programs in the build folder. Cariboulite_test_app and cariboulite_util.

I am running the SDR app clients on separate Linux and Windows machines. The Pi4B is only a server with CPU around 20% or less with lower sample rates. It is sensitive to load, the audio will chop a bit.

[K7MDL2]

I just noticed that if I am running SoapySDRServer and I try running a utility like SoapySDRUtil I will get access errors, cannot open /dev/smi among other errors. Killing the server won't remedy the problem, I have to reboot. I have SoapySDRServer configure to run at bootup. It never works, I have to kill it and then run it on the command line. I do have to run it with sudo. Will have to look how I am starting the service version up. Something to look out for.

FYI: A few days ago installation.md was changed and includes this note: change at https://github.com/cariboulabs/cariboulite/commit/745ad287038eef297b0e7b93df22b17398fc01ab

Note: Issues with distro bookworm - the required kernel modules cannot compile agains the latest 6.1.0 'bookworm' distribution. Current version was tested with bullseye 6.1.21-*. See details bellow.

[great9]

Looking back through my .bash_history file I noted I set gpio pins 14 and 18 hi and lo testing something. (raspi-gpio set 14 op dh (and dl) for example along with i2cdetect -y 1 commands. I do not recall why I did that but it appears a few times followed by cariboulite build commands. Pin 18 is used by default for cooling fan control, perhaps it clashed with the needs of cariboulite.

good info, should be added to docs / installation. what would be the best way to check if the running distro is utilizing those pins? if we can check for that setting we can add it to the install script

[K7MDL2]

All the GPIO pins used are documented. I think I listed them out with the sudo raspi-gpio get command and compared them (BANK0) to the docs. I set many of these for the PiHPSDR MkII controller board as well.

There was a GPIO tool that presented the pin status as an ASCII table that was very helpful. I only touch Linux admin every few months anymore, I tend to forget all the good stuff.

I Just disabled SoapySDRServer starting as a service. I can run SoapySDRServer without sudo and it works fine. Settles that question. It just never worked as a service for some reason. Maybe some critical setup is not yet complete and would work later in the startup process.

[K7MDL2]

A minor note. The install.sh script was checking for dtparam=i2c_vc=on and raised and error it was missing, please add it to /boot/config.txt. Per my example in above posts, I have it at the end. It appears the script is only looking in a specific section of the file. I uncommented the original line further up the file next to a few other i2c and i2s lines and the script check then passed.

I used to have to modify install.sh slightly to add a sudo. The build as of today has updates to the script and it came out clean on my 2nd run without modifications.

[dk6px]

Thank you for sharing your experiences, nice to follow, Caused by my reduced time to setup would it be possible to share a ready pi image with a standard user / pass, would be great Wish you nice advent , relax and happy end of this year 2023, Stefan dk6px

I used to have to modify install.sh slightly to add a sudo. The build as of today has updates to the script and it came out clean on my 2nd run without modifications. thank you

[K7MDL2]

I am running on a 256GB SSD and have several other projects on it including one for work and a year of massive changes.

However, I have a few Pi around, I really need to do a clean install and see if I can make it work right. That can be made into an image.

I have been running continuously playing mostly FM Xmas stations....tis the season..... once in a while tuning a large amount cause delay or a hang in the sdr app. Only CubicSDR is working smoothly for me now. Curious why.

Sent from my T-Mobile 4G LTE Device Get Outlook for Androidhttps://aka.ms/ghei36

---

From: dk6px @.> Sent: Sunday, December 3, 2023 12:09:24 AM To: cariboulabs/cariboulite @.> Cc: K7MDL @.>; Comment @.> Subject: Re: [cariboulabs/cariboulite] Problems with the Raspberry Pi OS (64-bit) version. (Issue #155)

Thank you for sharing your experiences, nice to follow, Caused by my reduced time to setup would it be possible to share a ready pi image with a standard user / pass, would be great Wish you nice advent , relax and happy end of this year 2023, Stefan dk6px

I used to have to modify install.sh slightly to add a sudo. The build as of today has updates to the script and it came out clean on my 2nd run without modifications. thank you

— Reply to this email directly, view it on GitHubhttps://github.com/cariboulabs/cariboulite/issues/155#issuecomment-1837403944, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APLVE7G4TQXP2DPKQW7RO7LYHQXTJAVCNFSM6AAAAAA743N2W6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGQYDGOJUGQ. You are receiving this because you commented.Message ID: @.***>

[dk6px]

Thank you Mike, never mind, please go on with your work, thank for your engagement I currently go two steps up with this setup ... will see to store this image after it will work ... Nice Advent , kind regards from Munich area. Stefan dk6px

[3B85A591]

Raspberry Pi OS (32-bit) - did not work. Missing "/dev/smi"

There appear to be issues with the driver install script.

Make sure that /lib/modules/`uname -r`/kernel/drivers/char/broadcom/ contains smi_stream_dev.ko.xz

uname -r will generate your current kernel version.

See #134, #158. Try placing them manually.

[great9]

Not having much luck -

Raspberry Pi OS (32-bit) - did not work. Missing "/dev/smi"

DragonOS_Pi64_Beta32 - is a joke it will not even update or upgrade

Ubuntu 22.04 64 bit - had to give the script sudo password. "SoapySDRUtil -i" would only run using sudo. Missing "/dev/smi".

I have found four setups that do not work - how about a list of setups that do work.

try the latest code from the master branch. it was updated today.

[mvmn]

One can also try this: https://github.com/cariboulabs/cariboulite/tree/main/driver

[K7MDL2]

Tonight I tried the latest changes published. As in previous versions, I had to add sudo in front of 'make' at line 144 of install.sh. to avoid FPGA errors then got a complete build without errors and runs as before for me.

[alphafox02]

Not having much luck -

Raspberry Pi OS (32-bit) - did not work. Missing "/dev/smi"

DragonOS_Pi64_Beta32 - is a joke it will not even update or upgrade

Ubuntu 22.04 64 bit - had to give the script sudo password. "SoapySDRUtil -i" would only run using sudo. Missing "/dev/smi".

I have found four setups that do not work - how about a list of setups that do work.

Not even sure what you mean by DragonOS won't update/upgrade? I see no issues with either (unless you mean the kernel on .33), and as far as the Caribou.. I can get it to work, but I grew tired of breakage on the repo. I will give it another shot.

[alphafox02]

I just pulled down the latest source, flashed DragonOS Pi64 R32, made the line 144 change above to add sudo, and ran through a complete .install without issue this time. Made the changes it says at the end (marked in red) to the correct boot config area.

As always, I basically have to run sudo SoapySDRServer --bind on the Pi and then connect to it from elsewhere.. although for the heck of it I had the Soapy Server running and run sudo CubicSDR and was able to connect to it all on the same Pi4 (performed poorly).

[K7MDL2]

FYI, I do not have to use sudo with SoapySDRServer. I have been able to run CubicSDR for a few days at a time.

I found I have to enable Swap I/Q in Cubic SDR and SDR++. I have not yet been able to make Quisk stream I/Q data, probably do not have the right Soapy connect string defined yet, TBD.

SparkSDR (on WIn11) is working to a degree with the versions current as of today. The tuning is not correct, for example WWV can be found 205KHz off. Audio sound correct at least. Stopping and starting the app sometimes help. There is no IQ swap setting. Best success is by clicking on a signal to tune rather than tuning up or down. If I try tuning, it eventually hangs, audio/spectrum stops. SoapySDR is new in SparkSDR and very well may have issues to resolve. Before the current CaribouLite build, audio was choppy. Progress at any rate.

I tried SDR++ with SoapySDR interface and the audio is very choppy, better at lower sample rates though still unusable. The tuning accuracy is correct and also required I invert I/Q to tune the correct direction. With the latest builds I have not been able to connect to sdrpp server mode interface, that worked for me best a few months ago. Win some, lose some.

S1G (and HiF) device work as long as I do not go outside the frequency limits. When I do, the channel is disabled. I have to disable the SDR app, set the frequency to something valid, then start the SDR app. This applies to any of 3 apps I tested (SparkSDR, sdrpp, CubicSDR).

Log snippet for S1G channel:

12-06 18:22:53.628 1815 217049 E CARIBOULITE Radio cariboulite_radio_set_frequency@cariboulite_radio.c:843 Unsupported frequency for the ISM S1G channel - 345712106.00 Hz, deactivating channel

Log Snippet for 6GHz channel. This is a legit scenario due to my invalid band offset entered in Cubic SDR (accepts only KHz, not Hz). As above, I have to restart the app with the correct value in place first.

12-06 19:50:12.210 233053 233180 E CARIBOULITE Radio cariboulite_radio_set_frequency@cariboulite_radio.c:960 Unsupported frequency for 6GHz channel - 2000007046000.00 Hz, deactivating channel

Seems multiple apps require I/Q to be swapped.

[alphafox02]

That's interesting on the sudo part, I hadn't thought that was fixed. For example, trying to start any application that uses it without sudo ends in issues. Was that fixed recently or did you make some change locally? I'll start trying out other applications asap.

[K7MDL2]

I know I used to run with sudo, certainly last spring, but recently that has changed, not sure exactly when. I have been running the install.sh script with the one sudo line mod and all stock otherwise.

Did a bunch more testing today with various apps. Got SparkSDR to work audio-wise at 1.33MHz sample rate but the tuning is screwy, I/Q inverted like other apps here. No way to invert it in SparkSDR yet. CubicSDR still works most of the time, pretty decent for me.

[alphafox02]

Take a look at the script around line 34 to 45. That part of the script failed for me, so I think that's why I'm still using sudo.. but I don't know that adding the user to root is a good solution?

[alphafox02]

I added the user to the groups it wanted, logged out and back in, but that doesn't keep me from needing to type sudo either.

[alphafox02]

Got it, just needed to also add dialout (I think I had it added already). So basically manually adding my user to "root dialout" allows me to not need sudo

[K7MDL2]

I am on Pi OS 64 bit bullseye, you must be on an Ubuntu release. Maybe those add user to dialout group lines are not working the same way in the script.

[alphafox02]

Yeah, it fails. But I just went and manually did it and it's fine. I can also start SigDigger as long as I make bandwidth match sample rate.

[K7MDL2]

I had not heard of SigDigger before. I just compiled it on LinuxMint on a old Nuc4 core i3 (partially on Windows 11) after a few hours of tracking down dependencies and restarting the clones ensuring all modules cloned came from the develop branch, not a mix of master and develop as I unwittingly did on the first effort. I can connect to the CaribouLite and hear a FM station OK, but not the weaker ham and NOAA weather that I can hear in the other apps. Playing around with the settings to try to improve that. Has promise.

[righthalfplane]

Not even sure what you mean by DragonOS won't update/upgrade? I see no issues with either (unless you mean the kernel on .33), and as far as the Caribou.. I can get it to work, but I grew tired of breakage on the repo. I will give it another shot.

What I mean is it just generates error messages - of various kinds and it will not do an update or an upgrade. I still have it on a SD card - I will give it another shot and see what happens now. I have made no changes - I just burned the disk image.

[alphafox02]

Hard to say, bad flash or download perhaps or you need more along the lines of a 32Gb SD card.

[mvmn]

CubicSDR works for me as well, but it doesn't have NTSC video decoder. SigDigger fails though - constantly says stream end and complains about source not supporting native DC correction. Samplerate matches bandwidth - but this doesn't help. This is on HiF channel.

SigDigger only works ok if I run suscli as root as a server, and connect to it from SigDigger over localhost.

The odd issue I have is that some software like sdrangel and SigDigger don't show me anything at 5.8GHz, while CubicSDR shows clear signal when I turn on my tiny whoop drone.

[alphafox02]

Check this newer video I and look in the comments for the follow up

DragonOS Pi64 Working CaribouLite Setup (Beta R32) https://youtu.be/CO4Sg5iWb3k

[righthalfplane]

I finally got things running using only the Raspberry PI 4. With a fresh version of the SD card, the "install.sh" can only be run once. The second time, the script starts up the CaribouLite and generates errors. The "#include 'memory'" needs to be added to "CaribouLite.hpp" or it generates errors. There seems to be no way that you cannot recover from the errors. I made some videos -

CaribouLite SDR - Demo of CubicSDR 0.2.7 vs. SdrGlut-1182 https://youtu.be/sKcm6edLB-U

HackRF One vs. CaribouLite at FRS Frequencies. https://youtu.be/fzVpYNdPsi8

The CaribouLite is generating frequency data that is reflected about the center frequency. CubicSDR and SdrGlut both see this problem. Other than that most of the time SdrGlut works very well with the CaribouLite. CubicSDR will likely work Ok (other than the frequency problem) - If The [INFO] messages are turned off - they seem to be hanging the program.

[K7MDL2]

Interesting, wonder if it is related to using Bookworm.

My refewrnce setup: CubicSDR v0.2.6a - Enablle Hardware gain and IQ swap Windows 11 and LinuxMint on a NUC4 Connect via LAN to my RPi4B Bullseye 64bit running SDRSoapy --server

If I run and SDR app on the Pi I will be guaranteed to get audio stutter so I only run SDR apps on remote computers. CPU usage is just too high.

With CubicSDR on both remote clients, I have correct frequency and 99% of the time no stutter. Once in a while something goes haywire but a restart of SoapySDR seems to resolve that.

With SparkSDR and some other apps I have, the frequency is off. I cannot swap I/Q in SparkSDR and it does not do broadcast FM demod but does work OK on the other signals once you can tune it in.

SDR++ V1.1.0 Oct 29, 2023 build connects with SoapySDR server for the source but stutters a lot for me.

[righthalfplane]

On Bullseye 32Bit, I can run gqrx up to 8 MSPS , CubicSDR up to 6 MSPS and SdrGut up 15 MSPS using a HackRF One before I get any audio Shutter.

On BookWorm 64Bit using SdrGlut, I can run CaribouLite at its maximum 4MSPS and HackRF One at its maximum 20 MSPS with two CPUs. The audio stutter starts if I try to go higher than 10 MSPS with one CPU. In the video, I ran the both the CaribouLite and the HackRF One at 2 MSPS to capture the I/Q data. I also ran them both at 4MSPS with no shutter while testing things out. Either my new PI 4 is a little faster or BookWorm is faster. I did not use Bullseye 64bit, because something I wanted to use only worked on 32bit at the time. May be Bullseye 64bit is a slow version ?

You are right, I/Q swap fixes the frequency problem - I though that it just interchanged the I and Q values.

[K7MDL2]

Got GQRX v2.14.4-23-g272bd75 running on Win11 finally. Sound is good. Worked OK for my AirspyHF+ but gave an error for the Cariboulite, "destination port 1 out of range".

I trimmed off the last part of the device string to be this and it works now.

This is what the device scan returns for the HiF device: channel=HiF,device_id=1,driver=remote,name='CaribouLite RPI Hat',remote=tcp://192.168.2.33:55132,remote:driver=Cariboulite,serial=f4a09ad9,soapy=7,uuid=4d7830e7-28bd-4bf8-9f95-d65f9081a6f2,vendor='CaribouLabs LTD',version=0x0001

I trimmed off everything from soapy to the end: channel=HiF,device_id=1,driver=remote,name='CaribouLite RPI Hat',remote=tcremote:driver=Cariboulite,serial=f4a09ad9

Also had to type in the sample rate 4000000 for 4MHz. It comes up blank and will not work until it is filled in. The other fields seem OK.

Installed Cubic SDR 0.2.8 on Win11. 0.2.6a worked better I think. After switching around the apps a few times nothing worked anymore. Had to reboot the Pi.

Trying to resurrect a dead PlutoPlus 6GHz SDR unit. Resorting to use a JTAG connection, maybe has a corrupt boot flash image.

[righthalfplane]

I recently bought an ANTSDR E200. It has two modes - a Pluto mode and a UHD mode. The Pluto mode works great as is. The UHD mode has to be hacked, but it then works very well. It puts the HackRF One to shame. It is very similar to the BladeRF xA5 with them giving almost identical performances.

[K7MDL2]

I just built rtaudio pre your video but with VS2022 and it went OK. Tried to build SDRGlut.exe but had error, missing AL/alut.h.

C:\Users\k7mdl\Documents\GitHub\SdrGlut\MainSource\audiolib.h(15,10): fatal error C1083: Cannot open include file: 'AL/alut.h': No such file or directory

I found al.h, but no alut.h in the C:\Program Files (x86)\OpenAL 1.1 SDK\include folder.

I have a LinuxMint system I can try build/run on later.

Instead I ran the precompiled SDRGlut.exe 1164 on my Win11 system. As a baseline, I first chose my Airspyhf+ with a FM broadcast station, sound and frequency control is good.

Then chose the CaribouLite HiF. No spectrum or audio. The Soapy data looks OK. This warning was in the terminal scrolling by:

[WARNING] StreamEndpoint resize socket buffer: set 43008 KiB, got 1024 KiB

I then chose the SiG channel and that worked. Choppy at 4Msps, but good at lower rates. Then raised it back to max rates and it stayed working. Nothing on the HiF channel still. Mystery.

[righthalfplane]

If you look at,

https://github.com/righthalfplane/SdrGlut/releases/tag/v1.32

you likely missed -

Some people may need to install OpenAL on Windows. Get the two packages - OpenAL1.1.CoreSDK OpenAL 1.1 windows install from "https://www.openal.org/downloads" and install them.

Are you are trying to get SdrGlut to use SoapRemote from Windows 11 to the PI ?

I have only used SoapRemote a few times an always from MacOS - I will have to look into it for Widows.

[K7MDL2]

I have the OpenAL stuff installed. There is no alut.h in the SDK include folder I could find. A quick cruise of the dev doc was not revealing.

[righthalfplane]

I do not understand what is going on it appears in -

Program Files (x86)/OpenAL 1.1 SDK/include/AL/alut.h

On My Windows 7 and Windows 10 machines.

The OpenAL people did change the way that the install worked not long ago - may be they have done it again.

On Windows 10 I have the two OpenAL programs installed.

OpenAL OpenAL 1.1 core pc SDK(ver 3.05)

installed.

I think that they came from -

oalinst.exe OpenAL11CoreSDK.exe

I also have

freealut_1.1.0.orig.tar.gz

floating around, but I do not think that I used it.