sudo apt-get install gnuradio-dev cmake libspdlog-dev clang-format
git clone https://github.com/krakenrf/gr-krakensdr
cd gr-krakensdr
mkdir build
cd build
cmake ..
make
sudo make install
Followed gr-krakensdr instructions: In the heimdall_daq_fw folder edit your Firmware/daq_chain_config.ini file and change out_data_iface_type to eth.
[data_interface]
out_data_iface_type = eth
What am I missing? Running ./kraken_doa_start.sh gives me a constant stream of “WARN:Ports used by the DAQ chain are not free! (5000 & 5001)” i.e.
>>./kraken_doa_start.sh
Shut down DAQ chain ..
Config file check bypassed [ WARNING ]
kernel.sched_rt_runtime_us = -1
WARN:Ports used by the DAQ chain are not free! (5000 & 5001)
Shut down DAQ chain ..
WARN:Ports used by the DAQ chain are not free! (5000 & 5001)
Shut down DAQ chain ..
WARN:Ports used by the DAQ chain are not free! (5000 & 5001)
Shut down DAQ chain ..
However running lsof -i :5000 and lsof -i :5001 says those ports are not being used.
Running the super simple GNURadio block to test and nothing pops up
Any suggestions what I’m missing or what I should try? Thanks
Make sure you are running ./heimdall_only_start.sh, not ./kraken_doa_start.sh as the latter will also start the Python DOA code which you do not want running.
im trying to use krakensdr on an x86 device via ubuntu. I tried my best following the instructions (im a beginner in these fields) but when I execute any example flow graph on gnu radio I get the following error and gnu radio crashes.
Thank you, yes that was certainly a problem. However still running ./heimdall_only_start.sh still gives me the same error:
~/krakensdr_doa$ ./heimdall_only_start.sh
Shut down DAQ chain …
[sudo] password for kraken:
Config file check bypassed [ WARNING ]
kernel.sched_rt_runtime_us = -1
WARN:Ports used by the DAQ chain are not free! (5000 & 5001)
Shut down DAQ chain …
WARN:Ports used by the DAQ chain are not free! (5000 & 5001)
Shut down DAQ chain …
Did you run kraken_doa_start at some point before? It seems like the Kraken software stack is still running from a prior run which is why the ports are in use.
You’ll need to shut it down first with kraken_doa_stop, or just restart your PC (assuming you haven’t done anything to make the software autostart).
I’m trying to set up the Kraken SDR with Ubuntu + GNURadio but I’m struggling with using heimdall_daq_fw.
When I set “out_data_iface_type = eth” in the daq_chain_config.ini and run “sudo ./daq_start_sm.sh”, I see error in the “delay_sync.log”. An because the delay_sync.py is crashing the iq_server is in a blocked state.
Traceback (most recent call last): File “/home/zp/code/krakensdr/heimdall_daq_fw/Firmware/_daq_core/delay_sync.py”, line 41, in import skrf as rf ModuleNotFoundError: No module named ‘skrf’
How are you using it? I don’t see how it could work when the python modules are installed in the conda environment but the script is running as sudo.
Update 1: Just for the completeness, when I’m running “./daq_start_sm.sh” without sudo I’m getting the following error:
chrt: failed to set pid 0’s policy: Operation not permitted
Update 2: The build looks good in that sense the unit test passes after reverting c525212da63c316169e9b1ef47d6791bba1af202 . (That change removes shared memory unlinking which seems to brake the unit test.)
Thanks — but in my case scikit-rf is already installed in the conda environment, so that alone doesn’t resolve the issue.
The underlying problem seems to be that daq_start_sm.sh (and therefore delay_sync.py) must be run with sudo, which causes it to bypass the current user’s conda environment. As a result, even though scikit-rf is available in conda, it is not visible when the script runs under sudo, since root uses a different Python environment.
So the issue is not simply a missing dependency, but a mismatch between:
Python dependencies installed in a conda environment
Execution happening under sudo, which does not preserve that environment
This is also why I was asking how daq_start_sm.sh is intended to be run on Ubuntu in your setup. From one side, chrt requires elevated privileges, but on the other side the Python layer expects packages from a user-level conda environment, which becomes inaccessible once the script is executed under sudo.