Vous n'êtes pas identifié(e).
Bonjour,
J'ai constaté récemment un problème de déclinaison magnétique (en fait l'absence de déclinaison magnétique, ou des aberrations de cap) après avoir installé certaines scènes freeware pourtant de qualité, mais aussi une scène payante. Cela se traduit par des indications de cap erronées qui sur la France sont généralement de quelques dégrés mais sur les US, à Boston par exemple, sont de 15° par rapport à la normale. Du coup, certains pilotes automatiques (comme celui du 737PMDG) sont à la ramasse pour intercepter et suivre un ILS ou une route aérienne.
Voici une liste non exhaustive de scènes freeware pour lesquelles j'ai constaté ce problème :
- Go Cairo 2010,
- Seychelles Islands 2007,
Pour la scène payante, je n'ai constaté pour le moment ce phénomène que sur la scène de Saint Lucia Hewanorra de Tropicalsim. C'est le fichier tlplxrwyendr.bgl qui génère le problème. Contactés, les développeurs ont pu reproduire le phénomène qui n'apparaît pas forcèment au 1er démarrage de FS après l'installation de la dite scène... En supprimant ce petit .bgl du répertoire scenery de la scène, tout rentre dans l'ordre.
Je n'ai pas cherché à débugger plus précisement les scènes freeware ci-dessus mentionnées car c'est assez long d'isoler le ou les .bgls incriminés.
Toutefois, si certains d'entre vous pouvaient me confirmer qu'ils ont le même problème, je me sentirais moins seul
A+
Emmanuel
Dernière modification par eparot (16-10-2010 16:12:16)
Hors ligne
Oui, Fs gère la déclinaison magnétique, sinon tu aurais du mal à suivre les routes entre deux points définis par leurs coordonnées dans fs.
Esparot je comprends pas trop ton soucis, normalement, la déclinaison est liée aux coordonnées, à moins que ça ne soit écrit en dur dans les scènes? Cela me surprendrait
Hors ligne
Hors ligne
Et oui, c'est bien géré au niveau des scènes.
Et contre toute attente, il semble que certains .bgl intégrant des données erronées puissent foutre la pagaille sur l'intégralité du globe...
Ce qui me chagrine le plus c'est que ces scènes ont été téléchargées des milliers de fois pour la plupart et que personne ne semble avoir remarqué ce détail très gênant pour qui fait autre chose que du VFR local.
A+
Emmanuel
Hors ligne
Bonjour,
Je suis en train de me demander si ce probleme a été réglé sur P3D ?
Est-ce que P3D lui-meme gère la déclinaison magnétique sur tout le globe ou est-ce uniquement les scenes (donc souvent l'aeroport lui-meme) qui font la correction ?
Merci
A+
Hors ligne
On peut toujours se mettre Ă jour ici : http://www.aero.sors.fr/
Patou
AMD Ryzen 9 7900X (4.7 GHz / 5.6 GHz)/ASUS ROG STRIX X670E-E GAMING WIFI / RX 7900 XTX GAMING OC 24G / SSD 980 PRO M.2 PCIe NVMe 500 Go / SSD 980 PRO M.2 PCIe NVMe 2 To / Samsung SSD 870 QVO 2 To / Corsair iCUE 7000X / Seasonic PRIME PX-1300 - Bluestork Grapheme / Acer Nitro XV345CURVbmiphuzx / Acer Nitro XV253QPbmiiprzx -JBL Quantum Duo - MSI MEG CORELIQUID S360
Hors ligne
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é
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
La déclinaison magnétique est bien introduite dans les scènes.
Ici la valeur introduite dans LFPO (déclinaison à la date de création de la scène par défaut):
Blédina: "Essayer c'est grandir"
Hors ligne
La déclinaison magnétique est bien introduite dans les scènes
Certes, mais il semble bien qu'elle ne serve à rien! et certainement pas en tout cas à expliquer un cap magnétique erroné ou un alignement d'ILS non conforme. Quelques explications sur mon forum (en anglais, désolé mais c'est facile à comprendre)
http://aerosors.freeforums.net/thread/112/magnetic-variation-problems-airac-data
Hervé
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
Le problème vient du fait que vous faites les mises à jour de vos données 'instruments' par le biais de mises à jour des aides à la navigation mais tant que la déclinaison correspondante à la date de vos mises à jour ne sera pas introduite en dur dans le fichier bgl de l'airport (défaut ou scène) vous rencontrerez ce genre de désagrément.
Blédina: "Essayer c'est grandir"
Hors ligne
tant que la déclinaison correspondante à la date de vos mises à jour ne sera pas introduite en dur dans le fichier bgl de l'airport (défaut ou scène) vous rencontrerez ce genre de désagrément
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é
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
Attention!
La déclinaison magnétique est introduite avant toute création d'objets airport et elle est bien prise en compte lors de la compilation.
Son changement après coup ... ne change rien.
Ex:
une piste dessinée au 84
déclinaison: +20
résultat: aligné sur la piste, cap: 104
modif déclinaison: 0.00
résultat: aligné sur la piste, cap: 104
Je dis donc que la déclinaison introduite est bien prise en compte lors de la création de l'airport et que pour avoir des alignements corrects en cas de changement de déclinaison ... il faut recréer l'airport.
Vaste programme auquel LM rétorque que pour apprendre, ou s'entraîner, les bases de données NAV actualisées ne sont pas nécessaires (le défaut, toujours le défaut!).
Blédina: "Essayer c'est grandir"
Hors ligne
elle est bien prise en compte lors de la compilation
Certes pour y etre intégrée à l'offset 0x24 du record airport..seul endroit où on la retrouve. Cela ne veut pas dire qu'elle est utilisée ensuite..il y a de nombreux exemples de données inactives dans les BGLs
pour avoir des alignements corrects en cas de changement de déclinaison ... il faut recréer l'airport
Ah bon!
une piste dessinée au 84
déclinaison: +20
résultat: aligné sur la piste, cap: 104modif déclinaison: 0.00
résultat: aligné sur la piste, cap: 104
Normal LOL puisque tu ne changes ni l'axe vrai de piste (084) ni la VRAIE déclinaison magnétique locale (magdec.bgl)..Le cap affiché aligné ne dépend en effet que (a) de l'axe vrai de piste (inchangé ici) (b) et de la valeur simulateur de la déclinaison magnétique récupérée dans le magdec.bgl et qui ne dépend que de ta position et des données temporelles du magdec.bgl.. rien d'autre.
Vaste programme auquel LM rétorque que pour apprendre, ou s'entraîner, les bases de données NAV actualisées ne sont pas nécessaires (le défaut, toujours le défaut!)
Sans rapport avec le sujet discuté ici..isn't it?
Mais bon j'abandonne le sujet..Il suffit de tester et expérimenter pour se forger une idée. Chacun se fera la sienne
Pour mémoire ce sujet a déja été abordé à maintes reprises sur le forum FSDeveloper notamment ici
https://www.fsdeveloper.com/forum/threads/changing-airport-magnetic-variation.7048/
Extrait
by which I assume you mean that the mag variation used in the sim to compute, among other things, runway mag. heading is generated by magdec.bgl. If so, what is the purpose of the mag variation stored for the airport itself, the localizers, the VORs and who know what else?
De jvile (expert)
..Studies I did back then on Mag variation showed that FS does not use those values. Some decompilers don't extract the mag variance for the runway and the BGLComp compiler does not need it.
Dernière modification par hervesors (24-07-2018 14:47:34)
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
Normal LOL puisque tu ne changes ni l'axe vrai de piste (084) ni la VRAIE déclinaison magnétique locale (magdec.bgl)
Changer l'orientation géographique de la piste ? Depuis quand cela se produit-il ? A part le mouvement des plaques tectoniques rien ne change la position ou l'orientation d'un aéroport, même si on repeint périodiquement le numéro des pistes.
Depuis quand les données aéroports sont-elles contenues dans magdec.bgl ?
Le problème vient surtout du fait que les instruments de navigation modernes founis dans Fs ou P3D utilisent avec aberration le cap magnétique au lieu du cap géographique, le GPS a été un peu créé pour éviter ce genre de problème, le travail en WGS84 se base sur des coordonnées géographiques invariantes (sauf erreur de positionnement!).
Exemple, après correction du GPS 500 Fs ou P3D (remplacement de 'Magnetic Track' par 'True Track' dans la définition de la gauge):
On voit bien la différence des caps puisque le compas magnétique indique le cap géographique corrigé de la déclinaison de 20° introduite lors de la création de la scène alors que le GPS indique maintenant le cap géographique qui lui est invariant. Il semblerait que toutes les centrales de navigation fonctionnent sur le cap magnétique dans nos simus contrairement aux réelles créées justement pour s'affranchir de la déclinaison.
Sur cet appareil tout est basé sur le Nord géographique, Cap (Heading) et course (Track) sont identiques et vrais et correspondent bien-sûr à l'orientation géographique de la piste (84°):
Dernière modification par bede40 (24-07-2018 20:05:56)
Blédina: "Essayer c'est grandir"
Hors ligne
Changer l'orientation géographique de la piste ? Depuis quand cela se produit-il ? A part le mouvement des plaques tectoniques rien ne change la position ou l'orientation d'un aéroport, même si on repeint périodiquement le numéro des pistes.
Depuis pas mal de temps je pense.
Dans les années 1980, quand j'ai pris mes premières leçons de pilotage, la piste nord-sud était 18-36.
A présent (en 2006, année où j'ai cessé de piloter) elle est (était) en 17-35.
Jean
MSI B250M Mortar, I7-7700K, 16Go 2400MHz, MSI RTX 4060 Ti 8Go, be quiet! Dark Rock TF, SSD Samsung 850 EVO, DD WD 1To, Oculus rift
Hors ligne
Salut LFML Marseille Marignane est devenu Marseille Provence même que les pistes aussi ont changé de nombre ...
Patou
AMD Ryzen 9 7900X (4.7 GHz / 5.6 GHz)/ASUS ROG STRIX X670E-E GAMING WIFI / RX 7900 XTX GAMING OC 24G / SSD 980 PRO M.2 PCIe NVMe 500 Go / SSD 980 PRO M.2 PCIe NVMe 2 To / Samsung SSD 870 QVO 2 To / Corsair iCUE 7000X / Seasonic PRIME PX-1300 - Bluestork Grapheme / Acer Nitro XV345CURVbmiphuzx / Acer Nitro XV253QPbmiiprzx -JBL Quantum Duo - MSI MEG CORELIQUID S360
Hors ligne
Normal! on les a faites pivoter Ă la barre Ă mine
tout Ă fait
comme on dit dans le MIDI 31, 32 et hop c'est fait ..!
L’origine de cette expression Provençale :
CE serait une légende racontée par de vieux bergers le soir autour d’un feu de bois perdu au milieu d’une colline dans le midi
Chaque berger ne devait posséder que trente moutons, pas un de plus. La dernière bête répertoriée était emmené par le diable un soir de pleine lune
Ils ont donc eu recours à un stratagème.
Le jour du recensement de leurs trente moutons, les bergers rajoutaient 31 32 , le diable ne voyant pas ces dernières bêtes repartait bredouille.
Pas très futé le diable, je vous l’accorde.
Dernière modification par NEPTUNE6P2V7 (25-07-2018 11:48:51)
AMD Ryzen 9 7900X (4.7 GHz / 5.6 GHz)/ASUS ROG STRIX X670E-E GAMING WIFI / RX 7900 XTX GAMING OC 24G / SSD 980 PRO M.2 PCIe NVMe 500 Go / SSD 980 PRO M.2 PCIe NVMe 2 To / Samsung SSD 870 QVO 2 To / Corsair iCUE 7000X / Seasonic PRIME PX-1300 - Bluestork Grapheme / Acer Nitro XV345CURVbmiphuzx / Acer Nitro XV253QPbmiiprzx -JBL Quantum Duo - MSI MEG CORELIQUID S360
Hors ligne
bede40 a écrit :Changer l'orientation géographique de la piste ? Depuis quand cela se produit-il ? A part le mouvement des plaques tectoniques rien ne change la position ou l'orientation d'un aéroport, même si on repeint périodiquement le numéro des pistes.
Depuis pas mal de temps je pense.
Dans les années 1980, quand j'ai pris mes premières leçons de pilotage, la piste nord-sud était 18-36.
A présent (en 2006, année où j'ai cessé de piloter) elle est (était) en 17-35.Jean
Il y un soucis de comprehension ici : Bede40 parle de l'orientation geographique des piste (par rapport au Nord geographique, ou Nord vrai). Cette derniere ne change jamais, a moins d'un cataclisme majeur...
Seule l'orientation magnetique (et donc la numerotation) change regulierement, en fonction des variations de la declinaison magnetique.
Donc en theorie, dans un fichier AFCAD, l'orientation vraie de la piste n'est jamais sensee entre modifiee.
Tim
"If flying were the language of man, soaring would be its poetry."
"Think positive, flaps negative !"
Hors ligne
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
Dernière modification par hervesors (25-07-2018 15:57:09)
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
Nous sommes d'accord sur un point, la déclinaison magnétique concernant un aéroport est introduite automatiquement lors de sa création depuis la table en service, elle n'est là qu'à titre indicatif. Si l'on veut la changer (pour le plaisir des yeux) il faut récréer la scène avec la table des déclinaisons à jour ce qui est inutile puisque le simulateur tient apparemment compte du changement de table, du moins P3D.
Le GPS indiquant le cap vrai
Table FsX (2006)
Table du 01/01/2014
Table du 01/01/2017
Table du 01/01/2018:
Maintenant, reste Ă prouver la valeur de cette table.
Dernière modification par bede40 (25-07-2018 17:17:48)
Blédina: "Essayer c'est grandir"
Hors ligne
On est parfaitement d'accord..
reste Ă prouver la valeur de cette table
Pour info, la table est intégralement chargée en mémoire (via le SIM1.DLL) lors du lancement du simu afin de générer des valeurs (interpolation bilinéaire) à chaque cycle de rafraichissement..c'est donc très rapide
Celle par défaut était basée sur des valeurs de DM datant de 2009 pour FSX (valides par comparaison aux données IGRF), inchangées dans P3D jusqu'à la V3. Je n'ai pas regardé la V4. Cette table peut facilement être reconstruite pour coller à des données plus récentes (modèle IGRF ou WMM d'ailleurs très proches).
Pour les techniciens et programmeurs, quelques infos supplémentaires ici
https://www.fsdeveloper.com/wiki/index.php?title=Magdec_BGL_File
Dernière modification par hervesors (25-07-2018 20:14:40)
Err is human, but for a real disaster you'll need a computer (Bill Gates, adapted)
Hors ligne
Comme beaucoup je pense, je les charge ici: http://www.aero.sors.fr/navaids.html
Blédina: "Essayer c'est grandir"
Hors ligne