On 2022-08-31 14:34, ri28...@mit.edu wrote:
I found the following lines in the Synchronizing USRP Events app note
<https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD>:
When commands enter the command queue, their timestamp is compared
against the command queue's sense of time and the commands are
executed when Queue Time >= Command Time. Commands without
timestamps are executed immediately when they're at the front of
the queue. Command queues in the USRP do not support on-the-fly
reordering, meaning a command at the front of the queue will block
subsequent commands from executing even if their timestamp has passed.
How does it work if a command arrives “late” to the USRP? For
instance, I set_command_time(t1), then issue a tx_set_freq(), but the
USRP doesn’t get the command until t1 + X, does the tx_set_freq
immediately issue, or is it dropped? The language implies it would
immediately issue, which is opposite the behavior of a timed tx/rx
command.
I’ve attached an image of a spectrogram. The x axis is time, y
frequency. I have some code that repeatedly issues tx_set_freq()
between two frequencies on a fixed time interval. In the image, the
fourth slot does not alternate frequency, while the fifth and sixth
slots appear to be a time shifted glimpse of how the fourth and fifth
slots should appear.
Is this likely an instance of the USRP not receiving the scheduled
command fast enough, and immediately issuing several commands upon
getting them?
I don't think any of the USRPs drop commands that are late, but rather,
they get executed immediately.
What is the hardware we're talking about, and what is your cadence?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
