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 >>> Discuss-gnuradio@gnu.org >>> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio