On 10/26/2020 02:26 PM, Hodges, Jeff via USRP-users wrote:
That's how I read the email as well, but not the behavior I'm seeing.
The DEBUG strings (from the USRP_Sink_Block) are informing me that the
time command is being processed, but the tune time is really way off:
[INFO] [B200] Asking for clock rate 32.000000 MHz...
[INFO] [B200] Actually got clock rate 32.000000 MHz.
----------------------------------------------------------------------
Tag Debug:
Input Stream: 00
Offset: 0 Source: n/a Key: tx_time Value: {1 0.5}
Offset: 0 Source: n/a Key: packet_len Value: 100000
----------------------------------------------------------------------
Tag Debug:
Input Stream: 00
Offset: 99999 Source: n/a Key: tx_command Value: ((time 1 .
0.6) (freq . 2e+08))
Offset: 100000 Source: n/a Key: tx_time Value: {1 0.7}
Offset: 100000 Source: n/a Key: packet_len Value: 100000
----------------------------------------------------------------------
DEBUG: Setting command time on mboard
DEBUG: Processing command message ((time 1 . 0.6) (freq . 2e+08))
----------------------------------------------------------------------
Tag Debug:
Input Stream: 00
Offset: 199999 Source: n/a Key: tx_command Value: ((time 1 .
0.8) (freq . 2.01e+08))
Offset: 200000 Source: n/a Key: tx_time Value: {1 0.9}
Offset: 200000 Source: n/a Key: packet_len Value: 100000
----------------------------------------------------------------------
DEBUG: Setting command time on mboard
DEBUG: Processing command message ((time 1 . 0.8) (freq . 2.01e+08))
----------------------------------------------------------------------
Tag Debug:
Input Stream: 00
Offset: 299999 Source: n/a Key: tx_command Value: ((time 2 .
7.45058e-09) (freq . 2.02e+08))
Offset: 300000 Source: n/a Key: tx_time Value: {2 0.1}
Offset: 300000 Source: n/a Key: packet_len Value: 100000
----------------------------------------------------------------------
DEBUG: Setting command time on mboard
DEBUG: Processing command message ((time 2 . 7.45058e-09) (freq .
2.02e+08))
In this case, I'm doing 100 ms bursts + 100 ms dead time. Frequency is
shifting 1 MHz at a time. Tuning is approximately 57 ms from the start
of each txburst (in the middle of the burst). Somehow the tx_time
commands must be interfering with my timed commands. Although, being
placed in the same queue in the proper order, they shouldn't affect
each other.
Jeff
------------------------------------------------------------------------
*From:* USRP-users <[email protected]> on behalf of
Marcus D. Leech via USRP-users <[email protected]>
*Sent:* Monday, October 26, 2020 1:45:35 PM
*To:* [email protected]
*Subject:* Re: [USRP-users] uhd tuning with tagged stream commands
On 10/26/2020 01:39 PM, Hodges, Jeff via USRP-users wrote:
I'm thinking that timed tune commands will not work on tagged streams
in burst mode. Is that correct? I've been looking at the USRP sink
block code and it supports the timed commands on the stream, but from
reading a recent thread, it seems like this will not work because of
how the DUC derives it's time:
https://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2020-March/061611.html
This thread says DUC derives it's sense of time from the samples, and
if the samples are not streaming, the DUC will not keep track of
time. Therefore, the timed command will not be executed.
For example, I set the tx_time tag to 1.0 second and the burst is
0.05 sec long. Then I place the tuning command tag on the last sample
of the burst with a tune time of 1.05. The radio does not actually
tune until I transmit the next burst at 1.1 sec (0.05 sec dead time)
and then it tunes at approximately 0.007 sec into the middle of that
burst.
I can try to implement tuning during the dead time by making calls
directly to the C++ api at the appropriate time in a separate thread,
but before I do that I just want to confirm that this burst time-tag
method will not work.
Thanks in advance,
Jeff
From the quoted thread, it seems that the *radio* part of the timing
will work fine, but the DUC won't be able to do its part of the deal--so
if your tuning requires "mop up" action on the part of the DUC, it
won't work properly.
This KB article may be useful in understanding the time-domain behavior
of AD936x-based devices, such as the B210:
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
