Debugging caribou_smi_read -> Timeout with SoapySDRServer

[MisterC925]

On stock RPI OS 64-bit with latest updates, I ran the install process.

I can see my Caribou lite in the test utility no problem.

When I try to access it via SoapySDR (using the server on my RPI4 and CubicSDR as client on a Mac) I get a few seconds of audio and then and endless loop of "caribou_smi_read -> Timeout" in the output from the server process.

If I stop and start the device in CubicSDR I get a few more seconds of audio and then it freezes again.

I've monitored the temps (since it's a new RPI4 and I haven't sorted out a cooling solution that works properly with a HAT installed) and then never exceed 55C my initial theory that it was a thermal issue seems to be bunk?

What further steps can I do to help debug this issue and provide good feedback to you all

Thanks

[MisterC925]

I just tried with SDR++ and it has the same issue. It can see the two radios remotely but once it starts running it starts the timeout loop

[alphafox02]

Refer to this ticket.

https://github.com/cariboulabs/cariboulite/issues/120

Download the source again, do a git pull of the revision I mention. Run the build script. That’s the last point I had it working, with more recent attempts resulting in the timeout issues you are mentioning. That’s with aarch64 22.04 on the pi4 anyways. Curious if it results in a working setup for you as well, at least until the new timeout issue is resolved.

[MisterC925]

Thanks for the response, I was away for a couple of days but am working on this now.

I recloned the repository into a new folder but git checkout bee3ddd fails with: error: pathspec 'bee3ddd' did not match any file(s) known to git

I noticed the web page for the commit (https://github.com/cariboulabs/cariboulite/commit/bee3dddb3e45fa466476907eeb739e6fb8d39736) has a warning (This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.)

I'm not a git ninja but I have checked out specific commits before so I'm not sure what I'm doing wrong.

Thanks

[MisterC925]

To update, I was able to download the entire branch as of bee3ddd and it wouldn't compile (something about pthreads but i was able to use the modified cariboulite_radio.h and .c files with the latest checkout (the CariboutliteStream.cpp file in the latest checkout reflects the change in bee3ddd already)

I was able to build and install it but same exact issue, I get 0-3 seconds of stuttering audio and then caribou_smi_read -> Timeout until the cows come home.

Thanks

[MisterC925]

Also I don't now if it's related or not but after the SMI goes nuts my wifi connection to the RPi4 goes wonky with all kinds of packet loss/etc.

This happens on both the stock download and the patched one.

[konimaru]

@MisterC925: For the sake of sanity, can you try the instructions in #82? It's an older build but it works for me on RPi3/4 without any issues.

[MisterC925]

Thanks @konimaru

I did a new checkout of your branch and installed it. I get more debug data from the SoapySDRServer but the end results are the same (a few seconds at most then nothing).

I'm not getting spammed with the caribou_smi_read -> Timeout anymore but effectively it the same issue.

I tried both with CubicSDR remote and OpenWebRX+ running locally on the Pi.

Interestingly when using OpenWebRX+ when the playback freezes, all network access to the RPi4 is lost as well. When you close the browser tab with the playback running, the network comes back up shortly afterwards.

I noticed you disabled Wifi in your setup, I haven't seen (but could have easily missed) where this was part of the setup, is there a known conflict between wifi and the cariboulite?

I recently moved and only have wifi in my work area, I might try connecting the pi to my laptop directly with ethernet to see how that works.

Thanks

[alphafox02]

Good point on you using WiFi. I have it wired from the Pi to a ddwrt client bridge. Could you temporarily check if you get the same result with a wired connection via a bridge of some sort?

edit - I missed that you’re going to try that next..