PPM Correction Universal?

[altonj]

I have 2 Nooelec dongles that were modified with an improved LO. From what I can see they don't drift. Using SDR# I tuned each dongle to a strong frequency that I could confirm in the RR database. Centered the signal as best I could and used rtl_eeprom to record the ppm correction in each dongle. From what I saw the corrections were 52 and 60 and (to me) seemed stable over time.

When I spark up Trunk88 it seems to disagree with my notions and sets the ppm correction at 60 and 72 (respectively). So I took the ppm correction numbers from Trunk88 and used them in Unitrunker and it seemed to work well, I would even say that the DSD+ decode on the digital voice comms was a little bit better.

So my question is... is a ppm correction value 'universal' across software programs such as SDR#, Trunk88, and Unitrunker or do each of these programs have their own notion of ppm correction?

 

[Voyager]

So my question is... is a ppm correction value 'universal' across software programs such as SDR#, Trunk88, and Unitrunker or do each of these programs have their own notion of ppm correction?

Each program may have different values for the correction factors. While they might be the same, I would doubt it.

 

[jonwienke]

If the dongles actually had a good TXCO, they wouldn't need a PPM adjustment in the first place.

 

[SCPD]

So my question is... is a ppm correction value 'universal' across software programs such as SDR#, Trunk88, and Unitrunker or do each of these programs have their own notion of ppm correction?

Unless SDR# has recently changed how they calculate PPM, they should agree. It's always lined-up for me.

 

[slicerwizard]

I have 2 Nooelec dongles that were modified with an improved LO. From what I can see they don't drift. Using SDR# I tuned each dongle to a strong frequency that I could confirm in the RR database.

What frequency?

Centered the signal as best I could and used rtl_eeprom to record the ppm correction in each dongle. From what I saw the corrections were 52 and 60 and (to me) seemed stable over time.

When I spark up Trunk88 it seems to disagree with my notions and sets the ppm correction at 60 and 72 (respectively). So I took the ppm correction numbers from Trunk88 and used them in Unitrunker and it seemed to work well, I would even say that the DSD+ decode on the digital voice comms was a little bit better.

So my question is... is a ppm correction value 'universal' across software programs such as SDR#, Trunk88, and Unitrunker or do each of these programs have their own notion of ppm correction?

PPM correction only means one *exact* thing, namely by what percentage tuning commands are altered to compensate for reference oscillator errors, so PPM can't mean one thing in one program and something else in another unless one of them is broken. Of course, since TRUNK88 uses PP10M values, its numbers should be ten times what SDR# uses.

 

[altonj]

The frequency I've used is 142.14 Mhz - the control channel of the Cayuga tower of the Bell Fleetnet system.

 

[SCPD]

When calibrating with a program like SDR# - use a 851+ Mhz or 935+ Mhz signal for reference.

The higher frequency magnifies the error. The effect of a 1.0 PPM change is more apparent. You'll get a more accurate warp setting.

 

[bama9999]

When calibrating with a program like SDR# - use a 851+ Mhz or 935+ Mhz signal for reference.

The higher frequency magnifies the error. The effect of a 1.0 PPM change is more apparent. You'll get a more accurate warp setting.

Wasn't aware of this. Thank you for this helpful bit of info!

 

[rbm]

If you can receive any OTA digital TV channels you can use the following procedure.
There are several ways to do it, but I've found this to be the quickest and easiest.

You can use the 'pilot' of an ATSC TV broadcast.

That is supposed to be 'exactly' 310 kHz within the TV signal. (ie. Channel 14 is at 470.310 MHz)
Using the highest frequency local channels works the best.

I've found that in practice, this will get you within plus or minus 1 ppm.
Remember, the 'accuracy' of the technicians that set up all those signals varies quiet a bit. So take a average of more than one.

You can see a list of the pilot frequencies here.
Just check against a few local TV signals.

North American television frequencies - Wikipedia, the free encyclopedia

Rich

This shows the view while calibrating to an ATSC TV pilot frequency.
Notice for best accuracy you need to zoom way in.

 

[altonj]

When calibrating with a program like SDR# - use a 851+ Mhz or 935+ Mhz signal for reference.

The higher frequency magnifies the error. The effect of a 1.0 PPM change is more apparent. You'll get a more accurate warp setting.

Thanks. Managed to locate a signal above 935 Mhz and checked both dongles. The one set to a ppm correction of 60 remained there but the one set to 52 needed to be corrected to 49. Seemed to improve DSD+ decoding.

 

[nd5y]

You can use the 'pilot' of an ATSC TV broadcast.

