EttusResearch / uhd

The USRP™ Hardware Driver Repository
http://uhd.ettus.com
Other
942 stars 644 forks source link

B2xx Repeated transmit decaying amplitudes starting with 4.5.0 #751

Open thomasteisberg opened 1 month ago

thomasteisberg commented 1 month ago

Issue Description

I use a b205mini as part of a radar system. It repeatedly transmits a short chirp (in this case 10us) at a fixed pulse repetition interval (in this case 100 us).

Starting with UHD 4.5.0, the first transmitted chirp looks fine but subsequent pulses decrease rapidly in amplitude until they disappear into the noise floor. The problem can be reproduced across a range of pulse lengths, output power levels, etc. It only occurs at relatively high duty cycles (which we define as receive duration / pulse repetition interval). By relatively high, I mean 50% or more.

This issue did not occur on UHD 4.4.0. It happens with the UHD 4.5.0 and UHD 4.6.0. Screenshots of the behavior in the respective sections below.

Setup Details

UHD and our user code runs on a Raspberry Pi 5. The output of the b205mini connects through a 30 dB attenuator and and RF splitter to an oscilloscope and back to the RX port of the b205mini. (So roughly 33 dB of attenuation from TX to both the scope and the RX port.)

The full codebase we run is available here: https://github.com/radioglaciology/uhd_radar

Expected Behavior

Here is an example screenshots from the oscilloscope while running with UHD 4.4.0. This is what we expect to see.

uhd_4_4_pi

Note that the measurement on the right side is a gated measurement of the first chirp. The scope is set to 50 ohm impedance and this corresponds to the expected output power level after the 33 dB of attenuation.

Actual Behaviour

With UHD 4.5.0 and above (this screenshot is with 4.5.0 but I've also tested with 4.6.0 and it has the same behavior), the amplitude of the first chirp remains roughly as expected. Subsequent transmitted chirps have lower amplitudes until they rapidly decay into the noise floor. They remain beneath the noise floor until something causes a longer interval between chirps. (This can happen in our code if an ERROR_CODE_LATE_COMMAND is detected. When this happens, a longer interval is commanded between chirps. With UHD 4.5.0+, the amplitude then returns to normal for one pulse and proceeds to decay again as shown here.)

uhd_4_5_pi

Steps to reproduce the problem

Unfortunately, I don't have a small self-contained example. Our full project source code is available here: https://github.com/radioglaciology/uhd_radar

Any duty cycle above 50% seems to clearly reproduce this issue.

Additional Information

This is basically just speculation, but the only commit I can find since 4.4.0 that seems like it would have mattered is this: https://github.com/EttusResearch/uhd/commit/69080b45e01f636b340d617e3b1cdb06c5c8e3c4

It seems plausible that this introduced an unexpected additional lag time in configuring the output switches after the end of receiving period.

I'm certainly open to suggestions about how to better architect our transmit and receive code. Perhaps there's a way to avoid changing the state of the RF switches? Relevant code would be here: https://github.com/radioglaciology/uhd_radar/blob/main/sdr/main.cpp

Thanks!

mmatthebi commented 1 week ago

Probably you can run a git bisect between v4.4.0 und 4.5.0 to identify the actual commit and within this commit identify the problematic change. I think this can help the developers a lot. Git bisect sounds more complicated to use than it actually is.