<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">JP,<br><br>Thanks for your reply and explanation.<br><br>I understand the cutting the coefficient table in half since it<br>repeats in a backwards manner, but what I don't understand<br>is why half the table is in 8 bit and the other in 12 bit?<br><br>Also I now understand that there is not enough room for extra<br>coefficients in the rtl2832 for lower bandwidth than 2048Khz.<br>That is unfortunate if you want lower bandwidth as it forces you<br>to sample at 2048 or greater and perform your own FIR and<br>decimation consuming CPU cycles on your host. On an armv4<br>SBC that is very taxing :^)<br><br>-Rick<br><br><div>> Date: Fri, 10 Jan 2014 01:50:51 +0100<br>> From: j-pi@seznam.cz<br>> To: n1gp@hotmail.com; osmocom-sdr@lists.osmocom.org<br>> Subject: Re: Incorrect samplerate from RTL-SDR<br>> CC: steve@steve-m.de<br>> <br>> You cannot fit internal FIR filter in SDR to such narrow bandwidth, it<br>> does not have enough coefficients.<br>> You can adapt it only to wider band width (some small improvement can be<br>> done for<br>> sample rates above 2048 kHz). Select proper values is a bit tricky and<br>> specialised software<br>> is almost unavoidable. You can get good hint from FIR filter designer in<br>> GNU Radio, but<br>> this software is not designed for this task and the work is cumbersome.<br>> <br>> The 8 / 12 bit means the coefficients can be only in range form -128 to<br>> 127 / -2048 to 2047.<br>> The usual FIR coefficients absolute value decreases from center to the<br>> side eg:<br>> <br>> 1, -3, 5, 10, 5, -3, 1,<br>> <br>> so this just reduces complexity of the device.<br>> <br>> For lower bandwidth you need more cofficients (more samples because the<br>> wave is wider).<br>> <br>> JP<br>> <br>> <br>> Dne 9.1.2014 23:53, Richard Koch napsal(a):<br>> > Hi Steve,<br>> ><br>> > In regards to your post about the anti-aliasing filter<br>> > you referred to, it appears that it is getting set in<br>> > librtlsdr.c, rtlsdr_init_baseband()<br>> ><br>> > If one wanted to change that to optimize the anti-aliasing<br>> > to a lower bandwidth, say 1500 Khz instead of the 2048 Khz<br>> ><br>> > How would you change the fir_coeff[] table entries to achieve<br>> > this? The 8 bit entries and 12 bit entries are confusing to me.<br>> ><br>> ><br>> > ==== orig post ====<br>> ><br>> >> I have seen other reports on the mailing list, saying that sample rates<br>> >> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL<br>> >> devices, then maybe it should be documented and the library can return<br>> >> an error code for such sample rates. Otherwise people will keep walking<br>> >> into this trap.<br>> > We could return some sort of error in those cases, but such low rates<br>> > (< 1MS/s) aren't recommended in general. First of all, the<br>> > anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and<br>> > although the coefficients can be changed, I doubt you can get a nice<br>> > filter for lower bandwidths with such a low order. And then the ADCs<br>> > only have 8 bits resolution, so you want to improve that by decimating,<br>> > and also profit from decimation gain.<br>> > Even Realtek uses 2.048 MS/s for FM reception in their original Windows<br>> > software. <br>> <br>> <br></div> </div></div> </div></body>
</html>