Digital filtering using LimeSDR

I am trying to use a LimeSDR board for some simple digital filtering - initially just performing a phase shift and attenuation. I’ve read in the LMS7002M data sheet (under heading ‘Transceiver Signal Processor’) that there are there are general purpose FIR filters. I would really appreciate some help trying to access them!

I’ve downloaded the LimeSuite software and found the GFIRs in the TxTSP and RxTSP tabs, but when I try to change the coefficients I get the following error: ‘Error reading GFIR coefficients: invalid channel number’. Does anybody know what I am doing wrong? Does limesuiteGUI have a manual that somebody could point me to?

I’ve also come across the Control LimeSDR via SPI using Arduino MCU post. I’ve flashed @Zack’s gateware that he kindly provided to my board and am currently having a play with his example arduino sketch. Could this approach also be successful and allow my to do some digital filtering?

As you can probably tell, this is very new to me, so any help/ pointers gratefully received!

Thanks a lot!


@jane - I’d try designing the filters in Pothos or GNU radio first (They’re pretty much the same thing) and then fine tuning in Limesuite and then flashing to an Arduino, in that order. Let us know how your filter designs progress.


@ricardas or @Zack can also give you great pointers on this, too - Let’s hope they see this and reply back. They helped me through this when I was beta testing the LimeSDR a year ago.

73 de Marty, KN0CK

Thanks for the reply! I’ve got my SDR working in GNURadio! However, the most important thing for my application is performance stability over a few hours, with the actual filters themselves being simple. The in-hardware filters are attractive as I was hoping to gain improved stability by not needing the host computer/USB. Thoughts on this issue appreciated!

From the screenshot and error message I suspect that the chip has been left in non working/powered down state (result of closing SoapySDR wrapper or whatever).

'Error reading GFIR coefficients: invalid channel number', channel which you want to configure is not selected.
Try switching A channel->B channel->A channel selection at the top of GUI, that should restore correct channel selection, and you should be able to access GFIR coefficients.

Notice, in the screenshot the whole TxTSP block is not enabled, so anything you do in it will not have effect until it is enabled.

Thank you @ricardas! I’m now able to access the GFIR coefficients, however I can only see whats shown in table below, I can scroll up and down ok, but scrolling left to right has no effect and so I can’t actually see what the values are. Does the scroll work in your GUI?

Hi @jane,

Try the latest LimeSuiteGUI, please.

Sorry I hadn’t realised I didn’t have the latest version. It’s working now – thanks!

Hello Everyone, how are you? Can you give me some directions on how to use right the TxTSP and RxTSPs in LimeSuiteGUI?:

  1. What’s the Meaning of the “Length” (because the filter can have up to 40 taps and Lenth can be from 0 to 7)
  2. How ClkRatio works?

For example, I have this SSBSC signal:

In this case, GFIR1,2,3 are bypassed.
If I use any (or all at the same time) with only 1 tap = 1 (I think about it as a all-pass filter), then the output signal must be the same as the all bypassed case, but instead I have:

This is the configuration I have for the RxTSP:

@Zack, @ricardas , I don’t know why I obtain this behaviour.

Thanks in advance.


  1. Length sets the number of taps used, according to datasheet GFIR1 and GFIR2 can have up to 40 taps.
    GFIR1/GFIR2 Length = roundUp(CoeffN/5)-1, so for 40 taps Length=7, for 15 taps Length=2, etc…
    GFIR3 can have up to 120 taps, so it’s Length = roundUp(CoeffN/15)-1, so for 120 taps Length=7, for 90 taps Length=5, etc…

Notice that number of active taps are enabled in multiples 5,10,15,20… or 15,30,35… . So you have to set coefficients for all enabled taps. In your case if you want to have 1 tap, you have to fill other remaining coefficients with zeros, otherwise they might have random uninitialized values and give the result you are seeing now.

  1. If I remember correctly clock ratio needs to be adjusted according to used decimation.

If you have decimation bypassed, clock ratio=0
decimation 2^1, clock ratio=1
decimation 2^2, clock ratio=3
decimation 2^3, clock ratio=7
decimation 2^4, clock ratio=15
decimation 2^5, clock ratio=31


Thanks @ricardas, but i couldn’t make it to work.
From the image #3 of my first post (GFIR 2 and 3 bypassed), if Length=1 for GFIR1, then I have 10 taps. I click in the coefficients button and into the “coefficient count” field (when it’s always in 40 when I click in the button) I put 10, and fill with the coefficients: 1,0,0,0,0,0,0,0,0,0. When I click “Ok” I obtain the same signal as in the image #2. This only works in TxTSP.
If i click again in the coefficients button, the coefficient count field it’s on 40 again and I have all the 40 coefficients fields to be filled.
I’ve tried with the filter 0,0,0,0,1,0,0,0,0,0 (setting Length = 1 and coefficient count =10) with the same results, but when I click again on the coefficients button, the tap filled with the number moved to a random position instead of being in the position #5.

Another thing that happen is: if I set Length in 7, fill the first coefficient with 1 and the rest with zeros and I click in Ok, the Length automatically sets in 1 (both in TxTSP and RxTSP).


Hi @Lucas,

When filters are engaged, you have to use TSP clock inversion. Go to CDS tab, Clock inversion group. Here are RX TSPA and RX TSPB check-boxes.

1 Like

Thanks @Zack.
In CDS tab I have all check-boxes checked. If I un-check any TX/RX TSPA/B the signal in the image #1 is detroyed/gone.
In this case, if I set the all-pass filter in GFIR1 I obtain the same (destroyed) signal.

Hello everyone, how are you?
I tried this from another PC with the configuration that @Zack proposed, and I obtain this:

As the image clearly shows, the noise floor have raised a lot, the signal has a “good” SNR, but the constellation diagram is not a clear circle.
The configuration in LimeSuiteGUI is the same as in the first PC I tried this, but I don’t know why I obtain those differences.
I don’t know if the LimeSDR is working ok or there is another configuration I’m missing.
@Zack, @ricardas, @andrewback do you have a .ini testing the GFIRs with a known signal? I don’t know what to do.


Hi @Lucas,

Could you upload your register settings ini file somewhere, please.

Hello @Zack. Here is the *.ini File. It’s the same for both computers.

Looks like there was GFIR coefficients layout in memory errors in the API level.
Commited a fix, need someone to verify. @IgnasJ

Current layout is correct (or at least as intended). Coefficients are displayed based on their layout in the chip. If you enter lower than maximum number of coefficients, then software places them in the chip GFIR registers based on current interpolation/decimation setting filling unused registers with zeros.

Here are some sample .ini files with RX GFIR configured: