transmission confusion

[User25514]

I need advice as well as information on the kinda non-existing manual.

Currently Im using python and im trying to transmit audio data to a receiver. Im using soapysdr, but Im wondering if theirs a good way to transmit audio data without using CW =1 continous wave.
Are their other options?

[righthalfplane]

There are transmit problems. CW =1 works to some extent - other options seem to error. There are some pull requests waiting maybe one of those will get things going better.

[User25514]

There are transmit problems. CW =1 works to some extent - other options seem to error. There are some pull requests waiting maybe one of those will get things going better.

Do you know what the other ones are so that I can atleast test them out?

[matteoserva]

The official source code is missing the fpga code for synchronizing the transmission channel with the radio chip.
I fixed the transmission errors in my private branch, tested it by sending arbitrary waveforms from gnuradio. Right now there are some issues with the soapy API.
My plan is to make the branch public this weekend.

[User25514]

The official source code is missing the fpga code for synchronizing the transmission channel with the radio chip. I fixed the transmission errors in my private branch, tested it by sending arbitrary waveforms from gnuradio. Right now there are some issues with the soapy API. My plan is to make the branch public this weekend.

That would be amazing! When you make the branch public, would you be able to get it to work with soapy api?

[matteoserva]

Right now the soapy api is only working for RX. I'm still struggling to make it work in TX.

[matteoserva]

If you feel brave, my branch is online but you have to be comfortable with working from a terminal.
Remember that it's a brach called "transmission_fix", not the main one.
My branch

[User25514]

If you feel brave, my branch is online but you have to be comfortable with working from a terminal.
Remember that it's a brach called "transmission_fix", not the main one.
My branch

The thing is currently, I have it working on a no GUI verson of the Raspberry os.
I currently need to use FGPA from the python soapyapi library.

[User25514]

Because this is for my dissertation, I'm trying to transmit a slow data stream atm just to prove the theory, but if I have time after I've proved my theory, then I will definitely try yours out.

[martinpetrovaj]

@matteoserva Hi Matteo, just went ahead and tried to install your 'transmission_fix' branch by following your manual, but I run into errors when compiling kernel drivers:

****@raspberrypi:~/repositories/cariboulite_matteo/driver/build $ uname -a
Linux raspberrypi 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux
****@raspberrypi:~/repositories/cariboulite_matteo/driver/build $ cmake .. && make
-- Kernel release: 6.6.20+rpt-rpi-v8
-- Kernel headers: /usr/src/linux-headers-6.6.20+rpt-rpi-v8
-- Configuring done
-- Generating done
-- Build files have been written to: /home/martin/repositories/cariboulite_matteo/driver/build
compiling module smi_stream_dev.ko...
In file included from /usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/linkage.h:7,
                 from /usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/kernel.h:17,
                 from /home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.c:48:
/home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.c: In function ‘smi_stream_dev_probe’:
/usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/export.h:29:22: error: passing argument 1 of ‘class_create’ from incompatible pointer type [-Werror=incompatible-pointer-types]
   29 | #define THIS_MODULE (&__this_module)
      |                     ~^~~~~~~~~~~~~~~
      |                      |
      |                      struct module *
/home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.c:1077:47: note: in expansion of macro ‘THIS_MODULE’
 1077 |         inst->smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
      |                                               ^~~~~~~~~~~
In file included from /usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/device.h:31,
                 from /usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/platform_device.h:13,
                 from /home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.c:51:
/usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/device/class.h:230:54: note: expected ‘const char *’ but argument is of type ‘struct module *’
  230 | struct class * __must_check class_create(const char *name);
      |                                          ~~~~~~~~~~~~^~~~
/home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.c:1077:34: error: too many arguments to function ‘class_create’
 1077 |         inst->smi_stream_class = class_create(THIS_MODULE, DEVICE_NAME);
      |                                  ^~~~~~~~~~~~
/usr/src/linux-headers-6.6.20+rpt-common-rpi/include/linux/device/class.h:230:29: note: declared here
  230 | struct class * __must_check class_create(const char *name);
      |                             ^~~~~~~~~~~~
cc1: some warnings being treated as errors
make[5]: *** [/usr/src/linux-headers-6.6.20+rpt-common-rpi/scripts/Makefile.build:248: /home/martin/repositories/cariboulite_matteo/driver/build/smi_stream_dev.o] Error 1
make[4]: *** [/usr/src/linux-headers-6.6.20+rpt-common-rpi/Makefile:1938: /home/martin/repositories/cariboulite_matteo/driver/build] Error 2
make[3]: *** [/usr/src/linux-headers-6.6.20+rpt-common-rpi/Makefile:246: __sub-make] Error 2
make[2]: *** [CMakeFiles/smi_stream_dev.dir/build.make:79: smi_stream_dev] Error 2
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/smi_stream_dev.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Is this a current issue you're aware of, or is it more likely an error on my part that I need to investigate?

