[USRP-users] rx_time for radar application

Ian Buckley ianb at ionconcepts.com
Tue Mar 22 20:36:41 EDT 2016


Martin, I always found a great lack of deterministic behavior in
undergraduate students, especially in the inexplicable delay department. To
quote my previous long buried post on N210 group delays:


Over the years a lot of people have asked for a figure for the group delay of
N210.
I finally had a reason to spend a few hours today putting together a
formula to calculate the digital portion of it.


Glossary:
DecCIC - Decimation rate across the CIC filter
DecHB1- Decimation rate across the small Half Band FIR (HB1)
DecHB2 - Decimation rate across the large Half Band FIR (HB2)

For the N210 Rx path (Tx will be similar) ADC -> Packetization, sum the
following:

Input register: 1
DC Offset Correction: 1
IQ Balance: 2
IQ Swap: 1
CORDIC: 21
Clip: 1
CIC Filter: 5+6*DecCIC
HB1: 7+6*DecCIC
HB2: 9+8*(DecCIC*DecHB1*2)
Clipping and Gain: 3

This is the number of 100MHz (10nS) clock cycles used in the DSP pipeline
before packets are timestamped and packetized.

For example if you had configured N210 to produce a 1MHz sample stream,
thats Decimation=100 which maps to :
DecCIC=25, DecHB1=2, DecHB2=2. This makes group delay ~11.51uS

Another example. If you configured N210 to produce a 25MHz sample stream,
thats Decimation = 4 which maps to:
DecCIC=1, DecHB1=2, DecHB2=2. This makes group delay ~790nS.

On Tue, Mar 22, 2016 at 3:55 PM, Martin Braun via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Aaron,
>
> to quickly add to this thread, I did some radar stuff with N210 a while
> back and it worked fine. For a fixed setup the tx/rx lag is
> deterministic and you can calibrate it out. I was doing measurements on
> the order of meters with great success. You need to sync the clocks,
> obviously, and then calibrate your sample offset (which is caused by the
> DDC/DUC stages, as someone pointed out, as well as other delays in the
> analog bits).
>
> For calibration I used a device called an "undergraduate student"; in my
> case it was much simpler though because we calibrated against a target
> that was something like 20m from the USRPs.
>
> Hope this is of any use,
>
> Martin
>
> On 03/22/2016 08: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
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> 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/bb095154/attachment-0002.html>


More information about the USRP-users mailing list