Message: 1<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Thu, 6 Sep 2012 05:22:25 +1000<br>
From: Ben Ryan <<a href="mailto:benryanau@hotmail.com">benryanau@hotmail.com</a>><br>
To: <<a href="mailto:osmocom-sdr@lists.osmocom.org">osmocom-sdr@lists.osmocom.org</a>><br>
Subject: "Best" sampling rate?<br>
Message-ID: <SNT139-W176A4A72E42D16D41CA612B6A90@phx.gbl><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
<br>
<br>
<br>
<br>
Come to think of it, I've also found some samplerates to be better than others. No further info to share beyond the fact that I've noticed it too.<br>
<br>
Drops at higher samplerates are probably due to your CPU, IO latency, etc (esp if virtualised). You should be able to run 2.048Msps with AF rate of 44.1khz with next to no drops and smooth carrier audio. If not, and your CPU isn't maxed out,  likely you have a latency or bandwidth issue.<br>

What's the rig you're running on?<br>
<br>
There appears to be an interaction between AF samplerate and IQ samplerate.. under HDSDR/Win32 anyways.<br>
It might well reduce skips and cpu load if the two rates were cleanly divisible but I haven't tried to work the theoreticals out..<br>
<br>
I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing an "audio print" of a signal using DRM mode I'll up it to 48khz. On the Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's hitting the limits for this system as-is (it's running VMWare MS plus it's got layers of drivers on it).<br>

<br>
Another thing to consider if under Win32: differing versions of libusb, ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, samplerates and drops.<br>
I haven't documented my findings yet but there's a complex relationship between the above elements and tuner range.. some RTL libs will permit 50mhz-~2000mhz, others puke at various spots on the dial etc.<br></blockquote>
<div><br>Thanks for the inspiration. I actually re-wrote my code to use async mode and now I'm getting reliable captures up to 1.92MSPS (my desired sampling rate). I was using sync mode but apparently that's not fast enough to capture all samples!<br>
<br>BR,<br>James<br><br>
</div></div>