RadarBox - Bug - Data being assigned to wrong aircraft

[flygfantast]

I agree with your solution.

Niklas

[AirNav Development]

This is now fully implemented.
Mode-s Hex code, Squawk and Callsign will only be accepted when received fro the third time.
We are working on other issues right now.

[Kenny]

That's quick for fixing one bug..  Hope to see the 4.04 soon.

Regards,

[Hawkeye]

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

Too techy for me as well Alan.

I checked MyLog for the 21st again and have no entries for 6R, 8K or 9B, but………
I decided to run a Registration filter for G-EUXL, which produced an unexpected result.

On the 21st, G-EUXL is shown with its correct code as having been logged operating SHT7P !!  The data also shows slightly different start and end times, and different start and end altitudes from the MyLog attach I sent previously for SHT7P.
It is also shown as having operated SHT6R the same day, which as I’ve said, did not appear in MyLog either.

I wouldn’t have the slightest idea whether this anomaly in logging is relative in any way to the ‘data being assigned .......’  bug being discussed here but perhaps it would be worth looking into at the same time. Alternatively, if it could be caused by some setting I have made, I would appreciate advice.

Syd

[tarbat]

Mode-s Hex code, Squawk and Callsign will only be accepted when received fro the third time.

I guess my only question is whether THREE is the right threshold.  Obviously the higher the threshold, the more "bad" data will be excluded, but the more "good" data may be lost.  So, I did an experiment (yes, I know, I've got too much time on my hands!!!).

I have a recorded file of ModeS messages (using testmodes.exe), containing 232,263 messages.  Within this there are 2,544 FlightID messages and 21,310 Squawk Code messages.

Out of the 53 HexCode/FlightID combinations received:
      2 were received once only.
      2 were received twice only.
      49 others were received 3 or more times.

And out of 98 HexCode/Squawk combinations received:
      3 were received once only.
      2 were received only twice.
      93 were receive 3 more more times. 

So, albeit with a relatively small sample, with a requirement for 3 matches, that will represent a potential loss (if none were actually corrupted) of:
      7.5% of FlightIDs.
      5% of Squawk Codes.

Alternatively, with a requirement for 2 matches, that will represent a potential loss (if none were actually corrupted) of:
      3.8% of FlightIDs.
      3% of Squawk Codes.

I guess I'm just questioning whether THREE is the best threshold to use, or whether TWO would be better - any thoughts?

[AirNav Development]

The way it works right now, witth the changes implemented, is:
1- Received mode-s code first time, do nothing;
2- Received mode-s code second time, do nothing;
3- Received mode-s code third time, add new aircraft;

After aircraft is added, flight number and squawnk will only be added when received for the third time after aircraft is added too MyFlights.

We can change these settings but we would prefer not have them as options which would confuse 95% of the users.

[Henning]

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

I don't agree with your approach. I prefer that you implement the proper solution using the parity check bits to clearly identify transmission errors. Everything else is just a workaround.

[neroon79]

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

I don't agree with your approach. I prefer that you implement the proper solution using the parity check bits to clearly identify transmission errors. Everything else is just a workaround.

Hi Henning, have you read my comment on your last post? Using the parity bits may not solve the problem, if these checks are already implemented in a special decoding chip or in this case in the pre-processing chip. As far as I know today these kinds of parity checks are usually fully integrated in the hardware if a special decoding chip is used, or at least in the firmware if no special decoding chip is used (like this case).

For me the question is now: Are there already proper checks implemented in the firmware of the box, or are they not. If not, the firmware may be get (back) in focus, to add the checks there. If, yes go ahead in the already started way. On the other hand: From my point of view no serious programmer will leave out the opportunity to get rid off of corrupted data if he has a chance to do it at the front end of a signal/data processing chain. I would do it that way. But final confirmation can only be given by airnav, or the guy(s) who wrote the firmware to be more precisely.

@airnav: A lot of Software is using a the option to set to a professional mode, where additional configurations, that only a few users may need, can be altered. Maybe it is worse to consider to add this option to the upcoming new versions of RB Software. Because, I like the I idea to be able to access this parameter set-up in a direct way. It would give me the opportunity, to set them to a state were they are perfectly suiting my needs.

[Runway 31]

Henning,

As I stated earlier I am not tchnically minded but I have a question regarding your statement that parity checking will identify transmission errors. 

Would it be the case that a parity check of a single transmission/packet could give a valid assumption of the wrong ID.

I ask as on the mode-s forum I see two or three times a week unknown ID's being made by different receivers and the answer given is usually misidentification of a bad packet.  These are usually received once or twice by the individual receivers.  Parity checks will have already been made I presume by the other box types and a further software processing appraoch as advocated would I presume further limit these misidentifications.

Examples

Probably corrupted packets rather than miscoded transponders.

4CA2D9/EI-DLM was airborne at the time you logged 4CA2DD
495145/CS-TJE was operating TAP663C while you had 495141 on your box

Another

> >
> > on the box in LHR right now is 400A2B which is G-JEDN (Dash 8), but based
> > on the flightlevel it must be a jet, probably an Embraer?
> >
> > Has anybody else seen this one before?

On Sep 21, 2012, at 14:59, "" <@...> wrote:

> Corrupted packets from TCX A320 G-KKAZ (400A0B) enroute IBZ-LBA.
>
> HTH

Alan

[neroon79]

Hi Alan, I'll try to answer your question:

Parity checks are used to identify and in some cases to correct a corrupted data transmission. They are realised by adding additional bits to the actual data containing the information to be delivered. The bits are usually calculated from the payload data by using a simple up to a quite complex algorithm. The identification of a corrupted data package may work in the following way:

-After Receiving the message the receiver generates a own set of parity check bits from the received payload part by using the same algorithm the sender did use.
-After that the receiver compares its on parity bits with the received ones. If they match-up the data is considered valid and will be futher processed. If they do not match up it depends if error correction is implemented in the parity bits or not. If yes, the receiver can try to identify the bit that was altered and correct the data by toggle the bit number to its opposite state. If not the data will be dumped.

The problem is, that sometimes the messages is altered in a way, that the parity check bits are true although the data was corrupted. This will occur especially if the payload and the parity bits are altered within the same received data-telegram. For all these cases the additional stage as it is realised now, is a good way to filter out this kind of corruptions.

So, even if the parity bits are used for check-up whether a data-telegram is valid or not, it is still possible that strongly damaged data blocks with invalid information are able to come through. In this cases additional routines are needed to reduce this misidentifications. The routines added are such a suitable way.

How good the identification of damaged blocks works, depends on the complexness and resistance of the algorithm used to generate them.

Hope that helps a bit. (Too bad once I was much more firm in this topic, but by the years passing by a lot of data has gone with the wind...)

[Runway 31]

Helped me a great deal Ingo.

Alan

[Henning]

Hi Alan,

If you need some more technical background have a look at this website:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check


Ingo, I am afraid that the RadarBox is not using a hardware parity check. On a competitor's product I haven't spotted any issues with miscodes messages.
But as you mentioned earlier, only AirNav can confirm this. We can just make assumptions.

[Runway 31]

Henning,

If that is the case how is the other box producing the errors in reply 23?.  There are plenty of other I can direct you too.  Go onto the mode-s forum and use the search option (if it works) and search on corrupt.

Alan

[Henning]

Corrupt can mean two different things:
1. The aircraft transponder can send out incorrect data - this cannot be handled by any receiver
2. During the transmission the original message gets corrupted (e.g. due to interference with other signals) - this can be identified using the parity check.

With the RadarBox I realised that sometimes information for one aircraft has been assigned to another aircraft maybe due to transmission errors. For example an aircraft that landed at an airport suddenly showed the same altitude that a high flying aircraft with a close by mode-s hex address had. And I never realised this happening with the other receiver.

But again: I assume that AirNav does not use the parity bits to check the integrity of the messages. But I cannot say if this is really the case.

Anyway, my comment was posted to give AirNav more information of how they can easily improve their product. Whether they wanna use this information or not is their choise.

At the moment I do not use my RadarBox at all as I am very disappointed because there are still no updates or bugfixes after years of waiting.
I also own a different receiver now and with that one I am quite happy at the moment. Although the UI does not look as nice as the RadarBox one. But a pretty interface does not help me if the data is not correct.

But if there will ever be an update of the RadarBox software I will definitely check it out. But that needs to be really good then after this long period of waiting for it. And not full of hacky workarounds.

Btw. are there any news about the exiting project which was announced to be released early September? It's nearly November now...

[Runway 31]

Henning,

The corrupt packages are as you describe is number 2, not sending out the wrong info in the first place.  How is the other receiver getting it wrong if they are carrying out parity check which you detail sorts out corrupted packages.

Crap out/Crap in springs to mind with corrupted data.  You cant on every occasion have 2 +2 making four, sometimes it may equal 3, 5, 10 etc giving the wrong answer

Alan