Transmission error between SimBrief and EFB2 client.
The flight is from ZGSZ to EDDM Takeoff from RWY 15 and Landing is RWY 08R.
TOM9WD TOMUD R200 LH R339 WUY R474 NOB W21 BQ B214 AKSAG B465 CEA A791 BPL L639 RASKI L301 RAGMA N571 IVOXI M557 TUMAK T602 ORSOL L602 TASMI UL602 ALPET L718 KABAN UL718 INB UL746 ODERO T86 MATEL T746 ARGES FLR AGNEP MOPUG MAVIR SASAL RUPET AMADI Q113 NAPSA NAPS1B
It seems that there is a tiny bug in SimBrief when they are generating the ICAO-FPL which is part of the downloaded XML-file.
On their webpage the first element in the routing (the name of the departure route) is properly named as TOM9WD (see next screenshot)
But in the ICAO-formatted flight plan, which is part of the downloaded XML-file, the first element (name of the departure route) is wrong, because the name is too long, see next screenshot. And BTW, the last element (arrival route) is also not properly named (NAPSA4A, instead of NAPS4A).
Therefore the message in EFB about the invalid element is correct.
This actually isn’t a bug. SimBrief expands the SID/STAR names to their full names for the ATC FPL. In the AIRAC data, procedure names longer than 6 characters aren’t possible, so “NAPSA1B” is shortened to “NAPS1B” (the same logic is used for many SID/STARs, including many in Europe).
Since SimBrief’s ATC FPL follows all applicable real world rules, the full SID/STAR names are used. For example, trying to validate a route with “NAPS1B” with Eurocontrol will return an error. Only “NAPSA1B” is recognized.
For Aivlasoft’s part, they will need to handle this within their software I’m afraid. Both route variations (with either short or long procedure names) are available in the XML data file SimBrief provides. It’s up to Aivlasoft to parse the correct one based on their needs (right now they are reading the full procedure names, whereas clearly they need to be using the shortened names instead to match the AIRAC data).
As an example, the route string with full procedure names can be found in <atc><route_ifps>, and the shortened version is in <atc><route>. It seems like Aivlasoft might be reading the full ATC FPL instead at <atc><flightplan_text>, and if so, they may need to perform a string replace, using the <atc><flightplan_text> as a base and replacing the route from <atc><route_ifps> with <atc><route>. That’s just one possible approach as an example, another option is to rebuild the ATC FPL string using the individual data under <atc>. The best/easiest solution will depend on their needs of course.
Feel free to forward this info to Aivlasoft, and they are of course free to contact me directly if they require more guidance or have any questions about this.
