10 Jan
2014
10 Jan
'14
4:23 a.m.
JP,
Thanks for your reply and explanation.
I understand the cutting the coefficient table in half since it
repeats in a backwards manner, but what I don't understand
is why half the table is in 8 bit and the other in 12 bit?
Also I now understand that there is not enough room for extra
coefficients in the rtl2832 for lower bandwidth than 2048Khz.
That is unfortunate if you want lower bandwidth as it forces you
to sample at 2048 or greater and perform your own FIR and
decimation consuming CPU cycles on your host. On an armv4
SBC that is very taxing :^)
-Rick
Date: Fri, 10 Jan 2014 01:50:51 +0100
From: j-pi(a)seznam.cz
To: n1gp(a)hotmail.com; osmocom-sdr(a)lists.osmocom.org
Subject: Re: Incorrect samplerate from RTL-SDR
CC: steve(a)steve-m.de
You cannot fit internal FIR filter in SDR to such narrow bandwidth, it
does not have enough coefficients.
You can adapt it only to wider band width (some small improvement can be
done for
sample rates above 2048 kHz). Select proper values is a bit tricky and
specialised software
is almost unavoidable. You can get good hint from FIR filter designer in
GNU Radio, but
this software is not designed for this task and the work is cumbersome.
The 8 / 12 bit means the coefficients can be only in range form -128 to
127 / -2048 to 2047.
The usual FIR coefficients absolute value decreases from center to the
side eg:
1, -3, 5, 10, 5, -3, 1,
so this just reduces complexity of the device.
For lower bandwidth you need more cofficients (more samples because the
wave is wider).
JP
Dne 9.1.2014 23:53, Richard Koch napsal(a):
Hi Steve,
In regards to your post about the anti-aliasing filter
you referred to, it appears that it is getting set in
librtlsdr.c, rtlsdr_init_baseband()
If one wanted to change that to optimize the anti-aliasing
to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
How would you change the fir_coeff[] table entries to achieve
this? The 8 bit entries and 12 bit entries are confusing to me.
==== orig post ====
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.