Ho appena provato VFRnav per la prima volta con Microsoft Flight Simulator (2024) collegandomi tramite FS2020NMEA.exe. Dopo aver dato un’occhiata al registro delle modifiche di VFRnav 4.10, mi chiedo se esista un’integrazione più approfondita?
Sarebbero ovviamente interessanti anche il traffico, la radio e il pilota automatico, ma anche così la mappa molto fluida e l’accesso rapido alle informazioni sono ottimi.
in effetti qualche tempo fa ho lavorato a una soluzione migliorata e più semplice per la connessione tra Microsoft Flight Simulator (su Windows) e VFRnav.
Le modifiche sono - come hai già menzionato - incluse in VFRnav dalla versione 4.10.
Per la connessione ora è necessario solamente questo strumento:
Grazie per l’informazione. Ho avviato lo strumento e sta ricevendo dati da MSFS 2024 (“Ricezione dati”). Viene inoltre aperta una porta UDP (casuale?).
Lo smartphone Android con VFRnav (ancora in versione di prova) è nella stessa rete, ma non riceve dati di posizione. Nelle impostazioni “Dispositivi di terze parti” era impostato TCP con l’indirizzo del computer e la porta 10110 (ancora per FS2020NMEA.exe). Anche con la porta 2000 o passando a UDP (porta 4000?) non si vede nulla e non viene stabilita alcuna connessione. Permettere manualmente le connessioni in entrata e in uscita tramite il Firewall di Windows (11) non ha cambiato nulla.
È necessario apportare impostazioni in VFRnav? Come avviene la comunicazione?
Un secondo problema è che la chiusura della finestra non termina il programma. Ho dovuto poi chiudere manualmente i processi nella Gestione attività.
Anche in MSFS 2020. Lo strumento rileva la connessione e anche l’avvio del volo, ma sembra non esserci una connessione a VFRnav. Non ho neanche notato pacchetti broadcast o simili.
Avviare il Flight Simulator e MSFS2VFRnav. Aprire la mappa del mondo. Selezionare il punto di partenza. “Decolla”
Non appena caricato, l’indicazione in MSFS2VFRnav passa da “Waiting for Data…” a “Receiving Data!”.
In VFRnav impostare le impostazioni predefinite sotto “Sorgente dati esterna” come segue:
Sia il PC che lo smartphone sono nella stessa rete Wi‑Fi. Nel router è impostato che i dispositivi Wi‑Fi possano comunicare tra loro. Nessuna modifica al firewall di Windows.
Prova ancora, per favore. Forse riusciamo a capire in quale punto si inceppa.
Lo testerò più tardi. Uso Windows 11 con la versione Microsoft Store (non Steam) per questo. VFRnav è anch’esso aggiornato. Tuttavia uso per il 2020 e il 2024 ciascuno la beta corrente (SU16/SU3), mentre per il 2020 relativamente stabile considero le modifiche nella beta piuttosto minime e probabilmente non rilevanti. Potrebbe comunque essere un problema.
In MSFS2VFRnav avevo con MSFS 2020 e 2024 le stesse visualizzazioni, incluso il passaggio a “Waiting Data…” e “Receiving Data”. A scopo di prova nel firewall di Windows ho consentito al processo tutto in entrata e in uscita e ho cercato traffico UDP con WireShark, ma nell’ultimo tentativo non sono riuscito a trovare nulla. Testerò comunque ancora, anche se in VFRnav credo di aver già provato le impostazioni predefinite.
msfs2vfrnav.exe invia pacchetti broadcast per recapitarli a VFRnav? Allora potrei controllare più accuratamente, ma comunque darò un’occhiata dopo il lavoro…
Purtroppo ancora nessun successo. msfs2vfrnav.exe sembra “corretto” (Receiving Data!) e apre una porta UDP (ultima 0.0.0.0:64721), ma non sembra che passi traffico UDP (verificato con Wireshark sullo stesso sistema). La rete è impostata come rete domestica. L’app VFRnav mostra, con o senza riavvii dell’app e dello strumento, “CONNECTING…” invece di “CONNECTED”/“VERBUNDEN”.
La connessione TCP via NMEA tramite l’IP locale funziona direttamente e il traffico dovrebbe essere inoltrato senza problemi attraverso la FRITZ!Box; almeno TCP e ICMP funzionano senza problemi in entrambe le direzioni.
Il Visualizzatore eventi di Windows non mostra anomalie. Ho inviato dati di test GDL90 dallo stesso computer con ra1fh/airtraffic all’indirizzo IPv4 del telefono sulla porta 4000 e VFRnav ha stabilito la connessione e ha mostrato immediatamente la posizione e gli aeromobili.
Le mie prime idee sarebbero soprattutto: i dati delle versioni beta sono cambiati e non vengono elaborati correttamente (ma probabilmente interesserebbe più strumenti), oppure problemi con i socket. Forse il broadcast non funziona? Oppure si tenta di inviare a un indirizzo/rete fissi? Qui è configurata una rete 10.0.0.0/24
Se posso aiutare con dei test, magari con una versione con log, fatemi sapere; altrimenti al momento sono un po’ perplesso.
Non credo che dipenda dalla beta di MSFS. Penso che la trasmissione (broadcasting) non funzioni in modo affidabile in tutte le possibili combinazioni di rete e che i dati rimangano bloccati o vengano bloccati da qualche parte.
Ho apportato ancora alcune modifiche. Versione 1.1.0 allo stesso link sopra.
Perfetto, con l’aggiornamento funziona subito. La connessione viene mostrata già prima dell’avvio di MSFS. Se chiudo la finestra del programma, anche il processo si chiude.
L’integrazione offre già altri vantaggi? Mi sembrerebbe abbastanza completa se venisse trasmesso anche il traffico (opzionale). Almeno finora non sono riuscito a osservarlo.
Dal punto di vista UX sarebbe utile un breve suggerimento sulla configurazione corretta in VFRnav e sarebbe carina anche la possibilità di specificare esplicitamente un IP di destinazione.
In questo modo sono utilizzabili le funzionalità più interessanti. Grazie per il rapido aggiornamento! Dopo la scadenza della versione di prova acquisterò sicuramente la versione completa.
Anche la radio e l’autopilota potrebbero essere controllati, ma probabilmente richiederebbero protocolli separati in VFRnav. Sono entrambe funzionalità di cui non ho bisogno, le menziono solo per completezza.
Sono riuscito a provarlo anche questo fine settimana. Funziona al primo colpo e molto più stabile rispetto all’altro programma nero. Quello dovevo riavviare sempre dopo ogni nuovo volo, ora tutto funziona automaticamente. Anche il traffico va
modifica: però volo “ancora” con il simulatore di volo 2020
sto usando VFRNav (ultima versione) per il volo reale e di simulazione e sto cercando di trasferire con msfs2vfrnav.exe (ultima versione) i dati GPS dal MSFS2020 al mio tablet (Android Doogee T20mini, in alternativa anche iPad) dal mio PC Windows11.
Purtroppo nella connessione UDP si verificano regolarmente interruzioni, anche se i pacchetti vengono inviati correttamente dal PC.
Questo ha come conseguenza che a brevi intervalli viene continuamente effettuato lo switch tra il segnale GPS del tablet e i dati UDP. (vedi immagine)
Dettagli:
I pacchetti dal MSFS vengono attualmente inviati come Broadcast all’indirizzo della sottorete .255.
Wireshark mostra che i pacchetti vengono regolarmente una volta al secondo inviati correttamente nella rete.
Sui tablet si verificano interruzioni sporadiche della connessione, in particolare sul dispositivo Android.
Anche l’iPad mostra interruzioni simili con il Broadcast.
Questo è osservabile anche in VFRNav in “Stato Sorgente dati esterna”
Nota: Ho già provato tutte le misure suggerite sui tablet, p. es. disattivare l’ottimizzazione della batteria, consentire l’attività in background, mantenere il Wi‑Fi attivo in standby, modificare le opzioni sviluppatore, ecc.
Nella rete domestica purtroppo non posso ottimizzare nulla ulteriormente.
Domanda / Richiesta:
Esiste un modo affinché msfs2vfrnav.exe / VFRNav inviino direttamente in Unicast a un IP definito, invece di usare solo il Broadcast, oppure che lo switch al segnale GPS non avvenga immediatamente?
In alternativa: ci sono altri suggerimenti o impostazioni per garantire una trasmissione Broadcast stabile nella rete domestica?
Grazie mille per il tuo supporto e cordiali saluti
Hai trovato l’impostazione e sei riuscito a inserire un indirizzo IP?
Sarebbe interessante sapere perché si verificano queste interruzioni… Anche io, però, sono per il momento perplesso… Soprattutto con un IP fisso questo non dovrebbe succedere.
La domanda è naturalmente se si tratta di un errore nell’elaborazione dei pacchetti e quindi il problema sia di VFRnav o se sia effettivamente dovuto alla rete.
Quando voli di nuovo, puoi volentieri far girare ancora una volta Wireshark & Co per vedere se salta fuori qualcosa.
Breve riscontro: la seconda prova dopo la modifica è stata decisamente migliore.
Oltre 3 ore di airtime e neanche un’interruzione. (Prima ne avevo diverse nell’arco di un minuto.) La modifica da broadcast a unicast è stata la soluzione!