High Level Software Architecture Block Diagram for Lime..?


I thought I’d start off by saying that I’ve been with the LimeSDR effort since February and have accrued a lot of information and various apps (Cypress for Windows and LMS7Suite for both Windows and Linux) to put the LimeSDR though its paces seeing it transmit and receive on various Amateur Radio bands - 2m (144 - 148 MHz), as well as operating it in the HF band using their down/upconverter in LMS7Suite. But I’ve yet to completely understand the underlying software architecture of the ‘Lime’ and have not seen a high level block diagram to know what the pieces are - especially the piece that’s controlled by the underlying OS (Ubuntu). It appears that they’re using a strategy very close to what Red Pitaya is using where there’s an underlying OS and the radio app is just loaded to reconfigure the radio subsystem for the application. I’m not sure that’s what we have right now using LMS7Suite that’s deployed onto a PC and just controls the Lime’s transceiver directly.

Just to level the playing field, I know we have BRILLIANT people working this with Andrew, Alex and now Simon being involved. I tend to be more HW centric and can code, but I’m looking at this from the angle re-implementing what I’m designing for the Red Pitaya where I have a driver board that will take the RF outputs and add Rx preamplication and Tx amplification so the Lime can operate to 5 - 12W in two channels and have 20dB of gain in Rx over a wide bandwidth.

