AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: MrT on October 03, 2009, 06:21:02 AM
-
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 ?
-
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....
-
Thanks John,
It's not just me then?
Cheers,
Paul.
-
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.
-
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.
-
Not so, much in the same way that the Flight ID is input by the crew - hence the occasional 'rude' ID or incorrect entry!
-
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"...........
-
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?
-
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 .
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
I think John is talking about other problems as well.
Thing is, near EHAM traffic levels are very high so there are more collisions on the air and strange things can happen, also Holland is very flat so he will hear many signals from a wide area.
He could collect all the port 30003 output to a file and see if he can find evidence of corruption.
-
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.
Sorry,
It's the route that was incorrect. The flight ID was ok.
-
Next silly question from me, if you look up the route in DataBase Explorer, is it showing the correct route for that Flight ID, or is is showing what you saw on the screen?
-
Next exemples without any comment from my side:
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/AFRDUBB.jpg)
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/AFRDUBB2.jpg)
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/21391010-03-2009.jpg)
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/21395510-03-2009.jpg)
-
It looks to me as if some garbled data has caused the registration to be incorrectly received, is this aircraft showing up as a different ModeS hex code?
Since all the other details appear to be correct I think this is the likely explanation. Maybe the demodulation algorithm in the PIC inside the RB hardware box could be improved a bit for marginal cases (probably a 1 bit corruption), but if the data received is like that then it's very difficult to process it differently.
-
Some more. No comment. It speak for it self I think:
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/AFRDUBB3.jpg)
-
It looks to me as if some garbled data has caused the registration to be incorrectly received, is this aircraft showing up as a different ModeS hex code?
That was my initial thought too.
But having said that, the flight number is coming from either a 112-bit Extended Squitter packet or a DF20/DF21 (also 112 bits). It seems very strange that a random bit error would only show up in the 24 bits of the hex code - I would have thought that there was more chance (double, in fact) of the 48-bit Flight ID field being equally corrupted, but from John's examples that doesn't seem to be happening
-
Could it be that just the mode-S is corrupted, by another signal.
This would generate the incorrect registration and aircraft details.
I have this at times, and use the Squawk as a cross-check, as most seem to be allocated to one aircraft at a time!!!
-
Good point, John if you can add the Mode S column to your list and take a screenshot when you see a duplicate that might help.
-
I have a small problem with aircraft detail displays, but only on the last aircraft in the myflights list, if the aircraft becomes the last due to a timeout of the previous last in list.
I sort by Mode-S, which may help with the explanation.
Screen shot attached
[attachment deleted by admin]
-
Good point, John if you can add the Mode S column to your list and take a screenshot when you see a duplicate that might help.
Good afternoon Support,
Immediately at your service!
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/DUBB-MODES.jpg)
-
They do seem close, the message through interference could have been corrupted.
Is it correct in saying when this occurs the second (mystery flight) never has ASD-B and then dissapears when the first flight gets timed out?
-
Hi Support,
I don't understand what you mean. I will try to do so and come back later.
Herewith an other exemple of wrong information:
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/fout01.jpg)
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/fout02.jpg)
-
Ok your having two issues here.
One your getting duplicates, your saying this a software issue. We are trying to work out if just corrupted signals, if so its not a software issue but there may be a way to hande it.
Secondly the routes issue. Can you check the aircraft which have the wrong route, whether they landed at EHAM or another airport close to you and then change there Flight ID. As I think I am right in saying RB only checks the route when a new aircraft comes into coverage.
-
Secondly the routes issue. Can you check the aircraft which have the wrong route, whether they landed at EHAM or another airport close to you
Support, thank you for your reaction! The aircraft involved (PH-KZH) was, at the moment of making the screenshot, enroute as KLM34K from EKBI to EHAM.
-
Assuming that the crew hasn't forgotten to program the correct flight number (which, in my experience, happens rarely)
If that is the case there should be come more and stronger punitive measures....(http://img.smileys.nl/49/smile.gif)
-
I think I am right in saying RB only checks the route when a new aircraft comes into coverage.
That sounds reasonable, but could you confirm and get back to us ?
It doesn't sound good when Support responds to an issue with an answer that starts "I think ..."
-
Yes dev will confirm if that's the case. I am sure you understand that we don't always know everything :) we are human.
-
we are human.
Hi Support, I thought so!
Do you have enough information from me in this case or should I go on reporting incorrect route info?
Please let me know.
-
Hi Support and All,
Until sofar no answer on my latest question to Support so I am reporting you a new one in this "story of the incorrected"....
FYI: BAW909U should be (and so it is in my local database EDDF-EGLL)
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/BAWWRONG.jpg)
-
Hi John,
Seems that a remote data source is being preferred to known local data (Routes table in DB) just like the overwritting by photgraphic sourced data of the GATS aircraft information.
-
John, that latest one looks like another corrupted ModeS hex code:
4008B4 = 10000000000100010110100
4008B0 = 10000000000100010110000
Just one corrupted bit.
-
Seems that a remote data source is being preferred to known local data (Routes table in DB) just like the overwritting by photgraphic sourced data of the GATS aircraft information.
No, I don't think it's a routes lookup problem.
The route being displayed in the pop-up for BAW909U is actually the correct route for BAW820, where the hex codes for the two aircraft operating those respective flights differ by only one bit.
Clearly, as Tarbat says, hex codes are getting corrupted somewhere along the line - the question is whether this is happening in the course of the transmission, or after the packet has been received by John's RB. I suspect the latter, given that there are few, if any, reports of similar problems from anyone else.
If I were in AirNav's shoes, I'd offer John a box swap, if only to troubleshoot the problem.
-
where the hex codes for the two aircraft operating those respective flights differ by only one bit.
Hi Dave,
I expected a remark like this all the time; I taked this shot later this afternoon and it looks here goes everything allright:
(http://i393.photobucket.com/albums/pp18/Bierboum/Screenshots/GOEDZO.jpg)
-
I expected a remark like this all the time; I taked this shot later this afternoon and it looks here goes everything allright:
No, the point I'm trying to make is that when you are picking up two aircraft with hex codes only one bit apart, your RadarBox will sometimes confuse them. I'm not suggesting that will always be the case.
-
your RadarBox will sometimes confuse them. I'm not suggesting that will always be the case.
OK Dave, clear to me. This all concern my RB only? Or is this a "normal" phenomenon with all RB users?
-
I've never noticed it myself, John, but if MyFlights ever gets to 100 aircraft, it's a very busy day!
Rod
-
but if MyFlights ever gets to 100 aircraft, it's a very busy day!
Rod, you must be a verry happy and unstressed person.....
-
It's the red wine keeps me sane ;-)
Rod
-
On your health!
-
John,
If you want your box tested you can send it back to us. If you want details please contact us directly from the methods in our signature.
Regarding the routes issues, we had a few testers go through this through the beta. We may work with you in seeing whether we can narrow it down. There is no need to post examples on the forum at the moment. Development will contact you.
-
Support and All,
Thank you verry much for all the help and advise given to me in this subject until sofar!
Support, I like specialy to thank you for you offer to send my box back to you for testing.
I consider or I use this given possibility.
Development did contact me in the meantime.
Thank you again!
-
I've noticed some aircraft are occasionally showing incorrect origin-destination information.
I can't agree with you more Mr T, that this seems to be a big problem.
I've spent hours in the last day just typing in route data where is is missing or incorrect. Think at the last count it's about 100 flights, and that's only stuff flying over the Midlands (UK).
Question for AirNAV Support
If a user inputs data into their routes database, does this get uploaded to other users via the AirNAV network, or is the local database just that, "local"?
-
It is local.
-
Right, so it's local.
My next question then is if a user has input data manually, does this at any point get overwritten by data received (potentially incorrect) from AirNAV?
-
There is date time stamp in database when you enter the route. If the time on that row is 6 months or greater in the past and we have information on that route it will overwrite it.
-
Thanks AirNAV for explaining how and when data gets updated, but obviously then if my data is correct, but your data after the 6 months is up is still incorrect, then your data overwrites mine.
Perhaps some sort of separate part of the site should be implemented for users to input data directly into your database? (obviously after the data has been verified)
-
Second day of route amending or adding!
Think I've worn www.libhomeradar.org out!
-
Thanks AirNAV for explaining how and when data gets updated, but obviously then if my data is correct, but your data after the 6 months is up is still incorrect, then your data overwrites mine.
You can prevent this by turning off route auto-populate in preferences. You'd then need to maintain your own routes database completely.