On 2022-02-10 11:59, Jim Palladino wrote:
I
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
A "command" from the perspective of the FPGA is a register setting. Any
given high-level UHD function call may well result in
several such register-setting commands. By design, the FPGA doesn't
*know* much beyond "you asked me to set a register
at address <X> to <Y>".
I'm surprised that the command FIFOs are so small, but perhaps they
consume more FPGA real-estate than you might think.
------------------------------------------------------------------------
*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 tousrp-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 tousrp-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
