PAW ID changing when viewed via Glidertracker

[Moffrestorer]

Hi Lee,

You informed me by PM the other day that our Eurostar appeared to be transmitting a different Hex code from the PAW compared with our Mode S ID. This appears to have been for a portion of the flight only, as recorded via a screenshot taken from Glidertracker.

I have just witnessed another aircraft apparently doing the same thing (screenshots available if required), and wonder if this maybe something to do with processing via OGN or Glidertracker and not related to PAW at all?

The aircraft did a round trip from Halfpenny Green today, landing at Shobdon. it’s Hex is variously reporting as 62F271, 627071, 627275, 627271 when I touched on the different aircraft symbols on the track, but all appear to be the same aircraft. I tried checking it on its return to EGBO via glidernet.org but it gave an ID of 4a31dd37.
None of the Hex codes above are identifiable via G- INFO.

Hope this may give a pointer to this phenomenon.

Thx,

Chris

[Admin]

Not sure if this is related, but ....
I think that the OGN hides the true ICAO code, UNLESS the user has signed up to share information on the OGN

What Phil Lee was reporting IIRC, is that the ICAO code was reported, but was incorrect.
I am not sure where the issue really is now...

[buzz53]

Is this not (one of) the issues we discussed a few weeks ago on the OGN forum, whereby corrupt packets are occasionally not detected due to the use of only a single byte checksum? At the time we were talking about occasional jumps in an aircraft's path due to corruption of (usually single) digits of latitude or longitude. But of course any part of the packet could be corrupted and I have recently noticed spurious "orphan" aircraft being left behind on a track for presumably this reason. It looks really scrappy on the tracker but the big question is whether it really matters for the primary purpose of the product? Personally I think it should be sorted if only to avoid criticism that the system has shaky foundations. This would really need the protocol modified to use a longer checksum (Flarm, I believe uses 16 bits) which would be logistically tricky with so many systems already in the field. A possible interim mitigation would be to compare consecutive messages from the same aircraft and reject implausable changes. To cope with the orphan problem, on first contact at least two messages with the same ID would be required before the new aircraft is recognised.

Alan

[Admin]

Hi Alan

I think this is not directly related, the issue we discussed previously, was one of persistence, in other words after the last packet is received, it is repeatedly sent to the APRS servers for upto 15 seconds. This was code from Pilotaware, and is not relevant for sending to the APRS servers. This meant that as an A/C went out of range of OGN-R(A), it was repeatedly reported in the same position, whereas it was being reported in a new position by OGN-R(B)
This is fixed in the latest release, and needs rolling out to the ground stations

Your idea of a count is a good idea for verifying the ID, and is easily implemented

I don't think there is a requirement for 16bit CRC, in the general case this works well, and data is a premium in these communications.

Thx
Lee

[buzz53]

Hi Lee,

I think we did discuss it before but maybe it wasn't wise to deal with more than topic per posting and I was wondering if it had been forgotten about! I see now that this probably doesn't explain Phil's original issue though, I was really following up on MoffRestorer's observations as they matched my own.

I'm not totally convinced this should just be ignored, even though things generally seem to work at the moment. I suppose the worst case scenario would be if a corrupted position caused a ghost aircraft to appear right in front of somebody else, like a Klingon battlecruiser uncloaking. Unlikely, but quite high impact for the person involved. More generally I can't help but feel having corrupt data floating around will sooner or later trip something up, possibly a function not yet thought of (and I believe the protocol is meant to be extensible). Flarm, for example, is used in the gliding world for automatic fleet logging and it would be a pain to have to filter out these ghosts from a PAW source.

Whatever the purely logical view, I think there is a reputational risk involved. I don't think an 8 bit CRC is really what the industry would use here, although I feel your pain at the thought of changing.

Alan