Cariboulite does not transmit using the SoapySDR API

[righthalfplane]

Cariboulite does not transmit using the SoapySDR API - all that it does is generate a writestream error -5. This error occurs on DargonOS and on BookWorm 64 bit. I have a simple Soapy program that works with all of the other SDR transmitters that I have (HackRF One, BladerRF-xA5, LimeMini 2.0, ANTSDR e200) on many systems MacOS Monterey, Ubuntu 22.04, Bookworm, Ubuntu 23.10, Windows 7, Windows 10. I have attached the test program -

sendManyFFT.cpp.txt

Somebody suggested a fix for the "error -5" problem and it got rid of the error and made the data transfer(the transfer routine said the correct number of bytes was sent) to the Cariboulite, but Cariboulite did not transmit the data that it received.

Is there any transmit program out there that actually works with the Cariboulite ?

[Paulo-D2000]

After the last PR it should work for CW tone...

[righthalfplane]

On Bullseye, Carboulite HiF and Carboulite S1G both transmit CW. However, on a relative scale the S1G puts out 30 db more power than the HiF. I would not expect that huge difference. The last PR has screwed up the reception - readStream, now returns zero every few reads and it losses the data - so the sound is somewhat garbled. Once, I run a transmit - the receive returns a zero on every read and no longer works at all.

[righthalfplane]

On DragonOS, everything acted the same as Bullseye, except that you had to run as super user.

[great9]

The last PR has screwed up the reception - readStream, now returns zero every few reads and it losses the data - so the sound is somewhat garbled. Once, I run a transmit - the receive returns a zero on every read and no longer works at all.

please open a new issue.

[great9]

On DragonOS, everything acted the same as Bullseye, except that you had to run as super user.

can you check if udev rules have been added and that the user you're running as has the permissions to a access the hat?

[righthalfplane]

"can you check if udev rules have been added and that the user you're running as has the permissions to a access the hat?"

Bullseye and DragonOS have the same dev rules -

SMI Devices

KERNEL=="smi", SUBSYSTEM=="smi-stream-dev", MODE="0666"

Other RPI Devices

SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0666"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0666"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0666"
SUBSYSTEM=="mem", KERNEL=="mem|kmem|port", GROUP="kmem", MODE="0666"

On DragonOS, it did not have the groups i2c,spi, or gpio. So, I added them and I added them to the user, but I did not do any good. It stops with the error -

Opening rpi in /dev/gpiomem: Permission denied
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libSoapyCariboulite.sostart_mmap() error: ubuntu:~>

It is as if it a needs a rule for "gpiomem" or something like that. I gave the DragonOS user (ubuntu) all the same groups as the Bullseye user and it still gets the same error.

[righthalfplane]

The DragonOS has some extra stuff -

raspberrypi:~> sudo find / -name "gpiomem"
/dev/gpiomem
find: ‘/run/user/1000/gvfs’: Permission denied
/run/udev/data/+platform:fe200000.gpiomem
/sys/class/bcm2835-gpiomem
/sys/class/bcm2835-gpiomem/gpiomem
/sys/devices/platform/soc/fe200000.gpiomem
/sys/devices/virtual/bcm2835-gpiomem
/sys/devices/virtual/bcm2835-gpiomem/gpiomem
/sys/bus/platform/devices/fe200000.gpiomem
/sys/bus/platform/drivers/gpiomem-bcm2835
/sys/bus/platform/drivers/gpiomem-bcm2835/fe200000.gpiomem
/sys/firmware/devicetree/base/soc/gpiomem

ubuntu:~> sudo find / -name "gpiomem"
/sys/class/bcm2835-gpiomem
/sys/class/bcm2835-gpiomem/gpiomem
/sys/devices/platform/soc/fe200000.gpiomem
/sys/devices/virtual/bcm2835-gpiomem
/sys/devices/virtual/bcm2835-gpiomem/gpiomem
/sys/bus/platform/devices/fe200000.gpiomem
/sys/bus/platform/drivers/gpiomem-bcm2835
/sys/bus/platform/drivers/gpiomem-bcm2835/fe200000.gpiomem
/sys/firmware/devicetree/base/soc/gpiomem
/sys/module/bcm2835_gpiomem
/sys/module/bcm2835_gpiomem/drivers/platform:gpiomem-bcm2835
/usr/lib/modules/5.15.0-1037-raspi/kernel/drivers/char/broadcom/bcm2835-gpiomem.ko
/usr/lib/modules/5.15.0-1044-raspi/kernel/drivers/char/broadcom/bcm2835-gpiomem.ko
/dev/gpiomem
find: ‘/run/user/1000/doc’: Permission denied
find: ‘/run/user/1000/gvfs’: Permission denied
/run/udev/data/+platform:fe200000.gpiomem

Perhaps some of that is the problem

[righthalfplane]

I have attached photos of the power spectrum for the S1G and HiF. The S1G has more than a single CW frequency peak. If I turn the transmit gain way down it reduces the number of peaks to one near the center frequency. SendMany is generating data to create single peaks across the frequency band - it may be close to doing the right thing for the data that it gets, but I assume in CW mode it does not care what is in the transmit buffer. The HiF has only one very tiny CW signal - It is the small peak just to the right of the green line at the center of the screen. The HiF signal is smaller than usual this time ?

[righthalfplane]

Filling the transmit buffer with zeros or ones did not change the results.

[great9]

Filling the transmit buffer with zeros or ones did not change the results.

@meexmachina

[User25514]

Im also struggling with this problem, all I can do is CW but I want to actually transmit audio data. If anyone has found a fix recently or some ideas, that would be amazing