FW: Incorrect samplerate from RTL-SDR
András Retzler
retzlerandras at gmail.com
Fri Jan 10 15:24:09 UTC 2014
Hi All,
Thanks for explaining how that works.
I was curious about the frequency response of the original filter that the
Windows driver used, so I've created a little script to calculate it.
Not sure if it helps anyone (I suppose that you've already done this), but
here are the results:
image: http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.png
script: http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.py
It turns out that amplitude is quite at its maximum until ~0.67 MHz, and is
half of the maximum at about 1.5 MHz (-3 dB bandwidth).
Looks okay for 2 Msps.
Anyway, I'll be using only +/-500 kHz for hunting for really weak signals
:-))
Regards,
Andras, ha7ilm
2014/1/10 Jiří Pinkava <j-pi at seznam.cz>
> Dne 10.1.2014 05:23, Richard Koch napsal(a):
> >
> >
> >
> > 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?
> 8 / 12 bit is used inside the dongle and is how the hardware is designed.
> It reduces the cost of hardware. You can think of it in the way
> the coefficients rea all 12 bit, but for the first 8 coefficients the
> top 4 bits must
> be always zero.
> This is only the bite width of coefficients not the actual width of
> multiplication
> result. Unfortunately I'm not able to explain details about FIR and
> hardware design here.
>
> I'm not sure if I explained your question, try reformulate and extend it
> if not.
>
> >
> > 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 :^)
> Working with such hardware is always a challenge, but the tweaked result
> is often beautifull.
> Good luck,
> JP
> >
> > -Rick
> >
> >> Date: Fri, 10 Jan 2014 01:50:51 +0100
> >> From: j-pi at seznam.cz
> >> To: n1gp at hotmail.com; osmocom-sdr at lists.osmocom.org
> >> Subject: Re: Incorrect samplerate from RTL-SDR
> >> CC: steve at 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.
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140110/fcc9d8f5/attachment.html>
More information about the osmocom-sdr
mailing list