Some have already built apps for the Lime (Andrew and his Bluetooth implementation using Pothos) and in time more will surface. But I’m not sure that all the team working this has the higher level block diagram of the Lime SW architecture and how the battle plan will be laid out for our goals. I would think first receive-only control of the Lime with traditional apps (SDR Console, HDSDR, SDR#, etc) to get the interest of a HUGE market - - I have a notion that Alex is already working on that (Alex please confirm). And now with Simon on board it’s possible he’ll be looking at this from his perspective with SDR-COM since Simon will receive a board next week (I’ve confirmed this with Ebrahim at Lime Microsystems).

I guess the purpose of this post is to seek alignment of the efforts so we’re working toward definite goals and as a team determine what those all are. I’m here to test what’s being implemented and confirm operation as that emerges, as well as work on the driver board for this - it’s coming along fine for Red Pitaya, but I want to get this fused to Lime soon, too.

So what do you all think? Let’s get the dialog started to make Lime an incredible product…!

1 Like

The credit for the driver software goes to @joshblum and the engineers at Lime Micro. The Pothos BLE demos also came from Josh — I simply ran them up and waved my hands about a bit :smiley:

A blog on the software architecture is planned.


Hi Marty,

I just got my LimeSDR board few days ago and this has been a very busy week for me. So, I have a lot of catching up to do and also get the board up and running on Linux. In exchange for the board, I have agreed to test it and provide one or more blog posts during the fundraising campaign, so that will be my primary objective here in the coming weeks.

Otherwise I will be working on integration with my SDR applications, namely gqrx and a new project I have been working on during the last few years (to be released soon).

I’m glad to hear that you are working on a hardware extension to give LimeSDR more TX power and better ears. Which frequency range are you targeting?

I will also be looking forward to your extension for the Red Pitaya since I have one and I would like to put it into hamradio use.

The LimeSDR and Red Pitaya are quite different designs IMO. The LMS7002 has sophisticated RF front end for wide frequency coverage and ADC/DAC integrated. It is connected to an FPGA, which is then connected to a general purpose PC via FX3/USB3.

The Red Pitaya on the other hand is really just a pair of ADC/DAC connected to a ZYNQ processor. The ZYNQ contains a small FPGA and 2x ARM cores, which can take the role of general purpose computer. In other words, the Red Pitaya can run standalone without external PC - at least in theory, there is still some software to be written for that.

1 Like


Thanks for writing back. I agree that the topology of the two platforms (Lime VS Red Pitaya) are different because of the RF transceiver device and the FPGA on the Lime, but I guess I saw the use of the underlying OS (Linux in both cases) as being the common thread in how the radio apps are loaded to characterize the configurable radio environment. But your points are well taken and I agree.

I’ve been prototyping the Red Pitaya tx/rx board on and off over the past month and this weekend I should have the transmit part nailed down, the receive portion has been in place since I started since it was largely lifted and dropped from my KN0CK HF Upconverting RTL-SDR receiver design. I just took that preamplifier and added it in - works GREAT on the Red Pitaya. The whole thing should be out of prototyping next week and I can send for the boards to be fabbed once I finish the layout. I can ABSOLUTELY guarantee that you will get one of these boards for the LimeSDR and if you twist my arm hard enough I’ll be glad to send you one for your Red Pitaya, too - FREE. All I ask is that you let me know when you have GQRX ready for Linux or Windows so I can test it on the LimeSDR.

The driver board itself is being designed to operate over a 2.0 to 56 MHZ bandwidth (generally, 160m to 6m). The receive preamp is good to 1 GHZ, but this first spin will be HF centric. Later, I may get the receive and transmit working well enough to operate from 160m to 2m, but that’s a stretch goal.

Anyway, I’m glad you’re aboard. I can completely understand that each developer will work on their specific apps. All I ask is that we all stay in contact with each other so we can also cross check our efforts with the other members of the development team. It’ll be a way to get fresh eyes on any issues that should arise while we’re all working the LimeSDR.

No kidding, glad you’re part of this, Alex…!

73 de Marty, KN0CK

1 Like


How good will this be on HF do you think?

1 Like


Well, and I can only tell you from personal experience using the LimeSDR with LMS7Suite, but to get the receive and transmit into the HF band you have to perform an upconversion in receive and a downconversion in transmit to make it work. The lower limit of the design is 30 MHz and you up/down convert from there. It works, but it is a little bit of tomfoolery to get there. When you get your board and load LMS7Suite I can help you with this. On the flip, from 30 MHz to its upper range at 3.8 GHz it’s largely unaffected from what I know of the design - you just tune and go.

Let me know if you need more info, Simon,

73 de Marty, KN0CK


In terms of how well it works in HF is largely unknown in receive, but I will play with it some this weekend and let you know. In transmit I know you take a power hit because of the output circuit not being optimized for it, but the driver board will make up for that. I think the same will apply for receive and again the driver board will do all that heavy lifting to preamplify and improve the receive sensitivity, but I need to confirm that.

Stay tuned…

73 de Marty, KN0CK

According to the data sheet the lower frequency limit can be extended down to 100 kHz using the NCO in the Transceiver Signal Processor, but perhaps that’s not supported in LMS7Suite.


All good - I’ll be interested to see how that works and will be excited to see the implementation. That’s the beauty of being a team on this - to find small details like this and bring it forward…

More to follow this weekend on my transmit side prototyping…stay tuned…!

73 de Marty, KN0CK


The LMS7Suite provides control for every register within the LMS7002M IC. Moreover, it has some embedded features such us FFTViewer, FPGA programing and more. So in short, yes you will be able to set up LiemSDR for 100kHz.

Alex (et al),

Here’s what my first spin of the Red Pitaya driver board looked like when I put it all together about a month ago, and will be re-spun for Red Pitaya, but largely be ‘lifted and dropped’ for LimeSDR, too. I found that the transmit driver circuit I put together i the first spin wasn’t as good as I thought it might be. I used a 2N3058 driver and then an IRF510 final. I wasn’t happy with the result. The IRF510 overheated - heatsink for the IRF510 was not shown in this picture for clarity on the layout - and the 2N3058 driver wasn’t appropriate for the 10mW input to produce enough drive for the IRF510. So this time I’m using a broadband driver RFIC that’s good from DC to 1.5GHz (and inexpensive) and then driving it with the IRF510 that’s good over the entire range from 160m to 6m with the ferrites I’m using. The Mini-Circuits MAR-8+ I used on a previous design for my KN0CK HF Upconverter boards that I installed in the RTL-SDR dongles and worked wonderfully for HF and will also work well beyond 6m in terms of 22dB gain receive preamplification. I’m not planning to low-pass/preselect for HF receive with this initial spin for either SDR, but it’s a consideration later on. Same goes for transmit - I’m not planning to roll-in the band filters for 160m to 6m for the transmit output, I’ll put that on a separate assembly that will be outboard for the SDRs (Lime and Red) and put an even larger amplifier out there (50W to 75W) that the SDRs can drive with the driver board, or just run through the band filter assembly for QRP operation.

Anyway, the purpose of this thread is to give you an idea of the size and topology for the driver board (potentially) for the Lime - it has to be a different board spin because the Lime doesn’t incorporate any I/O like the Red Pitaya does, but we’ll have to examine that further when I put that board spin together. This just gives you a sense that this isn’t ‘vaporware’. I’m off to do prototyping on it today in earnest to get this completed for both SDRs - the receive side is ready to go.


Great to see you in the fray…! Glad to get your input on this, too -



From the LimeSDR board I have I know that it doesn’t appear to have any external I/O immediately available for other functions (i.e. band switching, external T/R switching, etc) - - but are there any provisions for external I/O on the design of the existing LimeSDR on the board and on some sort of connector or circuit pads? I searched through the documentation I have and it’s not immediately apparent (forgive me if I glossed over it) but please let us know if that exists on the Lime and if we have access to it - thanks in advance!

Hey Marty,

There is a J18 connector on the board that is connected to FPGA IOs. This can be utilized for external switches control and etc.

1 Like


Thanks so much for that nugget of info - that’ll come in handy a little later on for the driver board I’m designing now for the Lime - thanks again…!

Great work Marty, this is going to be great, 5-12watts will drive most modern amps, I used a KX3 at 12 watts into my old alpha, and was getting 250watts out…

Iv built an amp for my UHFSDR that outs out 15mw driving through a vhf bandpass filter (another kit I can’t seem to remember it’s source – I’ll add it later) into a single module that I think is 3 stage amplification. With 16v supplying the amp puts out 70w fm/ssb. The vhf module is a fairly common one … I have one for 146mhz, 222mhz and 70cm … some day I’ll finish the 222 & 440mhz amps. …

Amps are built on RA60H1317M1 module. The bandpass filters are from HobbyPCB and are strip line with less than .5db insertion loss. .