Re: [Discuss-gnuradio] how to choose tune_delay?

[fquitin]

Hi all,

I've implemented Marcus' solutions, and it works fine. I thought I would 
just mention some detail that threw me off at first so that other people 
do not stumble on the same problems I did:
- when you issue a set_command_time/tune_freq/clear_command_time 
(scheduled for 2 sec in the future for example), the UHD prints out the 
message that it has re-tuned the USRP right away (not after 2 seconds). 
Additionally, the USRP will generate a time-tag right away when 
receiving the command, not after 2 seconds. But the effective change of 
frequency will indeed only happen after 2 seconds. So you need to 
implement a time-counter/sample-counter that will be able to detect when 
2 seconds have passed.
- when the command_time arrives too late at the USRP (after the 
scheduled time), the USRP will retune asap. But no alert is given to the 
UHD, and it is hard to detect from the software side when this happens. 
This might happen in particular when you get a lot of overflows, and 
your tuning commands are scheduled for a short time in the future. To 
get over this, it is recommended to send several tuning commands in 
advance (if you know the successive tuning times) so that the USRP 
always has several commands in its pipeline (I read somewhere you can go 
up to 16 timed commands). In that case, if the host processor lags a bit 
to send the latest tuning command, it will be OK since the USRP will 
have some instructions in its command buffer.

Cheers (and thanks again to Marcus)
Francois




On 04.08.2015 11:38, Marcus Müller wrote:
> Hi Francois,
>
> yes, N210 and later have timed commands abilities, which comes with the
> feature of metadata containing time stamps; the GNU Radio USRP source 
> is
> able to evaluate that metadata coming from UHD, and adds stream tags at
> the right position[1].
>
> Greetings,
> Marcus
>
> [1]
> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#a8ba918061af928ee7c01e7124580eb82
>
> On 04.08.2015 03:21, fquitin wrote:
> > Hi Marcus,
> >
> > Thanks for your comments, as usual, you're being a life-saver (I
> > wasn't aware of the existence of set_command_time/clear_command_time
> > functions, these will be immensely helpfull). From your suggestions, I
> > understand that the USRP will always re-attach a rx_time tag after
> > being re-tuned?
> >
> > Thanks,
> > Francois
> >
> >
> > On 03.08.2015 11:26, Marcus Müller wrote:
> > > Hi Francois,
> > >
> > >  yes, that seems rather high; but maybe you're seeing the effects of
> > > the DC offset removal filter. You can try to use use
> > > set_auto_dc_offset(False) to make that faster [1].
> > >
> > >  However, usrp_spectrum_sense is pretty old, and hence can't even 
> > > make
> > > use of stream tags on the GNU Radio side and timed commands on the
> > > USRP side, so the lower boundary for delay is the two-way latency
> > > between host and device -- which can easily be in the order of tens 
> > > of
> > > milliseconds.
> > >
> > >  I'd personally recommend just going ahead and reimplementing this:
> > >  * Use the USRP source as usual
> > >    * use set_time_now (if you don't have a time/PPS source),
> > > set_start_time
> > >    * issue two or three timed tuning commands right at the start
> > > (set_command_time, set_rx_freq, clear_command_time)
> > >  * write a python block that waits for rx_time tags (which
> > > automatically get added by the USRP source nowadays)
> > >   * that block would, upon detection of such a tag, issue "the next
> > > tune request in line" (set_command_time(rx_time+delay), set_rx_freq,
> > > clear_command_time)
> > >   * that block would, after detection of such a tag, first discard a
> > > few samples and then calculate your metrics based on the following N
> > > samples
> > >
> > >  Best regards,
> > >  Marcus
> > >
> > >  [1]
> > > https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
> > >
> > > [2]
> > >
> > > On 03.08.2015 11:11, Francois Quitin wrote:
> > >
> > > > Hi all,
> > > >
> > > >
> > > >
> > > > I want to retune the frequency of my USRP in Python during runtime.
> > > > I understand from usrp_spectrum_sense.py that I can just retune the
> > > > USRP during runtime, and that I need to allow for some tune_delay to
> > > > make sure that the samples corresponding to the old center frequency
> > > > are discarded.
> > > >
> > > >
> > > >
> > > > Is there any way to get a good estimate of tune_delay value? I want
> > > > to keep this as short as possible… (btw I’m using a USRP-N210
> > > > with WBX daughterboard) Some trial and error gave me values around
> > > > 50ms, but this seems rather high compared to what I’ve read
> > > > online.
> > > >
> > > >
> > > >
> > > > Any hints are welcome!
> > > >
> > > > Thanks,
> > > >
> > > > Francois
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> > >
> > >
> > >
> > > Links:
> > > ------
> > > [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > [2]
> > > https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio