Aircraft displaying incorrect info?

[MrT]

I've noticed some aircraft are occasionally showing incorrect origin-destination information.

ie; I've had aircraft leave Melbourne obviously tracking to say Adelaide and they are showing YMML to YSSY along with aircraft showing a reverse heading to their route info.

Any idea why this happens?

Is there some way you can 'refresh' the data maybe to fix this ?

[John Racars]

Hi,

This are well known problems. I think AirNav-developers have great  trouble to find a solution for this problems or they give it a low priority. We only can wait until the problems will be solved. I have reported much exemples in this case to AirNav in the meantime....

[MrT]

Thanks John,

It's not just me then?

Cheers,

Paul.

[tarbat]

In some/many cases it will be that the aircrew haven't updated the Flight ID after the turnaround.  The route info. is derived from the Flight ID.

[MrT]

In some/many cases it will be that the aircrew haven't updated the Flight ID after the turnaround.  The route info. is derived from the Flight ID.

Thanks Tarbat,

That would explain it.

I imagined it to be an automated process over which the crew had no (or limited) input.

[Allocator]

Not so, much in the same way that the Flight ID is input by the crew - hence the occasional 'rude' ID or incorrect entry!

[John Racars]

In some/many cases it will be that the aircrew haven't updated the Flight ID after the turnaround.

All the cases I reported to AirNav had nothing to do with this "not updating flight ID's by the aircrew"...........

[tarbat]

Yes, and in some cases the transmission can pick up interference which can corrupt the ModeS hex code.  Nothing Airnav can do about that, since the checksums are only usable if you know what was transmitted from the base station requesting the squitter.

John, I'm not sure what you expect Airnav to do about this?  How can Radarbox know whether the transmission has been corrupted during transmission?

[tommyg]

Yesterday I had BAW9256 showing EGLL-EHAM when it departed EGKK and was actually going to EGLC as this was A318 G-EUNB going on a crew training exercise at London City. Further this was the second time I had picked this acft up and it was full ADSB but no type or registration showing. It had only been delivered to EGKK on the 30th Sept and this was its first flight out of Gatwick . 

[John Racars]

Tarbat,

You talked about "some cases". With me, as I told on this forum before, it swarm with it.

Could it be an option that my hardware does not working correct? If this could be the case why did Support not suggest this possibillity in the past after reading all my reports?

Tarbat, it is clear to me now. I must be almost the one and only having this problems.

I suppose I must try to live with it...

[DaveReid]

You talked about "some cases". With me, as I told on this forum before, it swarm with it.

Could it be an option that my hardware does not working correct? If this could be the case why did Support not suggest this possibillity in the past after reading all my reports?

Tarbat, it is clear to me now. I must be almost the one and only having this problems.

I suppose I must try to live with it...

It's not rocket science.

Assuming that the crew hasn't forgotten to program the correct flight number (which, in my experience, happens rarely) then the following are the pre-requisites for getting the route displayed accurately:

a)  you need to be running the 3.x beta (since 2.x doesn't decode as many Flight IDs)

b)  you need a decent routes lookup routine that's capable of ignoring non-ICAO callsigns, that understands you can't reliably look up engineering, positioning or traning flight numbers, and is able to cope with all kinds of multi-leg flights (not just the simplistic from/to/via that's in the NavData database). 

Take a look at www.flightroutelookup.com/FlightRoute for example.

[MrT]

No, not rocket science??, but even the art of knitting can appear complex to someone who is new to it.

Ok, I have the latest v3.06 Beta of RB installed.

And surely the 'decent' routes lookup routine should already be embedded in the RB software ? Or am I missing something ?

Cheers,

Paul.

[tarbat]

It's not rocket science.

But how could Radarbox detect that the ModeS hex code in a DF20/DF21 frame has become corrupted?  I'm pretty sure that this is what's happening when an incorrect Flight ID is being assigned to an aircraft in Radarbox.

[DaveReid]

But how could Radarbox detect that the ModeS hex code in a DF20/DF21 frame has become corrupted?  I'm pretty sure that this is what's happening when an incorrect Flight ID is being assigned to an aircraft in Radarbox.

If a DF20/DF21 is corrupted, then yes, the Flight ID (or indeed any of the other data items in the packet) could be incorrectly decoded and neither RB nor SBS/BaseStation would be any the wiser.

But we're not talking about incorrectly decoded Flight IDs here, we're talking about a correctly decoded Flight ID that's being translated to an incorrect route.

[tarbat]

But we're not talking about incorrectly decoded Flight IDs here, we're talking about a correctly decoded Flight ID that's being translated to an incorrect route.

But if the Flight ID is incorrectly decoded then the route will be incorrect.  The original poster made no distinction between it being the route or the Flight ID that was wrong.