This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
András Retzler retzlerandras at gmail.comHi 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.htm>