<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 09/09/2014 08:01 PM, Jacob Gilbert via USRP-users wrote:
    <blockquote
cite="mid:CAC52AkDeqgcG4EZwGG28TWYT2c0J93fHfB=pzsbzOqx+DT3RWw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        Hello,
        <div><br>
        </div>
        <div>I am having some trouble with a USRP B210 and quickly
          retuning it for a wideband survey application. I have an OOT
          GR block which retunes (DSP only, since the LO retune takes
          quite a while) the USRP via a call to the usrp_source block's
          retune method, waits for the stream tag, passes some data
          forward, then repeats.</div>
        <div><br>
        </div>
        <div>The issue I am currently having is on occasion the stream
          tag indicating the retune will arrive well before the data is
          actually valid for the frequency the tag is indicating it just
          tuned to. I had originally thought the uhd source block would
          insert a stream tag when the USRP indicated the retune had
          been completed, however in looking into
          usrp_source_impl.cc:145, it looks like the tag is appended (or
          indicated it should be appended) immediately after the tune
          call is made regardless of whether or not the tune in the FPGA
          has actually completed.</div>
        <div><br>
        </div>
        <div>Is this correct? And if so, is there a better way to know
          when a DSP-only tune has completed and the data stream is
          valid for the new frequency?</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div><br>
          Jacob</div>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
USRP-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a>
<a class="moz-txt-link-freetext" href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>
</pre>
    </blockquote>
    The FPGA-only tune happens so quickly that the way it is currently
    written is "correct", modulo latencies in Gnu Radios internal
    buffering mechanisms,<br>
      which are definitely outside the scope of what the hardware can
    control.<br>
    <br>
    There will be ambiguous data after a retune, since you don't really
    know how many samples are "in flight" after doing that.<br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
<a class="moz-txt-link-freetext" href="http://www.sbrac.org">http://www.sbrac.org</a>
</pre>
  </body>
</html>