Jonathon, Marcus Usually, when something goes wrong, I'm getting an error like this:
[x300_fw_ctrl.cpp:53] [X300] 192.168.40.2: x300 fw communication failure #1 EnvironmentError: IOError: x300 fw poke32 - reply timed out [1] 193622 abort (core dumped) Marcus, I'm not sure which part of the code you might find interesting, this is the portion of my project that interfaces with a radio, for reference: https://u.pcloud.link/publink/show?code=XZ6jaIXZnTM8V7fAKtLbjS7NAlhtxjQm3Dl7 Dustin On 11/23/21 15:02, Jonathon Pendlum wrote:
Hi Dustin,
Can you provide the error message?
Jonathon
On Tue, Nov 23, 2021 at 2:20 PM Dustin Widmann <dw...@virginia.edu> 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
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
OpenPGP_0xCD731811BAE2BAF5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
