Je viens de tester VFRnav pour la première fois avec Microsoft Flight Simulator (2024) en me connectant via FS2020NMEA.exe.
Après avoir consulté le journal des modifications de VFRnav 4.10, je me demande s’il existe une intégration plus poussée ?
Le trafic, la radio et l’autopilote seraient bien sûr intéressants, mais la carte très fluide et l’accès rapide aux informations sont déjà super.
Bonjour bspline,
En effet, il y a quelque temps j’ai travaillé sur une solution améliorée, voire plus simple, pour la connexion entre Microsoft Flight Simulator (MS Flight Simulator) (sur Windows) et VFRnav.
Les modifications sont - comme tu l’as déjà mentionné - incluses dans VFRnav depuis la version 4.10.
Pour la connexion, seul cet outil est désormais nécessaire:
https://dl.flugbetrieb.com/v3/msfs2vfrnav/msfs2vfrnav.exe
Si celui-ci s’exécute en arrière-plan, VFRnav devrait automatiquement détecter la connexion.
N’hésite pas à tester et à faire un retour 
Salutations de pilote
Hermann
Merci pour l’information. J’ai lancé l’outil et il reçoit des données de MSFS 2024 (“Receiving Data”). De plus, un port UDP (aléatoire ?) est ouvert.
Le téléphone Android avec VFRnav (encore en version d’essai) est sur le même réseau, mais ne reçoit aucune donnée de position. Dans «Périphériques tiers» j’avais configuré TCP avec l’adresse de l’ordinateur et le port 10110 (encore pour FS2020NMEA.exe). Même en utilisant le port 2000 ou en passant à UDP (port 4000 ?) rien n’apparaît et aucune connexion n’est établie. Autoriser manuellement les connexions entrantes et sortantes via le pare-feu de Windows (11) n’a rien changé.
Faut-il effectuer des réglages dans VFRnav ? Comment la communication s’effectue-t-elle ?
Un deuxième problème est que la fermeture de la fenêtre ne termine pas le programme. J’ai dû ensuite fermer manuellement les processus dans le Gestionnaire des tâches.
Dans MSFS 2020 également. L’outil détecte la connexion et le début du vol, mais il ne semble pas y avoir de connexion à VFRnav. Je n’ai pas non plus remarqué de paquets broadcast ou similaires.
Salut,
merci d’avoir testé et pour ton retour rapide 
Sur quel système utilises-tu MSFS ? Est-ce la version Steam ?
Je vais le retester, mais je suis encore bloqué dans le gestionnaire d’installation de MSFS… 
Salutations de pilote
Hermann
Ouf, la mise à jour a été exceptionnellement rapide 
Meine Umgebung:
Le PC et le téléphone sont tous deux sur le même réseau Wi‑Fi. Le routeur est configuré pour permettre la communication entre les appareils Wi‑Fi. Aucune modification du pare‑feu Windows.
Essaie encore une fois, s’il te plaît. Peut-être que nous pourrons trouver à quel endroit ça coince.
Salutations de pilote
Hermann
Je vais tester ça plus tard. J’utilise Windows 11 avec la version Microsoft Store (pas Steam) pour cela. VFRnav est également à jour. Cependant, j’utilise pour 2020 et 2024 respectivement la bêta actuelle (SU16/SU3), bien que, pour le 2020 relativement stable, je considère les modifications de la bêta plutôt mineures et probablement non pertinentes. Cela pourrait néanmoins être un problème.
Dans MSFS2VFRnav, avec MSFS 2020 et 2024 j’avais les mêmes affichages incluant le passage à “Waiting Data…” et “Receiving Data”. À titre de test, j’avais autorisé dans le pare-feu Windows le processus pour tout le trafic entrant et sortant et j’ai cherché le trafic UDP avec Wireshark, mais lors de la dernière tentative je n’ai rien trouvé. Je vais en tout cas retester, même si, il me semble, j’avais déjà essayé les paramètres par défaut dans VFRnav.
Est-ce que msfs2vfrnav.exe envoie des paquets de diffusion (broadcast) pour les transmettre à VFRnav ? Dans ce cas je pourrais regarder de plus près, mais je vérifierai de toute façon encore après le travail…
Malheureusement, toujours pas de succès. msfs2vfrnav.exea l’air “correct” (Receiving Data!) et ouvre un port UDP (dernier : 0.0.0.0:64721), mais aucun trafic UDP ne semble transiter (vérifié avec Wireshark sur le même système). Le réseau est configuré comme réseau domestique, l’application VFRnav affiche avec et sans redémarrage de l’appli et de l’outil “CONNECTING…” au lieu de “CONNECTED”/“VERBUNDEN”.
La connexion TCP via NMEA sur l’IP locale fonctionne directement et le trafic devrait être routé sans problème par la FRITZ!Box ; au moins TCP et ICMP passent sans problème dans les deux sens.
L’observateur d’événements Windows ne signale rien d’anormal. J’ai envoyé des données de test GDL90 depuis le même ordinateur avec ra1fh/airtraffic à l’adresse IPv4 du téléphone sur le port 4000, et VFRnav a établi la connexion et a affiché immédiatement la position et les avions.
Mes premières hypothèses seraient surtout : les données des bêtas ont changé et ne sont pas traitées correctement (mais cela concernerait probablement plus d’outils), ou des problèmes avec les sockets. Peut-être que le broadcast ne fonctionne pas ? Ou qu’on essaie d’envoyer vers une adresse/réseau fixe ? Ici, un réseau 10.0.0.0/24 est configuré
Si je peux aider avec des tests, par exemple via une version avec des logs, dites-le-moi ; sinon je suis pour l’instant un peu désemparé.
Bonjour bspline,
Je ne pense pas que ce soit dû à la bêta de MSFS. Je pense que la diffusion ne fonctionne pas de façon fiable dans toutes les combinaisons réseau possibles et que les données restent coincées quelque part ou sont bloquées.
J’ai encore apporté quelques modifications. Version 1.1.0 disponible via le même lien ci‑dessus.
Merci de tester à nouveau
Super, avec la mise à jour ça fonctionne du premier coup. La connexion est déjà affichée avant le démarrage de MSFS. Si je ferme la fenêtre du programme, le processus se termine également.
L’intégration offre-t-elle déjà d’autres avantages ? L’intégration me semblerait assez complète si le trafic (optionnel) était transmis. En tout cas, je n’ai pas pu l’observer jusqu’à présent.
Du point de vue de l’UX, une brève indication sur la configuration appropriée dans VFRnav serait appréciable, et ce serait aussi sympa d’avoir la possibilité d’indiquer explicitement une adresse IP de destination.
Je vais certainement l’utiliser comme ça pour l’instant. 
Bonjour à tous,
La version 1.2 a maintenant activé le trafic à titre expérimental.
Ici aussi, vos retours sont les bienvenus 
Windows Defender a d’abord bloqué le fichier : https://www.virustotal.com/gui/file/c3a098dfd71d23c20b96d7fa5e910f0ed08fb5f9f1de0a20bf4e7d4f2f8107a9/detection Je suppose un faux positif, mais c’est un peu malheureux.
Le trafic a été affiché immédiatement :
Cela permet d’utiliser les fonctionnalités les plus intéressantes. Merci pour la mise à jour rapide ! Je vais en tout cas acheter la version complète à l’issue de la période d’essai.
La radio et le pilote automatique pourraient également être contrôlés, mais nécessiteraient probablement des protocoles séparés dans VFRnav. Ce sont deux fonctionnalités dont je n’ai pas besoin, mentionnées uniquement par souci d’exhaustivité.
J’ai aussi pu le tester ce week-end. Ça fonctionne du premier coup et est nettement plus stable que l’autre programme noir. Je devais toujours le redémarrer après un nouveau vol, maintenant tout fonctionne automatiquement. Le trafic fonctionne aussi
édit : mais je vole “encore” avec Flight Simulator 2020
Bonjour Hermann,
J’utilise VFRNav (dernière version) pour le vol réel et la simulation et j’essaie actuellement, avec msfs2vfrnav.exe (dernière version), de transmettre depuis mon PC Windows11 des données GPS de MSFS2020 vers ma tablette (Android Doogee T20mini, éventuellement aussi iPad).
Malheureusement, la connexion UDP subit régulièrement des coupures, bien que les paquets soient correctement envoyés depuis le PC.
Cela a pour effet qu’à intervalles rapprochés, la source bascule sans cesse entre le signal GPS de la tablette et les données UDP. (voir image)
Détails :
Les paquets de MSFS sont actuellement envoyés en broadcast à l’adresse .255 du sous-réseau.
Wireshark montre que les paquets sont régulièrement 1× par seconde correctement envoyés sur le réseau.
Sur les tablettes, il y a des coupures de connexion sporadiques, en particulier sur l’appareil Android.
L’iPad présente des coupures similaires lors du broadcast.
Ceci est aussi observable dans VFRNav sous «Statut : Source de données externe (Status Externe Datenquelle)»
Remarque : J’ai déjà essayé toutes les mesures suggérées sur les tablettes, par ex. désactiver l’optimisation de la batterie, autoriser l’activité en arrière-plan, garder le Wi‑Fi actif en veille, ajuster les options développeur, etc.
Dans le réseau domestique, je ne peux malheureusement plus rien optimiser.
Question / demande :
Y a-t-il un moyen pour que msfs2vfrnav.exe / VFRNav envoie directement en unicast vers une IP définie, au lieu d’utiliser uniquement le broadcast, ou pour que le basculement vers le signal GPS ne soit pas immédiat ?
En alternative : avez-vous d’autres conseils ou paramètres pour garantir une transmission broadcast stable sur le réseau domestique.
Merci beaucoup pour ton aide et cordialement
Uwe
Bonjour Uwe,
merci pour l’idée.
https://dl.flugbetrieb.com/v3/msfs2vfrnav/msfs2vfrnav.exe?1.3
Il est désormais possible d’entrer une adresse de destination unicast.
N’hésitez pas à tester - je me réjouis de votre retour.
Saluts de pilote et bon reste de dimanche
Hermann
Salut Hermann,
il y a clairement eu du changement après ta modification !
Le temps d’antenne était désormais presque 1h30 et il n’y a eu plus que trois interruptions.
Merci beaucoup pour l’excellente application et le support rapide!
Uwe
Salut Uwe,
As-tu trouvé le réglage correspondant et as-tu pu saisir une adresse IP ?
Ce serait intéressant de savoir pourquoi les coupures ont lieu… Là-dessus, je suis d’abord un peu dépassé… Avec une adresse IP fixe, ça ne devrait normalement pas arriver.
La question est bien sûr de savoir s’il s’agit d’une erreur dans le traitement des paquets et donc si le problème vient de VFRnav, ou si c’est réellement dû au réseau. 
Si tu reprends les vols, tu peux volontiers relancer Wireshark & Co pour voir si quelque chose ressort.
Sinon, je suis pour l’instant désemparé.
Salutations de pilote
Hermann
Salut Hermann,
Brève rétroaction : le deuxième test après la modification a été nettement meilleur.
Plus de 3 heures de temps d’antenne et pas la moindre interruption. (Avant, j’avais plusieurs coupures en moins d’une minute.) Le passage du broadcast au unicast a été la solution !
Merci beaucoup et meilleures salutations,
Uwe
Merci beaucoup pour la Rückmeldung ! Cela aide beaucoup et je suis ravi que la modification apporte une amélioration 
Je ne suis pas moi‑même actif dans la scène de simulation — je recommande volontiers VFRnav
Salutations de pilote et bon week‑end
Hermann
Bonjour
J’ai le même problème d’aller et venir entre la position GPS et la position du simulateur, dans ce cas XP12.3.0
Comment puis-je faire l’unicast pour Xplane, s’il vous plaît ?
Au fait - application absolument géniale