<div dir="ltr"><div><div><div>Ian,<br><br></div>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.<br><br></div>Best,<br><br></div>-Jeremy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 5:51 PM, Ian Buckley <span dir="ltr"><<a href="mailto:ianb@ionconcepts.com" target="_blank">ianb@ionconcepts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Jeremy,<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I let you know when there's a further update.  This is now issue #734 in our bug tracker for reference.</div><span class="HOEnZb"><font color="#888888"><div>-Ian</div></font></span><div><div class="h5"><div><br></div><div><br><div><div>On Mar 27, 2015, at 5:26 PM, Jeremy Hershberger <<a href="mailto:Jeremy.L.Hershberger.16@nd.edu" target="_blank">Jeremy.L.Hershberger.16@nd.edu</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div>Hi Ian,<br><br>Hopefully these answers will give you some insight.<br><i><br></i><u><i>You've put your linear chirp signal into a ROM that directly feeds the DSP?</i><br><br></u></div>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.<br><br><div><i><u>Is the DSP configured for any interpolation or CORDIC rotation?</u></i></div><br></div>No interpolation is required as master_clock_rate=25e6, the same as the desired TX/RX rate<br></div><br>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.<br><div><div><br><i><span style="font-size:12.8px"><u>You are correlating at a similar place (immediately after the DSP) in the RX chain?</u></span></i></div><div><br></div><div>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</div><div><i><br></i></div><div><i><span style="font-size:12.8px"><u>You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles) across different runs.</u></span></i><br></div><div><span style="font-size:12.8px"><u><br></u></span></div><div><span style="font-size:12.8px">Correct.  I do not care about the actual number, the only problem I am worried about is that it changes from run to run.</span></div><div><span style="font-size:12.8px"><br></span></div><div><i><u>The loopback is an (attenuated) cable between TX and RX SMA's?</u></i><span style="font-size:12.8px"><br></span></div><div><u><br></u></div><div>Correct.  I have tried it with and without 30dB pads.</div><div><br></div><div><i><u>The delay is stable over extended periods within the same run.?</u></i><br></div><div><u><br></u></div><div>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.</div><div><br>Let me know if you need more info.<br><br></div><div>Best,<br><br></div><div>-Jeremy<br></div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 7:01 PM, Ian Buckley <span dir="ltr"><<a href="mailto:ianb@ionconcepts.com" target="_blank">ianb@ionconcepts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Jeremy,<div>I'm not sure I have an immediate answer for you here so asking some more detailed questions:</div><div>You've put your linear chirp signal into a ROM that directly feeds the DSP?</div><div>Is the DSP configured for any interpolation or CORDIC rotation?</div><div>You are correlating at a similar place (immediately after the DSP) in the RX chain?</div><div>You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles) across different runs.</div><div>The loopback is an (attenuated) cable between TX and RX SMA's?</div><div>The delay is stable over extended periods within the same run.?</div><span><font color="#888888">-Ian</font></span><div><div><br></div><div><br><div><div>On Mar 27, 2015, at 2:38 PM, Jeremy Hershberger via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>This oddity is truly bewildering.<br><br></div>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.<br><br></div>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.<br><br></div>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?<br><br></div>Best,<br><br></div>-Jeremy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 4:12 PM, Jeremy Hershberger <span dir="ltr"><<a href="mailto:Jeremy.L.Hershberger.16@nd.edu" target="_blank">Jeremy.L.Hershberger.16@nd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Greetings Marcus,<br><br></div>Thanks for taking a look at this!  I have attached two different captures, each one with showing a different delay (indicated by the filename).<br><br></div>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.<br><br></div>Let me know if you need further info.<br><br></div>Best,<br><br></div>Jeremy<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 3:48 PM, Marcus Müller <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Dear Jeremy,<br>
    <br>
    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?<br>
    <br>
    Greetings,<br>
    Marcus<div><br>
    <br>
    <div>On 03/13/2015 07:08 PM, Jeremy
      Hershberger via USRP-users wrote:<br>
    </div>
    </div><blockquote type="cite"><div>
      <div dir="ltr"><p style="margin-bottom:0in;line-height:100%">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.</p><p style="margin-bottom:0in;line-height:100%"><br>
        </p><p style="margin-bottom:0in;line-height:100%">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?</p><p style="margin-bottom:0in;line-height:100%"><br>
        </p><p style="margin-bottom:0in;line-height:100%">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.</p><p style="margin-bottom:0in;line-height:100%"><br>
        </p><p style="margin-bottom:0in;line-height:100%">Best,</p><p style="margin-bottom:0in;line-height:100%">-Jeremy<br>
        </p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div><pre>_______________________________________________
USRP-users mailing list
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>
_______________________________________________<br>USRP-users mailing list<br><a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br><a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>