[USRP-users] rx_time for radar application

Aaron Smith aaron.smith22 at gmail.com
Tue Mar 22 14:48:06 EDT 2016


Thank you for the reply.

>From what I remember, there is a decimation process in the USRP block. So,
I assume the lag your talking about will still be present even if I went
directly from the USRP block into a meta file sink. So, if my first sample
was sampled 'at the antenna' at clock cycle 'zero', the rx_time tag would
read something larger than zero.

Would an additional decimation block (or any other block) in-between my
USRP block and my meta file sink, change the value of that rx_time tag,
assuming they do not interrupt the stream or cause an overflow?

Can you think of a way which I could measure the lag in clock cycles
between the true first sample clock cycle and the reported rx_time tag?

Aaron Smith

On Tue, Mar 22, 2016 at 11:42 AM, Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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
>   chain.
> 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.
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160322/c612d8c5/attachment-0002.html>

More information about the USRP-users mailing list