Hello everyone.

Sorry if I’m about to ask very stupid questions, but I spent the whole weekend scratching my head over this and I can’t find clear information about it.

I want to make some application for LimeSDR in my free time. I plan to do a GUI and program the transceiver for starters. It’s just a test to get around with LimeSDR at a deeper level. But the lack of tutorials is keeping me from making huge advances. So, keeping in mind that I just want to program a radio receiver GUI to listen to the radio stations in my neighbourhood and, just for fun, displaying the FFTs, I have a few questions:

  1. What is the difference between the LMS API and the SoapySDR API? What should be better for me to use in my program? I have played around with the LMS API and it is relatively easy to, for starters, communicate with the board. But then I found out about the SoapySDR API and I’m intrigued about what each one represent.

  2. Do I need to program anything with the FPGA or the FX3 (or use them in any sense) to program a simple radio receiver? And what if I intended to use a transmit+receiver? When should I attack them?

Again, sorry if these are stupid questions, but this is bugging my mind so hard. I hope the questions are clear enough. Thank you.


Both are abstraction layers from the physical hardware, to make using them easier.

If you write an application for the SoapySDR API it could eventually work with any hardware with SoapySDR API support. So if it was RX, that would include: Remote access, Audio devices, Osmo support, NovenaRF, EVB7, UHD, Blade RF, Hack RF, RTL-SDR, SDR Play, Red Pitaya, Lime Suite, Airspy, PlutoSDR. And in theory for TX: Remote access, Audio devices, Osmo support, NovenaRF, EVB7, UHD, Blade RF, Hack RF, Red Pitaya, LimeSDR, PlutoSDR.

If you write an application for the LMS API it should work for any hardware with LMS API support (LimeSDR, NovenaRF , EVB7, and soon the LimeSDR mini).

There are advantages to both. One is closer to the hardware (more tweaks possible), one is more generic (more supported hardware) one application fits all (or most). In the case of the LimeSDR the , the SoapySDR API stands on the shoulders of the LMS API, so there may be ways to pass less generic options to the lower layer.

I’m not sure, but I suspect that should be taken care of by the abstraction layer. Maybe someone else can clarify.