I have had this problem on three different hosts now - Ubuntu 22.04 (x64), Ubuntu 20.04 (x64) and NVIDIA L4T (Ubuntu 20.04 derived) for the Xavier NX.
I compile heimdall from source. Everything seems fine. kraken_test / rtl_test works on all 5 interfaces, without any error. rtl_daq.log also clear, just enumerates the devices and allocates buffers, no errors. iq_server.log is always empty.
I changed the ini from shmem to eth, and start with daq_start_sm.sh. No errors, starts up cleanly. I can see the rtl_daq is running as is iq_server. However, I cannot get gnuradio to actually connect. It seems that only one of the ports is being bound to (5001) by iq_server. So I just get an endless stream of messages that the ethernet connection failed.
The only time I have been able to get gnuradio to work is with a VM image (not an option for the NVIDIA board I am targeting). Not sure what I could be doing wrong - it seems I am following the instructions to the letter.
Any info or guidance much appreciated.
Is heimdall and GNU Radio all running on the same machine?
If one of the ports is stuck open you might just need to reboot and try again.
Worst case if port 5000 is used by something else on your machine, change it in heimdall_daq_fw/eth_server.h at main · krakenrf/heimdall_daq_fw · GitHub, recompile, and change the IQ server port in GNU Radio too.
Yes they are on the same machine. Port 5000 is not in use by anything else. It isn’t really that it fails to bind. What seems to be happening is it is getting stuck here:
Not sure why exactly. It looks like the decimator connects to this first without issue, and then iq_server just hangs on line 191. If I comment out the init_in_sm_buffer function call in iq_server.c it continues to bind and finish launching (but I assume without calling this of course it can’t work). Any ideas?
Hi, I confirm that there are some problem with using the ethernet interface. I use a Ubuntu Laptop and have been able to extract IQ samples from the data stream. But now my python scripts have broken and I am not able to communicate properly with the KrakenSDR.
When looking at the logs I found this which makes me believe this problems could be due to the same bug.
Sorry, if I stole the thread… Hopefully we can help each other 
Did you update heimdall from the GitHub recently? Or this problem randomly started happening after it was working? Does it work again after a restart?
I have tried two git commits, the current HEAD:
commit 1af9f470b2129519e9b9fa4ea5f28b0c6cca2c12 (HEAD -> main, origin/main, origin/HEAD)
Merge: 7c7c631 c525212
Author: krakenrf <78108016+krakenrf@users.noreply.github.com>
Date: Tue Feb 28 04:45:06 2023 -0600
Merge pull request #15 from redradist/bugfix/fix-recreation-shared-memory
Uncommented .unkink() methods and changed them to .unlink()
As well as what was in the VM:
commit 68f83be898abc8770052bffc7090a98d5f2afb58 (HEAD)
Author: krakenrf <78108016+krakenrf@users.noreply.github.com>
Date: Wed Aug 24 00:44:37 2022 +1200
Update daq_chain_config.ini
In both cases the same result, it hangs on the fopen call in sh_mem_util.c I mentioned above. It is really bizarre - fopen hangs on _data_control/fw_delay_sync_iq but it does exist. Strange. Any thoughts?
I did an update recently because I was having some trouble with my first install, a lot of samples were dropped. After the re-installation I am not able to connect to the Ethernet port at all.
I am running Ubuntu 20.04.6 x64 on a laptop. The only trouble I can think of would be if the new and old installation are interfering with each other
In my case, it ended up being because I wasn’t properly executing within the conda environment by running daq_start_sm.sh manually.
Interesting, I will look into that. Nice that you found the problem!
I can also add that I did run my modified RTL_receiver from the wrong folder and thus, I got file not found. Once that was fixed I could sample packets again.
1 Like
