On 2021-11-23 14:20, Dustin Widmann wrote:
Hi list,
I occasionally, unpredictably, get FPGA-related errors. Usually some
sort of FPGA timeouts, so I have to reset the USRP after these errors,
which is rather inconvenient.
The software is C++ using the UHD 4 multi-usrp API.
Without going into too much detail, I wonder if there is anything
particular to my *approach* that could make things more prone to FPGA
errors of any sorts. I'm also curious about the different
“stream_modes” that are available, their pros and cons / use cases,
and more particularly if I'm really using the one best suited to my
use case.
Before describing that, this is what I'm trying to do. It's fairly
simple, but I'm trying to make it tune, collect, and then tune again
as quickly as possible without leaving my cozy C++ bed. It's currently
doing this >100 times per second.
* transmits continuously
* in a loop:
*** tune the transmitter and receivers and set their gain:
*** receive a fixed number of samples
How I'm currently going about it:
In main object/thread
* init the radio
* create a tx object and move it to a new thread
* give the tx object a streamer
* tell the tx object to start streaming
* create a rx object and move it to a new thread
* give the rx object a streamer
* tell the rx object to start streaming
* in a loop (forever):
*** clear command time
*** set command time to now()+0.004
*** set_rx_freq to next frequency for both channels
*** set_tx_freq to next frequency for channel 0
*** set the rx gain
*** set the tx gain
*** sleep for 4ms
*** ask the rx object to save some samples
in tx object/thread
* in a loop (until asked to stop by main)
*** call send on the streamer with max_num_samps samples from a fixed
waveform
* when killed, send an empty end_of_burst
in rx object/thread
* issue STREAM_MODE_START_CONTINUOUS, starting 0.25 in the
future/_restart
* in a loop (until asked to stop by main)
*** recv max_num_samps from the streamer
*** check for/handle errors if they occur (often do at the start of
the stream)
*** copy the samples if currently collecting, else discard them
* when killed, issue STREAM_MODE_STOP_CONTINOUS
I can/will provide more detail/code/etc, but that's not necessarily
relevant to the *approach* I wouldn't think. To reiterate the
question, I want to know if there is anything about the approach that
would make FPGA related errors likely.
-Dustin
Setting your command-time only 4msec in the future will be a bit dicey,
just due to OS and network-layer latency.
But further input will likely require the actual errors produced, and
probably code snippets to show what provokes the errors.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
