[LimeXTRX] Strong Tx burst before sending data with SMA cable

[Petimothee]

Hi everyone,

I’ve been trying to run a protocol on GnuRadio using the LimeNET Micro 2.0. This protocol works on USRP, but does not seem to work yet for the LimeXTRX. I first try to send a SYNC message as a quick burst from the Lime XTRX, and receive it on the USRP end. Since I couldn’t receive anything, I analyzed if I saw this message or not on an Anritsu Spectrum Analyzer, connected directly by an SMA cable to the LimeXTRX Tx/Rx port. However, I do not seem to capture this burst, which would explain why my protocol is not working.

Instead, I see a very strong burst before my program starts streaming samples, almost up to -15dBm in power, which I find is extremely high and potentially dangerous to a USRP on the receiving end whose maximum input power is -15dBm, if one intends to transmit and receive with SMA cable + attenuator.

To simplify debugging, I sent a normal cosine signal at a signal frequency of 250kHz and an LO frequency of 433Mhz from the LimeXTRX to the Anritsu SA. The spectrum is shown below, where:

• Green trace is the max hold power of the signal transmitted from the LimeXTRX Tx/Rx port during the program execution (capturing the same very strong initial burst).
• Yellow trace is the Clear/Write instantaneous power of the same signal.

We can see that, while the instantaneous trace shows the correct tone at freq_LO + signal_frequency, the green has captured the very strong initial burst I was talking about. I think that this strong burst could explain why I’m not receiving my SYNC secondary burst in the first place, and it looks like it’s happening regardless of the executed program.

Instead, I should be receiving the following OFDM burst of my SYNC message. This is what I correctly receive when I transmit from the USRP instead of the LimeXTRX.

It is important to note that I do not receive the same initial burst when I transmit and receive with 433MHz dipole antennas. It is a much weaker burst:

In the figure above, the peak on the left is the intended cosine signal, while the peak on the right is the initial burst.

What is this initial burst signal, and how can I avoid it?
If necessary, I can send you my code.

Thank you for your help,
Timothee Mac Garry

[ricardas]

@Petimothee

What is this initial burst signal, and how can I avoid it?

That burst is most likely calibration procedure for DC and IQ imbalance, or some state during chip configuration step.
It would be best to see your code.

[ricardas]

Should be fixed in: xtrx: remove unnecessary lms7002m register defaults, and disable tran… · myriadrf/LimeSuiteNG@d18640e · GitHub
During startup, for a brief moment the chip was being reset with default values which had the transmitter enabled, and only after that user configuration applied.

[Petimothee]

Hi Ricardas,

Thank you very much for this fix. I analyzed the spectrum, and indeed the strong Tx burst at +500kHz from the LO frequency is gone! However, there is still a very strong DC signal when I turn on transmission, which increases as I increase the Tx gain as well:

Hence, when I send my SYNC, it is actually at a lower gain than the initial DC signal in the center:

Hence, this strong DC burst does not let me receive it on a USRP because it crashes beforehand with this error, which usually arises when the input signal is too strong for the USRP receive and decode properly.

Usually, this burst stays after I have exited the GnuRadio transmission, which is also inconvenient because I have to do limeConfig -i to reset it and make it disappear.

Would it be possible to remove this DC signal as well, or at least mitigate it? On the USRP, this does not occur, which leaves me space to receive my message properly.

Thank you for your help again, it very much appreciated.

Timothee Mac Garry

[ricardas]

I’ve added option to Sink/Source blocks to enable DC & IQ imbalance calibration, it should reduce the DC spike. gr-limesuiteng: add DC IQ calibration option · myriadrf/LimeSuiteNG@0d7178d · GitHub

[Petimothee]

Hi Ricardas,

Thanks for your help, enabling the DC & IQ calibration removes the persistent DC signal I was receiving! I’m now, however, receiving an initial burst, though different from the previous one:

The yellow trace in the figure above captures the initial burst when transmitting with the LimeXTRX at a tx_gain of 30. I increased the gain to 50, and as you can see in the figure below, the burst also grows with the gain.

In my protocol, I receive my signal perfectly well with the LimeXTRX when I transmit from the USRP. However when I transmit from the LimeXTRX and receive with the USRP, it is giving me this error again:

The good sign is that the USRP is not crashing upon reception, I presume because it is not receiving the very strong and consistent DC signal. However, it still cannot decode the OFDM signal properly from the LimeSDR. To make sure it wasn’t a problem with my OFDM chain, I tested the protocol again with 2 USRPs, leaving the LimeSDR out, and it worked very well.

My guess is that the problem is related to the initial burst. Would it be possible to remove this burst as well when I start any GRC program?

Thank you,
Timothee Mac Garry

[ricardas]

Now this burst, is the DC&IQ calibration procedure. Alternative would be to manually set the DC corrector values, but they are dependent on LO frequency, gain, temperature, so the optimal values can vary.

[Petimothee]

I see, and it’s not possible to perform loopback calibration in order to not radiate RF?
Thank you Ricardas,
Timothee Mac Garry

[Petimothee]

Hello,

I uploaded here the following code that transmits a random bit stream burst using OFDM. However, due to this initial DC&IQ calibration burst, I once again cannot receive correctly from the USRP when transmitting from the Lime, even with DC&IQ calibration enabled. My goal with the code linked below is to transmit 19968 random bytes, and receive almost all of them with a PER of ~1% with a File Sink. Again, this works well with 2 USRPs, but I get the same error previously mentioned when I transmit with the Lime:

Calibrating with loopback should solve this problem, please disable initial Tx radiation as I cannot run my programs right now.

Here is the code:

ofdm_tx_rx.zip

Thank you and I wish you a good day,
Timothee Mac Garry