EDDM/08R VAVO3E VAVOR M867 RADIZ DCT REKTI DCT NEMEK DCT VRANA DCT DIMIS DCT VELOP UY151 PLH UL604 SALUN N705 MMA P751 DASUM Y234 FYM M872 BDB Y214 RAPMA DCT KUVSO DCT KATIT DCT PEKEM M628 RIGIL G783 ASPED Q308 KIPOK Q568 IMPED IMPE3C OMDB/30L
The plane is unable to load the airway M872 and is loading FYM DCT BDB on import. Also manual input shows AIRWAY/WPT MISMATCH
Hi,
There is a BDB navaid on M872, but in another segment, and it looks like Aerosoft doesn´t recognise this:
Segment #1: FYM → SILKA
Segment #2: SILKA → KSA
The reason for the split is that SILKA is on the border between Egypt and Saudi Arabia. This navaid is included on the M872, so I would recommend reporting this to Aerosoft. We can´t fix this, sorry.
Cheers,
Richard
Okay our answers just came both at the same time. I will report this to aerosoft. Thank you very much!!
Edit: disregard, see A340-600 (Aerosoft) unable to load specific AIRWAY - #9 by Rodeo314
In Navigraph Chart’s database, the airway is split in two:
Presumably it’s also the case in the database used by the Aerosoft A346? Assuming it is the case:
The two M872 airways here seem to be distinct entries in the database, and IMO it’s not necessarily obvious for software that they should be merged just because both airways happen to have waypoint SILKA in common (i.e. because they are distinct in the database, to software, the airways might as well have different names, the fact that they are both named M872 is arguably coincidental).
There would need to be additional logic to merge airways with the same name that have a waypoint in common, but it’s not necessarily obvious that such logic absolutely has to be implemented.
Without the additional logic, a basic route parser (that e.g. only look at the route string) would see FYM M872 BDB, find an airway named M872 where FYM exists, and look for BDB on the same airway; it would find an airway in the database named M872 where FYM exists, then try to find BDB on the same airway portion, and fail.
If the intent is for both portions of M872 to link up seamlessly, then they should probably be joined in the published database, rather than relying on the database parser to join them at runtime.
This is already the case in e.g. the old X-Plane GNS430 format, where both “portions” of M872 above exist as a single A,M872,21 airway.
Regards,
Tim
Tim,
This is a common rule in the ARINC424 - it is much more complex than you wrote here. The old format that you refer to has been outdated for over 10 years. The new format has been in place for several years now, and all modern add-ons (like Fenix, PMDG, Just Flight, Maddog, iFly, … also X-Plane) use it without any issues, except for Aerosoft now.
So, please be so kind and don´t play the ball back to us. It is not our fault; it is standard in the real-world aviation.
Thank you very much,
Richard
I was looking at the more modern formats and it looks like airways aren’t laid out according to my assumption there anyway, so indeed my post doesn’t make much sense after all. Sorry for the sidetracking.
Cheers,
Tim
No probs, Tim - thanks for your clarification 
Have a nice evening,
Richard
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
