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?