[USRP-users] rx_time for radar application

Marcus D. Leech mleech at ripnet.com
Tue Mar 22 12:42:48 EDT 2016

On 03/22/2016 11:46 AM, Aaron Smith via USRP-users wrote:
> Hello,
> I was hoping someone with experience could help me with the situation 
> below.
> Background:
> My research group is trying to use a N210 USRP to sense the altitude 
> of the ionosphere. Originally we were going to transmit our own 
> signals, so to test this, I connected my TX daughterboard directly to 
> my RX daughterboard.
> I then used the function set_start_time() on my tx and rx to build up 
> a little test case. I had a vector source -> repeat block -> usrp sink 
> -> usrp source -> fir dec low pass filter -> file sink and this caused 
> a discrepancy in samples of +50 samples (which would translate into 
> kilometers--big deal). I attributed this to buffer loading and several 
> other forms of non-zero lag between blocks.
> To simplify the issue, I'm going to focus on precise receiving. I am 
> going to attempt to capture the WWV atomic clock signal out of 
> Colorado, but I still need to be able to convince myself the the time 
> I think I received the first sample, is actually the time I received 
> my first sample.
> I am going to abandon using the set_start_time() as an absolute and 
> instead hope to use the file meta sink to extract the rx_time tag. To 
> handle clock synchronization, I am using the set_clock_source() and 
> set_time_unknown_pps() functions with a GPS pps signal.
> Questions:
> Is this as simple as connecting a USRP source block up to a meta file 
> sink block? If I add a block in between the USRP source and the meta 
> file sink (like a decimator), will that impact my rx_time tag? Can I 
> trust the the rx_time tag is the time that the receiver received it's 
> first sample? Would you recommend this approach, or is there a better way?
> Thank you for your time,
> Aaron Smith
You cannot rely on predictable latency between TX and RX, and also, I 
hope that you were using substantial attenuation between your
   TX and RX in this case, otherwise, there's a significant risk of damage.

What you need to do is set your USRP device time--as you've shown 
above.  On RX, use the time-tags to determine when your signal
   was received--which will have some fixed latency between that tag, 
and the "as received at antenna port".  But for a given sample-rate
   setting that latency will be fixed and measurable, and is a 
consequence of the inherent group delay of the DSP filters in the decimation

A fresh time tag is inserted when streaming commences, and whenever an 
overrun (O) happens.  Since your sample stream is at a fixed
   rate, you can simply calculate what the RX time is of each sample, 
using the most-recently-received time tag.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160322/3133a43c/attachment-0002.html>

More information about the USRP-users mailing list