<div dir="ltr">Hi All,<div><br></div><div>Thanks for explaining how that works.</div><div><br></div><div><div>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.</div>


<div>Not sure if it helps anyone (I suppose that you've already done this), but here are the results:</div><div>image: <a href="http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.png" target="_blank">http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.png</a></div>


<div>script: <a href="http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.py" target="_blank">http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.py</a></div><div>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).</div>


<div>Looks okay for 2 Msps.</div><div>Anyway, I'll be using only +/-500 kHz for hunting for really weak signals :-))</div></div><div><br></div><div>Regards,</div><div><br></div><div>Andras, ha7ilm</div><div class="gmail_extra">


<br><br><div class="gmail_quote">2014/1/10 Jiøí Pinkava <span dir="ltr"><<a href="mailto:j-pi@seznam.cz" target="_blank">j-pi@seznam.cz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Dne 10.1.2014 05:23, Richard Koch napsal(a):<br>
<div>><br>
><br>
><br>
> 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>
</div>8 / 12 bit is used inside the dongle and is how the hardware is designed.<br>
It reduces the cost of hardware. You can think of it in the way<br>
the coefficients rea all 12 bit, but for the first 8 coefficients the<br>
top 4 bits must<br>
be always zero.<br>
This is only the bite width of coefficients not the actual width of<br>
multiplication<br>
result. Unfortunately I'm not able to explain details about FIR and<br>
hardware design here.<br>
<br>
I'm not sure if I explained your question, try reformulate and extend it<br>
if not.<br>
<div><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>
</div>Working with such hardware is always a challenge, but the tweaked result<br>
is often beautifull.<br>
Good luck,<br>
    JP<br>
<div><div>><br>
> -Rick<br>
><br>
>> Date: Fri, 10 Jan 2014 01:50:51 +0100<br>
>> From: <a href="mailto:j-pi@seznam.cz" target="_blank">j-pi@seznam.cz</a><br>
>> To: <a href="mailto:n1gp@hotmail.com" target="_blank">n1gp@hotmail.com</a>; <a href="mailto:osmocom-sdr@lists.osmocom.org" target="_blank">osmocom-sdr@lists.osmocom.org</a><br>
>> Subject: Re: Incorrect samplerate from RTL-SDR<br>
>> CC: <a href="mailto:steve@steve-m.de" target="_blank">steve@steve-m.de</a><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 <a href="tel:9.1.2014%2023" value="+3691201423" target="_blank">9.1.2014 23</a>: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>
<br>
<br>
</div></div></blockquote></div><br></div></div>