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@seznam.cz To: n1gp@hotmail.com; osmocom-sdr@lists.osmocom.org Subject: Re: Incorrect samplerate from RTL-SDR CC: steve@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.
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@seznam.cz To: n1gp@hotmail.com; osmocom-sdr@lists.osmocom.org Subject: Re: Incorrect samplerate from RTL-SDR CC: steve@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.
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@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@seznam.cz To: n1gp@hotmail.com; osmocom-sdr@lists.osmocom.org Subject: Re: Incorrect samplerate from RTL-SDR CC: steve@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.
Can someone clarify what the frequency range is in Direct sampling mode.
The rtl2832u dongle has a 28.8Mhz osc.
So can the dongle in "direct sampling mode" (with appropriate antenna connection) receive > 14.4 Mhz (Nyquist) ?
Googling I find conflicting advice.
I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if that's due to some non-optimal method...?
I'm guessing it can because the tuner chip provides both I & Q data therefore allowing the double rate...?
Hi, (from my little knowledge about DSP) RTL2832U (if) sample at 28.8MHz, by Nyquist, usable maximum frequency is 14.4MHz, above you have a aliases (mirrors, ghosts, harmonics). Frequencies above half of sample rate (Nyquist frequency) need to filtered to avoid aliases effect. For example, sound cards at 44.1KHz/48KHz have filter to cut frequencies above 20KHz. Front end tuner (E4000, R820T), used on RTL dongles, have a low pass filter. I don't know if RTL chip have a input filter, probable no. Direct Sampling mode, or IF mode of RTL2832U, use ability of RTL chip to tune to any IF used on front end tuner (3.57MHz for R820T). I suppose, ADCs of RTL3832U always sample at 28.8MHz, and decimate to lower sample rate, and output as I/Q signal. RTL IF can tune from 0 to 28.8MHz and output a small chunk of sample rate frequency as I/Q. If set sample rate at 2400000Hz (or samples per second), and tune IF to 1.2MHz, you have a signal from 0 to 2.4MHz. If tune to 10MHz, signal from 8.8MHz to 11.2MHz. On direct sampling mode (IF mode), use only one ADC, at 28.8MHz, input need to filtered to pass only frequency bellow 14.4MHz. But, IF can tuned above 14.4MHz, entering on zone of aliases. Suppose that you want ti listem a Medium Wave (MW/AM) radio at 1500KHz, you have a station on 1.5MHz and 27.3MHz, or inverse, instead you favorite station, you hear some one talking on CB band channel 29 or 30. So, to use Direct sampling mode need a low pass filter to tune below 14.4MHz and a band pass filter to tune from 14.4MHz to 28.8MHz.
On Tue, Jan 28, 2014 at 9:50 PM, Richard Koch n1gp@hotmail.com wrote:
Can someone clarify what the frequency range is in Direct sampling mode.
The rtl2832u dongle has a 28.8Mhz osc.
So can the dongle in "direct sampling mode" (with appropriate antenna connection) receive > 14.4 Mhz (Nyquist) ?
Googling I find conflicting advice.
I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if that's due to some non-optimal method...?
I'm guessing it can because the tuner chip provides both I & Q data therefore allowing the double rate...?
Can someone clarify what the frequency range is in Direct sampling mode.
In direct sampling mode you can "tune" by setting the IF between 0 and 30MHz.
So can the dongle in "direct sampling mode" (with appropriate antenna connection) receive > 14.4 Mhz (Nyquist) ?
Yes, and it has nothing to do with Nyquist because the sample rate you receive is only 2MHz or so as per normal. Direct sampling mode does not capture a wider band than normal, it just uses a different method to tune the receiver. So the oscillator frequency is irrelevant, and Nyquist doesn't come into it any differently with direct sampling than with normal sampling.
Cheers, Adam.
Ah yes, that makes sense now. Tnx everyone.
Date: Wed, 29 Jan 2014 22:12:03 +1000 From: a.nielsen@shikadi.net To: osmocom-sdr@lists.osmocom.org Subject: Re: Direct sampling mode frequency range?
Can someone clarify what the frequency range is in Direct sampling mode.
In direct sampling mode you can "tune" by setting the IF between 0 and 30MHz.
So can the dongle in "direct sampling mode" (with appropriate antenna connection) receive > 14.4 Mhz (Nyquist) ?
Yes, and it has nothing to do with Nyquist because the sample rate you receive is only 2MHz or so as per normal. Direct sampling mode does not capture a wider band than normal, it just uses a different method to tune the receiver. So the oscillator frequency is irrelevant, and Nyquist doesn't come into it any differently with direct sampling than with normal sampling.
Cheers, Adam.
Yes, and it has nothing to do with Nyquist because the sample rate you receive is only 2MHz or so as per normal. Direct sampling mode does not capture a wider band than normal, it just uses a different method to tune the receiver. So the oscillator frequency is irrelevant, and Nyquist doesn't come into it any differently with direct sampling than with normal sampling.
Mmm, AFAIK, the rtl ADC work at 28.8 MHz and then the IF tuning is done by an internal digital DDC (which will also decimate down to 2MHz or so to ship via usb).
Cheers,
Sylvain
Yes, and it has nothing to do with Nyquist because the sample rate you receive is only 2MHz or so as per normal. Direct sampling mode does not capture a wider band than normal, it just uses a different method to tune the receiver. So the oscillator frequency is irrelevant, and Nyquist doesn't come into it any differently with direct sampling than with normal sampling.
Mmm, AFAIK, the rtl ADC work at 28.8 MHz and then the IF tuning is done by an internal digital DDC (which will also decimate down to 2MHz or so to ship via usb).
Good point, that may be correct but I'm not familiar enough to say for sure. But either way, direct sampling doesn't impose any additional limitations than you already have with normal sampling.
It's also worth noting that there seems to be a way to do direct sampling without any hardware modifications, by exploiting some undocumented behaviour/bugs in the tuner chip(s?). I hadn't seen any mention of this on any of the mailing lists so I thought I would mention it. Seems to be plenty of info about it on Google!
Cheers, Adam.
On Thu, Jan 30, 2014 at 8:06 AM, Adam Nielsen a.nielsen@shikadi.net wrote:
... It's also worth noting that there seems to be a way to do direct sampling without any hardware modifications, by exploiting some undocumented behaviour/bugs in the tuner chip(s?). I hadn't seen any mention of this on any of the mailing lists so I thought I would mention it. Seems to be plenty of info about it on Google!
http://www.reddit.com/r/RTLSDR/comments/12d2wc/a_very_surprising_discovery/ https://github.com/keenerd/rtl-sdr/commit/39b5cd1561602d4f99c49bbc6434004ad9...
-
Adam Nielsen -
András Retzler -
Jiao Xianjun -
Jiří Pinkava -
Paulino Kenji Sato -
Richard Koch -
Sdr Guru -
Sylvain Munaut