[USRP-users] Fwd: The microsecond time offset between tx and rx bursts are real...

Matt Ettus matt at ettus.com
Fri Sep 13 16:50:14 EDT 2013


Max,

The issue you refer to from another user was actually an error in that
user's application.  He had believed there to be an offset between multiple
different receive chains, but there is none.

What you are seeing is offset between TX and RX.  The reason you are seeing
this is that the reference point for time is before the DSP section on the
TX and after the DSP section on RX.  So in your application, on the TX
side, your samples are placed into the TX DSP at the timestamp you
indicate.  They will take some number of cycles to propagate through the
DSP chain, and then there is some delay in the DAC and analog hardware.  On
the RX side, when a signal comes in, it must propagate through the analog
chain, into the ADC, and then through our DSP processing before it is
timestamped.

The analog delays are mostly a function of the daughterboard used, and the
ADC and DAC delays are fixed.  The delays in our DSP processing are a
function of sample rate, and that explains the sample rate dependence you
see.  If you need precise TX/RX alignment, the best way to do it is to
measure the delays, exactly like you have done. Then adjust the TX and RX
times accordingly.  This is how it is done in OpenBTS (GSM) for example.

There are a number of reasons we have chosen this reference point for
timestamps.  Mostly it comes down to it being more repeatable when users
change the DSP processing, some standards expect that to be the demarcation
point, and the fact that there may not even be a fixed delay in your DSP
code in certain situations.   Also, since some DSP happens in the ADC and
DAC, these chips give significant delay.

Matt



On Fri, Sep 13, 2013 at 1:27 PM, Max Scharrenbroich <max at sazetech.com>wrote:

