[USRP-users] varying TX delay on TX/RX loopback with B210

Ben Hilburn ben.hilburn at ettus.com
Tue Apr 14 15:11:09 EDT 2015


Hey Jeremy -

I just wanted to let you know that debugging this is taking longer than we
anticipated, but we haven't dropped it. We'll get back in touch as soon as
we have an update.

Cheers,
Ben

On Thu, Apr 9, 2015 at 3:20 PM, Jeremy Hershberger via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Ian,
>
> 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.
>
> Best,
>
> -Jeremy
>
> On Thu, Apr 9, 2015 at 5:51 PM, Ian Buckley <ianb at ionconcepts.com> wrote:
>
>> Jeremy,
>> 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
>> ideal.
>>
>> I let you know when there's a further update.  This is now issue #734 in
>> our bug tracker for reference.
>> -Ian
>>
>>
>> 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
>> DSP?*
>> 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.
>>
>> Best,
>>
>> -Jeremy
>>
>>
>> On Fri, Mar 27, 2015 at 7:01 PM, Ian Buckley <ianb at ionconcepts.com>
>> wrote:
>>
>>> Jeremy,
>>> 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
>>> DSP?
>>> 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.?
>>> -Ian
>>>
>>>
>>> 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
>>> transmitting?
>>>
>>> Best,
>>>
>>> -Jeremy
>>>
>>> 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
>>>> filename).
>>>>
>>>> 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.
>>>>
>>>> Best,
>>>>
>>>> Jeremy
>>>>
>>>>
>>>> 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
>>>>> somehow?
>>>>>
>>>>> Greetings,
>>>>> Marcus
>>>>>
>>>>>
>>>>> 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 TX/RX?
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> -Jeremy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>> 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
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> 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/20150414/5571da6b/attachment-0002.html>


More information about the USRP-users mailing list