RadarBox - Bug - Data being assigned to wrong aircraft

[AirNav Development]

We would like to have the feedback of our users on the bug listed below:
"Data (callsigns, altitudes, squawks, routes, etc) being assigned to the wrong aircraft."

This bug is also discussed at:
http://www.airnavsystems.com/forum/index.php?topic=6532.msg73788#msg73788

This is caused by having a single bit error in the transmission/receiving process and can be avoided from reaching the flight grid using software. The same error happens with any ADS-B decoder.

We our ideas on how to prevent this from happening.
Basically we will only show on the Grid (actual valid and correct received aircraft) data that has been received from a single aircraft twice.

For example if we have:
hexcode1,flightID1

The aircraft will be put on hold until:
hexcode1,flightID1

is received again and at this time it will be shown.
As usually we would like to know your feedback on this one and f you agree with this approach.

[ACW367]

Sounds sensible enough, however I guess we will only find out with roll out of bug patches after internal testing.  At the moment circa 1% of flights shown on the MyLog reporter on any given day are affected by this bug (IE regularly over 30 out of 3000 recieved daily).

[pjm]

Personally I'd display the information, but perhaps at half intensity (as if it was greyed out) until you have verified it with a second transmission, when you can display it at full intensity.

[neroon79]

I would preffer the following precedure:

- Airframe appears greyed-out after first reception*
- Airframe gets valid after third reception in a row (just to be sure one more)
- Time between two "in a row receptions" should be limited to about let's say 5 to 10 seconds or so.
- Airframe will be available on port 30003 after it is validated.

this may also work for airframes were no flight id was received at all. Many of my decoding errors in my list are  without a received flight id.

* Or you may concider to use the globe that is momentary indicating the shared ADS-B flights :

- dark-grey shaded globe: timed out airframes or any other that do not match up with one of the following:
- red (or dark yellow for the fellows with red/green problem): airframe awaiting validation
- green: validated non ads-b airframe
- blue(existing one): validated ads-b airframe

If adding all received airframes to MyLog, you should make it possible to indify the not validated ones, maybe by adding a column named valid and adding a y in it if it was validated. Just like you already do with the ADS-B status.

About the reports: You may put a + for non validated airframes were you already put a * for first time received airframes.

[Runway 31]

Maybe I am seeing this the wrong way and being a bit simplistic, but I wonder if this can even be called a bug.  Spurious packets/fragments of data are flying about all over the place in between valid data and affect all receivers but are handled differently by each.   From my point of view the box is trying to assign an identity to these mangled data fragments and is therefore assigning an identity to an aircraft which may not even be in the receiving area.

If this is the case why do we even want to see these mangled fragments/single packets being displayed on screen if they are not real identities.  I therefore consider that these should be filtered out using software and are only displayed when they are considered valid.  Software filtering should then minimise the number of mis-identified packets and we are only shown valid data.  You will never eliminate mangled packets but will minimise their appearance on screen/logs.

Alan

[Henning]

As far as I know the ADS-B messages contain a 24bit parity check field which can be used to check whether the transmission is ok or there are errors.
I don't know the exact details yet, but as the parity check field is pretty big, I assume that it can even be used to restore received erraneous data. But the simple solution is to just ignore messages that are identified to have a transmission error.

Some links with more detailed information about this:
https://trainingzone.eurocontrol.int/ATMTraining/PreCourse/SUR/ADS/Taste%20the%20Course/32501.10.32657.85.28722/Default.html
http://www.radarspotters.eu/forum/index.php?topic=5617.0
http://jetvision.de/sbs/adsb/crc.htm

And Google returns a lot more:
https://www.google.com.au/search?hl=en&safe=off&q=adsb+parity+check&oq=adsb+parity+check&gs_l=serp.12...0.0.0.127946.0.0.0.0.0.0.0.0..0.0...0.0...1c.duPabi4gY8Y

So I think that the best solution is to use the parity check to identify transmission errors instead of waiting for second messages or other workarounds.

[Netcop]

I am statistics lover. And for me personally this is a bug. And very, Very, VERY sensible bug :)

If you, AirNav, will correct it I am ready to close my eyes on the most other positions in the bug list. Even this problem will be solved partially and it would reduce the display of aircraft data on the edge of my reception range, as colleague tarbat correctly mentioned.

We have now perfect coverage of Moscow FIR in our network so I don’t worry about my own reception range at all. I worry about my statistics tables and daily reports which are now full of errors due to this bug.
 
Please validate correct combination twice or even more times, or use a more complicated procedure but give me clear daily reports :)

The other problem for me here is “U letter” problems in FlightID. It’s mostly connected to cargo flights. The same flight displayed in my log twice with the different FlightID’s – let say ABW243 and ABW243U. Even this is not a software error, we need to do something with this issue.

Regards,
Nick

[Runway 31]

Nick,

I would think the flight ID problem is coming from the equipment on the aircraft itself and nothing to do with Airnav software.  I have on occasion seen maybe over 20 different flight ID's in a very short space of time from the one aircraft, how would the receiver be able to identify which if any of these flight Id's is the correct one.

Alan

[tarbat]

