Strange TX burst before intended transmission - LimeSDR-mini

Soapy and gr-osmosdr related… just going out on a hunch here, but is your signal transmitted at DC or shifted somewhere away from DC (LO leakage? am I wrong here by much?).

I remember when I adapted my program to work on the Lime-mini, I had to shift away some kHz from DC in GNU radio specifically for this, as the USRPs did not exhibit this.
Take a look at this: https://github.com/kantooon/qradiolink/blob/next/gr/gr_mod_base.cpp
specifically the use of the rotator_cc before the sink.

I’m sure you could do this in a more elegant fashion somewhere else.

Adrian

I have a LimeUSB (not a mini) but I think I see the same, at least when using SoapySDR.

Here’s what I do

  1. Configure the transmission part (SoapySDRDevice_setSampleRate, setFrequency, setBandwith, setGain, …). I already start seeing noise around my TX frequency when using a high gain.
  2. Start the transmission stream (SoapySDRDevice_setupStream followed by activateStream): I see the strange noise mentioned
  3. After that I still see the noise around my transmit frequency
  4. As soon as I provide samples to send and the Lime transmits them, the noise disappear

So for me there are 2 things:

  1. The weird noise mentioned by the others, that seems to last around 55ms, corresponding to SoapySDRDevice_setupStream and/or activateStream
  2. The noise around my transmission frequency, before I start transmitting something (and even before I setup and activate the stream). To fix this, I send some dummy samples after activating the stream, as I don’t need to send real data at once

Maybe @Zack or @joshblum have some ideas.

Can someone from Lime shed some light on the matter? Maybe @andrewback or @Zack? Should I send some samples after activating the stream, just so that the noise disappears before I really start sending something?

No problems noted with my software (SDR Console), I suggest it’s the application rather than Lime at fault?

I tried transmitting with gr-limesdr, pothos (through soapy) and the gr-osmosdr sink (also uses soapy I think) and they all had the burst come out before the actual desired transmission. It is only observed before the first transmission.

Here is another report:

https://wiki.batc.org.uk/Using_LimeSDR_with_Portsdown#WARNING_-_High_Power_Output_During_Calibration_Before_Transmit

I’m using the Lime through Soapy, so there could be some bug in there.

There could also be issues in my code but I doubt it: I simply initialize the TX and then starts it, without giving it any samples to actually send at first (as I need it up for later).

I wanted to try something similar through GRC or Pothos, by using a delay block, but in both cases those blocks insert zero items at the beginning of the stream, meaning a stream of 0s will be passed at first (instead of nothing). In GRC I must connect the input of the TX or else the flow doesn’t start, and on Pothos if I don’t connect it the stream doesn’t start, so I wasn’t able to reproduce the same environment as in my code.

I do notice briefly on Pothos the noise happening at the very beginning of the transmission, as reported by others above, corresponding probably to the initialization phase.

SoapyLMS performs calibration by default. So it is possible that the signal before transmission is calibration running. There is “skipCal” option that can be passed to stream arguments to disable calibration.

I assume the calibration is done over the loop-back, is it leaking to the output port?

Thanks @IgnasJ,

I tried using skipCal = true when setting up the streams through Soapy, for both RX and TX.

I know it’s doing something because when skipCal = false (by default), I always get :

e[1me[31m[ERROR] Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)e[0m
e[1me[31m[ERROR] Tx Calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)e[0m

while I’m not getting those messages with skipCal = true.

Still, not matter the value of skipCal, I’m always getting:

  1. The weird noise mentioned by the others, that seems to last around 55ms in my case
  2. The noise around my transmission frequency, that seems to start after the previous noise, probably once the TX stream is started, and that doesn’t seem to stop until I start transmitting something. To fix this, I send some dummy samples after activating the stream, as I don’t need to send real data at once