That is supposed to be 'exactly' 310 kHz within the TV signal. (ie. Channel 14 is at 470.310 MHz)

They aren't all exactly 310 kHz from the lower band edge.
Some DTV stations are offset to reduce co channel interference.
You should verify the exact frequency your local stations are on before you use them for a calibration standard.

 

[altonj]

rbm,

Thanks. That's pretty cool. Just to be sure, what do you hear from those pilot signals? When I'm lined up on one and I turn the audio way up it sounds like wind to me.

I recorded about 6 pilot signals into SDR# and it looks like, based on this method, the proper ppm correction value is 51. Had one that worked best at 50. This is for the one dongle previously set at 49.

On one particular pilot signal it seemed that switching between 51 and 52 moved correct alignment from one side of the signal to the other. So I entered 51.5 to see what would happen. SDR# rounded it up to 52 on screen but shifted the signal by more than just 1. Suddenly the signal now seemed to be between 52 and 53 leaving me to think that the 0.5 was still added but not showing. So I entered 51.1 which it rounded down to 51 and everything seemed normal again.

So much to learn.

Thanks again.

 

[rbm]

rbm,

Thanks. That's pretty cool. Just to be sure, what do you hear from those pilot signals?

You won't hear a thing.
They're just a steady, reference signal.

And, they are 'intended' to be quite accurate.

SDR# ppm correction is limited to whole numbers only.
So you have to find a 'happy medium'.

Check a few signals, and pick the value that seems the closest most often.

Rich

Edit: For decoding digital modes, it may help to increase the bandwidth slightly.
Also, in many cases, I get better decodes using WFM mode than with FM. (While still using the same bandwidth)


Here's a sample NOAA-19 satellite image, from Nov. 13th, decoded in WFM mode with the bandwidth at 38,000.
Using one of my ST2 antennas. (the same one my feed is on)

 

[garys]

The method I stumbled on tonight is to find an analog 900Mhz trunking control channel, start Unitrunker and read the frequency it displays. Then I correct SDR# to match that. From that point on, I can use DSD+ to read the data on the 900 MotoTrbo systems I'm trying to figure out.

 

[altonj]

Check a few signals, and pick the value that seems the closest most often.

Rich

Edit: For decoding digital modes, it may help to increase the bandwidth slightly.
Also, in many cases, I get better decodes using WFM mode than with FM. (While still using the same bandwidth)


Here's a sample NOAA-19 satellite image, from Nov. 13th, decoded in WFM mode with the bandwidth at 38,000.
Using one of my ST2 antennas. (the same one my feed is on)

Thanks again. I compared what I observed between 6 different signals and went with what works best, most of the time. I think I recall you (or someone else here) mentioning the WFM trick and I've used it a couple of times when working with SDR# but I'm just getting into digital modes. So far I've stuck to trunking and some simple analog transmissions - with a little adsb thrown in.

ST2 looks interesting... do you employ an fm trap with that?

 

[Voyager]

If the dongles actually had a good TXCO, they wouldn't need a PPM adjustment in the first place.

TCXO and PPM adjustment allow for two different things. A TCXO will only stabilize the oscillator frequency. You would still need the PPM adjustment to allow for the exact frequency adjustment.

IOW, a TCXO only makes sure the frequency does not drift (once warmed up). So, with a TCXO and no PPM, you may be 780 Hz off frequency, but with no way to adjust that. But, with the TCXO you would always be 780 Hz off frequency. By contrast, an identical unit also with a TCXO may be 190 Hz off frequency. You need a way to set the frequency in any oscillator where frequency matters.

A TCXO without PPM adjustment is like having a clock that is 5 minutes fast, but no way to set the time. But, at least it will always be 5 minutes fast. ;->

 

[jonwienke]

Except that TXCOs are typically calibrated more accurately in the first place, compared to a crystal that can drift around more than 75PPM depending on ambient temp.

My point was that a TXCO is much more likely to have a consistent PPM adjustment between programs than the cheap crystals that come with the standard dongles. When the oscillator varies more than 50PPM, you aren't going to get a consistent correction factor in one program, let alone in multiple different programs.

In contrast, the good TXCOs are accurate and stable within 2PPM, which is generally close enough that you don't even need to worry about correcting the frequency in most cases.

 

[altonj]

Just for the record. The ppm correction of the two dongles I have hasn't changed more than 1 or 2 ppm in the time I've had them regardless of how long I have them running. That 1 or 2 ppm change in ppm correction is more a result of my lack of knowledge when it comes to properly setting the correction.