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 <usrp-users-boun...@lists.ettus.com> on behalf of Marcus D.
Leech via USRP-users <usrp-users@lists.ettus.com>
Sent: Monday, October 26, 2020 1:45:35 PM
To: usrp-users@lists.ettus.com
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.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
