Log data analysis results

[DaveReid]

I've now completed my analysis of the logs and socket capture files that users have kindly sent to me - 6 files in total containing nearly three-quarters of a million records, which I would consider to be a representative sample.

All 6 files contain multiple instances of the previously identified problem - data (callsigns, altitudes, squawks, etc) being assigned to the wrong aircraft.

I don't propose to do any further analysis as the aim was simply to establish whether or not my experience of anomalies with my own box was unique, and I'm now satisfied that it isn't.  The likelihood of all 7 of us coincidentally having rogue boxes is infinitesimal, so it seems highly likely that the issue affects all RadarBoxes.

That's unfortunate - I'd been hoping to offer RadarBox as an option to one of my clients for a tracking project (clients always love options!) but clearly now that won't be possible.

I'd stress that my conclusions only apply to professional use of RB where data integrity is important.  For everyday amateur enthusiast use the typical symptoms (sudden jumps in altitude, two aircraft showing the same Flight ID, duplicated squawks, etc) may be considered acceptable - obviously that's up to individual users' judgement.

Thanks again to everyone who participated.

Dave

[tarbat]

Dave, were you able to come to any general conclusions?  For example:

1. Were the aircraft affected both ADS/B and non-ADS/B equipped aircraft?

2. Did the aircraft affected generally have very similar ModeS hex codes, so could this still be caused by corrupted data being received?

3. I asked over on the other forum (before being banned again), but do you know which message types can be parity checked, and which can't?  In other words, could any data corruption be filtered out by Radarbox using the parity bits?  Also see http://www.airnavsystems.com/forum/index.php?topic=1641.msg28678#msg28678

4. Roughly what percentage of data received exhibits these problems?

5. Is this the same problem identified in one of the competing product, where the option bits are set?  See http://www.kinetic-avionics.co.uk/forums/viewtopic.php?f=5&t=5691&p=42860&hilit=parity#p42860

[DaveReid]

I don't have time to do any more detailed analysis but my findings match those of other users previously, in that the hex codes for the pairs of aircraft that are being confused normally only differ by a few bits.

Whether that's caused by data corruption or not is something only AirNav can answer, and so far they have been conspicuously absent from this discussion.  It seems odd that, if a 24-bit address is being incorrectly decoded, it always happens to match that of another aircraft that's being picked up at the same time - I would have thought that data corruption would produce random address errors.

Re parity-checking, all DFs incorporate check bits using one of two different schemas, depending on which DF is being considered.

As I said in my first post, I've done all the work I need to now, having ascertained the answer to the question re RadarBox's suitability for professional applications.

[tarbat]

Okay Dave, I'm sure we all appreciate your efforts.

I still think Edgy31's theory is the most plausible explanation I've heard so far - at least the parts that I understand.  That affects the SBS-1 receiver as well, and is described over on the SBS-1 support forum at http://www.kinetic-avionics.co.uk/forums/viewtopic.php?f=5&t=5691&p=42860&hilit=parity#p42860

My own theory is that this is a generic problem affecting any ModeS receiver that is not able to receive the transmissions from the ground station requesting the aircraft data in the first place, and so not able to check parity on all message types.

It seems odd that, if a 24-bit address is being incorrectly decoded, it always happens to match that of another aircraft that's being picked up at the same time - I would have thought that data corruption would produce random address errors.

Maybe the Radarbox software always attempts to match these types of ModeS message with an aircraft already in the MyFlights list, and so you're only seeing examples where the corrupted 24-bit address does match one in the list.  There may be many other corrupted 24-bit addresses that simply get thrown away because there is no match to an aircraft already in the list.

[Runway 31]

Does these defect mean that no SBS receiver is entirely suitable for professional applications or has the SBS-1 been updated to correct this defect?.

Also would someone like me who is no where near an airport have thios problem if I cannot see aircraft on the ground?

[Deadcalm]

What's probably more important - does Airnav recognise this as a problem, now, and are they prepared to investigate and fix it, if it is?

Thanks, Dave, for your efforts.

DC

[AirNav Support]

We have paid attention to the post and unlike what Dave has said we have read his post and looked through details we had and past support queries etc.. We decided however to wait and see whether anything more was found.

Our Professional customers (which we have quite a few Airlines, ATC and Agencies) do use the RadarBox but do not use the .rbl files or the 30003 port data. They use a different interface altogether and we haven't had issues with them regarding this.

However we will investigate this further, this was investigated in the past however the actual investigation of what is wrong isn't easy at all. This case could be GIGO (Garbage in Garbage out)

[DaveReid]

