Bonjour,

Au moins 3 conditions pour pouvoir exploiter les données TACAN
1. Que les fichiers contenant les données de navigation (habituellement les fichiers NVX) contiennent les enregistrements TACAN correctement codés (et pas seulement une simple conversion en données DME standard)
2. Que les routines de base du simu rĂ©cupèrent les donnĂ©es TACAN lorsqu'elles sont prĂ©sentes 
3. Que les gauges dédiées exploitent correctement les data passées par le simulateur
En l'absence de gauge dédiée, une simple information DME sera habituellement fournie (ce qui est la réalité sur les récepteurs NAV standard)
N'ayant pas testé le process sur MSFS, impossible de répondre mais dans P3Dv4-6 (disposant d'un codage TACAN), il est fréquent que une ou plusieurs de ces conditions ne soient pas remplies..

Hervé

Bonjour,

Je partage ton pessimisme mais, ceci étant, il a fallu un peu de temps pour comprendre comment fonctionnait FS9->P3D vis à vis du codage interne des moyens de radionavigation dont les ILSs (c'est à dire au niveau BGL), la prise en compte de la déclinaison magnétique, etc le SDK n'étant guère plus documenté (avec seulement des commentaires génériques totalement inutiles). Il n'est pas impossible que ceux qui s'y intéressent finissent par acquérir une compréhension suffisante pour modéliser les choses convenablement. Comme tu as pu sans doute le lire sur les forums ni Navigraph (Richard), ni Jon ne sont encore tout à fait à l'aise avec les paramètres ILS de MSFS mais cela viendra peut-être (ou pas).
Perso, MSFS ne m'intéresse pour le moment pas plus que cela, l'aspect visuel n'étant pas ma priorité, les modèles de vol étant pitoyables et les changements incessants étant assez décourageants. Mais peut être un jour..

C'est plus la base de données de navigation de Little NavMap qu'il faut incriminer en prenant en compte les problèmes spécifiques recontrés avec MSFS. La procédure de mise à jour est décrite par l'auteur ici (paragraphe 43.1)
LittleNavMap manuel
et n'est pas la même selon que tu disposes ou non d'une mise à jour Navigraph pour LittleNavmap (celle incluse par défaut date de Janvier 2018)

Ou pas..mais tu as raison, c'est la référence (et pas en vue extérieure). Il n'en reste pas moins que la plupart (presque tous des scènes par défaut) ne sont pas du tout réalistes en vue cockpit..Il faut donc souvent les recalibrer. Armand42 nous dira dans quelles conditions il a effectué ses tests

Les anglo-saxons toujours Ă  la recherche de formules simples (et efficaces) utilisent souvent
"Variation West, Magnetic Best; Variation East, Magnetic Least"

Mais pour la petite histoire, certains (Microsoft repris par LM) n'ont rien trouvé mieux que d'adopter un codage de signe inverse (W+, E-), histoire d'embrouiller un peu plus

Extrait d'un des nombreux champs du SDK de P3D
"magvar    Magnetic variation at the ILS to True North in degrees.    -360.0 to 360.0 floating point value. Default = 0.0. East magvar is negative, West magvar is positive."
http://www.prepar3d.com/SDKv4/sdk/world/scenery/scenery_overview.html

mais pas grave puisqu'au final les calculs sont effectués en interne correctement..après inversion du signe.
Ceci étant quand on décompile une BGL, il faut y faire attention (et inverser soit même..)
Pourquoi faire simple quand on peut faire compliqué

On est bien d'accord et cette valeur d'orientation vraie est renseignée dans la BGL (l'AFCAD ou n'importe quel éditeur ne fait compiler une BGL à partir des informations entrées) mais au départ, là n'était pas le problème mais celui de la signification et de l'utilisation par le simulateur de la valeur de déclinaison magnétique ASSIGNEE à l'aéroport (également inscrite dans le fichier BGL dans l'en tête du record airport). Je persiste et je signe (comme d'autres qui ont bien étudié les fonctionnements internes du simulateur, cf plus haut). Cette valeur n'est pas utilisée par le moteur du simulateur. D'ailleurs les compilateurs acceptent qu'elle ne soit pas renseignée, c'est tout dire et la changer en interne dans la BGL ne fait strictement rien. . Elle est de toute façon sans importance puisque, comme indiqué plus haut le cap magnétique de piste lorsu'aligné (celui que tu liras sur ton compas, ton HSI s'il est asservi et fonctionne en mode MAG et pas TRUE) est calculé par le simulateur à partir de l'axe géographique de piste (connu et fixe) et la valeur COURANTE de la déclinaison magnétique à la position de l'appareil récupérée par le biais du magdec.bgl (qui ne contient rien d'autre qu'une table de calcul..LOL). Et, comme tu l'indiques, les renumérotations de piste sont en effet liées aux changements temporels de déclinaison magnétique.
Maintenant rien n'empêche un développeur de scène de modifier l'axe vrai (géographique) pour mieux le faire coller à la réalité (s'il est incorrect au départ); certaines pistes reconstruites peuvent également avoir un axe VRAI plus ou moins différent de l'existant antérieur..Mais bon, c'est un autre sujet

Humm..comme indiqué précédemment, le problème n'est pas dans la valeur de la déclinaison magnétique assignée à l'aérodrome dans la BGL (qui ne fait absolument rien). Amusez vous à entrer une valeur totalement farfelue par exemple E15 pour LFPO (mon outil AIE permet de faire cela simplement au niveau BGL) et regardez (n'oubliez pas de faire un backup de votre BGL originale)..RIEN N'EST CHANGE (orientations de piste, ILSs, vue map, GPS, etc..). Seule incertitude: le trafic AI mais je n'ai pas testé ce point

Hervé

Je suis très étonné qu'une scène puisse gérer la déclinaison magnétique locale à la position de l'appareil sauf à intercepter les routines du SIM1.DLL et les modifier (et ce n'est pas une mince affaire mais de toute façon cela ne peut en rien être défini dans une scène). Emmanuel peux tu nous en dire un peu plus car je pense que le problème est ailleurs (définition des axes ILS incorrecte notamment puisqu'il semble que le problème soit là..cela me parait beaucoup plus probable et ne retire en rien ton commentaire étonné..)

Hervé

Lesquels car j'en ai corrigĂ© la plupart (en tout cas ceux possĂ©dant une procĂ©dure instrumentale) mĂŞme si ce n'est pas indiquĂ© dans le rĂ©sumĂ©... mais j'en ai peut ĂŞtre oubliĂ©..il faut toutefois installer en plus  du World Navaids package les "ILS/Rwy regional updates" sinon ne sera corrigĂ©e que l'Europe..Je ne peux pas facilement corriger les aĂ©rodromes fermĂ©s (je ferme les pistes et supprime toutes les procĂ©dures mais l'infrastructure reste) ni ajouter les nouvelles plateformes..merci pour le retour et je ferai les corrections nĂ©cessaires s'il y en a

Oui c'est assez facile. Info en MP

Hervé

En attendant que Rémi (Starway366) propose une version ultérieure
voici donc sa version précédente où tous les ILS ont été corrigés (seule modification)
http://www.aero.sors.fr/private/LFPG_AFX_T2G_Wi16.bgl

S'il n'y avait que cela..et pas si petit que cela l'offset surtout pour un Cat III=(
- L'ILS 26R (GAU) est sur la mauvaise fréquence (111.95 maintenant) et n'a pas son DME associé
- L'ILS 08L (GLE) n'a pas non plus son DME
- Les antennes sont presque toutes mal positionnées (LOC et glide)
- Les largueurs de faisceau de LOC ne sont pas nominales
- Tous les ILS sont définis en "backcourse" !
- Les variations magnétiques des ILS sont toujours à 2W
J'ai corrigé ton AFCAD Starway36 si tu es intéressé (uniquement les moyens de radionavigation) mais bon, normalement c'est pas notre boulot (pour une scène payante s'entend)

Hervé