[USRP-users] timed_command

Sam mite mite.engr11 at gmail.com
Mon Sep 2 15:01:49 EDT 2013


> > On 08/26/2013 12:40 AM, Sam mite wrote:
> > > I want to change frequency of transmitter and receiver for frequency
> > > hopping using set_command_time(), and "tx_time" tags. For this I wanted
> > to
> > > test the timed_commands by running ./test_timed_commands. And I got the
> > > following output
> > >
> > >
> > > Testing support for timed commands on this hardware... pass
> > >
> > > Perform fast readback of registers:
> > > Difference between paired reads: 177.655100 us
> > >
> > > About to start streaming using timed command:
> > > Received packet: 100 samples, 897 full secs, 0.974692 frac secs
> > > Stream time was: 897 full secs, 0.974691 frac secs
> > > Difference between stream time and first packet: 0.013300 us
> > >
> > > From this I get the timed commands are supported. What is this
> difference
> > > of 0.013300 us means? Does this mean my command will be executed with
> > this
> > > much accuracy in time i.e if I say change frequency at x, then command
> > will
> >
> > In this test I am using the fact that the rx packets have a timestamp to
> > show that the timed commands are indeed working. Its sort of a
> > convenient feedback mechanism.
> >
> > The execution time is down to the clock cycle, so the delay you see is
> > probably the cycles taken to process the stream command, and the group
> > delay through the DDC chain.
> >
> > > be executed at x+0.013300 us? Does this accuracy apply to "tx_time" tag
> > > too? Any comments would be appreciated.
> > >
> > >
> >
> > Sort of. The tx_time specifies the time that the tx sample will be
> > released from the deframer into the DUC chain. There will also be some
> > group delay to when the first sample exits the DUC chain.
> >
> > -josh
> >
>
> Hi Josh,
>
> Thanks for your time and explanation.
>
>
> --
> Sam
>

When I use set_command_time(), flow graph or USRPN210 seems to hang up. For
example,

...
...
while 1:
...
...
t1 = usrp.get_time_now().get_real_secs()
usrp.set_command_time(t1+0.02)
usrp.set_center_freq(uhd.tune_request(f1,LO))
usrp.clear command_time()
....
....

flow graph/USRP doesn't run smoothly. What could be the issue? How many
commands could be in a queue at a time?

One more question. Lets say current USRP time is 5.0 seconds. I give the
following commands to USRP
usrp.set_command_time(5.0+3.0)
usrp.set_center_freq(uhd.tune_request(f1,LO))
usrp.clear command_time()

print usrp.get_time_now().get_real_secs()

what would be print 5.0+something or 8.0+something? What I get from the UHD
documentation is that if there is already a timed command waiting in queue,
new commands will be executed after the waiting timed command has been
executed. Is that right?

Any comments on this would be highly appreciated.

--
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130903/7dcacb62/attachment-0002.html>


More information about the USRP-users mailing list