setup.sh error

[wrstrand]

I can clone the github repository onto my Raspberry Pi 4B: mkdir ~/projects cd ~/projects git clone https://github.com/cariboulabs/cariboulite cd cariboulite Than I get an error message when trying to run sudo setup.sh (sudo: setup.sh: command not found) sudo setup.sh gui

or

sudo setup.sh

[alphafox02]

Setup.sh is not actually in the repo.

[alphafox02]

Change into software/libcariboulite/ and run git submodule update --init

Then mkdir build && cd build Then cmake .. Then make Giving it a go now.

[wrstrand]

Thanks

On Sat, Jan 28, 2023 at 17:55 alphafox02 @.***> wrote:

Peaked in software/libcariboulite/ and attempted to build, but it's missing src/iir/ content.

— Reply to this email directly, view it on GitHub https://github.com/cariboulabs/cariboulite/issues/28#issuecomment-1407514589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUL6PMNTZIUPAN35HYHDBN3WUWWVRANCNFSM6AAAAAAUJ3KFWU . You are receiving this because you authored the thread.Message ID: @.***>

-- Sent from Gmail Mobile

[EelkeVisser]

Hi, I have experienced the same problems. Also solved a few problems. See this thread in satnogs forum: https://community.libre.space/t/cariboulite-need-help/

Specifically, the iir directory is another github repository that you need to clone into the iir dir. I described this in linked post.

I haven't got it working yet, and I guess we need an update or two on the documentation and software.

[EelkeVisser]

Some general YouTube videos shows the previous version working. Unfortunately it doesn't show the software installation process. https://youtube.com/playlist?list=PLoIRme2mYsktpHwpnQJnwHowSaTJaPzCn

[alphafox02]

I’ll do up a short video and show how I have it somewhat working w/ Soapy Remote and SigDigger, but I suspect maybe the repo will see some updates now that hardware is out in the wild.

[meexmachina]

Hi Guys!!! Yes indeed... I'm updating the installation and setup right now. We have been working mainly on the 64-bit distro. So the SMI drivers are built for 64bit and they are out of line "non standard" drivers for now - until they will be integrated inside the Linux kernel (hopefully).

1. The original drivers from Broadcom are working but do not allow for poll/select APIs thus we had to rewrite them to support for async I/O. They were built for generic usage...

2. The current working repo is not MAIN but "develop_R1" which is still a work in progress.

3. Basically, for the IIR submodule what is needed is to clone the repo and run

git submodule init
git submodule update

if you want to contribute to the "develop_R1" you can check it out by git checkout develop_R1

4. Soapy SDR is needed and Soapy Remote is recommended for remote debugging:

https://github.com/pothosware/SoapySDR.git
https://github.com/pothosware/SoapyRemote.git

5. If you want to make changes in the FPGA, you will need the ice-storm - but it is not needed for all cases. Once the FPGA, dtbo and other binary files are built (by us) there is a standard sub-program that embeds these binary files into the code (through an c/c++ h-file). Then they are statically embedded inside the main built system. for IceStorm project: https://clifford.at/icestorm or follow the following (see that we use NextPNR rather than Arachne-PNR for place and routing):

sudo apt-get install build-essential clang bison flex libreadline-dev \
                     gawk tcl-dev libffi-dev git mercurial graphviz   \
                     xdot pkg-config python python3 libftdi-dev \
                     qt5-default python3-dev libboost-all-dev cmake libeigen3-dev
git clone https://github.com/YosysHQ/icestorm.git icestorm
cd icestorm
make -j$(nproc)
sudo make install
git clone https://github.com/YosysHQ/nextpnr nextpnr
cd nextpnr
cmake -DARCH=ice40 -DCMAKE_INSTALL_PREFIX=/usr/local .
make -j$(nproc)
sudo make install
git clone https://github.com/YosysHQ/yosys.git yosys
cd yosys
make -j$(nproc)
sudo make install

6. Still missing - udev rules for SMI. I would highly appreciate your help with it to set up two devices with non-root (non sudo) permissions: /dev/smi and /dev/gpiomem which are needed.

7. The boards have been tested and configured with a DTBO inside them. meaning - the device tree is written into each and every CaribouLite board (EEPROM). The pin-muxing as well. see the DTBO sub-directory in the software part.

Then we will be able to embed them into the mainline installation script.

Thanks for now! I am really excited to see that our boards found their way finally to your hands! we still have a lot of work and a lot of things to tidy up...

[alphafox02]

Sounds exciting and now makes sense maybe why the standard smi driver that’s in Pi OS wasn’t working so well? Would it be safe to say maybe I could add the smi driver to the aarch64 Ubuntu 22.04 build? I’ll run down your notes and test more this afternoon.

[meexmachina]

Sounds good to try. please note that there is an "almost full" (missing udev) install.sh in the root.

[alphafox02]

Currently trying the script, curious why the packages do not have make install? Also, on the lib caribou package I'm getting a failure to finish the compile due to something related to zmq, I'll jump over to Pi OS and make sure it's not because I'm on aarch64. I'm basically manually applying your script line by line now.

