Hi,
I’d like to announce that the pre-release 0.8.0-alpha1 version is ready for testing by users. The transceiver application has received a graphical re-design with UI elements from Gqrx and contains improvements to the digital voice modes, audio compressor, multiple sample rate support up to 4 Msps and some performance tweaks.
The new interface gets rid of the GNU radio Qt GUI elements and is based entirely on Qt5.
Of course, QRadioLink still supports the LimeSDR and Lime-mini through SoapySDR.
Since there is no release build yet, users can test alpha1 by building it from the “next” branch of https://github.com/kantooon/qradiolink
A release will follow in the months to come after any issues found are ironed out.
Any support for HF (at least 2 - 30 MHz)? Please let me know - I’d give beta testing a go. Also let me know if this is an open source project or not. I would be adding the LimeRFE API calls to any open source code to try and integrate it, too.
Hey Marty,
What do you mean by support for HF? The software is agnostic to what frequency you use it on. You can use it on LF, HF as well as Es’hail 2 as long as your hardware supports it. The frequency counter only goes up to 9.99 GHz but only because there are no mass-market SDRs that go higher. Easily fixed by changing a single line of code, same as the highest sample rates for the FFT.
With regards to the license, being based on GNU radio means it’s GPLv3 with some BSD and public domain code sprinkled in. If you want to contribute, make pull requests towards the “next” branch here: https://github.com/kantooon/qradiolink/
Any contributions will be appreciated since I have limited time and the code base gets bigger every time I add something new.
I need to put Linux on a computer for this. Looks pretty good to me.
The Git shown that it’s Debian Stretch for an OS. I would like to confirm that.
One thing that I “Think” I understand about the QT SDK is that it is cross platform.
Now, for the biggie, can it be “Ported” to Windows? If so, that would be great for the casual users, that are not well versed in Linux.
I am getting ready to move in a month or so. Because of that, all of my test gear & LimeSDR-USBs are packed away.
I personally am interested in 2-50 MHz, which is not supported to well by certain developers, which is a shame.
I look forward to trying this out in November, when I am at the new house & all set up.
Thank you for your work on this & if there is hope of a Windows version, many will “Contribute” to the cause.
I’ll give it a spin this evening and let you know my findings on it. You could run this in a VM from a Windows machine, but still under a Linux OS client. It’s not like it’s on a Windows machine, but it does give you the ‘one stop shop’ of being on a Windows PC but running it on a VM Windows client. I am intrigued that this is ‘frequency agnostic’ - let’s hope that translates to running well on receive and transmit for HF using the Lime…In six to eight hours I’ll know that…Please do stay tuned…!
It’s good to know that there’s that kind of operation with it, but as you should know well the LimeSDR-USB requires that you use the NCO to travel into the HF Band, meaning, that if you want to operate at 3.970 MHz, you have to set the NCO to 26.03 MHz (approx) to make it transmit and receive there. If that isn’t set, no one is going to operate HF on the LimeSDR-USB. I think the ‘Mini’ is a little more straightforward in that it’s set (published) to operate from 10MHz to 3.8 GHz and you just set the frequency - - I don’t think there’s an NCO to play with on that one, but I could be wrong.
Thanks for the link on the Github repo for pulls on the current build. I am VERY VERY interested in looking at the transmit receive side of the code to apply elements of the LimeRFE to be keyed from your software, so I will look into this further. Again, thanks for sending me the link to the pull repo for this project.
Please advise if this has been checked with the LimeSDR-USB or just with the Mini - thanks,
Hey Marty,
The gr-osmosdr API has no call to set NCO frequency, so I assume that it will be handled internally via SoapyLMS and the limesdr library. I didn’t test this feature, but if gr-osmosdr does not do the right thing, then support for this feature should be added to the gr-osmosdr library. You actually made me curious, now I have to go dig into the code of gr-osmosdr.
Ed, I don’t see why it could not be ported over. Most of the code should not need much tweaking, however the video feature is using V4L2 which is a Linux kernel thing and would need to be removed completely. Also, the audio layer is specific to Linux and would need to use something else on Windows (OpenAl?). I don’t program on Windows so not sure how much effort that would take.
Well, the last honest programming I did was on a TRS-80 color computer (16K). So, it is not my forte’.
Hopefully, Marty can assist, along with others.
If it truly works HF as is, I will do the Linux thing.
I appreciate your endeavor.
With the default settings (1 Msps, 32764 FFT size, 15 FPS) I got the perfromance to a reasonable 24% of CPU usage on my laptop. Disabling the FFT/waterfall display or minimizing the window allows me to listen to local FM stations with low (10-15%) CPU usage.
I have some ideas how to improve the scanner. Again, useful if you don’t use the graphic display to find signals.
I think I can finally implement a quick way to calibrate the S-meter on a reference signal. The calibration would have to be done for each device setup separately though.
Spread spectrum quite simple and possible now with some of my latest GNU radio forays.
The bad:
High sample rates (30 Msps or more) will use up to three cores at 100%. I don’t see a way to solve this without FFT on the FPGA and OpenGL display. Both hard.
Video RX is still a CPU hog mainly due to the high sample rate required to demodulate. I don’t have any solution as of now. Also, still no sound on video, because the video framerate is different to the audio packet rate.
I still get apparently random segfaults in libjpeg even though video frames have the correct CRC.
DMR, Yaesu C4FM, D-Star. All these modes use Ambe, and adding TX/RX support means having to use the only open source implementation, mbelib. However, Ambe is covered by patents, so not sure how to progress. Also, these modes require Yaesu, Icom hardware to test, lots of $$$ for basically zero usage in my area.
GNU radio released 3.8 recently. This removed some of the old blocks and added new ones. Building against 3.8 will probably not work at all because of that. Until my distro has it packaged, I probably won’t look at this.
The ugly:
The build system. I have close to zero package maintainer experience. I can give half reasonable instructions for Debian, but users of the rest of the distros are on their own at the moment, except for Opensuse where Martin Hauke has done the packaging.
Text messages and file transfer. Basically I put no work into this in the last two years, so whether they work is a question of luck.
Video quality is still bad because I’m using libjpeg instead of a modern video encoder. If anybody knows any encoder/decoder that is open source, supports constant bitrate and does not hog CPU, please let me know. The ffmpeg API is Chinese to me.
DVB-S2. Seems worth investigating, but even with Ron W6RZ’s bullet proof implementation it’s still a monster that is difficult to understand for a beginner. I kind of like the very simple homebrew video that exists currently.
DMR TX and any other TDMA modes need real-time or at least possibility to timestamp bursts of signal. Right now only Lime and UHD devices can do that. Using gr-limesdr and gr-uhd directly is possible, but would leave other hardware users behind.
Thanks to a few users who tested 0.8.0-rc1, we’ve identified some issues that were fixed in 0.8.0-rc2. Highlights of this release candidate like full duplex operation and improved tuning mode are presented in the video below. A known issue that can’t be fixed is that some devices don’t support operating the transmitter and receiver at different sample rates. Since the transmitter always uses 1 Msps regardless of what the receiver is set to use, this can be a problem sometimes. The workaround is to switch to 1 Msps for the receiver before starting the transmit cycle or to use two separate devices for RX and TX.
Marty,
In my opinion, the latest versions of LimeSuite (19.04.0) automatically set the NCO frequency and offset if the frequency is set below 30 MHz and I once tested and checked through the LimeSuite GUI that NCO was turned on.
Thanks very much for the report on that. I’m attempting to set up QRadiolink on my Ubuntu (Bionic) PC and get it running this evening - ran into a compiler issue that @yindra helped me through and hope to have that running this evening and try the Lime on HF. If I get it running on my Linux box, then my next trick will have it running on a non-root Linux distro that I can install onto either a Samsung J7 or my LG smartphone and set up UDP audio routing for it or run it via the server.
More as I have it later this evening - stay tuned…
Marty, when you start with it, make sure to keep up to date with latest code from next. I’ve only just begun to heavily test the Lime-mini with the full duplex mode introduced recently and I have many problems and I’m still working around them one by one.
See one example here: TX/RX turnaround time with Pluto compared with the Lime mini.
I hope you can confirm this is because of me using a preproduction board with an old version of LimeSuite libraries.
Can do - I have both the Lime Mini and it’s current in terms of its firmware as well as the LimeUSB that is also current firmware load. I need to straighten out a compiler error I’m having (GNU Radio Companion dependencies not in the right place to what the makefile needs) and once that’s corrected and I recompile it should be capable of doing testing later tonight. I’ll keep you advised of my findings on that when I have that info available - please do stay tuned…
Marty, why are you not using your distro’s provided packages for GNU radio? I see Ubuntu bionic has 3.7.11 https://packages.ubuntu.com/bionic/gnuradio , which is newer than what Debian Stretch had. I haven’t compiled GNU radio from source since at least 2009, the distro ones are usually good. Just apt-get install them and hope for the best. And don’t forget the devel packages with the headers.
The only things I build myself are osmocom libraries which tend to be older in Debian and some of their dependencies, exotic Soapy plugins which are not shipped by the distro, external GNU radio modules that are not in the main tree etc.
I don’t use any external module right now.
