@obj
Just reading your dump1090 code i was wondering if it’s possible to do CPR location decoding for surface aircraft without a reference position?
As in global CPR for surface targets?
I’m trying to understand the process, but i’m not sure i will, so that’s why i ask 
Not unambiguously. Given an odd/even pair of surface positions, there are 8 possible solutions (2 latitudes, 4 longitudes, each separated by 90 degrees) so you need additional information to know which is the correct one. (This is because the encoding process for surface positions discards the top bits of the encoded lat/lon)
Yeah thank you i had almost guessed that after reading the part of 2 bits being omitted for surface positions.
That’s really annoying.
I suppose that’s one of the uses for the FA estimated position?
Or is that not sent to the piaware client?
Estimated receiver positions aren’t used for this (they probably could be with a bit of work) but manually set receiver positions are.
In theory you should get surface positions for landing aircraft regardless of whether the receiver location is set, because in that case there’s an airborne position to use as the reference.
Yeah i’m aware
(I understand some of the code)
Thanks again for the explanation.
Wait… Not it hit me - the “reverse MLAT” is possible too.
If a “radar” station sends 4 or more feeds of aircraft ADS-B positions, and those aircraft GPS coordinates are known (decoded from ADS-B feed), one can triangulate the exact location of the “radar” station.
A website can determine the location of every “radar” station that feeds ADS-B to that website.
So my approach of being paranoid about what site I do feed my ADS-B message just got another confirmation.
PS: The first one was the possible tracking of local military planes exercise by other countries spyops.
I think you are probably being too paranoid 
In the UK the licencing authority publishes the locations of protected radars
https://www.ofcom.org.uk/__data/assets/pdf_file/0020/44921/protected_radar.pdf
I suspect the same information for the US is available via the FCC.
You, running an ADS-B receiver, are NOT a “protected radar”.
I am talking that YOUR location can be determined by the website you are feeding the data - if they choose to reverse MLAT you.
In order to do MLAT in the first place the sites I am feeding need to know my exact location, so I am totally not bothered by anybody wasting their time and effort trying to reverse MLAT things they already know.
No they don’t. They can easily work out your location from the timing of certain packets(similar to how GPS/GNSS works).Not that anyone would care.
Not as described; you don’t know the time offsets between those different transmissions so every time you add an additional message to the system of equations, you also add an unknown and never make any progress.
However if you add a second receiver that’s at a known location and is receiving the same messages then I expect it’d be possible. (Maybe? Time synchronization does become an issue; I haven’t thought this all the way through)
Maybe you are right, but it would not be inconceivable to do, with so many sites feeding data now.
However, this nothing more than just another theoretical reason for me not to feed each and every site that wants ASD-B data.
Don’t let me hijack this thread…
Thread was over anyway
Oh yay CPR decoding, i’ve got another question @obj:
Consider a synthetic MLAT position being sent from the mlat server, following that you receive a valid odd or even CPR from the aircraft.
Could that be combined to an inaccurate MLAT position which is not shown as MLAT in the json?
Even ignoring every json entry for which the mlat array has lat, i get some MLAT positions.
I’ve compared to a dump1090-fa instance only decoding the received data and no MLAT results which doesn’t output those stray positions.
I’ve looked into the code of dump1090-fa a bit, but i can’t quite put my finger on where the bug? is.
The problem normally doesn’t occur that often because the mlat client/server doesn’t do MLAT for planes with ADS-B position.
But the mlat-server doesn’t do surface position decoding it seems, so there are cases where a receiver gets valid positions and MLAT is still being done.
No - the CPR decode will only use odd/even pairs that have the same source (mlat, direct ADS-B, and TIS-B are considered separate source). see dump1090/track.c at master · flightaware/dump1090 · GitHub
Also, the individual CPR odd/even state is only updated when the new message is from the same or a better source type (mlat < tisb < adsb), or when the existing data is stale (>60s old). A corner case is that relative CPR using a mix of mlat and direct ADS-B could perhaps happen if you don’t ever hear one of the odd/even types via direct ADS-B for a long time.
What’s the context here? I don’t understand quite what you’re looking at.
I was tinkering with my web interface modifications and tried to get rid of MLAT positions for aircraft on ground because those mess up the ground tracks of aircraft as they lack the precision for airport display.
Sadly it seemed i couldn’t filter out all of the MLAT positions while the aircraft was on ground.
Started up a separate dump1090-fa that only received the non-MLAT data for comparison.
The ADS-B positions can indeed be intermittent.
How long before the decode logic would use a MLAT position after doing a valid relative CPR?
124 F(cpr_odd, 60, 70); // ADS-B only
125 F(cpr_even, 60, 70); // ADS-B only
I’d assume 60 seconds before MLAT CPR would be accepted after an ADS-B CPR is received?
I think i’m seeing MLAT positions sooner than that.
So that could happen if one were to receive only odd ADS-B CPRs and the even ADS-B CPR were to be older than 60 seconds, a relative CPR would be done on an even MLAT CPR?
Hmm i got sidetracked, that isn’t really the problem.
The problem is the MLAT derived position isn’t marked as MLAT in the json data.
Otherwise my webinterface would discard it (for ground positions, but i’ve also tried discarding all json positions marked with mlat, the MLAT positions still get through)
I think so, yes. If you were receiving both the synthetic mlat pairs of odd/even messages, and odd (only) ADS-B position messages, then you’d get both position types coming through via relative decoding; it’d never use a mismatched odd-ADSB/even-MLAT pair together for global CPR, but it could use each independently I think. Maybe something that needs fixing.
Do you have some raw data for this case that I can look at?
In what form would you like to look at that?
Beast data streams?
I’ll send you a private message.
Beast data or or view1090-fa --no-interactive output would be fine
I’ll try and filter out an example of it happening so you know what i mean.
And then record two view1090-fa --show-only outputs for the plane in question.
One output from a dump1090-fa with both beast data streams and an output for which dump1090-fa only has the non-MLAT stream.