RTL2832 Sample Rates

[Dennis Sheirer]

I've been working on porting the rtlsdr library over to Java, testing against an original RTL-2832/E4000 Tuner.  

I'm using integral polyphase decimation to arrive at a final 48k channel rate and I was experiencing very choppy demodulated audio (buffer underruns).  After ruling out computer performance as a factor, I wrote a test app to measure the sample rate output from the rtl2832.

I tried hundreds of combinations of settings for registers 0x9F (high bits) and 0xA1 (low bits) and measured the output of each setting, averaged over a 100 second period, and discovered a significant disconnect between the expected sample rates set through the rtlsdr library versus actual output sample rates.  It seems that register 0xA1 doesn't affect the sample rate.

It appears that the rtl2832 supports two sets of sample rate outputs.  Both are divided multiples of the oscillator/crystal frequency.  

RTL2832 with an E4000 with 28.8 MHz oscillator supports sampling rates of: 225-300 kHz and 900 - 2032 kHz.  I couldn't get consistent stabilized outputs above 2032 kHz.

It looks like the anti-aliasing filters work equally well across both sets of rates, but I haven't tested all of the IF filter settings yet to verify.  This might work out well for the folks trying to use these devices on lower powered processors like the raspberry pi, so that they don't have to process such high sample rates.

Here's what I discovered for 16-bit demod register 0x9F:

FEDCBA9876543210 (bit positions)

FEDC - not used for sample rate

B = 0 = 32x divider mode

A9876 - integral units ( 1 x oscillator frequency - 1/32nd of the oscillator frequency ) 

543210 - fractional units

--------------------------

B = 1 = 128x divider mode

A9876 - integral units ( 1/96th - 1/128th of the oscillator frequency )

543210 - fractional units

Some example settings for register 0x9F:

32x mode:

0x037F - 2057143 Hz (highest setting that locks consistently on my E4K)

0x07FF -  900000 Hz

128x mode:

0x0800 - 300000 Hz

0x0FFF - 225000 Hz

The full range of divided sample rates in 128x mode (225-300 kHz) works very well.  The highest rates in 32x mode (1 - 13x) don't appear to lock at all.  14x (2057 MHz) drifts considerably from 2025 to 2031 Hz.

v/r,

Denny 

  

[Dennis Sheirer]

Attached pdf shows sample rate register settings.

[jdow]

You might try 2.4 msps. It manifestly works. At least the five dongles I
have of mixed types don't know they're not supposed to work at 2.4 msps
and provide me with very stable decoding.

{^_^} Joanne/W6MKU

> --
> You received this message because you are subscribed to the Google Groups "Ultra
> Cheap SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to ultra-cheap-s...@googlegroups.com.
> To post to this group, send email to ultra-c...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ultra-cheap-sdr.
> For more options, visit https://groups.google.com/groups/opt_out.

[Dennis Sheirer]

Hi Joanne, I originally coded my java version to match exactly how rtlsdr is setting the sample rate, and was able to use the 2.4 msps setting and get a stable output.  But, when I measured the actual output sample rate for that 2.4 setting, it measures about 2.019 msps.  I tested each of the rtlsdr rate settings, measuring each setting 3 times, and got consistent results each time.  Four of the rtlsdr settings align very closely with the rates in the pdf that I measured, but lower/higher rate settings are very skewed from actual measurements.

rtl-sdr  / measured

1,536,000.0	1,523,764.0
1,824,000.0	1,808,043.0
1,920,000.0	1,903,060.0
2,064,000.0	2,019,300.0

When I use the settings/rates in the pdf that I attached, all of the spectral components are right where they should be for the local environment, and they align with what my funcubes both show.  Using the new rates, I don't have to dial in any frequency correction on the e4k.

I've got an R820T and an FC0013 both new in the box that I'm going to check over the next couple days to see if they reflect what I'm seeing on the E4k.

-------------------------------------------------

[jdow]

Here the 2.4 Msps is dead nuts on once I correct for the crystal's PPM
error. I have three E4000 dongles and two R820T dongles. All of them
behave correctly. The spectrum display shows signals at the right places
across the spectrum with a full 2.4 MHz showing. This would be impossible
if the actual sample rate was wrong.

Note that 2.4 Msps is 1/12 th of the 28.8 MHz clock. So setting to that
frequency should be quite easy. And the path from 28.8 MHz to 2.4 MHz
is pure decimation steps with no resampling required.

I'd suggest you reinvestigate your measurement and settings processes
there.

{^_^} Joanne/W6MKU

> > to ultra-cheap-s...@googlegroups.com <javascript:>.

> > To post to this group, send email to ultra-c...@googlegroups.com

> <javascript:>.

> > Visit this group at http://groups.google.com/group/ultra-cheap-sdr

> <http://groups.google.com/group/ultra-cheap-sdr>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Dennis Sheirer]

Joanne,

I looks like my sample counter code starts getting flaky above ~2.xx GHz.

I originally worked out all of the ratios using the lower sample rate range (225 - 300 MHz) and extrapolated those register settings to the upper sample rates.  The register settings and sample rates in the spreadsheet seem to align close enough to the register settings produced by rtlsdr library's setSampleRate() method.  And, I'm now able to run ~3.0 GHz sample rates stably after I reset the dongle.

Thanks for your help,

Denny

On Saturday, January 11, 2014 2:35:23 PM UTC-5, Dennis Sheirer wrote: