The aircraft labelled as VAQ is reported in the tracklog as coming from ADSB receivers.
The aircraft labelled as VH-VAQ is reported in its tracklog with positions from Aus ATC (ADS-B)
Same aircraft but different information.
Which is correct?
A
Trick question, they’re the same data with a differing delay.
(We’re probably missing a hexid / tail mapping for VH-VAQ, which is why they’re not getting merged; the Aus convention for VH- registered aircraft when there’s no assigned flight number is to use a callsign that has the leading VH stripped; we restore it before doing flight matching, but only when we actually know the registration of the aircraft…)
It wasn’t meant to be a trick question.
At one stage they were flying a parallel course so the location was different not merely delayed.
S
Hm, well in theory if it is purely Aus ATC ADS-B, that’s data from Airservices’ own ADS-B network so it should be the same thing as the data we hear via the PiAware network.
There is also non-ADS-B data (radar, etc) from Airservices that might differ.
I assume in a case like this you would only know the registration based on the ICAO hex code.
Does this imply the Hex codes didn’t match?
Also, is there anywhere on this page that I can identify the aircraft? As you said the VH- is dropped off when there is no flight number and I can’t find a hex code.
On this page the aircraft is noted as a 90 whereas all other activity noted it as a B190.
Thganks,
S
Hex code plus a registry mapping the hexcode to a registration.
The logic is something like:
- determine a registration from hexcode
- if we know the registration, and (VH + ident) = registration, then set ident = registration
Is it these two? https://flightaware.com/live/flight/VAQ/history/20190726/1344ZZ/YMMB/YDPO and https://flightaware.com/live/flight/VHVAQ/history/20190726/1330ZZ/YMMB/YDPO
I eyeballed the tracks and I don’t see the same divergence that’s in your screenshot; I wonder if you managed to get some estimated data at the time or something like that.
The aircraft type can come from a number of different places and unfortunately it’s not well normalized for some datasources (I get the feeling that sometimes what we receive is “whatever got typed into the flightplan” with no additional validation)
I provided all I have from that flight but that aircraft flies within range every day or two and I will look out for a similar anomaly…
What would you suggest I capture next time I see such an event?
As this is an aircraft (registration) rather than a flight (assigned flight number) then all appearances of VH-VAQ and VAQ should be referring to the same metal. You would think that ATC would know what the aircraft carrying that registration is and it would not need to be validated with each flight.
Does the information you receive from Australian ATC have a hexcode or just the VH- registration?
Thanks for your help,
S.
The permalink (long URL that embeds origin/destination/times etc, like the ones I posted above) for the two flights.
I don’t think this happens.
Registration and ident only (and a bunch of flightplan information associated with the ADS-B data). So the ATC feed has reg + ident and we glue the VH- prefix onto the ident. The PiAware feed has hexcode + ident, and we don’t have a mapping for the hexcode to a registration, so that ident does not get VH- glued on, and you end up with two copies of the flight.