Microsoft Flight Simulator-Integration

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.

Hello bspline,

Indeed, some time ago I was working on an improved or simpler solution for connecting MS Flight Simulator (on Windows) and VFRnav.

As you’ve already mentioned, the changes have been included in VFRnav since version 4.10.

Only

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.

Hi,
thanks for testing and the quick feedback :ok_hand:
Which system are you using MSFS on? Is that the Steam version?

I’ll test it again, but I’m once again stuck in the MSFS installation manager… :face_exhaling:

Happy flying
Hermann

Phew, the update went exceptionally quickly this time :grinning_face:

My setup:

  1. Start the Flight Simulator and MSFS2VFRnav. Open the world map. Choose a departure point. “Take off”

  1. As soon as it’s loaded, the display in MSFS2VFRnav switches from “Waiting for Data…” to “Receiving Data!”.

  1. In VFRnav, set the default options under “External Data Source” as follows:

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.

Happy flying
Hermann

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.

Hello bspline,

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.

Please feel free to test again :grinning_face:

1 Like

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.

I will definitely use it like this for now. :+1:

Hello everyone,

Version 1.2 now has traffic enabled on a trial basis.
Feel free to leave feedback here as well :waving_hand:

Windows Defender initially blocked the file: VirusTotal I suspect a false positive, but it’s a bit unfortunate.

The traffic was displayed immediately:


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.

edit: I’m ‘still’ flying with the 2020 flight sim

Hello Hermann,

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).

VFR_Nav_UDP

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.

Thanks very much for your help and best regards

Uwe

Hello Uwe,

thank you for the idea.

https://dl.flugbetrieb.com/v3/msfs2vfrnav/msfs2vfrnav.exe?1.3

It is now possible to enter a unicast destination address.

Please feel free to test it – I look forward to your feedback.

Pilot’s regards and enjoy the rest of your Sunday

Hermann

Hi Hermann,

There’s been a noticeable improvement after your change!

The airtime was almost 1h30 and there were only three dropouts.

SC_VFR_Nav

Many thanks for the great app and the speedy support!

Uwe

Hi Uwe,

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. :thinking:

When you’re flying again,

Hi Hermann,

Just a quick update: the second test run after the switch was much better.

VFR_Nav_UDP_unicast

Over 3 hours of airtime and not a single dropout. (Previously I had several within a minute.) Switching from broadcast to unicast was the solution!

Many thanks and best regards,

Uwe

Thank you very much for the feedback! That helps a lot and I’m pleased that the change brings improvement :clap:

I’m not active in the sim scene myself – happy to recommend VFRnav :grinning_face:

Pilot’s regards and have a great weekend

Hermann

Hello

I have the same problem of jumping back and forth between GPS position and the sim position, in this case XP12.3.0

How could I do the unicast for Xplane please?

Btw - absolutely great app