We bought two Kraken SDRs for prototyping RF algorithms and would like to capture coherent IQs without direction finding or other post-processing. That is, write a few seconds’ worth of IQs, captured at the same time across all channels, to 5 files.
And we are hitting snags doing this. We have krakenSDR connected to a RPi 4 with the recommended image. Direction finding (ran as a test) reports some sane numbers, so our setup seems to be OK.
heimdall_only_start.sh starts and reports (after setting out_data_iface_type = eth) that it is ready to communicate via network.
But we cannot run anything that successfully communicates with heimdall.
Specifically, trying to build gr-krakensdr to get a gnuradio module for krakensdr to run on the RPi, fails at the “cmake …” stage, as the module from GitHub wants GnuRadio 3.10 and the OS image contains 3.8 only.
We can build gr-krakensdr on a different Linux machine, make a simple GRC file with KrakenSDR source and 5 file syncs and point the IP of the KrakenSDR block to the RPi (running heimdall). Running this GRC file on that Linux machine, either from GnuradioCompanion or as a standalone Python code fails with terminal spewing “connection refused” lines. Linux machine is on the same network and the RPi is reachable from it (we have an ssh session from it to the RPi).
I would not recommend trying to load GNU Radio itself on a Raspberry Pi 5, it will probably be far too slow to run all five tuners of the Kraken in real time. The GNU Radio blocks are intended to be used on a Linux PC. If you are running Windows, the easiest way is probably to try out our Virtual Box image.
The Pi 5 can optionally act as the coherent heimdall server, sending coherent data over gigabit ethernet. If you are getting connection refused lines, then there is most likely something wrong with your network setup. Can you at least ping the Pi running heimdall?
Thank you for the response! To clarify – we are connecting SDR to Raspberry Pi 4, not 5. If it is important to switch to 5, we can do that, but for now we are set up with 4.
I will call Raspberry Pi 4 as P, and our Linux system as L. Yes, L is connected to P. It can ping P. It can ssh into P from L and run commands on P. And P is connected to the Kraken SDR and is running a “start_heimdall_server_only” with out_data_iface_type set to “eth”.
I believe P is successfully running the heimdall server. I can even do, from L: “telnet P 5000” to open a connection to port 5000 on P, and the connection succeeds (but is closed when I tried to send a few random bytes). So we seem to be tantalizingly close, but not yet able to pull the data.
My current goal is to use KrakenSDR for verifying our algorithms as we wait for our target hardware. I only need to record 2000-10000 coherent IQs samples, store them to a file and post-process them offline. If we decide to switch to Kraken from our current hardware provider for our real-time operation we will solve the real-time data flow, but for now I just want to check out the algorithms.
I definitely understand that running gnuradio on the Pi is unwieldy; I was just trying to do anything to see if we can make any bytes come out. For now, if we can dump a set of coherent samples (which I think heimdall is ready to publish), to a file on P or L it would be a complete success.
If you are using the Pi 4 image for direction finding to run your heimdall only server, did you first disable the autoboot of Heimdall and the DFing DSP software?
We switched from using a Pi 4 to a VM on a laptop and things are running smoother now. We see the FFT plots in gnuradio that look reasonable so I am hopeful that we can now capture raw IQ (e.g., by using gnuradio file sinks) without dropping samples.
To record the IQ samples for analysis you have an option to use our dedicated IQ sample recorder.
You can find its repo here:
(Use the development branch)
You have to start the Heimdall_DAQ_firmware only in “eth” mode and connect to it with the IQ recorder. You can do it either locally or remotely. I dont recommend to run the recorder on the P as it will not able to dump the IQ data without data loss.
Also don’t forget to set the config file of the recorder properly (ip, port, location to record the IQ data)
Thank you for the advice, but not quite there yet. Now running from VirtualBox image on a Windows host (pretty beefy Windows laptop), image from June 2024 (latest available on your shared google drive).
Starting VM
cd krakensdr_doa
Run the first portion of the kraken_doa_start.sh, through the ‘sudo env “PATH=$PATH” ./daq_start_sm.sh’ line. DAQ seems to be running OK (see no errors reported)
From a separate directory (development branch of the “heimdall_iq_req” repo), run “/bin/sh create_environment.sh”. Success.
Run ./start_recorder.sh, see error below in the _logs/iq_recorder.log. Same error running _src/IQStreamer.py directly. No files being written (writing to a local FS on the VM).
Traceback (most recent call last):
File “/home/krakenrf/alex/heimdall_iq_rec/_src/IQStreamer.py”, line 526, in
curses.wrapper(IQStreamer_inst0.main)
File “/usr/lib/python3.10/curses/init.py”, line 94, in wrapper
return func(stdscr, *args, **kwds)
File “/home/krakenrf/alex/heimdall_iq_rec/_src/IQStreamer.py”, line 389, in main
stdscr.addstr(24, 0, "Status: "+self.status_msg)
_curses.error: addwstr() returned ERR
Exception ignored in: <module ‘threading’ from ‘/usr/lib/python3.10/threading.py’>
Traceback (most recent call last):
File “/usr/lib/python3.10/threading.py”, line 1567, in _shutdown
lock.acquire()
KeyboardInterrupt:
UPDATE: Regarding the Raspberry Pi 4 image currently provided, I was able to get both ports 5000 and 5001 to work by, rather than executing heimdall_only_start.sh, instead executing:
I’m not sure why heimdall_only_start.sh fails to open both ports (nor why _sm is in the name of the working script since that implies shared memory).
END UPDATE
I’m having a similar problem but don’t understand why you ask this question. Are you saying that running:
$ cd ~/krakensdr
$ ./kraken_doa_stop.sh
$ vi heimdall_daq_fw/Firmware/daq_chain_config.ini
out_data_iface_type = eth
:wq
$ ./heimdall_only_start.sh
is inadequate to activate ports 5000 and 5001 on the eth0 port of the Raspberry Pi 4 with the default image?
I did just the above sequence and ended up with port 5001 listed but not 5000 in :
$ netstat -nl
Do I need to change the way the default image boots on the Raspberrry Pi 4 in order to get synchronized IQ streams delivered to the gnuradio via eth0 KrakenSDR block configured on my other machine to talk to the IP address of the Raspberry Pi 4’s ports 5000 and 5001?
The easiest way to avoid the ports being blocked problem is to disable the krakenSDR_doa software from booting. The instructions under ‘Usage Instructions’ on GitHub - krakenrf/gr-krakensdr show how to disable the DOA code startup.