I do write software that uses the LimeSDR, but it’s usually application-specific. So far, I’ve been using SoapySDR to interact with it due to the simplicity of its API.
I have never used SDR Console. I see it is closed source, so there’s no easy way to modify it.
The world of SDRs reminds me of the early days of computers and operating systems. Everyone has their own way of doing things, and it is up to the person using the product to adapt, rather than manufacturers following a certain standard (though it’s not as bad as it was back then). This is why I like APIs like SoapySDR. It gives me a common framework to work with. Sadly, there’s still a lot of workarounds and extra stuff to do when it comes to each individual SDR apparatus. There’s no global way of saying: tune to frequency X. With the LimeSDR it is: tune to frequency X, but if you can’t, try adjusting this parameter until you can, then change your filter bandwidth, recalibrate your receiver, and when you’re done let’s get this stream up again. All of that should be covered by that one simple command to change the tuned frequency and the rest handled by either the hardware or the driver.
Whether it’s the RTL-SDR (I need to send the tuning command multiple times for it to really change the center frequency), the USRP (this one works wonders… when the Linux part of it doesn’t crash), the LimeSDR or any other, they all have their own specific quirks that make development painful. 99% of the time, all I need is a way to change the frequency, select the sampling rate, and exchange data (I’m not even including gain in here, most radios I’ve used do better on hardware AGC than on fixed gain). The other features and configuration options are all for very specific optimizations that I’ve very rarely used. The main goals of using an SDR are to have frequency agility and to apply DSP on top of a data stream. For application developers, an SDR transceiver is just a tool to get the RF signal into a data stream and vice versa. It doesn’t matter how the tool works underneath, as long as it works.
I’ve built satellite and communications-related software with the RTL-SDR, the USRP, and the LimeSDR (had to switch radios throughout development – USRP had reliability issues, RTL-SDR had quality issues, LimeSDR had configuration issues i.e. overly complicated) and the easiest one to get working was the RTL-SDR, but the frequency stability, the quality of the signal received and the sensitivity made me switch to the LimeSDR. However, with the LimeSDR, I almost always feel like I’m spending more time writing drivers rather than DSP. The research work I did at university required to cover a very wide bandwidth (as close as we could get to 200 MHz), and I have not been able to get the LimeSDR transfer data at or near its maximum sample rate on a single channel without stuttering (USB is horrible for that – it’s a poll system, not a push system like Ethernet). The board is limited in the maximum transfer bandwidth despite the ADCs being able to push even more data through (limitations of the Altera Cyclone IV if I recall correctly). Using both channels to receive was then limited by the USB data transfer speeds, and we didn’t even have transmission in there yet. We tried using multiple transceivers (we had to use 2 anyways, we tried going up to 4), but the synchronization of the whole system was overly complicated, so we went for a different SDR that supports USB3.1 gen 2 speeds (10 Gbps) and also works through PCIe x16 at full speed (around 30 GBps at that time), but that’s a story for another time.
Having access to all of those configuration options for the LimeSDR is both a curse and a boon. It gives more flexibility to developers, but increases the development time and the risk of bugs. I can understand why some developers would rather not add a lot of extra code just to support one radio for a feature that should have already been supported but needs a workaround to work.
In short, yes I do develop software for the LimeSDR (through the SoapySDR API, so really for any SDR supported by them), but no, it is not general purpose RX/TX programs – I work on application-specific software and DSP.
73 de VE2ZJD