[USRP-users] varying TX delay on TX/RX loopback with B210
Jeremy.L.Hershberger.16 at nd.edu
Thu Apr 9 18:20:17 EDT 2015
Interesting stuff. In response to your question about the actual delay
value spread, the standard delay spread is +/-1 sample, which is very
repeatable. Only once in a blue moon did I have a run that managed to get
as far as +/-3 samples....but it has happened.
On Thu, Apr 9, 2015 at 5:51 PM, Ian Buckley <ianb at ionconcepts.com> wrote:
> I had sometime to look at this the last couple of days and I wanted to
> give some hopefully useful feed back to yourself and the list.
> First off, the issue is real, I can reproduce it. I have further isolated
> it to the logic thats closely associated with the sample data interface on
> AD9361. Running in data port loopback mode so that data is looped TX->RX
> before entering the DSP logic in AD9361 and using a master_clock_rate of
> 10MHz with no FPGA decimation I see loopback latencies spread over 4
> different lag values (86/87/88/89 dataclk cycles) with a very even
> distribution after a long batch scripted run. I've also run a loopback test
> with the loopback at the periphery of the FPGA to verify that both your
> methodology was sound and the Ettus logic is not directly the cause, and
> observed in this case fixed deterministic lag.
> My hypothasis at this point is that the source synchronous buses used for
> RX and TX data interfaces probably use FIFO's to move data between clock
> domains within AD9361. Certainly this is a technique ADI use in other data
> converter products, though in this case the documentation reveals nothing
> about the internals of this functionality. This particular use of a FIFO
> tends to yield this effect unless you specifically design against it, and
> indeed other ADI chips such as the AD9146 Ettus use in X300 have
> programming features to counter it.
> Since AD9361 is intrinsically designed for implementing
> multi-chip,multichannel systems it seems logical to believe that there is a
> way to make this delay deterministic. I implemented ADI's MCS (Multi Chip
> Sync) procedure in the hope that this might help but observed no measurable
> difference in latency jitter. So at this point I have a message into ADI's
> AE community to get some more help since the documention doesn't offer any
> more clues.
> Out of curiosity are you sure you saw +/- 3 cycles of jitter, not +/-2? I
> have not observed this range in any mode I have tested.
> Clearly there is a workaround possible using the loopback mode to
> calibrate your application, since you can activate loopback without
> reconfiguring the whole radio and incurring a latency change (see
> data_port_loopback in b200_impl.cpp), but I realize thats far less than
> I let you know when there's a further update. This is now issue #734 in
> our bug tracker for reference.
> On Mar 27, 2015, at 5:26 PM, Jeremy Hershberger <
> Jeremy.L.Hershberger.16 at nd.edu> wrote:
> Hi Ian,
> Hopefully these answers will give you some insight.
> *You've put your linear chirp signal into a ROM that directly feeds the
> Yes. However, I do want to emphasize that my modifications to the FPGA
> resulted in the same behaviors as was seen with the stock FPGA image + my
> GNU radio script.
> *Is the DSP configured for any interpolation or CORDIC rotation?*
> No interpolation is required as master_clock_rate=25e6, the same as the
> desired TX/RX rate
> I have tried it with and without CORDIC rotation. I have tried requesting
> 2412MHz, but the RF Lo will only do 2411.999998MHz, so the DSP needs to
> make up 0.000002MHz. I have also tried requesting 2000MHz, which UHD
> reports it can successfully tune to with the use of DSP.
> *You are correlating at a similar place (immediately after the DSP) in the
> RX chain?*
> I believe the correlations are happening at the same point. I made no
> changes to the behavior of the RX in my custom FPGA image, so the RX in the
> stock image and the RX in my image should have identical delays
> *You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles)
> across different runs.*
> Correct. I do not care about the actual number, the only problem I am
> worried about is that it changes from run to run.
> *The loopback is an (attenuated) cable between TX and RX SMA's?*
> Correct. I have tried it with and without 30dB pads.
> *The delay is stable over extended periods within the same run.?*
> Yes. The waveform is 250 samples long, and the correlation peaks appear
> every 250 samples. My problem is the location of the first correlation
> peak moves (~160 samples +/- 3 samples) from run to run.
> Let me know if you need more info.
> On Fri, Mar 27, 2015 at 7:01 PM, Ian Buckley <ianb at ionconcepts.com> wrote:
>> I'm not sure I have an immediate answer for you here so asking some more
>> detailed questions:
>> You've put your linear chirp signal into a ROM that directly feeds the
>> Is the DSP configured for any interpolation or CORDIC rotation?
>> You are correlating at a similar place (immediately after the DSP) in the
>> RX chain?
>> You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles)
>> across different runs.
>> The loopback is an (attenuated) cable between TX and RX SMA's?
>> The delay is stable over extended periods within the same run.?
>> On Mar 27, 2015, at 2:38 PM, Jeremy Hershberger via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>> This oddity is truly bewildering.
>> I recently completed a FPGA-only TX, by nesting a small ROM in the B210
>> image and hacking apart the original TX state machine to accept only data
>> from the ROM instead of the host. To make the TX and RX work
>> simultaneously, I connected the TX's start signal to the RX's start signal.
>> Even with this "hard-wiring" of the TX to the RX, I still see the same
>> varying delay in the received data. The delay is usually in the low 160's
>> and varies over 2 to 3 samples.
>> I don't know too much about the transceiver chip on the B210, but
>> shouldn't it have a fixed start-up time once it is told to start
>> On Tue, Mar 24, 2015 at 4:12 PM, Jeremy Hershberger <
>> Jeremy.L.Hershberger.16 at nd.edu> wrote:
>>> Greetings Marcus,
>>> Thanks for taking a look at this! I have attached two different
>>> captures, each one with showing a different delay (indicated by the
>>> Each of these data files was captured using the same GNU radio script I
>>> have already provided, which uses the B210 to Tx/Rx a chirp waveform. If
>>> you run the matlab script I provided, you should be able to see the delay
>>> change in the correlation plots.
>>> Let me know if you need further info.
>>> On Fri, Mar 20, 2015 at 3:48 PM, Marcus Müller <
>>> usrp-users at lists.ettus.com> wrote:
>>>> Dear Jeremy,
>>>> sorry I've been misisng your mail! I don't have an immediate answer;
>>>> this is a very interesting problem. Would you mind sharing your RX samples
>>>> On 03/13/2015 07:08 PM, Jeremy Hershberger via USRP-users wrote:
>>>> Using the timed commands, I zero'd the time on a PPS and set the B210's
>>>> transmitter and receiver to begin at a set time (1.5 seconds into the
>>>> future). The transmitter port is connected directly to the receive port via
>>>> a short cable. The transmit waveform is a linear chirp built in Matlab and
>>>> saved in a binary file. Upon correlating the received data with the
>>>> original transmitted waveform, I noticed the location of the first
>>>> correlation peak varies from run to run (over a range of +/- 2 samples). I
>>>> expected some delay from TX to RX (due to cable length and dsp), but I
>>>> expected that delay to be constant.
>>>> Has there been any success in using the B210 to simultaneously transmit
>>>> a waveform from file and receive to file with a known fixed delay between
>>>> In case there is interest in reproducing the problem, I have included a
>>>> simple GNU radio python script to demonstrate the problem. I have also
>>>> included the original chirp waveform and a matlab script to show the
>>>> correlation lag.
>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>> USRP-users mailing list
>>>> USRP-users at lists.ettus.com
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users