I still think Edgy31's theory is the most plausible explanation I've heard so far - at least the parts that I understand.  That affects the SBS-1 receiver as well, and is described over on the SBS-1 support forum at http://www.kinetic-avionics.co.uk/forums/viewtopic.php?f=5&t=5691&p=42860&hilit=parity#p42860

Well my understanding (and probably Edgy's too) of the issues is probably a bit better now that it was two years ago when that dialogue took place :-)

My own theory is that this is a generic problem affecting any ModeS receiver that is not able to receive the transmissions from the ground station requesting the aircraft data in the first place, and so not able to check parity on all message types.

That would make sense were it not for the fact that I only started to notice this phenomenon when I changed the source for my EGLL arrivals website from SBS-1 to RadarBox. 

If the problem was generic, I would presumably have been seeing examples of aircraft landing at Heathrow at FL380 for the past 4 years. 

Although I said I wouldn't do any more analysis, I've just done a quick and dirty count - out of 673,000 or so LHR arrivals in my database, the only ones that have shown silly altitudes on finals are those from last week during the period when RadarBox was supplying the data.

So clearly there is a way of avoiding assigning data to the wrong hex code, but I suspect that's something each vendor has to work out for themselves.

[tarbat]

I do wonder whether this only happens in areas of high traffic volumes with the possibility of more data collisions.  I've run testmodes.exe (a Radarbox native capture utility) for a couple of hours now, and ported all the data into Excel.  I see no altitude anomolies, etc.  I am in an area of VERY low volume at the moment though :(

[DaveReid]

Our Professional customers (which we have quite a few Airlines, ATC and Agencies) do use the RadarBox but do not use the .rbl files or the 30003 port data. They use a different interface altogether and we haven't had issues with them regarding this.

That's good news.

If you are saying that there is an alternative way of getting data out of RadarBox that's reliable then I would welcome details and, if satisfied, will happily put RadarBox back onto the shortlist for use in developing professional solutions.

[tarbat]

Okay, I've now found examples of this problem in the native capture:

$PTA,400620,NPT521P,,,,,,,,,,17
$PTA,400620,,,,,,,,,,,11
$PTA,400620,,16000,,,,,,,A,,4
$PTA,400620,,-1200,,,,,12.0127,0,A,,17
$PTA,400620,,,,,,,,,A,6005,21
$PTA,400620,,-1200,,,,,12.0127,0,A,,17
$PTA,400620,,16000,,,,,,,A,,20
$PTA,400620,,16000,,,,,,,A,,20
$PTA,400620,,,,,,,,,A,6005,21
$PTA,400620,,-1200,,,,,12.0127,0,A,,17
$PTA,400620,,,,,,,,,,,11
$PTA,400620,,-1200,,,,,12,0,A,,17
$PTA,400620,,16000,,,,,,,A,,0
$PTA,400620,,-1200,,,,,12,0,A,,17
$PTA,400620,,,,,,,,,,,11
$PTA,400620,,-1200,,,,,12,0,A,,17
$PTA,400620,,16000,,,,,,,A,,20
$PTA,400620,,16000,,,,,,,A,,20
$PTA,400620,,16000,,,,,,,A,,20
$PTA,400620,,-1200,,,,,12,0,A,,17
$PTA,400620,,,,,,,,,,,11
$PTA,400620,,16000,,,,,,,A,,0
$PTA,400620,,-1200,,,,,12,0,A,,17
$PTA,400620,,16000,,,,,,,A,,4
$PTA,400620,,16000,,,,,,,A,,4
$PTA,400620,,-1200,,,,,12,0,A,,17

In this example, it appears to be getting a negative altitude (-1200) from DF17 messages.  The altitude from DF4 and DF20 looks okay.

Hopefully this will help Airnav diagnose the problem and develop a fix.

[DaveReid]

Hmmm, I'm not sure that's the same problem, bearing in mind what we know about the ADS-B fit on ATPs - unless you're suggesting that there's a submarine close to you with a similar hex code :-)

Edit:  Out of interest, what do those other parameter values (12 and 12.0127) in the DF17 represent ?

And is 6005 a valid squawk in your part of the world ?  My squawk list may be out-of-date, but it says "6001-6006 Not allocated".

[Runway 31]

Tarbat, Silly question from someone who hasnt a clue, is this the fault of radarbox or duff info coming from the aircraft?.

[tarbat]

Hmmm, I'm not sure that's the same problem, bearing in mind what we know about the ADS-B fit on ATPs - unless you're suggesting that there's a submarine close to you with a similar hex code :-)

You may be right.  Unfortunately it was the only anomoly I could find :(   In your testing, do you know if it was particular DF messages that were causing the anomolies?

[DaveReid]

In your testing, do you know if it was particular DF messages that were causing the anomolies?

I don't know, I've only got access to the socket and RBL logs, not the raw data.