If this is the case why do we even want to see these mangled fragments/single packets being displayed on screen if they are not real identities.  I therefore consider that these should be filtered out using software and are only displayed when they are considered valid.  Software filtering should then minimise the number of mis-identified packets and we are only shown valid data.

Totally agree.  I've recommended to AirNav the proposed approach as part of the v4.04 development work.  Only when two (or three?) messages with the same hex code and data (squawk, FlightID, altitude, etc) have been received is the data considered valid and NOT from a mangled packet.  This should prevent most corrupted data - unless you're so unlucky to receive two (or three?) messages with exactly the same mangled bits!  I did suggest they open this up to the forum in case anyone could see any flaws in my suggested approach.

My opinion is that TWO identical messages is enough to validate the data.  As you increase this to THREE or FOUR, you risk losing useful data.

[Henning]

As I wrote before, there is a proper way of handling the messages so that corrupted messages can be identified and maybe even corrected. The parity check is a standard algorithm that every programmer should be familiar with. It shouldn't be too hard for Airnav to implement it.
Then you do not need to wait for any messages and will always have correct information and not just decreased the likelihood of wrong data to be displayed.

[neroon79]

As I wrote before, there is a proper way of handling the messages so that corrupted messages can be identified and maybe even corrected. The parity check is a standard algorithm that every programmer should be familiar with. It shouldn't be too hard for Airnav to implement it.
Then you do not need to wait for any messages and will always have correct information and not just decreased the likelihood of wrong data to be displayed.

As far as I know the functionality of simple parity checks are usually directly implemented in the Hardware. If there is the possibility of error correction in the "parity Data", then it would be part of software to use this error correction Block to re-calculate the original data. Because of the fact that this are usually quite simple standard algorithms too, this is often directly implemented in the hardware too. The question is, are the ADS-B decoding part of the Box equipped with this kind of error handling or not. If yes: your proposal won't work. If not, and only the raw data is sent to software, then you are right and they shall integrate the error correction routines to the software.
But remeber there is also the possibilty that the scramble adds up to a valid parity check, although the data is corrupted. Then a THREE (My own programming experiency told me, that TWO are not enough) needed receptions before valid will filter these ones out.

[Hawkeye]

Not so sure about the proposed solution to this problem being to show information on the grid after only two or three messages with the same hex code have been received.
Have a look at the attached piccy, MyLog.jpg

Last Sunday, the 21st, I picked up Shuttle 7P from EGPF to EGLL with the code 40105C, correctly relating to G-AVGA, a Piper24 which was showing as operating this flight in My Log
You will see that it was being logged from 1546 to 1605 with a message count of 111. With so many messages over a period of 19 minutes it must surely have transmitted its code more than two or three times.

When AirNav opened this thread I dug a bit deeper into this flight and took a look at:-   http://www.flightradar24.com/data/flights/ba1489/ 
BA1489 is the flight number for SHT7P.  I found that the ‘plane actually operating SHT7P on the 21st was of course an A321, G-EUXL code 4010DC, - one character different. If you take a look at the above site you’ll see that at 1555, SHT7P was overhead Blackpool, only thirty miles from my home in East Lancashire.  As MyLog shows it was between levels 27000 and 32000+, well within reception range, (100 miles approx in that direction), so the false data was not caused by the flight being at the extreme edge of my coverage.
My first thoughts were that the aircraft must have been continuously transmitting an incorrect hex code and the glitch was not in the AirNav software because, on checking today, not once in the 19 minute period did G-EUXL appear in the log, But it would appear the plane must have been sending correct info or the data produced at the above site would have been wrong too.

One more point on this problem which has been in my mind me for quite some time.
If one hex code character difference can cause so much confusion in a flight at such close range, just how often does it happen without us realising it?
I wonder if RB owners who use it for spotting, regularly log the wrong plane where the data isn’t so obviously incorrect as the SHT7P one
For example, BA A319s  G-EUPE and G-EUPF have the codes 40083B and 40083C.
If one of these was affected by ‘the bug’, unless the user actually read off the registration, at an airport for instance, I very much doubt they would question the validity of the  registration data produced in MyLog  if they had seen it as an overflight from their window.

Regards

Syd

[AirNav Development]

Tks for all your input.

"but remeber there is also the possibilty that the scramble adds up to a valid parity check, although the data is corrupted."

This is an error that cannot be avoided by any hardware and the reason to implement further software checks.

>Then a THREE (My own programming experiency told me, that TWO are not enough) needed receptions before valid will filter these ones out.

We will implement this to the mode-s, callsign and squawnk fields.
All the other fields don't need this since they may constantly change (altitude, groundspeed, track, verticalRate, airspeed, latitude, longitude) althought other checks are already being done on these fields (purple rain problem, etc).

Please confirm you agre with our approach and the coding will start.

[Runway 31]

I havent a clue to the problem here Syd and whether the proposed solution would work ot not, far too techy for me.  G-EUXL flew the Glasgow-London route all day on 21st.  As well as SHT7P it also flew SHT6R, SHT8K and SHT9B, did you pick it up operating them and if so what was its hex used on those flights.

I would however suggest implements the proposal.

Alan

[Netcop]

I agree with your approach and will be impatiently waiting for final results.

Nick