I spent more time on this and found that it does appear that timed commands (like set_rx_freq() and set_rx_gain()) are working on an N320 with UHD 4.1. This did not work on an E320 -- Marcus and Martin both pointed out that this isn't supported on the E320. The "get" commands (and thus the the "test_timed_commands" example UHD application) don't work on any platform that I've tried in UHD 4.1. This is probably related to the comments David made about blocking/not blocking. I'm not sure how that worked in any version of UHD . . . . obviously something is different now.
Now that timed commands seem to be working, I'm wondering how to manage the command queue. According to this, the command queue depth of the N320 (also X300) radio core is 8: https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Command_Queue In the following example, you can see they set the command depth for an X300 to 16: https://github.com/EttusResearch/uhd/blob/master/host/examples/twinrx_freq_hopping.cpp I've been doing my own tests by writing timed commands to the fifo -- way out into the future, and waiting until I hit the point where I see: "Error: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer" What I've found is that the number of commands I can send varies a lot by the command. If I send alternating "set_rx_freq()" and "issue_stream_cmd()" timed commands repeatedly, I found that I can send 14 commands before the above error. If I repeatedly send only "set_rx_freq()" timed commands and keep the frequency the same every time, I can send 12 commands. If I increment the frequency by 250MHz each time, I can send 10 commands. If I make very large jumps in frequency (like > 1GHz), I can only send 7 commands. If instead of frequency, I send "set_rx_gain()" commands, I can send 104 before the fifo is full. I'm assuming that the issue is either related to command length, or that when I call a function like set_rx_freq(), it really sends a series of commands that might vary depending on the frequency I'm tuning from/to. So, what I'm wondering is: how I can tell how much room remains in the command FIFO -- or some way to know how many future timed commands I can issue. Thanks, Jim ________________________________ From: Jim Palladino <j...@gardettoengineering.com> Sent: Monday, February 7, 2022 10:37 AM To: Dustin Widmann <dw...@virginia.edu>; usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: [USRP-users] Re: Timed Commands Not Working Thanks Dustin and David -- that is good info regarding UHD versions that worked or didn't work with the test_timed_commands example application. David, I'm not sure of the answer to your question regarding get_time_now() and blocking . . . now that you got me thinking about it, I'm a little confused by that, too. But I'm confident that the set_rx_freq() commands are not working in my own test code either. In that case, the response isn't an issue -- I can see that the LO gets tuned immediately when I call set_rx_freq() -- not at the time I specify with set_time_command(). Thanks, Jim ________________________________ From: Dustin Widmann Sent: Friday, February 4, 2022 1:23 PM To: Jim Palladino; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Timed Commands Not Working For reference, I've done it over again with the latest commits from the UHD-4.0 and UHD-3.15.LTS branches. Creating the usrp device with: ... [INFO] [UHD] linux; Clang version 13.0.0 ; Boost_107400; UHD_4.0.0.0-240-gb38c9d83 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Radio 1x clock: 200 MHz Using Device: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: UBX RX RX Channel: 1 RX DSP: 1 RX Dboard: B RX Subdev: UBX RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: UBX TX TX Channel: 1 TX DSP: 1 TX Dboard: B TX Subdev: UBX TX Testing support for timed commands on this hardware... pass Perform fast readback of registers: Difference between paired reads: 1060.659100 us Testing control timed command: Span : 100000.000000 us Now : 249431.750000 us Response 1: 250515.950000 us Response 2: 251521.850000 us Difference of response time 1: -98915.800000 us Difference of response time 2: -197909.900000 us Difference between actual and expected time delta: -98994.100000 us About to start streaming using timed command: Received packet: 100 samples, 0 full secs, 0.359452 frac secs Stream time was: 0 full secs, 0.359452 frac secs Difference between stream time and first packet: 0.000000 us Done! Creating the usrp device with: ... [INFO] [UHD] linux; Clang version 13.0.0 ; Boost_107400; UHD_3.15.0.0-74-ge35f66e8 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [GPS] No GPSDO found [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1309 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000) Using Device: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: UBX RX RX Channel: 1 RX DSP: 0 RX Dboard: B RX Subdev: UBX RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: UBX TX TX Channel: 1 TX DSP: 0 TX Dboard: B TX Subdev: UBX TX Testing support for timed commands on this hardware... pass Perform fast readback of registers: Difference between paired reads: 60.434350 us Testing control timed command: Span : 100000.000000 us Now : 1848964.600000 us Response 1: 1948964.655000 us Response 2: 2048964.655000 us Difference of response time 1: 0.055000 us Difference of response time 2: 0.055000 us Difference between actual and expected time delta: 0.000000 us About to start streaming using timed command: Received packet: 100 samples, 2 full secs, 0.155770 frac secs Stream time was: 2 full secs, 0.155770 frac secs Difference between stream time and first packet: 0.005000 us Done! -- This is pretty concerning, looks like the latest commit of the UHD-4.0 branch has this broken as well? Timed commands at least used to work in UHD 4.0, but I hadn't tried in a while, and never with this nifty test program. I'm going to have to see if I can find where the breakage occurred, so I can roll back for the time being. -Dustin On 2/4/22 11:23, Jim Palladino wrote: Dustin, Thank you for running that. So apparently, it isn't just an issue on my end. Thanks, Jim ________________________________ From: Dustin Widmann <dw...@virginia.edu><mailto:dw...@virginia.edu> Sent: Friday, February 4, 2022 11:16 AM To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com><mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: Timed Commands Not Working "Hopefully, someone can try the uhd "test_timed_commands" example in 4.1 to..." Figure I ought to be about as good as the next somebody. test_timed_commands output with UHD 4.1.0 and an X310 Creating the usrp device with: ... [INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107800; UHD_4.1.0.HEAD-0-g6bd0be9c [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Radio 1x clock: 200 MHz Using Device: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: UBX RX RX Channel: 1 RX DSP: 1 RX Dboard: B RX Subdev: UBX RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: UBX TX TX Channel: 1 TX DSP: 1 TX Dboard: B TX Subdev: UBX TX Testing support for timed commands on this hardware... pass Perform fast readback of registers: Difference between paired reads: 1079.015300 us Testing control timed command: Span : 100000.000000 us Now : 253256.340000 us Response 1: 254437.230000 us Response 2: 255676.840000 us Difference of response time 1: -98819.110000 us Difference of response time 2: -197579.500000 us Difference between actual and expected time delta: -98760.390000 us About to start streaming using timed command: Received packet: 100 samples, 0 full secs, 0.365935 frac secs Stream time was: 0 full secs, 0.365935 frac secs Difference between stream time and first packet: 0.000000 us Done! -Dustin On 2/3/22 08:02, Jim Palladino wrote: Thanks, Rob. I always appreciate when you "chime in". Hopefully, someone can try the uhd "test_timed_commands" example in 4.1 to help confirm whether or not it's a problem with something on my end or with UHD. Marcus already confirmed its working for him with an N310 and UHD 3.15. Thanks, Jim ________________________________ From: Rob Kossler <rkoss...@nd.edu><mailto:rkoss...@nd.edu> Sent: Wednesday, February 2, 2022 3:26 PM To: Jim Palladino <j...@gardettoengineering.com><mailto:j...@gardettoengineering.com> Cc: Marcus D. Leech <patchvonbr...@gmail.com><mailto:patchvonbr...@gmail.com>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com><mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Re: Timed Commands Not Working Hi Jim, This sounds like a pretty big issue. I haven't chimed in because I couldn't say for sure if timed commands were working for me or not in UHD 4.1. I am using N321s with shared LO, so the normal commands I use for setting frequency aren't critical (from a timed command perspective) except for how the DDC/DUC might be handling them. In any case, once you find out the issue, could you please share the solution here. If I get a chance, I will try this on some of my devices. Rob On Wed, Feb 2, 2022 at 12:22 PM Jim Palladino <j...@gardettoengineering.com<mailto:j...@gardettoengineering.com>> wrote: Just to add one more data point, I just ran test_timed_commands on a different computer connected to an X310 -- still UHD 4.1. I have the same problem with that device where it looks like timed commands are not working right. Thanks, Jim ________________________________ From: Jim Palladino <j...@gardettoengineering.com<mailto:j...@gardettoengineering.com>> Sent: Wednesday, February 2, 2022 10:44 AM To: Marcus D. Leech <patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] Re: Timed Commands Not Working Correct -- I am using the stock FPGA image for the E320 and the N320. Thanks, Jim ________________________________ From: Marcus D. Leech <patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>> Sent: Wednesday, February 2, 2022 10:39 AM To: Jim Palladino <j...@gardettoengineering.com<mailto:j...@gardettoengineering.com>>; usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] Re: Timed Commands Not Working On 2022-02-02 10:21, Jim Palladino wrote: Thanks Marcus. Please let me know if R&D comes back with anything. I'm at a bit of a loss . . . Thanks, Jim ________________________________ Just to clarify--this is with the stock FPGA image, correct? _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto: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
