Confused On Navdata Updates

[Flaps30 3]

I have had FS9 since its release and although tempted, never updated my navdata files since there never seemed to be any conflicts with charts, etc. I just purchased the Wilco CRJ and tried entering the airport identifiers into the FMC. It took my departure airport KAVP with no problem, but the destination KUNV brought back a data error message that it was unable to find it. This airport (University Park - Penn State in Pennsylvania) is in the FS9 database and has never posed a problem before. I then decided to import the FS9 created flight plan directly through the FMC and it did, now recognizing the KUNV entry. However, on approach when I tried to select the ILS runway on the DEP/ARR page, no runways were available. I assumed the CRJ Wilco database is the latest one or at least much newer than my original FS one. How many different NAVDATA databases does FS need. A different one for each aircraft? And why this problem with the CRJ? I have had no problems with Level D or PMDG. Thanks. Regards, Tom

[Egbert Drenth 250]

I have had FS9 since its release and although tempted, never updated my navdata files since there never seemed to be any conflicts with charts, etc. I just purchased the Wilco CRJ and tried entering the airport identifiers into the FMC. It took my departure airport KAVP with no problem, but the destination KUNV brought back a data error message that it was unable to find it. This airport (University Park - Penn State in Pennsylvania) is in the FS9 database and has never posed a problem before. I then decided to import the FS9 created flight plan directly through the FMC and it did, now recognizing the KUNV entry. However, on approach when I tried to select the ILS runway on the DEP/ARR page, no runways were available. I assumed the CRJ Wilco database is the latest one or at least much newer than my original FS one. How many different NAVDATA databases does FS need. A different one for each aircraft? And why this problem with the CRJ? I have had no problems with Level D or PMDG. Thanks. Regards, Tom

Hi,The Nav databases of your (payware) aircrafts operate totally independent from the default internal FS9 nav database.Unfortunately they all have a proprietary format and need to be updated separately. If you have a wide range of payware aircraft,you end up with updating about 10-15 nav databases each month.I checked KUNV and it still should be available, however some of those Nav databases are being filtered (on runway length or something) so a specific airports may be includedin the Nav database for aircraft A but not in the database for aircraft B.

[ronzie 21]

Wilco CRJ FMC limited data is available at Navigraph.com. The list states No TP meaning no terminal procedures (SIDS and STARS). See here for an explanation:http://www.navigraph.com/www/fmsdata.aspFor my PMDG 737NG the Navigraph furnished data has no SID or STARs for KUNV but does have the ILS procedure in the FMC database for RWY 24. This does not guarantee it would be in the CRJ database but I'd guess it would be.In any subscription period you can download as many FMC formats as you wish with just that one subscription fee. KUNV has a 6,200 x 150 foot runway with an ILS at one end according to AFCAD. That should be just long enough for a CRJ to squeeze in there with proper loading I would think.I suggest one minimum credit which allows a few downloads within the 270 day subscription period. That should include data that might have been left out of the Wilco supplied database.

[David Vega 348]

Hi,The Nav databases of your (payware) aircrafts operate totally independent from the default internal FS9 nav database.Unfortunately they all have a proprietary format and need to be updated separately. If you have a wide range of payware aircraft,you end up with updating about 10-15 nav databases each month.I checked KUNV and it still should be available, however some of those Nav databases are being filtered (on runway length or something) so a specific airports may be includedin the Nav database for aircraft A but not in the database for aircraft B.

Not to steal the thread, but this brings up an interesting topic. Wouldn't it be great if we had a standard for simulator Nav data, one that could be used for all developers? I'm certain this would simplify producing the Nav data. It would also motivate more developers to offer functional FMC implementations. I'm sure there would be other benefits. Does anyone know if this has been attempted? Regards.

[Egbert Drenth 250]

Not to steal the thread, but this brings up an interesting topic. Wouldn't it be great if we had a standard for simulator Nav data, one that could be used for all developers? I'm certain this would simplify producing the Nav data. It would also motivate more developers to offer functional FMC implementations. I'm sure there would be other benefits. Does anyone know if this has been attempted? Regards.

I've tried it 2 times in the past:http://forums1.avsim.net/index.php?showtop...p=0entry0The developers really don't care and keep running in their own circles. If they put their heads together in no time they would have consensus about the format, and this would be a lot easier for us (and the developers too).For example we are waiting now for 8 months! for Navdata for the DA Fokker 70/100 and for the ESDG CitationX there's also no Navdata yet.Moral: They all use a proprietary format.

[ErnieAlston 33]

I think the points made in that thread Egbert linked are generally spot on.I think the somewhat independent nature of add-on developers, probably makes a consensus not very likely. Its just the nature of the beast, most add-on developersare somewhat independent operators, the majority coming from the freeware developer ranks.Once you have a consesus/committee defining the standard, as a developer you in effect are limited by that committee's decisions.For that reason alone, I'd likely not be interested in being part of such a consensus.Why would I want to ?, I can make and use whatever data format I wish right now. It servesno real benefit to me.The only real benefit I see for a common standard is the customers/users. Its less data for themto download every cycle. That's not really enough of a compelling reason, for the developers to come to a consensus.I think a much more compelling reason, would be a large number of customers refusing to puchase an add-on unless it did not require them to make additional downloads every cycleto keep the navdata up to date.But the latter is not likely anytime soon, as I think really only a minorty of customers/users are really compelled to keep their add-on databases faithfully up to date every Airac cycle. Everyone differs on how often they wish or feel the need to upgrade their navdata.Some religiously do it every cycle, some only once a year, some only when a significant changeis made in the areas they frequent. And some never update at all from the version they originally get with the program.Regards.Ernie.

[scott967 62]

I think the fix would be if MS provided the data in a database format as part of FS, then all developers could simply extract from that database. As it is, the data are embedded in various files and not all that easy to extract (and MS provides no tool to do so). At one point super flight planner had a data extraction tool (dbwiz) , but my understanding is that the developer is giving up on that and obtaining data external from fs in the future.scott s..

[Egbert Drenth 250]

Once you have a consesus/committee defining the standard, as a developer you in effect are limited by that committee's decisions.For that reason alone, I'd likely not be interested in being part of such a consensus.Why would I want to ?, I can make and use whatever data format I wish right now. It servesno real benefit to me.The only real benefit I see for a common standard is the customers/users.

I do not agree with you, also for developers there are huge advantages:1. There is always Navdata available, incl SID/STARs if necessarry2. There would be a common/public set of C++ libraries to accomodate all functionality for a simple GPS to a complex FMC. The truth is: IRL there is already a standard and it's called ARINC 424.It accomodates Boeing, Airbus, Embraer, Garmin, you name them.... So what is different in the virtual world, why is it so difficult to arrange?

[ErnieAlston 33]

I do not agree with you, also for developers there are huge advantages:1. There is always Navdata available, incl SID/STARs if necessarry2. There would be a common/public set of C++ libraries to accomodate all functionality for a simple GPS to a complex FMC.

If the data is already being provided in each developers format, there is no additional benefitto the developer to switch to common or universal format.Its a detriment as you limit yourself to the approval or rejection of a committee,for any future changes or additions which may or may not like your idea for modifying the format.

The truth is: IRL there is already a standard and it's called ARINC 424.It accomodates Boeing, Airbus, Embraer, Garmin, you name them.... So what is different in the virtual world, why is it so difficult to arrange?

Navdata providers like Jeppessen, and Garmin have a different versions of this data that actually go into their products. It fact you'll be hard pressedto find two commercial vendors using the same data format in all their products.Really no different than from FS add-on developers.What you are suggestioning is that all FS developers use a single dataset, so that theuser only need to download one Navdata update every cycle. This is definitely not what Boeing, Airbus, Embraer, Garmin etc are doing. They wouldn'twant to anyway. They have proprietory and legacy reasons not to.Regards.Ernie.

[ronzie 21]

Hello, Egbert:I did a search on AIRINC 424 and besides a basic description of the objectives I found a document on the FAA's implementation:http://naco.faa.gov/index.asp?xml=naco/cat...rts/digital/nfdwhich indicates to me that the datasets in this format are not universally accepted yet. Without purchasing the specification I have no clue how complete that specification is. Note the FAA is not furnishing coded IAP routines from what I can see in their implementation.With regard to your comment number one below, I am not as confident in the FS environment of that being true, at least in the complete data dictionary necessary. This can be illustrated in Richard Stefan's experiencing his data source from DAFIF becoming restricted material and also being in many areas only for purchase. He partnered with Navigraph to make available funds to continue his wonderful work. Note the FAA dataset mentioned above is only available for purchase as is much of their data formatted material. Other countries must be doing the same.With regard to Navigraph if you go to the FMC description page and then to the developer's information page, you see that a developer must license and work out a contract to make data available in that specific nav format required. If Navigraph moved to AIRAC format standards for output, would that reduce any developer derived revenue? If so, only user subscription would support the FMC division. Now many developers appear to have licensed this service so perhaps it is not that expensive. It would have to continue to support all the proprietary FMC formats already out there.I wonder if this standard would be adapted by the ICAO? That could certainly simplify matters.I agree with you that developers complying to a standard would be very nice.

I do not agree with you, also for developers there are huge advantages:1. There is always Navdata available, incl SID/STARs if necessarry2. There would be a common/public set of C++ libraries to accomodate all functionality for a simple GPS to a complex FMC. The truth is: IRL there is already a standard and it's called ARINC 424.It accomodates Boeing, Airbus, Embraer, Garmin, you name them.... So what is different in the virtual world, why is it so difficult to arrange?

