AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: Chris11 on September 11, 2010, 03:54:18 PM
-
When is a BAE 146 a B462, B463 or RJ85?
-
Chris
B461 British Aerospace 146-100
B462 British Aerospace 146-200
B463 British Aerospace 146-300
RJ85 British Aerospace 146 RJ85
R1TH British Aerospace 146 RJ100
Alan
-
Chris,
the 462 is a 146 series 200 and 463 is a 146 srs 300, an extended version with approx 100 seats. Bae System remodeled the 146 with new avionics and a new engine, orginally an ALF 502 to an ALF 507 and remarketed the aircraft as a Bae Regional Jet (RJ) with the number giving an approximation of the available seats. So a RJ85 is the later version of the Bae.146-200 (Bae 462), the RJ75 is the later version of the 146 srs 100, and RJ100 is the later version of the 146 srs 300 (B463).
If you see any close up count the windows between the front passenger door and the beginning of the wing and you will learn to note the differences.
Hope this helps
-
Chris
B461 British Aerospace 146-100
B462 British Aerospace 146-200
B463 British Aerospace 146-300
RJ85 British Aerospace 146 RJ85
R1TH British Aerospace 146 RJ100
Alan
Slight error it is RJ1H for the RJ100
There is also the RJ70
There is a good production list which details them here
http://www.planelist.net/bae-146.zip
Construction numbers are four numbers starting with an E. The second number is the mark no.
E1 = 146-100 or RJ70
E2 = 146-200 or RJ85
E3 = 146-300 or RJ100
The last three numbers are the sequential construction number. They changed from being 146s to Avro RJ from airframe number 222 (full C/N E3222, a B463). Airframe number 223 is a RJ70 (full C/N E1223)
Therefore c/n E1199 is a B461, but E1225 is a RJ70.
E2046 is a B462, but E2314 is RJ85
E3126 is B463 , but E3387 is RJ1H
Hope this helps
ACW367
-
Not forgetting a further warmover of the design towards the end of the programme, which produced the RJX85 (one example only) and the RJX100 (5 airframes, not all completed).
-
On the C/N front there are two anomolies before and after airframe 222 changeover. Airframe 221 SE-DSO (E3221) is a RJ1H and airframe 227 YR-BEA (E2227) is a B462.
-
Thanks for a very comprehensive answer
-
Large number of errors in the database - I might just delete them all and see what they repopulate as
-
Large number of errors in the database - I might just delete them all and see what they repopulate as
Yes the original 2 year old Navdata is about 50% out on having the correct tie-ups. I agree it is best to delete them from the Navdata a let them repopulate from our work.
-
Yes the original 2 year old Navdata is about 50% out on having the correct tie-ups. I agree it is best to delete them from the Navdata a let them repopulate from our work.
The problem some of us have is that we've made lots of updates to navdata to include our own data. For example, I've added Tornado GR4s seen on the bombing range. And I've used GAS Populate to correct thousands of other aircraft. If I delete everything to pick up the work you've done, then I lose the work I've done.
That brings me to a question. Can you provide a list of the ModeS hex codes that have been updated by the database team? We can then use that list to only delete the aircraft that will be repopulated from your work.
And another question. In your opinion, is the GAS database more (or less) up-to-date than the work of the database team?
-
Tarbat
I am just suggesting this for the 146 where there are alot of errors in the original Navdata in releation to whether they are B46* or RJ**.
Until Airnav fix the issue with the ICAO codes it is not recommended from us updaters to do bulk deletions of other data that you have manually changed from the original old NAVDATA.
-
If AirNav continue to drag their feet over releasing an updated NavData.db3, then I seriously think we should prevail upon the updaters team to release their own version.
After all, it contains the results of all their hard work, and if AirNav aren't prepared to put their stamp of approval on it that's no reason why RadarBox users shouldn't get the benefit of it.
As things stand at the moment, for anyone using RadarBox without an Internet connection and relying on the NavData, all the updaters' work has been a complete waste of time.
-
Agreed Dave. I wonder what, if anything, is stopping someone in the updaters team releasing an extract of their work?
-
Agreed Dave. I wonder what, if anything, is stopping someone in the updaters team releasing an extract of their work?
What, and blow the best part of several months efforts?
We, as a team , have a pretty good, totally independant working routine to try and achieve what we set out to do.
To be fair, AirNav have left us alone to decide how and what we do. We disagree with each other, and regularly with AirNav, despite what a fair few people seem to think?
However, one thing we all have in common is a desire to try and make this work to the best of our ability.
I'm not going to debate if using a team of volunteers is the correct option, as it basically isn't - however it's where we are at the moment.
Unfortunately, we have lives outside of this task, so as I'm sure you'll all respect, we can only afford to give up the time we feel appropriate.
We're very lucky in that we have one member who almost operates 24-7 manning the "update request" thread.
The rest of us generally work away in the background, checking and improving etc, trawling production lists, other forums for info etc etc.
We're also aware of a "target" database that would be worth releasing, and at the moment, we're not there - or near for that matter - so maybe we need to gauge peoples opinions as to what is acceptable, before any new Navdata file is released?
We are also equally frustrated with some areas of our work not "getting through", and are currently banging on about this with AirNav. This is obviously the main point of contention with this thread. We've been in discussion with AirNav today, before this thread went this way, regarding this very issue, so believe me, our frustrations are just as, if not more fraught than others.
However, that said, we're not just going to suddenly throw our toys out of the pram and do what people seem to want us to do.
There's absolutely nothing stopping us "releasing an extract "of our work .We have the tools to do it, but why would we just throw it all up in the air in such a way.
Believe me (and I'm sure many won't!) , but we as a team are as near as damn it to a "user voice" to shout at AirNav on these things, and shout we certainly do!
Sometimes we feel frustrated, particularly as we have to come on here almost daily, answering on AirNav's behalf, primarily as we as a team know full well the issues of the way all this hangs (or not) together, only for no fixes or answers!
However - saying all this, we are not going to jeopardise what we are doing for the benefit of all users, just because a few people are voicing their frustrations! Everyone at the time had an equal opportunity to get involved - to be brutally honest, the silence was deafening!!
We will bat on regardless, and will bang on at AirNav regardless as well, for answers and solutions..........and I can see the responses now "but you're wasting your time" "you shouldn't be having to do this for AirNav" etc, etc, all stuff that's been heard a million times before.
I'll no doubt get slaughtered for this on here and elsewhere, but only thought it right that everyone knows where we're at.
If anyone wants to throw any questions our way, we'll do our best to honestly answer them, but please please respect what we're doing,and not compromise the position we are in. There's absolutely nothing to gain at all for anyone in that?
Thanks for reading
Regards
Rich
-
At this time we are in direct contact with our Database Updaters team regarding the points above.
They are doing an excellent job: thanks to them RadarBox is still the only Virtual Radar with included database updates (both aircraft and callsign) integrated into the provided software for free. As everyone knows, with RadarBox you don't have to rely on paid/external addons to something that is already included on the main application.
After we discuss some of the suggestions above with our Updaters team we will be back with more information. They know better than anyone what is good for the users.
-
Just to confirm - yes we are, and yes we will!!!
Don't particularly like the middle para though ! (other than the bit about doing an "excellent job" :-))
Rich
-
They are doing an excellent job: thanks to them RadarBox is still the only Virtual Radar with included database updates (both aircraft and callsign) integrated into the provided software for free.
The one flaw in this statement is that the databases are way out of date, and Airnav are sitting on thousands of updates to these databases, and appear to be unwilling to say what plans they have for releasing that data.
It would only take a few hours to create a solution to force update to our local databases, and fix the "..." problem. But we see no progress. The ratio of database team effort to Airnav effort appears to be 100:1 (or more!!).
My nagging doubt is that Airnav will not release a new navdata database, because they fear that doing so will lose them a competitve edge over the competition.
Airnav, what is the plan of action here, and timescales?
-
Tarbat, just so I understand why do you say this:
My nagging doubt is that Airnav will not release a new navdata database, because they fear that doing so will lose them a competitve edge over the competition.
Cheers
Dave
-
Again we are discussing with the database updaters the best way of approaching this.
-
Dave, I fear that Airnav may think that by releasing a fully up-to-date navdata database, that could then be used by owners of competing products to populate a basestation.sqb for use with those products. If, instead, they only provide the updates via. the Radarbox software, then they retain a perceived competitive advantage.
Of course, I may be totally wrong on this. But I just can't understand why Airnav won't tell us what their plans/timescales are to make the data available. I would have thought that when they recruited the database updating team, they had a plan in place to distribute their hard work.
-
Okay I see where your coming from, but could that not have also been true when the product was first released?
For me as part of my updating, I used a empty Navdata file to see what updates etc were coming down, doing this has removed all the old data and most of the stuff I get now is what we have already updated. Understand for most people this is not an options as they would lose any stuff their interested in, all I did was backup my original navdata in case I wanted to access it. (including deleting after saving the images)
Dave
-
>Dave, I fear that Airnav may think that by releasing a fully up-to-date navdata database, that could then be used by owners of competing products to populate a basestation.sqb for use with those products.
Chris, you are totally wrong on this. We can't tell you any plans/timescales as we are still discussing this with the Updaters team. The hard work done by the database updaters team is being stored on the database servers and properly propagated to the client applications (except on some cases as discussed above).
-
The hard work done by the database updaters team is being stored on the database servers and properly propagated to the client applications (except on some cases as discussed above).
No, it's NOT being propagated to the client applications if that client application (eg Radarbox) already has out-of-date or incorrect data stored in it's database.
But, if you're saying you can't tell us the plans/timescales until you've agreed this with the Updaters team, then fine - I trust the updaters team to look after the best interests of Radarbox users. But the impression I was getting is that there is no plan/timescale.
In the meantime, I've:
1. Deleted my aircrafts table.
2. Re-populated the 12,000 aircraft in MyLog from GAS.
3. Added a CH date/timestamp field to my aircraft table.
4. Have a process in place to regularly re-populate potentially out-of-date or incorrect data.
So, my database is fixed.
-
Hi all, I just wish I was computer savvy enough to use the db upgrade that you've put together - I haven't a clue - any info would be gratefully received. Is it as simple as opening up the ANRB folder, delete a "db" file and paste in the update? Sorry to ask something as basic as this, I am struggling! I suppose I can always delete and try it - I'm not worried about losing history files, but have already once b*ggered it up, had the hassle of re-formatting HDDs, then re-installing (got rid of a load of cr*p in doing so though - a few anxious hours re-loading and a lot of Acer stuff still missing) Win 7 O/S and loads of other stuff - computer does run a heck of a lot faster though.
-
We're also aware of a "target" database that would be worth releasing, and at the moment, we're not there - or near for that matter - so maybe we need to gauge peoples opinions as to what is acceptable, before any new Navdata file is released?
It might help to look at it this way:
A customer who goes out tomorrow and buys a brand new RadarBox, and plans to operate it without an Internet connection (which is a perfectly legitimate mode of use, Internet isn't listed as a requirement) will basically be getting a database that's more than 2 years out-of-date, and the updaters team might just as well not exist as far as he/she is concerned.
And the argument that "OK, our current database is cr*p, but at least we've got one whereas the competition hasn't" doesn't really hold water, does it ?
After we discuss some of the suggestions above with our Updaters team we will be back with more information.
One might have hoped that, at the same time the updaters team started work all those months ago, AirNav would have also started work on an architecture that would support the new database.
Instead, it would seem, months later, we haven't got past the "discussing suggestions" stage.
-
To me it seems very clear that there can be no improvement until a date stamp field is added to aircraft table in the database. The software will have to be changed to check the network database to see if the datestamp on the network is later or not. There should be an ability for users to add a code into that field if they never want the data overwritten.
I think any user with a small amount of technical sense will realise if they are not connected to the internet their information will be dated the day they buy it. I am more concerned with the dated information for people who do connect to the internet
-
They are doing an excellent job: thanks to them RadarBox is still the only Virtual Radar with included database updates (both aircraft and callsign) integrated into the provided software for free. As everyone knows, with RadarBox you don't have to rely on paid/external addons to something that is already included on the main application.
Well, it seems to me that here is the nub of the matter in black and white.
Having a system where "database updates (are) included integrated into the provided software for free" may well be the virtual radar Holy Grail however if that system fails then the user is in big trouble.
If things stop working, the customer finds himself locked into a system that, far from "have(ing) to rely on paid/external addons", actually prevents him from accessing the external data he now needs.
There's nothing new here as any PC user will testify. A system is valid for as long as it can be updated and maintained. After that, it's junk.
-
I think any user with a small amount of technical sense will realise if they are not connected to the internet their information will be dated the day they buy it.
Er, yes.
What might not be so obvious to a user, no matter how technically savvy they are, is that a product calling itself RadarBox 2010 still ships with a database that belonged in RadarBox 2008.
-
To me it seems very clear that there can be no improvement until a date stamp field is added to aircraft table in the database. The software will have to be changed to check the network database to see if the datestamp on the network is later or not. There should be an ability for users to add a code into that field if they never want the data overwritten.
Hi Chris
On the current server database, every record has a date stamp attached, and is automatically changed when one of the team amends/adds a record.
I don't know if this is to be included within any future NavData files though.
AirNav?
HTH
Rich
-
We're also aware of a "target" database that would be worth releasing, and at the moment, we're not there - or near for that matter - so maybe we need to gauge peoples opinions as to what is acceptable, before any new Navdata file is released?
It might help to look at it this way:
A customer who goes out tomorrow and buys a brand new RadarBox, and plans to operate it without an Internet connection (which is a perfectly legitimate mode of use, Internet isn't listed as a requirement) will basically be getting a database that's more than 2 years out-of-date, and the updaters team might just as well not exist as far as he/she is concerned.
And the argument that "OK, our current database is cr*p, but at least we've got one whereas the competition hasn't" doesn't really hold water, does it ?
I was actually commenting on the possibility of a methodology of continual weekly/monthly updates , following on from a release of a suitably sized initial "up to date" NavData file, rather than wait until we've covered all bases.
After we discuss some of the suggestions above with our Updaters team we will be back with more information.
One might have hoped that, at the same time the updaters team started work all those months ago, AirNav would have also started work on an architecture that would support the new database.
Instead, it would seem, months later, we haven't got past the "discussing suggestions" stage.
Of course we have, but this stage is a continual process as most people will realise - things don't just get set in stone on day one - they may do if only one person is involved, but as I've tried to explain, we're finding new ideas/suggestions as time evolves.
We've suggested - now it's over to AirNav to decide which suits their software approach the best?
We're limited to what we can achieve on this front as I'm sure you'll appreciate?
-
Hi Chris
On the current server database, every record has a date stamp attached, and is automatically changed when one of the team amends/adds a record.
Rich
I assume this is in the same format as the route datestamp ie yyyymmddhhmss and is an additional filed in the aircraft table.
I think I will add the same to my database to cover where I add/correct data
-
romdouk
So's mine, as my database is updated at least once a week by the ADU SBS/Radarbox Utility. (PLEASE NOTE: I have no connection or pecuniary interest in ADU).
All my aircraft types are correct in most cases (No BKC3/BKC5 or the dreaded ...).
The Operators have standard format (United States Air Force / USA - Air Force etc).
The only unpopulated items I've had in the last 3 weeks are Mis-codes and ground applications.
Regards
Terry
So what procussions to do take to make sure that Airnav does not overwite your data
-
We're limited to what we can achieve on this front as I'm sure you'll appreciate?
It certainly wasn't my intention to belittle the efforts of the updating team, by all accounts you're doing sterling work.
It's just so frustrating that AirNav seem happy to leave all of us (including you guys) with the impression (rightly or wrongly) that they still haven't got a clue how they are going to integrate your work with the day-to-day operation of RadarBox.
-
So what procussions to do take to make sure that Airnav does not overwite your data
What I do is run a couple of queries each week to look for problems:
1. WHERE
(aircraft."AT" = "...") OR
(aircraft."AT" IS NULL) OR
(aircraft."AT" = "")
2. WHERE
(aircraft.AC LIKE "untitl%") OR
(aircraft.AN LIKE "untitl%")
I maintain a separate field called GA1, which I use to indicate aircraft where I have auto-populated data from GAS.
I have another field called CH, where I put the date that I populated the data from GAS.
Over the last few months this seems to be working well.
-
Sent you a PM Terry
cheers
Andy
-
We're limited to what we can achieve on this front as I'm sure you'll appreciate?
It certainly wasn't my intention to belittle the efforts of the updating team, by all accounts you're doing sterling work.
It's just so frustrating that AirNav seem happy to leave all of us (including you guys) with the impression (rightly or wrongly) that they still haven't got a clue how they are going to integrate your work with the day-to-day operation of RadarBox.
No worries Dave
If nothing more, then hopefully this thread will at least have stirred enough up to produce some answers?
Rgds
Rich
-
One more time we underline that we are discussing all the possible solutions with the database updaters team.