# How to choose tune\_delay? **URL:** \ **Category:** GNU Radio\ **Created:** [August 3, 2015, 11:13am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854 "2015-08-03T11:13:09Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [August 3, 2015, 11:13am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854/1 "2015-08-03T11:13:09Z")
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 ---
**Author:** ![Francois\_Quitin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecb155/32.png) [@Francois\_Quitin](https://www.ruby-forum.com/u/Francois_Quitin)\ **Post date:** [August 3, 2015, 11:27am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854/2 "2015-08-03T11:27:45Z")
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](https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#adb62a194b0b0761c6a0b4c8c808a20b0) ---
**Author:** ![Francois\_Quitin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecb155/32.png) [@Francois\_Quitin](https://www.ruby-forum.com/u/Francois_Quitin)\ **Post date:** [August 4, 2015, 11:39am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854/3 "2015-08-04T11:39:29Z")
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](https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#a8ba918061af928ee7c01e7124580eb82) ---
**Author:** ![Francois\_Quitin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecb155/32.png) [@Francois\_Quitin](https://www.ruby-forum.com/u/Francois_Quitin)\ **Post date:** [August 4, 2015, 3:22am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854/4 "2015-08-04T03:22:20Z")
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 ---
**Author:** ![Francois\_Quitin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecb155/32.png) [@Francois\_Quitin](https://www.ruby-forum.com/u/Francois_Quitin)\ **Post date:** [August 6, 2015, 2:47am UTC](https://www.ruby-forum.com/t/how-to-choose-tune-delay/242854/5 "2015-08-06T02:47:56Z")
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