[Flaps30 3]

I have had FS9 since its release and although tempted, never updated my navdata files since there never seemed to be any conflicts with charts, etc. I just purchased the Wilco CRJ and tried entering the airport identifiers into the FMC. It took my departure airport KAVP with no problem, but the destination KUNV brought back a data error message that it was unable to find it. This airport (University Park - Penn State in Pennsylvania) is in the FS9 database and has never posed a problem before. I then decided to import the FS9 created flight plan directly through the FMC and it did, now recognizing the KUNV entry. However, on approach when I tried to select the ILS runway on the DEP/ARR page, no runways were available. I assumed the CRJ Wilco database is the latest one or at least much newer than my original FS one. How many different NAVDATA databases does FS need. A different one for each aircraft? And why this problem with the CRJ? I have had no problems with Level D or PMDG. Thanks. Regards, Tom

Thanks for the feedback guys. Now I know why there are so many different versions of the Navdata for the various aircraft. Since I have not updated them before, is it pretty much straightforward when updating - in other words, just swap the file? Tom

[David Vega 348]

Great contributions by all. Consider that an FMS data standard doesn't mean the data would be free. It also doesn't mean developers would have to convert their existing products, but that it would facilitate the development of new products. One would expect that this would benefit the customer also since less development effort may mean less cost. I'm old enough to remember the earlier computer generation where each major company, such as IBM, DEC, Honeywell, etc, sold their own format or machine or assembly language; they wanted the consumer to only purchase their products. Look at what the standards in high order programming languages have brought us. Consider what the W3 Consortium have done for the Internet, HTML, XML, etc. This also makes me think about those standards that have been created by a user community. Wonder if AVSIM would mind sponsoring such a standard for FMS data.

[Egbert Drenth 250]

Navdata providers like Jeppessen, and Garmin have a different versions of this data that actually go into their products. It fact you'll be hard pressedto find two commercial vendors using the same data format in all their products.Really no different than from FS add-on developers.

Hi Ernie,It should be irrelevant to a customer what goes in, as long as the source is mutual.So if the developer would like to provide an automatic convertor it's fine with me, but I really don't think that is necessary.Also wether the standard should be AIRINC424, PMDG, LevelD, ABC123, or XML789 is none of my business as long as they choose/define one.Consider this analogy:Currently we require 15 dictionaries to translate the navdata from English (Navigraph) into French (PMDG), Dutch (LevelD), German (...), Italian, Zwahili etc. Why not speak all the same language?Being a professional .NET developer myself, I really don't buy it that a single (extended) set of Navdata could not cover all required functionality for each GPS/FMC/CDU/....The only complicated issues is the interpretation of the SID/STARs. If a common C library is provided that should be covered too and developers don't have to worry about 'inventing the wheel each time'.

[ronzie 21]

If the standard data defined structure is provided like data definitions in a C header file, the vendor could elect to convert that data himself writing his own routines. (Of course once the data structure is known almost any programming language could be used.) In that case the data provider only needs to assemble the various source data and output that data to a subscriber in that formatted standard ready to be imported by the add-on. If a developer wants the standard converted to his desired format before delivery for whatever reason, then the current system which is a charge for proprietary formatted data delivered (user subscription) and conversion charge (add-on developer contract) can still be maintained.

The only complicated issues is the interpretation of the SID/STARs. If a common C library is provided that should be covered too and developers don't have to worry about 'inventing the wheel each time'.

[ErnieAlston 33]

It should be irrelevant to a customer what goes in, as long as the source is mutual.

Hi Egbert,What 'source' are you referring to ??AFAIK there is no source of Navigation data that is available to all since DAFIF's public area was closed.

So if the developer would like to provide an automatic convertor it's fine with me, but I really don't think that is necessary.

Providing converters results in multiple versions/downloads. Doesn't that pretty much defeat the goal/purpose of having thestandard ?

Currently we require 15 dictionaries to translate the navdata from English (Navigraph) into French (PMDG), Dutch (LevelD), German (...), Italian, Zwahili etc. Why not speak all the same language?

Because Navigraph is doing the conversion for them, there's no cost to them for this conversion/translation.The benefit of course PMDG,LDS, Wilco etc do not have to to provide the Navdata updates themselves. Which mostwould not be able to do anyway because the cost is too prohibitive.The benefit to Navigraph of course is the subscriber fees. So far that benefit appears to be greater than the cost ofthe actual translations/conversions.

Being a professional .NET developer myself, I really don't buy it that a single (extended) set of Navdata could not cover all required functionality for each GPS/FMC/CDU/....

No-one is claiming that what you suggest is not feasable, clearly it is.The point again is where is the benefit to the developers, in relation to the cost ?The benefit here is to the users/customers, and really only the small minority of them, that faithfull update theirNavdata for every application every AIRAC cycle.Regards.Ernie.