AirNav Systems Forum
AirNav Radar => AirNav Radar Discussion => Topic started by: vassylad on November 05, 2010, 11:18:30 AM
-
Hi forgive me if this topic has been brought up before but I am getting some weird flight numbers that make no sence to me
RYR2LV EIDW-EGGW but actually doing the opposite
RYR56ER ENRY-EGSS (Overhead Liverpool)
DLH7MA EDDF-LROP (Just departed MAN)
Is there any remedy for this please.
Michael
-
Have a read at this. http://www.airnavsystems.com/forum/index.php?topic=5333.0
Alan
-
Boeing C32 MS Code AE0443 is shown as 00-9001 c/n 25494 & MS Code AE0446 99-6143 is also shown as c/n 25494.
Any ideas as which is correct and what the incorrect one should be?
Bryan
-
Bryan,
AE0443 is not in the d/b as the hex/serial combination has not been confirmed. AE0446 is applicable 99-6143 and the data detailed is correct.
I presume that the information re AE0443 is contained in the original data which came with your Radarbox and is incorrect. hence the reason for the thread "Database update requests".
Alan
-
Hi forgive me if this topic has been brought up before but I am getting some weird flight numbers that make no sence to me
RYR2LV EIDW-EGGW but actually doing the opposite
RYR56ER ENRY-EGSS (Overhead Liverpool)
DLH7MA EDDF-LROP (Just departed MAN)
Is there any remedy for this please.
Michael
No remedy until Airnav decides to update the databases but as we've been waiting since at least last June and have absolutely no indication of anything coming within the near future, I wouldn't hold your breath.
I used to enjoy monitoring flights in and out of my local airports but frankly now that routes information for all lo-cost and some national airlines in the UK has deteriorated so far, it's hardly worth switching the box on.
Think we'll be changing horses this Christmas.
-
Think we'll be changing horses this Christmas.
Hold your horses!! FD7 for Radarbox might be finished beta testing by Christmas. That should resolve the route problems without having to rely on Airnav to fix the routes database.
-
If past performance is anything to go by, you can add at least another six months to that prediction...
DC
-
If past performance is anything to go by, you can add at least another six months to that prediction...
I'm surprised by that statement. The developer of FD7 seems very responsive.
-
OK Tarbat - I'll always listen to anything you have to say.
So what's FD7 when it's at home?
-
FD7 is an addon for the "other" box. Among other things it can do automatic route lookups at the following sites:
- Dave Reid's FRL Service
- Libhomeradar
- FlightAware
- FlyteCom
- FlightStats
I meantioned it in response to your comment about "changing horses this Christmas". Any other ModeS receiver has to rely on addons like FD7 to lookup routes.
More discussion at http://www.airnavsystems.com/forum/index.php?topic=5472.msg55138#msg55138
Available from http://sites.google.com/site/0flightdisplay/homepage
It currently only partially works with Radarbox, but the author is working on this.
-
Understood - to a degree......however you said "FD7 for Radarbox" which begs a couple of questions:
What form does this take - software or hardware? - and is this in conjunction with, or regardless of, Airnav?
I take your point about other recievers. The actual reception by RB and my current aerial set-up would take some beating by any other receiver but when you've got your couple of hundred onscreen flights you need be sure what they are.
If the DBs are not scrupulously maintained but deteriorate to the point of being absolute horlix, the operation becomes pointless. Hence change of horses.
-
What form does this take - software or hardware? - and is this in conjunction with, or regardless of, Airnav?
It's software, and Airnav have no involvement in its development. Current beta looks identical to the SBS-1 version of FD7, but obviously needs tweaking to cope with RB port 30003 differences, and the navdata database for routes. I don't want to say any more without the permission of the developer.
If the DBs are not scrupulously maintained but deteriorate to the point of being absolute horlix, the operation becomes pointless. Hence change of horses.
But a change of horses (to another hardware/software combination) will not solve the routes problem. AFAIK, it's only Radarbox that does route lookup, any other box needs addon software to get routes.
-
OK,so we add a bit more software (and maybe pay a fee/sub?), no problem.
But - and this is the million dollar question - will the information on the screen get updated/changed?
For example, suppose I have on screen RYR123AB showing Newcastle to Murcia. when it is in fact Manchester to Murcia. How do I know this is an error without tracking it on network or looking it up just out of interest?
If however I subsequently find out the route is wrong, will I be able to correct my database so that the error is not perpetuated?
At the moment the skies are full of wrong routes and obviously corrections to these will only be useful if they can be put in my database and thence on to my screen.
I already have access to some correct routes but it's getting them onscreen that's the problem.
I hope this make sense and thanks for taking the time to help. :)
-
I've been using Fd7.5 for a couple of months, took a bit of playing with to get it going with Rbox but it's a great little tool. Sometimes the routes are incorrect but this not the fault of FD but the look up source.
-
Hi Bearcat - when you use FD7 what route appears in MyFlights and on your screen display - the original Airnav one or the FD7 corrected version?
-
FD 7.5 displays the route on it's own screen. I then manually input it into the Routes database for it to be displayed next time the flight is picked up. I might be wrong but I don't think this version will write direct to the database.
-
Thanks for that bearcat. From what you say it sounds as if, FD7 notwithstanding, Radarbox users will continue to be split between those who can manually input data and those who can't. Put another way, those who have reasonably accurate onscreen information and those (the majority) who have a screenful of mystery flights and dubious aircraft data.
I can't see how much longer this situation can continue. Users like Michael (who started the thread) and new buyers in particular will start screaming that the product is just not doing what it says on the tin.
-
From what you say it sounds as if, FD7 notwithstanding, Radarbox users will continue to be split between those who can manually input data and those who can't.
But that's using the SBS1/Planeplotter version of FD7. I'm beta testing a version specifically designed to work with Radarbox. The intention is that it will auto-populate the routes table for all flights received locally, so that the correct routes are displayed in Radarbox.
-
Tarbat - that sounds like great news, almost too good to be true in the context of this problem.
I won't push you for a timescale (too many "cheques in the post" already) but if you advise hanging on to my box for a wee while longer, I'll take your advice.
Great stuff.
John
-
Tarbat - that sounds like great news, almost too good to be true in the context of this problem.
I won't push you for a timescale (too many "cheques in the post" already) but if you advise hanging on to my box for a wee while longer, I'll take your advice.
Yes, the timescales aren't down to me anyway, they're down to the author of FD7, but I believe he's making good progress.
-
Hi guys may I say a big thank you for all your replies, they are both interesting and a little sceptical, there are lots of if's and but's but no real explanations to my question.
I really hope that FD 7.5 appears on the market sooner rather than later, I for one am becoming very disillusioned with how AirNav seems to spend thousand of pounds on developent with RB 3D but something as simple as a correct routing added to their database seems light years away.
Michael
-
Not defending them but I think that Airnav have also spent a few bob on this aspect as well and it doesnt seem to have been money well spent, at this stage.
Alan
-
I think that's very unfair vassylad and others, have you forgotten our link up with Flight Stats (which is also google's flight tracking provider choice). A large amount of investment has gone into that as well as the algorithm to try and deduce routes from the network.
The reality is here there isn't one magical source where we can get the entire worlds route data. We can do our best by joining other companies but even they cannot provide us the worlds data and you would still run into issues with alphanumeric routes.
We cannot go down the route like FD7 does as what FD7 by polling other websites is on dodgy ground and we would get in trouble.
We would intrested to know what you think should be our next move? As this is not a simple fix issue.
-
Alan
Thanks for the reply re AE0443/AE0446.
I am now even more confused. I deleted AE0443 (00-9001) from my database but now it is shown over New Hampshire at 9,000 ft.
Bryan
-
Bryan,
As I said it is in the original database provided with the system and may well be the registration in question. While the hex AE0443 equates to 00-9011, no other details re the frame have been confirmed from any source as can been seen from the wrong c/n details given which belong to another aircraft, AE0446.
Alan
-
It is well known that the problem with less than 1% of flight routings shown is due to the client/server synchronization (old routes remain on the client application for too much time).
Unlike any other system on the market AirNav Systems has a contract with flightstats.com to provide accurate real-time flight routing information to feed the RadarBox software.
This problem as well a few other minor problems are already listed on our to-do list and will be addressed as soon as AirNav ShipTrax is released, which will happen in no more than 2/3 months.