I’ve just tested VFRnav for the first time with Microsoft Flight Simulator (2024) via a connection using FS2020NMEA.exe. After looking at the changelog for VFRnav 4.10, I’m wondering whether there is any further integration?
Of course, traffic, radio and autopilot would also be interesting, but even as it stands, the very smooth map and quick access to information are brilliant.
Thank you for the information. I have started the tool and it is receiving data from MSFS 2024 (“Receiving Data”). It also opens a (random?) UDP port.
The Android phone with VFRnav (still a test version) is on the same network but isn’t receiving any position data. In Third-Party Devices I had set TCP with the PC’s address and port 10110 (still for FS2020NMEA.exe). Even when using port 2000 or switching to UDP (port 4000?) nothing appears and no connection is established. Allowing inbound and outbound connections manually in the Windows (11) firewall did not change anything.
Do I need to configure anything in VFRnav? How does the communication work?
A second problem is that closing the window does not terminate the program. I had to manually kill the processes in the Task Manager afterwards.
Same in MSFS 2020. The tool recognises the connection and even the start of the flight, but there doesn’t appear to be any connection to VFRnav. I also haven’t noticed any broadcast packets or the like.
Both PC and phone are on the same Wi-Fi network. The router is configured to allow Wi-Fi devices to communicate with each other. No changes have been made to the Windows Firewall.
Please try it again. Maybe we can figure out where it’s getting stuck.
I’ll test that later. I’m using Windows 11 with the Microsoft Store version (not Steam) for this. VFRnav is also up to date. However, I’m running the current betas for both 2020 and 2024 (SU16/SU3), although for the relatively stable 2020 I consider the beta changes minor and probably not relevant. It could still be an issue.
In MSFS2VFRnav with MSFS 2020 and 2024 I had the same displays, including switching to “Waiting Data…” and “Receiving Data”. As a test, I allowed the process all inbound and outbound traffic in the Windows Firewall and used Wireshark to look for UDP traffic, but in my last attempt I couldn’t find anything. I’ll definitely test again, even though I believe I’ve already tried the default settings in VFRnav.
Does msfs2vfrnav.exe send broadcast packets to deliver them to VFRnav? Then I could look out for it more closely, but I’ll check again after work anyway…
Unfortunately, still no success. msfs2vfrnav.exe looks “correct” (Receiving Data!) and opens a UDP port (last 0.0.0.0:64721), but no UDP traffic appears to be passing (checked with Wireshark on the same system). The network is set as a home network, and the VFRnav app shows “CONNECTING…” instead of “CONNECTED”/“VERBUNDEN”, both with and without restarting the app and the tool.
The TCP connection via NMEA over the local IP works straight away and traffic should be forwarded by the FRITZ!Box without problems; at least TCP and ICMP work without issues in both directions.
The Windows Event Viewer shows no anomalies. I sent GDL90 test data from the same PC using ra1fh/airtraffic to the phone’s IPv4 address on port 4000 and VFRnav established the connection and immediately displayed the position and aircraft.
My initial thoughts are mainly: data from the betas have changed and aren’t being processed correctly (though this would likely affect more tools), or there are socket issues. Perhaps broadcast isn’t working? Or it’s trying to send to a fixed address/network? A 10.0.0.0/24 network is configured here.
If I can help with testing, perhaps via a version with logs, please let me know, otherwise I’m somewhat at a loss.
I don’t think it’s down to the MSFS beta. I believe that the broadcasting doesn’t run reliably across all possible network configurations, and the data gets stuck or blocked somewhere.
I’ve made a few more changes. Version 1.1.0 is available via the same link above.
Great, it works first time with the update. The connection is already shown before starting MSFS. If I close the program window, the process also terminates.
Does the integration offer any other benefits? The integration would seem quite complete to me if traffic could be transmitted (optionally). At least I haven’t observed that so far.
From a UX perspective, a brief pointer to the proper configuration in VFRnav would be nice, and also the ability to explicitly specify a target IP.
This makes the most interesting features usable. Thanks for the quick update! I will definitely purchase the full version once the trial expires.
Radio and autopilot could also be controlled, but would probably require separate protocols in VFRnav. These are both features I don’t need, just mentioned for completeness.
I was also able to test it over the weekend. It works on the first try and is significantly more stable than that other black programme. I had to restart that one after every new flight, but now everything works automatically. Traffic works too.
I’m using VFRNav (latest version) for real and simulated flying and I’m currently trying to transfer GPS data from MSFS2020 on my Windows 11 PC to my tablet (Android Doogee T20mini, alternatively also an iPad) using msfs2vfrnav.exe (latest version).
Unfortunately, the UDP connection regularly drops, even though the packets are being sent correctly from the PC.
As a result, the system keeps switching back and forth between the tablet’s GPS signal and the UDP data at short intervals (see image).
Details:
Packets from MSFS are currently sent as a broadcast to the subnet address .255.
Wireshark shows that the packets are correctly sent into the network once per second.
The tablets experience sporadic connection drops, especially on the Android device.
The iPad shows similar drops when using broadcast.
This can also be observed in VFRNav “External Data Source Status”
Note: I have already tried all the suggested measures on the tablets, e.g. disabled battery optimisation, allowed background activity, kept Wi-Fi on during standby, tweaked developer options, etc.
Unfortunately, I can’t optimise anything further in my home network.
Question / Request:
Is there a way for msfs2vfrnav.exe / VFRNav to send directly as unicast to a specified IP, instead of only using broadcast, or to prevent the switch to the GPS signal from occurring immediately?
Alternatively, are there any tips or settings to ensure stable broadcast transmission in a home network.
Did you find the setting for that and manage to enter an IP?
It would be interesting to know why these dropouts are happening in the first place… But I’m at a loss there for now… Especially with a static IP, that really shouldn’t happen.
The question, of course, is whether it’s an error in the packet processing and thus a problem with VFRnav or whether it’s actually network-related.