Hi,
Let me first say that librtlsdr is great. It is a fantastic way for me to learn about SDR. Also, the library seems very well designed, easy to use, and at a convenient level of abstraction. Many thanks for putting this together!
I'm using librtlsdr to make a wideband FM receiver in C++. Perhaps more about that later.
I noticed the following problem: When I configure a sample rate lower than 1 MS/s, I often get a very different sample rate then what I ask for. The library reports back the same sample rate that I asked (via rtlsdr_get_sample_rate), but the actual sample rate does not match at all.
For example, asking 900 kS/s results in ~ 290 kS/s. Asking 800 kS/s gives ~ 285 kS/s. Asking 600 kS/s gives ~ 255 kS/s. Asking 400 kS/s gives ~ 1700 kS/s. Asking 300 kS/s gives 300 kS/s.
I know the real samplerate from looking at the amount of data I get out of the library in a given amount of time. I have also looked at the FFT spectrum of the data and this confirms my estimate of the actual sample rate (this eliminates the hypothesis that RTL is sampling at configured rate but losing some of the data packets).
After diving into librtlsdr.c, I found that the pattern of configured vs real sample rate can be explained by assuming a specific bit error in the configuration word rsamp_ratio. Bit 28 of the word is forced equal to bit 27.
It is as if somebody is doing rsamp_ratio = (rsamp_ratio & 0x0fffffff) | ((rsamp_ratio & 0x08000000) << 1); after the configuration is sent out via USB but before it is applied by the RTL chip.
I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3. The RTL-SDR library reports: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Terratec Cinergy T Stick RC (Rev.3) Found Elonics E4000 tuner
Does this ring any bells for people who understand the RTL chip? Is it caused by the difference between RTL2832 vs RTL2838?
I have seen other reports on the mailing list, saying that sample rates between 300 kS/s and 900 kS/s don't work. If this applies to all RTL devices, then maybe it should be documented and the library can return an error code for such sample rates. Otherwise people will keep walking into this trap.
Kind regards, Joris van Rantwijk.
Hi,
On 05.01.2014 15:54, Joris van Rantwijk wrote:
I noticed the following problem: When I configure a sample rate lower than 1 MS/s, I often get a very different sample rate then what I ask for. The library reports back the same sample rate that I asked (via rtlsdr_get_sample_rate), but the actual sample rate does not match at all.
Yes, this is a known hardware limitation.
It is as if somebody is doing rsamp_ratio = (rsamp_ratio & 0x0fffffff) | ((rsamp_ratio & 0x08000000) << 1); after the configuration is sent out via USB but before it is applied by the RTL chip.
Good find, we could use this to calculate the real rate in those cases.
I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3. The RTL-SDR library reports: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Terratec Cinergy T Stick RC (Rev.3) Found Elonics E4000 tuner
Does this ring any bells for people who understand the RTL chip? Is it caused by the difference between RTL2832 vs RTL2838?
There is no RTL2838 really, it's only used in the USB descriptor of OEM dongles, don't ask my why... but if you open up your dongle, you'll find an RTL2832U.
I have seen other reports on the mailing list, saying that sample rates between 300 kS/s and 900 kS/s don't work. If this applies to all RTL devices, then maybe it should be documented and the library can return an error code for such sample rates. Otherwise people will keep walking into this trap.
We could return some sort of error in those cases, but such low rates (< 1MS/s) aren't recommended in general. First of all, the anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and although the coefficients can be changed, I doubt you can get a nice filter for lower bandwidths with such a low order. And then the ADCs only have 8 bits resolution, so you want to improve that by decimating, and also profit from decimation gain. Even Realtek uses 2.048 MS/s for FM reception in their original Windows software.
Regards, Steve
Hi Steve,
Thanks for your quick answer.
On 2014-01-05, Steve Markgraf wrote:
We could return some sort of error in those cases, but such low rates (< 1MS/s) aren't recommended in general.
If you know that the hardware is going to freak out, I think returning -EINVAL is a more useful thing to do.
Normally I expect a function to either do what it promised or return an error. Because RTL-SDR is reverse-engineered, it is not fair to judge it to such high standards. Still, it would be good to document known limitations of the RTL chip in the library via comments or error codes.
First of all, the anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and although the coefficients can be changed, I doubt you can get a nice filter for lower bandwidths with such a low order. And then the ADCs only have 8 bits resolution, so you want to improve that by decimating, and also profit from decimation gain.
That is good to know. So in general I should try to keep the hardware sample rate high, and resample in software if needed.
Thanks, Joris.
Hi,
On 05.01.2014 18:04, Joris van Rantwijk wrote:
If you know that the hardware is going to freak out, I think returning -EINVAL is a more useful thing to do.
Thanks for the suggestion, after some further testing I've now pushed a change that excactly does this.
Normally I expect a function to either do what it promised or return an error. Because RTL-SDR is reverse-engineered, it is not fair to judge it to such high standards. Still, it would be good to document known limitations of the RTL chip in the library via comments or error codes.
I've also documented the function in rtl-sdr.h now.
That is good to know. So in general I should try to keep the hardware sample rate high, and resample in software if needed.
Yes, that indeed is the best approach with those devices.
Regards, Steve
-
Joris van Rantwijk -
Steve Markgraf