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

Jeremy Hershberger Jeremy.L.Hershberger.16 at nd.edu
Thu Apr 9 18:20:17 EDT 2015


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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150409/99bc1f4d/attachment-0002.html>


More information about the USRP-users mailing list