I have been working on establishing a communication link between two LimeSDR Mini’s. I want to use any BPSK modulation which is available with Qradiolink and make these devices communicate with each other. I have installed all the dependencies and Qradiolink (branch gr_3.8_port) with GNURadio 3.8. When I try to run FM for testing with LimeSDR Mini in RX mode, it detects the device but is not able to initiate it. It gives a following message on console:
[FATAL] Could not init TX device, check settings and restart
I am unable to fix the issue with the setup. Could you let me know how to go about it? Does QRadioLink work with GNURadio version 3.8 or I need to install 3.7.X version to get it to work. Moreover, what settings I need to use to get LImeSDR Mini working with QRadioLink?
Any suggestions or pointers to resolve the issue are highly appreciated.
What is the device string you’re using? Does SoapySDRUtil --find detect the device?
If it does, check that gr-osmosdr has been compiled with SoapySDR support. You may want to build it from source instead of using your distro’s package. And you haven’t mentioned the operating system.
Device string: soapy=0, driver=lime
SoapySDRUtil --find detects the device and gr-osmosdr is also built from source with SoapySDR support. I am using ubuntu18.04 (bionic).
I have now tried installing Qradiolink (branch - master) with GR3.7 version with freedv support and gr-osmosdr for gr3.7. It now detects and initiates RX on LimeSDR Mini but when I try to run TX with it, it gives the same error as before:
[FATAL] Could not init TX device, check settings and restart.
That is a failure mode I haven’t seen before and can’t reproduce with either the LimeSDR-mini or the LimeNET-micro.
Just to confirm, you are using the same device arguments for both RX and TX chains right? Does TX work when RX is not started?
Please list the versions of SoapySDR, the SoapyLMS plugin and LimeSuite that you have installed.
The error you are quoting (Could not init TX device, check settings and restart.) should be preceded in the console output or log file by other errors which come from somewhere deeper in the stack, it is gr-osmosdr that would report them but can originate from anywhere below. If you can’t run both TX and RX simultaneously (which is strange if you have the right device arguments) that suggest an USB context lock issue and I have no suggestion for that except to use your distro’s normal support channels (forums, mailing lists).
Yes, the device arguments are same for TX and RX. Have tried running TX before starting RX but it still gives same error. Moreover, Rx is initialised only when I used GR 3.7 with master branch of QRadioLInk. However with GR 3.8 version and gr_3.8_pot branch it gives same error for RX also. Moreover, when i run ./qradiolink to open another session , it takes couple of minutes to open and sometimes doesn’t open. I have no idea why that’s happening.
Sounds like you got the wrong antenna configuration. My advice: use Auto for both TX and RX and LimeSuite will do the right thing (since latest versions).
Thanks for your reply, it fixed the issue of TX and RX being initialized.
Now I am facing another problem. When I try to transmit file/text using BPSK1K/2K, and test with spectrum analyser to check if TX is actually transmitting or not, I see a peak at tuned RF frequency but the console shows that 0 samples are being popped out of TX. I am not sure why is that happening even when I select a file to be transmitted.
This results in RX not receiving anything and how to ensure that it is synchronized with the TX. Any pointers to fix this issue are highly appreciated.
The “send file” action is incompletely implemented and not yet available in the next branch.
Try either “send text” or “text file beacon” (which just takes a text file and sends it in a loop). To interupt the loop just press PTT twice until the red led goes out. You can also send over the air text messages obtained from the internet via the Mumble server conection (with “forward radio”). Try them first on the same device using Duplex mode and then move on to two devices and machines.
Also, make sure that TX and RX calibration is successful. TX calibration can fail if your gain is set too low. I had a similar issue to what you describe with an early model developer board, but both the 1.2 mini and the Lime-net Micro are fine now and I can’t reproduce this.
But do make sure to pull the code from the next branch first as I noticed a small regression introduced recently in the PSK receivers and pushed a quick fix this morning.
Thanks for your quick reply and clarification.
The TX and RX are calibrated completely when I am running this. When I use “text file beacon” , I can see the red LED go on until I stop it by pressing PTT twice. I tried using duplex mode with TX and RX both using BPSK 1K with zero as well as non zero frequency split between them. But for both the scenarios, the program prints following on console:
[Warning] Blocked attempt to set TX frequency outside of configured band limits
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8306:(snd_pcm_recover) underrun occurred
Also what RX is receiving is just noise since the constellation is not observed and it keeps displaying “Radio timeout” at regular intervals.
Moreover, I also tried running just RX with BPSK 2K mode and there is no TX running on another machine. Now when I rotate the position of clarifier, RX starts showing BPSK constellation without transmitter being sending anything. This is strange and I am unable to decipher this behavior. Could you please explain that what is the role that clarifier is playing?
Would be great if you could point me in the right direction for correctly setting up this duplex mode/ communication link between TX and RX using QRadiolink.
Ok, so this is probably not yet in the manual, but here goes: by default the transmitter will only operate within the amateur radio bands (IARU region one) for your own and others safety. Since I did not put in a table with other IARU regions frequencies, there is a setting for TX band limits that you can disable in the “General settings” page, but do this at your own risk. I recommend using a TX frequency around 433 MHz since this is an almost universal ISM band.
The Alsa underrun messages suggest you are not using a Pulseaudio sink and go to Alsa directly. Alsa will probably work for you but might need some configuration which is described in the readme. You can also try to choose another audio device if you have many in the list. Going in depth regarding the Linux audio system is out of scope here and you need to do your own homework regarding this.
The Split setting near the Duplex mode button is just the TX offset relative to the displayed frequency. Duplex is exactly what it says. The device will transmit and receive at the same time. Whether it does so on the same frequency or not depends on your Split value in kHz (you want 0 to use the same frequency for both RX and TX). If you transmit in duplex mode on the same RX and TX frequency you will receive and demodulate the signal that you transmit with exactly the same frequency (no ppm offset) since the clock is the same. It’s really not that complex (pun intended).
And finally, if you see a BPSK constellation, that means there is a BPSK signal there. Without a signal all you will see are many random dots.
@adim: Thank you so much for your prompt and useful replies. I was successfully able to run QRAdioLink on two systems with two devices communicating with each other in half duplex as well as in full duplex.
When I started working on the BPSK communication system with SDR, I tried implementing packet-communication in GNURadio using two systems each acting as TX and RX. Using the examples provided in gr-digital , I tried running TX and RX with LimeSDR Mini, but was unable to get them to work. In order to identify and solve the issues, I moved on to implementing everything in step-wise approach, as in-
Transmit just alternating 1’s and 0’s using BPSK modulation and receiving it on other end using synchronization and demodulation.
Introduce packet structure into the previous raw-communication model .
Then add FEC into the system and finally include CRC and achieve the same packet-communication as provided with gr-digital.
In this step-wise approach, I was able to get raw communication model (point 1 in above) work properly. However, I was not able to get packet version (number 2) working. I used the same system setting just the introduction of packet structure at TX and correlation estimation & header-payload demux at RX but still no luck. That’s when I tried out QRadioLink. However, my aim is to get the GNURadio implementation working.
I was wondering if anyone could help me out or suggest some pointers so that I am able to fix the problem.
Go take a look at the source code of qradiolink, especially the GNU radio flowgraphs in the gr/ directory, to understand how it’s implemented. I’m not using the correlation estimator for some reasons, so the weak signal burst performance might not be the best possible. Also, I could do with better FEC than convolutional code, but my time is also limited so I have to draw a line somewhere.
For a more advanced example, look at the IP network layer 2 modem which does preamble and CRC for frames as well, if you don’t mind it being DQPSK or 4FSK instead of BPSK. You’ll have the full IP stack and be able to use any upper layer protocols you want to transfer files and stuff.
Thank you for your reply. I started understanding and working through your gr codes. I tried implementing GNURadio flowgraph using the codes in gr directory of QRadioLink. I have created a simulation model with channel between the TX and RX flowgraphs defined in gr directory. It can be found here:
I am unable to understand how in your codes you are managing to detect the start and stop of a packet if you are not using Correlation estimator or preamble. Moreover with this implementation I observe BPSK modulation but its quite noisy as well as the data received is erroneous.
Could you suggest some pointers/documentation to look into to fix the problems.
The packet headers, preamble addition, header detection and frame assembly are all done in src/gr_modem.cpp
This is done for historical reasons outside of gnuradio. Originally the modems did not use gnuradio and this part has remained unchanged.
