LimeSDR new set of tests

We use the latest commit in

Ubuntu 18.04

LimeSDR (HW: V1.4) flashed with latest firmware (Limeutil –update)

Scope: LTE SISO downlink signal

We use a custom OpenAirInterface version

The LimeSDR interface code is:


 LMS_LoadConfig(lms_device, );
 LMS_SetSampleRate(lms_device,4), “”); //rate is LTE standard one, so a division of 30720MS/s
 LMS_SetLOFrequency(lms_device,LMS_CH_RX, 0); // several feq tested 700MHz-3600MHz
 LMS_SetLOFrequency(lms_device,LMS_CH_TX, 0); // Tx/Rx freq are different, gap is defined by 3GPP
 LMS_SetGaindB(lms_device, LMS_CH_TX, 0, MyGain);
 LMS_SetGaindB(lms_device, LMS_CH_RX, 0, MyGain);
 //value is 0…70, we saw the today limitation: it is not actually in dB, but still the range is 0…70
 LMS_SetLPFBW(lms_device,LMS_CH_RX,0,ChosenLTEBand); // 5MHz or 10MHz or 20MHz

First observation is: the API calls often fails: calibration reports failures

With some ini files, it is simply impossible to run successfully the above sequence.

With “good” ini files, we have to power-off the board before each trial.

The key problem is to make a decent .ini file, that is good only in a specific case: RF band, modulated band, power, …

Then, even with a good ini file, the result of the calibration is not repeatable, and often fails randomly (need to power off the LimeSDR board).

Measuring this DL signal

A USRP B210 output:

The best of LimeSDR can be close to this

Even in this best result, the DC offset is not well calibrated

Also it is not repeatable, and depend heavily of the .ini file we use

or non repeatable results

At lower frequency, LimeSDR is globally better

Leave a Reply

Your email address will not be published. Required fields are marked *