R820T and SDRTrunk frequency error question Current PPM and Measured Error

Status
Not open for further replies.

IAmSixNine

Member
Feed Provider
Joined
Dec 19, 2002
Messages
2,522
Reaction score
705
Location
Dallas, TX
Im trying to manually tune some of these RTL-SDR dongles for a project.
Boss is using linux app to run them and im not a linux person.
I am using SDRTrunk V0.5.0 Alpha 6 windows.
Tuners tab, I see it shows Current PPM and Measured Error.
When stuff starts out its 0.0 under Current PPM. However that changes as the dongles warm up and are used.
I also notice Measured Error changes slightly. Example 54Hz to 140Hz and will show (0.1ppm)
So my question is,
If Current PPM shows -0.6 and Measured Error shows 140Hz (0.2ppm) does this mean its only off by 140Hz or is it off by that plus the -0.6 in the Current PPM
I need to get these things tuned in so he can make the adjustments in the program he is using.
 

DSheirer

Member
Premium Subscriber
Joined
Feb 15, 2010
Messages
628
Reaction score
174
Location
Fulton, NY
Current PPM is what's being applied to the signal to align it to the specified frequency.

Measured error is a feedback value from the DQPSK demodulator that indicates how far the carrier is from from channel center.

The auto-correction feature will periodically adjust the Current PPM value automatically if the measured error exceeds +/- 0.5 PPM over a specific time frame.
 

IAmSixNine

Member
Feed Provider
Joined
Dec 19, 2002
Messages
2,522
Reaction score
705
Location
Dallas, TX
Got it. I think.
So the two values are independent of one another.
My boss needs me to get them aligned and he is asking me for a +/- frequency and not a PPM value.
I run them for 15 minutes then see where the program puts them.
What is causing me to doubt my self in the understanding of this is when its first started Current PPM is 0 and Measured error is around 800Hz,
Then after a few minutes it will change to say -6 under Current PPM and the Measured Error will be down to around 100 with -0.1 or -0.2ppm value.
So in my mind it made sense that for each Current PPM value = a specific amount of Hz. But it sounds like that is not the case.
 

DSheirer

Member
Premium Subscriber
Joined
Feb 15, 2010
Messages
628
Reaction score
174
Location
Fulton, NY
PPM or parts per million is the offset needed to align the tuner's signals to the displayed frequency.

If you're tuning a signal at 150.250000 MHz, each unit (1.0) of PPM is equal to (150,250,000 / 1,000,000) or 150.25 hertz. Tuning a signal at 450.25 MHz, each unit (1.0) of PPM is equal to 450.25 hertz.

The user applied PPM is simply used to align the signals to the frequency readouts in the spectral display.

There will always be a difference in the frequency of the signal that is transmitted and the received signal that your tuner presents to the software. The software demodulator uses a mixer to compensate for that difference. In sdrtrunk, the measured PPM value is the amount of offset mixing the software has to apply to the received signal to center the carrier signal. sdrtrunk could present that error measurement as a Hertz value, but then you would have to convert that to PPM in order to manually adjust the PPM if needed ... something that sdrtrunk does for you automatically.
 
Last edited:

Ubbe

Member
Joined
Sep 8, 2006
Messages
10,608
Reaction score
4,385
Location
Stockholm, Sweden
When stuff starts out its 0.0 under Current PPM. However that changes as the dongles warm up and are used.
I got two RTL-SDR and I have the same -0,6ppm error and when I use SDR# it only allows non decimal values so I have them at -1ppm and that doesn't change when they are cold or warm. They use temperature compensated oscillators so they should have a constant error.

PPM are parts per million so if you are monitoring a 1MHz signal a 1PPM corresponds to 1Hz. So 100MHz are 100Hz error for each full PPM. 800MHz have 800Hz error at 1PPM. Professsional analog radio equipment usually allows a tolerance of 1,5KHz for mobile and 800Hz for basestations. Digital systems are often GPS synced to a much higher tolerance. When I monitor digital systems like DMR or Tetra I can go 3PPM offset in SDR# and still decode without any problem so it probably isn't extremly important to be spot on if the signal strenght are good.

/Ubbe
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Reaction score
135
Location
Portage Escarpment
Also keep in mind that (unless your SDR has an infinite number of bits in its frequency-setting registers), the actual tuning is performed in small, discrete steps rather than being continuously variable - with the result that there is always a quantization error when setting the hardware oscillator frequency. Each time the tuner is tuned to a new frequency, the amount of error will appear to change, randomly.

Secondly, the PPM errors aren't necessarily linear over the tuning range (typically, HF to UHF) of the device.

Max
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,620
Reaction score
1,018
Location
Talbot Co, MD
Also keep in mind that (unless your SDR has an infinite number of bits in its frequency-setting registers), the actual tuning is performed in small, discrete steps rather than being continuously variable - with the result that there is always a quantization error when setting the hardware oscillator frequency. Each time the tuner is tuned to a new frequency, the amount of error will appear to change, randomly.

Secondly, the PPM errors aren't necessarily linear over the tuning range (typically, HF to UHF) of the device.

Max
I've not been able to find out the number of bits in the RTL tuning registers but I can empirically say you'll be lucky to get one to repeatably tune anything under about 300Hz. If you sweep the tuning in small steps you'll see all sort of weird jumps in the output; sometimes it even goes the wrong direction! Airpy seems a little better (more linear) but they both use the R820T2 tuner chip as far as I know.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
3,620
Reaction score
1,018
Location
Talbot Co, MD
Sounds like a bug in the control code (typically in rtlsdr.dll)
Unclear exactly the cause, but if you ramp the hardware tuning on an RTL device in small steps (say +100Hz) you can observe the spectrum and see a signal peak moving by an amount other than +100Hz. Whether or not it's a bug would be really dependent on the expected resolution of the tuner and tolerances of the components attached to it along with the accuracy of any decimation being carried out by the firmware.

In practical terms it's not really that big of a deal because more SDR apps don't need the signal to be tuned that accurately since their own tracking loops can take care of small errors.
 

IAmSixNine

Member
Feed Provider
Joined
Dec 19, 2002
Messages
2,522
Reaction score
705
Location
Dallas, TX
Thank you guys very much for the follow up.
Im soaking it in and going to work on this some more today.
 
Status
Not open for further replies.
Top