<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><small>Slight correction/clarification
        to the below: obviously, I am not calling rtlsdr_set_center_freq
        when using rtl_tcp.exe.  Instead, what I see is that I can queue
        up a bunch of tuning calls, but they only kick in at a very slow
        rate (1 hz).  The effect is similar to when I used the native
        libs, where rtlsdr_set_center_freq  also took 1 s on the main
        thread.<br>
        <br>
        -Scott<br>
        <br>
      </small><br>
      On 9/26/2012 3:23 AM, Scott Cutler wrote:<br>
    </div>
    <blockquote cite="mid:5062D7AA.7050506@scottcutler.net" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <small>I've ported my app to use rtl_tcp.exe instead of the native
        rtlsdr libs, and while it is partly working (samples reading
        correctly, no dropped samples, etc.), I have run into two
        issues.<br>
        <br>
        First--when I start reading samples too quickly after setting
        the sample rate, I get this error:</small><br>
      <small><tt>C:\Users\Scott
          Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe

          -f 100000000 -s 2048000</tt><tt><br>
        </tt><tt>Found 1 device(s).</tt><tt><br>
        </tt><tt>Found Elonics E4000 tuner</tt><tt><br>
        </tt><tt>Using Generic RTL2832U (e.g. hama nano)</tt><tt><br>
        </tt><tt>Tuned to 100000000 Hz.</tt><tt><br>
        </tt><tt>listening...</tt><tt><br>
        </tt><tt>Use the device argument 'rtl_tcp=127.0.0.1:1234' in
          OsmoSDR (gr-osmosdr) source</tt><tt><br>
        </tt><tt>to receive samples in GRC and control rtl_tcp
          parameters (frequency, gain, ...).</tt><tt><br>
        </tt><tt>client accepted!</tt><tt><br>
        </tt><tt>set freq 105000000</tt><tt><br>
        </tt><tt>set sample rate 1920000</tt><tt><br>
        </tt><tt>worker cond timeout</tt><tt><br>
        </tt><tt>Signal caught, exiting!</tt><tt><br>
        </tt><tt>comm recv socket error</tt><tt><br>
        </tt><tt>Signal caught, exiting!</tt><tt><br>
        </tt><tt>all threads dead..</tt><tt><br>
        </tt><tt>listening...</tt><tt><br>
        </tt><tt>Use the device argument 'rtl_tcp=127.0.0.1:1234' in
          OsmoSDR (gr-osmosdr) source</tt><tt><br>
        </tt><tt>to receive samples in GRC and control rtl_tcp
          parameters (frequency, gain, ...).</tt></small><br>
      <br>
      <small>If I instead wait about two seconds after setting the
        sample rate, there is no problem.  There is also no problem if I
        immediately read samples after connecting, where I set the
        sample rate on the command line.<br>
        <br>
        The other issue is that tuning is very slow--about one second
        per call to rtlsdr_set_center_freq.  I had a similar problem
        with the rtlsdr.dll library, and I found that tuning was very
        slow if performed from the main thread, but fairly quick (maybe
        10-20 hz) if done from the async proc thread that
        rtlsdr_read_async launches.<br>
        <br>
        That seemed a bit odd to me but it worked.  I suspect that
        rtl_tcp.exe is doing the same thing; calling
        rtlsdr_set_center_freq from the main thread.<br>
        <br>
        Ideas, anyone?  Thanks!<br>
        <br>
        -Scott<br>
        <br>
        PS: I'm running Win7-64, in case it matters.  Also using the
        latest version here:<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip">http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip</a><br>
      </small><br>
    </blockquote>
    <br>
  </body>
</html>