RTL-SDR sample bit depth

John Ackermann N8UR jra at febo.com
Sun Mar 4 22:26:01 UTC 2018


Leif, one other question... how do you use a noise figure meter to 
measure an SDR?  I have an HP 8970A with noise head available, but 
haven't figured out how to do a measurement where there's no RF output 
to connect the meter to.

Thanks,
John
----

On 03/04/2018 11:56 AM, Leif Asbrink wrote:
> Hi John,
> 
>> For an approximation of the minimum discernable signal (MDS) I adjust
>> the signal generator amplitude until I see a noticeable signal that is
>> consistently just above the noise.  To find the overload point, I
>> increase the amplitude until I see the first spur appear -- it's a very
>> sudden transition, with a 1 dB amplitude increase triggering spurs many
>> dB above the noise.
>>
>> Based on the assumptions in my earlier message, I would expect to see a
>> dynamic range of about 59 dB (~50 dB from 8 bits at 1.536 Msps, plus 9
>> dB processing gain by the decimate-by-8).
> No, you are measuring noise in a much narrower bandwidth.
> "until I see a noticeable signal" implicates that you look at
> a spectrum of some kind. If I assume your bin resolution is
> 19.2 Hz you have another 40 dB higher dynamic range.
> You might be interested in this:
> http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr-03.40.htm
> 
>> However, I'm seeing closer to 100 dB dynamic range -- for example, with
>> the RF gain set to 20 dB, the MDS is -124 dBm and the overload level is
>> 25 dBm.  This tracks for various settings of the RF gain, though there
>> seems to be a few dB of compression with gains above 30 dB.
> MDS in what bandwidth? In amateur radio it is usually 500 Hz
> which, if you adhere to that means you found the noise floor
> at -151 dBm/Hz. That is 23 dB from room temperature (-174 dBm/Hz)
> so your noise figure would be 23 dB.
> 
> With overload at -25 dBm (typo?) your range would be 126 dBm/Hz
> or 99 dB in a 500 Hz bandwidth. That is not really true however
> because you would have to measure the noise floor while there
> is a strong signal present and reciprocal mixing would set the
> limit. On the other hand, if the strong signal is at 90 MHz
> it would not reach the ADC so performance would be determined by
> the tuner chip.
> 
> 
> Regards
> 
> Leif
> 
>   
> 
> 
>>
>> I'm trying to understand this discrepancy, which could be the result of:
>>
>> 1.  Some AGC operation or gain compression in the R820T2 tuner chip;
>>
>> 2.  My assumptions about the internal sample rate bit depth or
>> decimation being wrong; or
>>
>> 3.  My math being wrong (for example, is there a log10 vs. log20 error
>> in my dB calculations, or is the dB scaling in the FFT showing voltage
>> rather than power?).
>>
>> Any thoughts would be appreciated.
>>
>> Thanks,
>> John
>> ----
>> On 03/02/2018 09:46 AM, John Ackermann N8UR wrote:
>>> Hi --
>>>
>>> I'm trying to understand the sampling and decimation structure of the
>>> RTL-SDR dongle, to work out the effective number of bits after decimation.
>>>
>>>   From Google and looking at the librtlsdr code (which is beyond my
>>> programming depth), I think I've figured out the following.  I'd much
>>> appreciate verification/correction/amplification.
>>>
>>> 1.  Actual ADC in the RTL-2832U is a single-bit sigma-delta running at
>>> some very high rate.
>>>
>>> 2.  This is converted to 28.8 msps at 8 bit depth.
>>>
>>> 3.  28.8 msps is downsampled to the rate requested by the user and sent
>>> over the USB bus as 8 bit unsigned IQ pairs.
>>>
>>> Based on that, I *think*:
>>>
>>> a.  Any processing gain in the downsample from 28.8 msps/8 bits within
>>> the chip is lost because the wire samples are limited to 8 bits.  The
>>> output is 8 bits dynamic range regardless of the sample rate set.
>>>
>>> b.  THEREFORE... for best dynamic range one wants to set the RTL-2832U
>>> to the highest sample rate that avoids lost samples, and do further
>>> decimation in the host processor, where the added bits aren't lost on
>>> the wire.
>>>
>>> I'd appreciate any verification or correction of that analysis.
>>>
>>> Thanks,
>>> John


More information about the osmocom-sdr mailing list