5 Jan
2014
5 Jan
'14
3:54 p.m.
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.
5 Jan
5 Jan
4:37 p.m.
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
6:04 p.m.
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.
10:55 p.m.
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
3771
days inactive
3771
days old
3 comments
2 participants
participants (2)
-
Joris van Rantwijk -
Steve Markgraf