Hi Anna, I do not have a response to your direct question regarding performance. However, I have a suggestion that may make the performance irrelevant. The X310 image comes with a Replay block that accesses the DRAM chip for storage. Given that you are sending a repeatable waveform, you should have plenty of room to store this ahead of time and playout from the Replay block. This is exactly how I do all of my radar testing. While it will take some effort to make your application play nice with the Replay block, it will be worth it because you will never fight "Late" or "Underrun" again. (Note that there may be a RAM I/O bottleneck if trying to play both channels simultaneously from the Replay block at 200 MS/s, but one channel will be no problem). Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome <abro...@stanford.edu> wrote: > Hello, > > We are developing a radar application built on the Ettus SDR platforms. > Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and > a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to > take advantage of recent power calibration utilities and other features not > present in UHD 3.15, so I am now trying to run our code on an X310 with the > most recent UHD 4.5 release. > > When running our code on the X310 with UHD 4.5 I get warnings for both > radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): > *[WARNING] > [0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses > timed commands to transmit and receive samples from a frequency-swept pulse > at a consistent interval (pulse repetition frequency). Our application > requires a high PRF and we can tolerate some late command errors, but need > to log them for post-processing. Using UHD 4.5, the behavior is not as > expected in that something seems to be hanging. At some point during the > process—I think once we first hit a late command error—the timing becomes > very off from what it should be, and eventually, samples stop being > transmitted or received and the application just hangs. Sometimes when > killing the application, I get this warning: *[WARNING] > [RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from > 0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen > when running the application with UHD 3.15. > > I have tried running the benchmark_rate example with the same host > computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high > sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout: > Control operation timed out waiting for ACK, which stops the test before > it begins running. Lower sample rates in UHD 4.5 run, but produce more > errors (including sequence errors) than the same set up running UHD 3.15. > > I have tried refreshing the FPGA image for UHD 4.5 with no change in > behavior. The behavior is replicable using multiple host computers (Mac and > Ubuntu). If anyone has suggestions on debugging steps, or potential reasons > why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well > with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect > it may have something to do with the command queue and how it evolves after > getting behind. > > Thanks, > Anna Broome > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
