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

[Marcus Müller]

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