FlightAware Discussions

Anyone doing a PPM offset for their RTLSDR?

Anyone doing a PPM offset for their RTLSDR?
I’m wondering if it’s worth investigating to improve performance.

I’ve tried it, but didn’t see a change.
Have a go, it’s surprisingly easy - at least it is on an unfiltered dongle where you have your choice of transmitters to call your reference.

I never bothered to set ppm :slight_smile: , but did bother to set gain, and tweaking gain definitely improves reception.

1 Like

I’ve figured out ppm on all my dongles.
Make sure they are warmed up.
Once I have a good offset I write it on the dongle(along with the serial number I set them too), so I can easily remember when messing around.

Same here. Good learning and fun, but no benefit.

Some dongles, like the RTL-SDR Blog, have TXCOs so PPM adjustments are not necessary, if it was a factor.

A quick sanity check can be made, even with a filtered dongle or LNA, by feeding ADSBexchange.
They have a page where you can check your MLAT sync with adjacent feeders and observe your offset relative to other contributors in your area.

1 Like

you mean this one for example?

https://adsbx.org/sync/4B/
How can i determine the possible offset?
The corresponding line beside my feeders are showing “green” for almost all connects

Hello foxhunter
Yes, correct.
Normally, you click on a feeder name and it will give offset from that feed to all other feeds with which it is synchronised.
Unfortunately this is not working at the moment.
ADSB exchange are not as well funded as some other sites. Sometimes their servers struggle, or they may be in the process of upgrading again.
Definitely worth sticking with if one reads the objectives of the organisation or just for this feature alone. (It usually works. The “sort columns” feature is really useful but you need to be quick to beat the automatic reloads of the page).

If there are individual sites which show “offset” from mine while the majority is green, i would assume it’s more the problem of these indvidual sites, but not me, or?

At least this is what i read also from the explanation there:

* PPM offset - these are relative values, but if you have lots of red, check the ppm setting for dump1090 ( < 50 = green )

Yes, that is what I understand too.
But to check, what you can do, as you seem to be synced with a lot of other feeders (If you have the time) is look for another feeder in your area and see if you can spot your feed by hovering over the green, yellow and red dots of that user.
I’m sure there is a feeder map an ADSB Exchange.

https://map.adsbexchange.com/mlat-map/

Clicking on any of the receivers you’re interested give you details

The ones i am synced to are all green except the ones which show yellow/red on mine. They seem to have the problems
My primary has 56 connections and only four of them are yellow. So i am not concerned :slight_smile:

When they fix the web-page, if you have a bored moment or are feeling a bit OCD, you can always optimise another setting.
There’s not much that can be done with gain if there are no planes.

I did but it was so tiny that it wasn’t worth it. The TXCO makes the tiny difference irrelevant.

Mine is not synced to any sites? Does it only show syncs when there are active MLAT aircraft being picked up? (EDIT: can’t be right as the site next to mine is synced with 46 peers!)

https://adsbx.org/sync/feeder.html?3A-1&bussey_48

MLAT sync’ing has to do with reception of the same aircraft signals between stations and time accuracy, not frequency accuracy (PPM). What am I missing?

1 Like

PPM is important if the dongle is used to receive SSB Voice communication, where channel width is 3khz. The ADS-B has channel width of 2 MHz and ppm accuracy is irrelevant

2 Likes

Even more important than for SSB, for narrow modes like FT8, FT4, WSPR, etc.

1 Like

adsbxchange’s MLAT implementation is basically my original mlat-server work with no major changes. That implementation works by, for each pair of receivers, modelling each receiver timestamp as starting at a fixed value and then counting at a fixed frequency.

Since it can’t trust either receiver to have a “true” value, it actually models the difference between the two clocks as an absolute difference (the difference between the fixed values) and a frequency difference. And then the server uses those parameters to adjust all timestamps involved in receiving a particular message to a common time basis (as if they’d all been received with a single synchronized clock).

So the model naturally has the difference in clock frequency available for each receiver pair. My original implementation had a quick-and-dirty html page which would show the matrix of all receiver pairs and their frequency offsets; that’s evolved into whatever they have now.

2 Likes

Thanks @obj.

My ‘perspective’ was, if the signal is received, a few PPM here and there would be irrelevant. If the frequency drift is too big, no reception would occur, therefore MLAT sync’ing would be a moot point.

Part of the puzzle there is this:

To build the clock model, receivers need to see a message in common from an ADS-B equipped aircraft with a known position.

Since it’s entirely possible for bit-for-bit identical messages to be transmitted at different times, the mlat server looks at the (high resolution) interval between pairs of messages to identify the “same” message pair. (It needs a message pair anyway for two reasons - (a) you need a pair of messages to determine the aircraft position; (b) you need a pair of messages to determine the frequency-offset part of the model).

Different receivers don’t hear exactly the same interval (even after compensating for receiver location vs. aircraft location) because of local variation in clock frequency. So the server has to allow some leeway when trying to match together these pairs of messages. But you don’t want to allow too much difference or you’ll start matching pairs that are not actually the same transmissions, which then disrupts the synchronization process. So there’s an upper limit to how much leeway to allow.

The original value I picked (fairly arbitrarily) was, IIRC, around 100ppm; if the difference between receiver clocks is more than that, then you just won’t get sync even if you’re hearing the same messages.

1 Like