10 Jan
2014
10 Jan
'14
5:23 a.m.
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(a)seznam.cz
To: n1gp(a)hotmail.com; osmocom-sdr(a)lists.osmocom.org
Subject: Re: Incorrect samplerate from RTL-SDR
CC: steve(a)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. 
10 Jan
10 Jan
10:52 a.m.
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(a)seznam.cz
To: n1gp(a)hotmail.com; osmocom-sdr(a)lists.osmocom.org
Subject: Re: Incorrect samplerate from RTL-SDR
CC: steve(a)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. 
4:24 p.m.
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(a)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(a)seznam.cz
> To: n1gp(a)hotmail.com; osmocom-sdr(a)lists.osmocom.org
> Subject: Re: Incorrect samplerate from RTL-SDR
> CC: steve(a)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.
29 Jan
29 Jan
12:50 a.m.
New subject: Direct sampling mode frequency range?
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...?
12:33 p.m.
New subject: Direct sampling mode frequency range?
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(a)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...?
--
Paulino Kenji Sato
1:12 p.m.
New subject: 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.
1:25 p.m.
New subject: Direct sampling mode frequency range?
Ah yes, that makes sense now. Tnx everyone.
Date: Wed, 29 Jan 2014 22:12:03 +1000
From: a.nielsen(a)shikadi.net
To: osmocom-sdr(a)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.
1:27 p.m.
New subject: Direct sampling mode frequency range?
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
30 Jan
30 Jan
7:06 a.m.
New subject: Direct sampling mode frequency range?
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). 
9:11 a.m.
New subject: Direct sampling mode frequency range?
On Thu, Jan 30, 2014 at 8:06 AM, Adam Nielsen <a.nielsen(a)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/39b5cd1561602d4f99c49bbc6434004ad…
3746
days inactive
3766
days old
10 comments
8 participants
participants (8)
-
Adam Nielsen -
András Retzler -
Jiao Xianjun -
Jiří Pinkava -
Paulino Kenji Sato -
Richard Koch -
Sdr Guru -
Sylvain Munaut