[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