[alphafox02]

Both on 22.04 aarch64 and the Pi 64bit bullseye build after making sure libzmq3-dev is installed the following happens now w/ the develop_R1 branch install.sh script (doesn't happen on main).

Linking CXX executable cariboulite_prod
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_close':
lcd.c:(.text+0x110): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x12c): undefined reference to `zmq_recv'
/usr/bin/ld: lcd.c:(.text+0x144): undefined reference to `zmq_close'
/usr/bin/ld: lcd.c:(.text+0x14c): undefined reference to `zmq_ctx_destroy'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_init':
lcd.c:(.text+0x280): undefined reference to `zmq_ctx_new'
/usr/bin/ld: lcd.c:(.text+0x28c): undefined reference to `zmq_socket'
/usr/bin/ld: lcd.c:(.text+0x29c): undefined reference to `zmq_connect'
/usr/bin/ld: lcd.c:(.text+0x2ec): undefined reference to `zmq_close'
/usr/bin/ld: lcd.c:(.text+0x2f4): undefined reference to `zmq_ctx_destroy'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_clear_screan':
lcd.c:(.text+0x3b4): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x3d0): undefined reference to `zmq_recv'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_write':
lcd.c:(.text+0x430): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x444): undefined reference to `zmq_recv'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_writeln':
lcd.c:(.text+0x4b4): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x4d0): undefined reference to `zmq_recv'
/usr/bin/ld: lcd.c:(.text+0x500): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x51c): undefined reference to `zmq_recv'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_get_keys':
lcd.c:(.text+0x570): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x584): undefined reference to `zmq_recv'
/usr/bin/ld: src/production_utils/libproduction_utils.a(lcd.c.o): in function `lcd_set_params':
lcd.c:(.text+0x674): undefined reference to `zmq_send'
/usr/bin/ld: lcd.c:(.text+0x690): undefined reference to `zmq_recv'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/cariboulite_prod.dir/build.make:116: cariboulite_prod] Error 1
make[1]: *** [CMakeFiles/Makefile2:422: CMakeFiles/cariboulite_prod.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

[alphafox02]

Should I use insmod on the smi kernel module that's built?

[alphafox02]

Also I think a CMakeCache.txt file got pushed up to the repo

"The current CMakeCache.txt directory /home/ubuntu/Downloads/cariboulite/software/utils/CMakeCache.txt is different than the directory /home/pi/projects/cariboulite/software/utils where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt"

[EelkeVisser]

I have the same errors as mentioned above when compiling on Raspberry Pi 4B, but I also see this error:

Scanning dependencies of target smi_stream_dev
compiling module smi_stream_dev.ko...
make[3]: *** KERNELHEADERS_DIR-NOTFOUND: No such file or directory.  Stop.
make[2]: *** [CMakeFiles/smi_stream_dev.dir/build.make:87: smi_stream_dev] Error 2
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/smi_stream_dev.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

[alphafox02]

I also had to sudo apt upgrade the raspi kernel (can’t remember the package). Should just be able to do sudo apt upgrade and you’ll end up with matching kernel headers and kernel. That was at least my problem, but even so the necessary CaribouLite library wouldn’t build, so I just stuck with the main branch for now.

[EelkeVisser]

I got the develop_R1 branch to compile by removing the production tool from the makefile. See https://community.libre.space/t/cariboulite-need-help/10068/8 for more info. I hope we don't need this tool. Got some other cariboulite app running. But now I am unsure how to continue. I must try some random things I guess!

[mpbraendli]

Hi there, also got my board, installed on a RPi3 running archlinux ARM

Compiled both main and develop_R1 branches. Now on commit d332593, SoapySDRUtil --find gives me a bunch of errors

E CARIBOU_SMI_Main caribou_smi_init@caribou_smi.c:185 failed reading native batch length, setting the default - this error is not fatal but we have wrong kernel drivers

and

E CARIBOULITE Setup cariboulite_self_test@cariboulite_setup.c:436 The assembled modem is not AT86RF215 (product number: 0x35)

Haven't gone farther yet, as those errors don't look too good, and I don't want to invest time into this if it isn't clear if something is wrong with this SMI library.

I understand that you're working on it, but now that people actually receive the boards, please please pretty please make sure

1. the github default branch is the one people are supposed to use
2. the README doesn't mislead people (absence of setup.sh)
3. the prerequisites are clearly stated (32bit, 64bit or both? Which SMI driver? How to check that?)
4. first steps and install actually works
5. be transparent in limitations (manage users' expectations)

The first impression is crucial, and right now it's not good...

Looking forward to what's coming next!

[MartinHerren]

Hi @EelkeVisser !

I got the develop_R1 branch to compile by removing the production tool from the makefile. See https://community.libre.space/t/cariboulite-need-help/10068/8 for more info. I hope we don't need this tool. Got some other cariboulite app running. But now I am unsure how to continue. I must try some random things I guess!

Got it to compile with the following micro-patch to solve the libzmq linking error:

diff --git a/software/libcariboulite/src/production_utils/CMakeLists.txt b/software/libcariboulite/src/production_utils/CMakeLists.txt
index 1d64b3a..0342705 100644
--- a/software/libcariboulite/src/production_utils/CMakeLists.txt
+++ b/software/libcariboulite/src/production_utils/CMakeLists.txt
@@ -22,4 +22,5 @@ target_link_libraries(test_power_mon rt m pthread zmq ${SUPER_DIR}/zf_log/build/
 
 #Generate the static library from the sources
 add_library(production_utils STATIC ${SOURCES_LIB})
+target_link_libraries(production_utils zmq)
 target_include_directories(production_utils PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

Also yes as mentioned the CMakeCache.txt must be first deleted if your user on the Pi isn't pi or you cloned to a different folder.

With that i can compile the develop_R1 branch and start cariboulite_app. It doesn't seem to build the SoapySDR module anymore which worked on master branch (but only detected the sub-Ghz channel).

[G0MJW]

Hi there, also got my board, installed on a RPi3 running archlinux ARM

Compiled both main and develop_R1 branches. Now on commit d332593, SoapySDRUtil --find gives me a bunch of errors

E CARIBOU_SMI_Main caribou_smi_init@caribou_smi.c:185 failed reading native batch length, setting the default - this error is not fatal but we have wrong kernel drivers

and

E CARIBOULITE Setup cariboulite_self_test@cariboulite_setup.c:436 The assembled modem is not AT86RF215 (product number: 0x35)

Haven't gone farther yet, as those errors don't look too good, and I don't want to invest time into this if it isn't clear if something is wrong with this SMI library.

I understand that you're working on it, but now that people actually receive the boards, please please pretty please make sure

1. the github default branch is the one people are supposed to use
2. the README doesn't mislead people (absence of setup.sh)
3. the prerequisites are clearly stated (32bit, 64bit or both? Which SMI driver? How to check that?)
4. first steps and install actually works
5. be transparent in limitations (manage users' expectations)

The first impression is crucial, and right now it's not good...

Looking forward to what's coming next!

So right, I wasted a few hours on this. I have given up for now as I don't have the knowledge to get around and I mistakenly set everything up on the main branch using a standard PI 32 bit distro. I was also planning to do it headless on a Pi Zero W but I am not sure it is up to the task.

[alphafox02]

About the only way it’s running at the moment. Also needs 64 but I believe. No different outcome with the develop r1 branch and either the system default smi or the kernel built from the repo.

DragonOS Pi64 Caribou Setup (So far) https://youtu.be/YVl0995zDS4

[MartinHerren]

So right, I wasted a few hours on this. I have given up for now as I don't have the knowledge to get around and I mistakenly set everything up on the main branch using a standard PI 32 bit distro. I was also planning to do it headless on a Pi Zero W but I am not sure it is up to the task.

Currently trying on a headless Pi Zero W also. Best i achieved is get a IQ stream dump using rx_sdr tool from rx_tools.

Still have the error 'cannot transitioned state' that other experience as well. It still creates an IQ file with all samples being 0.

The Pi Zero might be not fast enough to support 4MS/s so supporting a lower samplerate would be welcome. Especially as front end filters for lower rates seem to be readily available.

[G0MJW]

I would hope the PI Zero would work, that's what it was designed to fit on. The Version 2 has quite a fast CPU, just limited RAM.

[edegraaff]

I would hope the PI Zero would work, that's what it was designed to fit on. The Version 2 has quite a fast CPU, just limited RAM.

Similar here, the PI Zero 2 and caribulite could be :

• great for on the road usage small, compact, and complete
• hope for some sort of interface layer like support for OpenWebRX
• great for testing over rtl_tcp and stream to your pc with your pc software like SDR#

[RobertSwirsky]

I've now spent about 8 hours total on this and haven't gotten anything to really work.

The farthest I've gotten was to get the FGPA firmware to load.

I'm OK with having to run specific versions of the OS, compiler, Soapy, and RaspberryPi, for a device like this to work. But I'm beginning to doubt the thing works at all.

I switched back to the "happy path" using RaspberryPi OS, and tried the latest install.sh script with the latest changes

That's ba16b60bb8822107f034091140658fbad41e2f5d in develop_r1

It build without error, after I delted the Cmake cache files, and I have a /dev/smi

But

pi@raspberrypi:~/projects/cariboulite $ sudo SoapySDRUtil --find
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

No devices found!

SoapySDRUtil isn't finding any devices.

I got further on DragonOS where it started to upload the device firmware, etc, but I never was able to get any data over the SMI for more than a few seconds.

[PRufener]

Just another shitty project that doesn't work... another waste of money!!!

[unixpunk]

do you even lift? works for rx via soapy and arbitrary tx is around the corner.

[alphafox02]

It’s not my project, but I have taken the time to put together a guide and made a video showing that it works. Even with the latest code. It would probably help if these old tickets were just closed.