EDIT:
There seems to be a potential fix in an issue here in the original CaribouLite repo. Will try it out and update this comment with the result.

EDIT 2:
After applying the fix mentioned in previous edit to both the original cariboulite repo as well as matteo's branch I was able to compile matteo's kernel driver successfully.
The 'compile software' step printed the following error at one point (missing cmakelists.txt file, see below), but cmake output log seems ok.

****@raspberrypi:~/repositories/cariboulite_matteo/software/libcariboulite/build $ cmake .. && make
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
CMake Error at CMakeLists.txt:46 (add_subdirectory):
  The source directory

    /home/martin/repositories/cariboulite_matteo/software/libcariboulite/src/iir

  does not contain a CMakeLists.txt file.


-- Performing Test HAS_STD_CXX11
-- Performing Test HAS_STD_CXX11 - Success
[INFO] SoapyCaribouliteSession, sessionCount: 0
04-23 14:21:57.734  3132  3132 I FPGA caribou_fpga_program_to_fpga@caribou_fpga.c:210 FPGA already operational - not programming (use 'force_prog=true' to force update)
[INFO] SoapyCaribouliteSession, sessionCount: 0
04-23 14:21:57.970  3141  3141 I FPGA caribou_fpga_program_to_fpga@caribou_fpga.c:210 FPGA already operational - not programming (use 'force_prog=true' to force update)
-- Module SoapyCariboulite configured with version: 1.2.0
-- Configuring incomplete, errors occurred!
See also "/home/martin/repositories/cariboulite_matteo/software/libcariboulite/build/CMakeFiles/CMakeOutput.log".

Don't know how to run the transmission test though, as there is only a tx_test.c source file in libcariboulite/src directory but no executable file with that name.

The transmission fix doesn't seem to work when testing tx with a Python script. Do the bindings need to be updated?

[alphafox02]

@matteoserva

I'm finally getting around to trying this fork. But a few things are not clear.

You say "install original software" but don't show that you should run ./install and only say cd cariboulite_original.

Following that you mention "install my branch in cariboulite" which almost makes it sound like you want your fork git cloned into the above direct.

I'm assuming what you mean is to install the original with ./install and make sure it works? Then git clone your fork into another directory and checkout the tx branch? Or do you mean to install your fork with ./install as well?

You then say to compile the kernel and compile the software, however, iir would not have been pulled in using your steps. Notice in the error above it's saying

 /home/martin/repositories/cariboulite_matteo/software/libcariboulite/src/iir

  does not contain a CMakeLists.txt file.

I copied iir from the original cariboulite build that appears after running ./install into your project. I was then able to compile the software which of course made the tx_test.

I created a flow graph as pictured, had socat etc installed, ran the command provided and connected to it with the gnuradio flowgraph. I show nothing transmitting over the air with the gain turned up.

This leads me to wonder, was I supposed to install install your fork? I compiled the kernel driver, but did nothing with it?

Can you please clarify your steps and I may be able to recreate the transmission capability on my end?

[alphafox02]

I also noticed that on the original main that the cariboulite_test_app does transmit a cw tone, but on your fork it does not. Maybe unrelated, but at least I know the hat can transmit.

[matteoserva]

@alphafox02 Yeah sorry for the confusion. I'll update the documentation to clarify the steps.
Basically the steps are these:

1. Install the original software and make sure that it works.
2. clone my branch somewhere else and install it by following the same steps you used in step 1. It will overwrite the original software.
3. perform the step called "compile software". This will create the tx_test application
4. run tx_test

[alphafox02]

I actually did try this. I used the latest original fully installed. I made sure it worked. I then installed yours, which would’ve installed over top of it. Your tool compiled, but after I built the GNURadio graph and ran your tool I saw no transmission over the air. I also saw no transmission using the default test app in your repo either. If I get a chance, I will refresh and start all over again.

[User25514]

If you feel brave, my branch is online but you have to be comfortable with working from a terminal. Remember that it's a brach called "transmission_fix", not the main one. My branch

hows the branch developing coming along? Did you get transmissions to work properly in Python, or are you still struggling?

[User25514]

@alphafox02

gnu radio didnt work with mine either, but if you have a receiver, check the receiver. Mine didn't show in gnu but it showed transmissions when I opened up my radio analyser from another pc

[alphafox02]

I’m using SDR plus plus with an RTLSDR to check the 433 MHz frequency. Using the original and the test app to transmit a tone I can see it transmits so I know that is all working. However, when I try to use the method of sending a transmission in conjunction with gnuradio flow to transmit the wav file, I see no sign of any transmission. I’ll try it all again maybe while I’m at DEFCON.

[alphafox02]

Actually, now thinking about it. I don’t see the transmit light come on at all when I’m using the method described in the transmit fix branch.

[alphafox02]

And to clarify, I’m not using gnuradio in order to use the Caribou light as a source. I’m using gnuradio to pump the wav file into the tx test as described in this transmit fix branch mentioned above. I wasn’t sure if we were both talking about the same thing.