Hello Ms. Broome,
that does sound complicated and undesirable. From the top of my head, I have no idea what
could cause this. Barring any method of directly debug this – how quickly does
reproduction for you work? Meaning, from the start of your application to the application
hanging or no samples flowing, how long does it take?
Let me quickly throw in my thoughts on the things you write, so that we maybe find a good
way forward, or maybe someone else spots something:
On 28.09.23 19:54, Anna Lamkin Broome wrote:
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 ability to emit that warning was added in UHD 4.0.0.0; I think it's quite normal to
see this during initialization.
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.
Sounds good to me.
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 think this is just the fact that in UHD 4, RFNoC is much tighter in integration with the
host-side UHD. (The USRP's FPGA conains a flowgraph, conceptually not too different from a
flowgraph as in GNU Radio or Simulink, to handle the samples. Now, at host-side
application teardown, we need to tell the components of that graph to shut down, and
disengage. This might be a minor misunderstanding about what is still there during shutdown.)
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.
Great work! Just to get a feeling: at which rates does this happen now, at which it did
work on 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.
Yeah, that would be a suspicion I share – but here's where I'll have to admit that I
haven't followed the changes to the radio ctrl changes lately, and flow control under UHD
4 is indeed a bit different than under 3.15.
Best,
Marcus M
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
