Reproducible Cold Start?

Projects LimeSDR
1

I am having problems with the cold start of a Lime Mini 2. Unfortunately the circumstances are hard to describe and I cannot come up with a minimal example. Perhaps also I am overlooking something that is obvious for others.

I am using the driver from LimeSuitNG together with a LimeMini 2. Extending the example programs from the driver source I tx a complex sinus of frequency 10 kHz on a carrier of 53 MHz. Last week when I did the experiment everything looked fine and I got a very clean sinus on my spectrum analyser with a more than 60 dB spurious free signal.

Retrying the very same setup this week the signal looks bad exhibiting a lot of noise around the carrier, but still within the bandwidth, however, I have programmed using the FIR filters of the chip.

What I am unsure about is, what is the exact procedure to get the Lime into a clean state from where to start so the result will be reproducible? I remember having played around with the GUI last week, not sure having done something that modified the internal state, something that got lost since then. What is the recommended procedure to set up the Lime? Do you have some example code for that? What is the ini files that are mentioned in some places?

2

Sometimes if the USB is not plugged in properly, the device enumerates as USB 2.0 device, which severely limits the data bandwidth. Check if your device is enumerated as USB3.0 by command line interface. Also make sure if you aren’t using software built in debug mode, as in debug mode the data transfers might not keep up with realtime resulting in packet drops.

limeDevice
Found 1 device(s) :
0: LimeSDR Mini, media=USB3.0, addr=0403:601f

Which API function you used to do that? If you set GFIR coefficients manually, they have to be set after sampling rate and RF oversampling are already configured, because those parameters affect the layout and number of GFIR coefficients. If sample rate or oversampling is changed after GFIR coefficients were set, then GFIR will not work properly.

device->Init(); resets the device and loads default register values.

Ini files contain the register values of LMS7002M chip, so the state of the chip can be saved to file and loaded again.

3

I do a routinely check now that I know the Serialize() function includes that info:

[2025-10-26 15:33:45.663] [info] device opened: LimeSDR Mini, media=USB3.0, addr=0403:601f, serial=obfuscated

I am using this code:

      dev->Init();
      lime::SDRConfig cfg;
      {
        lime::ChannelConfig &ch{cfg.channel[0]};

        ch.rx.enabled = true;
        ch.rx.centerFrequency = freq;
        ch.rx.sampleRate = sample_rate;
        ch.rx.oversample = 1 << 5; // 32
        ch.rx.path = 3;            // RX1_W 0.03 - 1.9 GHz
        ch.rx.lpf = 2.5e6;
        ch.rx.calibrate =
            lime::CalibrationFlag::DCIQ | lime::CalibrationFlag::FILTER;
        ch.rx.gain[lime::eGainTypes::LNA] = 30.0; // 0 ... 30
        ch.rx.gain[lime::eGainTypes::TIA] = 9.0;  // 0, 9, 12
        ch.rx.gain[lime::eGainTypes::PGA] = 0.0;  // -12 ... 19
        ch.rx.gfir.enabled = true;
        ch.rx.gfir.bandwidth = 2e6;

        ch.tx.enabled = true;
        ch.tx.centerFrequency = freq;
        ch.tx.sampleRate = sample_rate;
        ch.tx.oversample = 1 << 5; // 32
        ch.tx.path = 2;            // TX1_2 0.03 - 1.9 GHz
        ch.tx.lpf = 5.5e6;
        ch.tx.calibrate =
            lime::CalibrationFlag::DCIQ | lime::CalibrationFlag::FILTER;
        ch.tx.gain[lime::eGainTypes::IAMP] = 0; // 0 ... 63
        ch.tx.gain[lime::eGainTypes::PAD] = 44; // 5 ... 55
        ch.tx.gfir.enabled = true;
        ch.tx.gfir.bandwidth = 2e6;
      }
      cfg.skipDefaults = false;

      ops = dev->Configure(cfg, 0);
      if (lime::OpStatus::Success != ops) {
        warn("configure returned nonzero status {:d}", unsigned(ops));
      }

      lime::StreamConfig strcfg;
      strcfg.channels[lime::TRXDir::Rx] = {0};
      strcfg.channels[lime::TRXDir::Tx] = {0};
      strcfg.format = lime::DataFormat::F32;
      strcfg.linkFormat = lime::DataFormat::I12;

      strcfg.extraConfig.rx.packetsInBatch = 8;
      strcfg.extraConfig.tx.packetsInBatch = 8;
      unique_ptr<RFStream> stream = dev->StreamCreate(strcfg, 0);
      stream->Start();

The frequency is 53 MHz, the sample_rate is 4 MHz.
Then I initialize a software oscillator:

complex<double> w = exp(2.0i * acos(-1) * double(tone / sample_rate));
complex<double> y = conj(w);

And run a loop:

      while (0 == signal_status) {
        complex<float> *rx_wrap[1]{rx_buffer.data()};
        uint32_t rc = stream->Receive(rx_wrap, rx_buffer.size(), &rx_meta);
        tx_meta.timestamp =
            rx_meta.timestamp + 2 * rx_buffer.size() / sample_rate;
        tx_meta.hasTimestamp = false;
        tx_meta.flags = 0; // StreamTxMeta::EndOfBurst;

        for (size_t n = 0; n < tx_buffer.size(); ++n) {
          tx_buffer[n] = 1.0 * (y *= w);
        }
        complex<float> *tx_wrap[1]{tx_buffer.data()};
        uint32_t tc = stream->Transmit(tx_wrap, tx_buffer.size(), &tx_meta);
      }

The result looks like so after having cold plugged the Lime:

Bildschirmfoto vom 2025-10-26 15-03-30
Bildschirmfoto vom 2025-10-26 15-03-301047×653 213 KB

Now the discovery from today. If I run my old code (a amateur radio beacon), that is based on the legacy LimeSuite results get interesting.

  1. The beacon signal, which besides generating some OFDM packets als generates a plain CW signal which looks clean, i.e. almost no I/Q imbalance and no intermodulation.

  2. Now after I have stopped the the beacon and start again the very same test program from above I get the following result on the spectrum analyzer:

Bildschirmfoto vom 2025-10-26 15-34-01
Bildschirmfoto vom 2025-10-26 15-34-011047×653 154 KB

This puzzles me:

  1. The init() obviously does not guarantee a fresh start, because the only explanation to me is that there must be some left over state from my legacy beacon.

  2. The configuration done with the LimSuiteNG must be incomplete, because some parts done by the legacy LimeSuite are missing.

Hopefully you can give me some insight how I could resolve the issue.
Regards, Roland

4

I have found, using a Mini v2.4 with LimeSuiteNG, that I need to initialize the devices twice in order for them to function properly. I realize that doesn’t make a lot of sense, but once it is realized that is necessary it isn’t a problem.

5

Should be fixed now: limesdr mini: fix sampling rates <5MHz after cold start · myriadrf/LimeSuiteNG@4d86388 · GitHub

limesdr mini FPGA gateware requires interface clock phase configuration, software does that only for sampling rates >5MHz, so in this case after cold start a 4MHz sample rate was being used, therefore clock phase was using default values, which are not always suitable. After any configuration that was setting sampling rate >5MHz, it would set better clock phases, and therefore going back to 4MHz sample rate would start working good.

6

Looks fine. Many thanks for the fast fix.