> Hey all,
>
> A few days ago I saw that someone had asked a question about +/- 2
> microsecond time alignment offset between transmit and receive.  This is
> something that I have observed in several different configurations and it
> has been nagging me for a while and have spent many hours trying to figure
> this out.
>
> In my last attempt to investigate it, I looked at the time_specs returned
> in the meta_data structs (returned by recv() and recv_async_msg()) after
> attempting to do a simultaneous transmit and receive.  While the returned
> time_specs in the meta_data for tx and rx are not exact (all the time),
> they only indicate a sub-microsecond difference, something I'm willing to
> live with especially if I can trust those timestamps and correct for the
> offset later.
>
> The big problem I have is that there is a 1 to 2 microsecond offset
> between the transmit and receive stream but the time_specs don't indicate
> that - so which timestamp can I trust?  Is it the time_spec from the
> transmit, the receive or neither?  I dunno.
>
> To test my sanity I wrote a rudimentary leading-edge-detection (LED) tool
> using the UHD example code as a starting point. I've attached the code - if
> you want to run it, to compile you can just plop it into the example uhd
> cpp directory and add it to the CMakeList, re-run cmake and then make.  The
> code simply starts a receive operation 10 msec(@25 MHz) before the send
> operation (both use time_specs and the receive uses the issue_stream_cmd()
> function) so the LED can estimate the noise before it receives the transmit
> burst and to give plenty of padding around the burst to make sure it's
> leading edge is received in the buffer.  The detection threshold can be set
> by the user to some dB above the noise sigma.
>
> In all the permutations of configurations I've tested the results seem to
> be identical:  either the rx stream is starting ~1.5 usec too early, the tx
> burst is starting ~1.5 usec too late, or something in between.
>
> There are three different hardware configurations I've used to test this:
>
> UHD Driver:
> ABI String: 3.6.0-1
> Version String: 003.005.003-121-gaa5e5d23
>
> All firmware on the USRPs are coherent with the driver release.
>
> (A) One N210 (w/ GPSDO), WBX, TX (TX/RX ANT) and RX (RX2 ANT) connected
> via a cable less than 1 ft long.  I'm not using an attenuator but set the
> TX and RX gain to 0 dB to be safe.
>
> (B) One N210 (NO GPSDO), WBX, TX (TX/RX ANT) and RX (RX2 ANT). Same cable
> and gains as above.
>
> (C) Two N201s, each w/ WBX, TX (TX/RX ANT) and RX (RX2 ANT).  One has a
> GPSDO (for PPS) and they are connected via MIMO cable to sync clocks and
> PPS.  I'm using the same cable and gains as above.
>
> I've also noticed that the timing offset changes with tx and rx sample
> rate although I have not included the results here.
>
> Output from (A):
>
> > ./usrp_time_offset --tx-addr=192.168.10.2 --rx-addr=192.168.10.2
> --args=recv_frame_size=4095,send_frame_size=4095,recv_buff_size=50e6,send_buff_size=50e6
> --tx-rate=25000000 --rx-rate=25000000 --tx-freq=915000000
> --rx-freq=915000000 --tx-ant=TX/RX --rx-ant=RX2 --tx-ref=gpsdo
> --rx-ref=gpsdo --pps-sync
> ...
> Starting RX Ahead: 10.0000 msec
> Noise Mu: -36.33 dB, Noise Sigma: -31.26 dB, Max Value = -5.16 dB
> Detected at 250039 (of 510000), LED Value = -9.40 dB, TX/RX Timing Offset:
> 1.5600 usec, # Samples @ 25 MHz: 39
> Noise Mu: -36.44 dB, Noise Sigma: -39.12 dB, Max Value = -5.16 dB
> Detected at 250038 (of 510000), LED Value = -17.23 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.37 dB, Noise Sigma: -39.05 dB, Max Value = -5.17 dB
> Detected at 250038 (of 510000), LED Value = -17.17 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.37 dB, Noise Sigma: -39.03 dB, Max Value = -5.17 dB
> Detected at 250038 (of 510000), LED Value = -17.25 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.42 dB, Noise Sigma: -39.09 dB, Max Value = -5.18 dB
> Detected at 250038 (of 510000), LED Value = -17.30 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.42 dB, Noise Sigma: -39.11 dB, Max Value = -5.18 dB
> Detected at 250038 (of 510000), LED Value = -17.21 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> ...
>
> Output from (B):
>
> > ./usrp_time_offset --tx-addr=192.168.10.3 --rx-addr=192.168.10.3
> --args=recv_frame_size=4095,send_frame_size=4095,recv_buff_size=50e6,send_buff_size=50e6
> --tx-rate=25000000 --rx-rate=25000000 --tx-freq=915000000
> --rx-freq=915000000 --tx-ant=TX/RX --rx-ant=RX2 --tx-ref=internal
> --rx-ref=internal
> ...
> Starting RX Ahead: 10.0000 msec
> Noise Mu: -36.40 dB, Noise Sigma: -32.54 dB, Max Value = -4.92 dB
> Detected at 250039 (of 510000), LED Value = -9.32 dB, TX/RX Timing Offset:
> 1.5600 usec, # Samples @ 25 MHz: 39
> Noise Mu: -36.49 dB, Noise Sigma: -39.12 dB, Max Value = -4.93 dB
> Detected at 250038 (of 510000), LED Value = -17.13 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.48 dB, Noise Sigma: -39.13 dB, Max Value = -4.92 dB
> Detected at 250038 (of 510000), LED Value = -17.13 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.50 dB, Noise Sigma: -39.14 dB, Max Value = -4.92 dB
> Detected at 250038 (of 510000), LED Value = -17.13 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.50 dB, Noise Sigma: -39.15 dB, Max Value = -4.92 dB
> Detected at 250038 (of 510000), LED Value = -17.16 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> ...
>
> Here is the output from (C):
>
> > ./usrp_time_offset --tx-addr=192.168.10.2 --rx-addr=192.168.10.3
> --args=recv_frame_size=4095,send_frame_size=4095,recv_buff_size=50e6,send_buff_size=50e6
> --tx-rate=25000000 --rx-rate=25000000 --tx-freq=915000000
> --rx-freq=915000000 --tx-ant=TX/RX --rx-ant=RX2 --tx-ref=gpsdo
> --rx-ref=mimo --pps-sync
> ...
> Starting RX Ahead: 10.0000 msec
> Noise Mu: -36.38 dB, Noise Sigma: -31.07 dB, Max Value = -4.54 dB
> Detected at 250039 (of 510000), LED Value = -7.21 dB, TX/RX Timing Offset:
> 1.5600 usec, # Samples @ 25 MHz: 39
> Noise Mu: -36.51 dB, Noise Sigma: -39.13 dB, Max Value = -4.54 dB
> Detected at 250038 (of 510000), LED Value = -17.65 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.49 dB, Noise Sigma: -39.13 dB, Max Value = -4.54 dB
> Detected at 250038 (of 510000), LED Value = -17.62 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.47 dB, Noise Sigma: -39.08 dB, Max Value = -4.54 dB
> Detected at 250038 (of 510000), LED Value = -17.58 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.48 dB, Noise Sigma: -39.12 dB, Max Value = -4.55 dB
> Detected at 250038 (of 510000), LED Value = -17.73 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.49 dB, Noise Sigma: -39.12 dB, Max Value = -4.55 dB
> Detected at 250038 (of 510000), LED Value = -17.73 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> Noise Mu: -36.48 dB, Noise Sigma: -39.07 dB, Max Value = -4.55 dB
> Detected at 250038 (of 510000), LED Value = -17.73 dB, TX/RX Timing
> Offset: 1.5200 usec, # Samples @ 25 MHz: 38
> ...
>
>
>
> _______________________________________________
> 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/20130913/14c01286/attachment-0002.html>


More information about the USRP-users mailing list