No signal on LimeSDR XTRX with mismatch rx.path

Projects LimeSDR
1

Hi everyone,

I’ve finally managed to get something out from the LimeSDR XTRX board but for that I had to set rx.path of second channel to the same value as the first channel. Using basicRX.cpp what I need to do is to config.channel[1].rx.path = 2;. Without doing so the samples received by the StreamRx is simply a noice floor at around -80dBFS.

The test configuration goes as following:

  • LimeSuiteNG hash c57dcd13a78
  • Gateware from the hash bdd0c69078e
  • basicRX.cpp modified to have static const double frequencyLO = 100e6;
  • Signal generator at at 98MHz, 2 mVrms connected to RxA

Without any modifications the reported peak is somewhere around Peak amplitude: -81.26dBFS @ 100.001 (which is just noise floor).

If I add config.channel[1].rx.path = 2; then re reported peak is around Peak amplitude: -27.20dBFS @ 98.000 (which seems to correspond to the actual signal, and the reported dBFS does change with the changes in the input signal power and frequency).

At the same time, the signal across MN33 (across the RX1_L_A_P and RX1_L_A_N) does not change depending on the value of the config.channel[1].rx.path. So intuitively it does not seem to be caused by wrong antenna switching part of the circuitry.

Not sure if that’s a quirk of current API, or something else is going on. So far I’m out of ideas.

P.S. It might be something to do with the RF test failure I’ve mentioned in another thread. With the attenuator and wiring I have I’d expect the TX_2->LNA_L tests to pass.

2

I did some extra testing to see dependency between configuration and reception of signal.

test configuration:

  • LimeSuiteNG 86458b614a1
  • LimeSDR-XTRX_HW 09488b98664
  • Tests are based on the baseRX.cpp code with tweaks for the LO, and configuration of rx.path for an “inactive” RX path, and eventually some code to listen to ChB instead of ChA
  • frequencyLO: 100 Mhz
  • Test signal: 98 MHz, 2 mVrms

The measurements goes as following (dBFS @ MHz):

Test signal is fed to ChA, listening to ChA

          ChB ANT     None         LNAH         LNAL         LNAW
ChA ANT
LNAH                  -81 @ 100    -79 @ 98     -81 @ 100    -82 @ 100
LNAL                  -82 @ 100    -82 @ 100    -24 @ 98     -76 @ 98
LNAW                  -43 @ 98     -43 @ 98     -43 @ 98     -43 @ 98

Test signal is fed to ChB, listening to ChA (to test possible cross-talk or short circuit, or something else that might be correlating the two channels electrically)

          ChB ANT     None         LNAH         LNAL         LNAW
ChA ANT
LNAH                  -82 @ 100    -82 @ 100    -82 @ 100    -81 @ 100
LNAL                  -81 @ 100    -83 @ 100    -83 @ 100    -81 @ 100
LNAW                  -82 @ 100    -80 @ 100    -81 @ 100    -80 @ 100

Test signal is fed to ChB, listening to ChB

          ChA ANT     None         LNAH         LNAL         LNAW
ChB ANT
LNAH                  -82 @ 100    -78 @ 98     -78 @ 98     -83 @ 100
LNAL                  -83 @ 100    -82 @ 100    -24 @ 98     -83 @ 100
LNAW                  -43 @ 98     -83 @ 100    -84 @ 100    -43 @ 98

Test signal is fed to ChA, listening to ChB (to test possible cross-talk)

          ChB ANT     None         LNAH         LNAL         LNAW
ChA ANT
LNAH                  -83 @ 100    -81 @ 100    -83 @ 100    -83 @ 100
LNAL                  -81 @ 100    -81 @ 100    -74 @ 98     -82 @ 100
LNAW                  -82 @ 100    -83 @ 100    -74 @ 98     -81 @ 100

Some thoughts:

  • ChA LNAW seems to behave as expected. Not sure about what the expected dBFS value for such configuration is, but at least it is independent of the rx.path configuration of ChB.
  • ChA LNAL only works if ChB is configured to LNAL.
  • ChB LNAW is different from ChA LNAW: it doesn’t seem to receive proper samples when ChA is configured for LNAH/LNAL
  • There is some interference when signal is plugged to a different port from the one which is being used to calculate peak, but it doesn’t seem that bad. Could be just a quirk of the setup with the wiring and such.
  • I didn’t double-check the signal levels after the matching transformers/circuits (such as T5, T6, etc), but from quick tests from yesterday it didn’t seem signal dependent on configuration of the other channel.

Not sure what to make of all of it: is it expected or is it not, do i just need to get a second device and compare. Maybe there is indeed some aspects to the signal paths which aren’t that obvious from quick glance through the datasheet.
At least there seems to be a way to get signal out of the radio with matched RX paths, and that’s enough for the current projects I am working on.

Some details for the code modification:

config.channel[1] = config.channel[0];
config.channel[<the other channel>].rx.path = AntennaNameToIndex(chipDescriptor.pathNames.at(TRXDir::Rx), "LNAL");
  • For receiving the ChB: stream.channels[TRXDir::Rx] = { 0, 1 }; and use rxSamples[1] for FFT.
3

LMS7002 channels can have different LNA selections, but on XTRX the onboard RF switches for both channels are controlled by the same value on FPGA. So currently using the LMS7002 channel A selection, to decide the RF switches value:

4

Ah, good to know, thanks for clarification. It explains behavior when I was experimenting with the RxB.

The thing which i still don’t quite understand, is that basicRX.cpp is “death” on RxA until I add config.channel[1].rx.path = rxPath; to the configuration.

5

Sorry for multi-post, but it seems different enough from the previous comment, so decided against editing it.

Something similar happens with TxA and basicTX as well: there is no output on the TxA connector until I do config.channel[1].tx.path = 2;.

Maybe someone from the community can check with their XTRX whether the basicRX “hears” RxA out-of-the-box, and similarly whether basicTX produces signal on the TxA out-of-the-box as well? Would really appreciate :slight_smile: