How do I build Arduino PAPI lights for MSFS?

Build Arduino PAPI lights for Microsoft Flight Simulator by wiring four independently controlled red-and-white units to an Arduino, then using a Windows PC bridge to read SimConnect data, calculate the viewing angle to the selected runway’s PAPI, and send a complete four-lamp state over USB serial. MSFS does not provide that hardware output directly.

How the MSFS-to-Arduino system should work

The dependable design has three separate layers: Microsoft Flight Simulator supplies aircraft data, a PC application performs the PAPI calculation, and the Arduino controls the lamps.

PAPI means Precision Approach Path Indicator. Its colours depend on the viewing angle from the light units to the pilot’s eye, not simply on aircraft pitch, indicated altitude or the position of an ILS glide-slope pointer.

SimConnect does not provide the four rendered PAPI colours as a standard ready-made hardware variable. We recommend calculating them from geometry rather than attempting to read pixels from the screen.

This project applies to Microsoft Flight Simulator 2020 and 2024 on a Windows PC. A console-only Xbox or PlayStation installation cannot run the normal local SimConnect bridge or present an Arduino serial port to MSFS.

Can the Volanta plugin for MSFS drive Arduino PAPI lights?

No—the Volanta plugin for MSFS is a flight-tracking connector, not a standard Arduino or four-lamp PAPI interface.

If you searched for a Volanta plugin because you need simulator telemetry, use a purpose-built SimConnect-to-serial bridge instead. Volanta and that bridge can normally run alongside one another because SimConnect supports multiple client applications; only the bridge should open the Arduino’s serial port.

If flight tracking is your only aim, use Volanta’s own MSFS connector as intended. The Arduino sketch is uploaded to the board and the bridge runs as an external Windows application; neither part of this PAPI project belongs in the MSFS Community folder.

What parts do you need for Arduino PAPI lights?

You need four optically separated red-and-white units, eight controllable colour channels and a power arrangement suitable for the LEDs being used.

• Arduino Uno, Nano or compatible board: choose one with enough free GPIO pins after reserving any pins needed by its serial hardware.
• Four three-lead bi-colour LEDs: common-anode or common-cathode devices are compact and give each colour a separate connection.
• Separate red and white LEDs: these are larger but often easier to wire and diagnose.
• One resistor for every LED colour channel: red and white usually need different values because their forward voltages differ.
• Transistors, logic-level MOSFETs or an LED driver: required for bright modules or any load exceeding the board output rating.
• A regulated external supply: match it to the lamp voltage and size it for every channel that could be on simultaneously.
• USB cable, connectors and four hooded housings: physical dividers prevent colour bleed between units.

Two-lead bi-colour LEDs reverse colour when their polarity is reversed. They require an H-bridge or equivalent switching arrangement, so we would not choose them for a first build.

Ordinary indicator LEDs are adequate for a desk prototype. A cockpit shell generally needs brighter modules, controlled through drivers and powered separately from the Arduino. Our advice on planning home-cockpit power, USB connections and mounting also applies to this display.

How should the four PAPI units be wired?

Wire one red channel and one white channel for each unit, while ensuring that the Arduino never has to supply the lamp current directly.

1. Label the units in approach-view order from 1 to 4. Keep the same order in the wiring, firmware and PC configuration.
2. Fit an individual resistor to every colour channel. For a low-current LED, start from R = (supply voltage − LED forward voltage) / desired current and select a suitable higher standard value.
3. Add the driver stage between the Arduino and any high-current or higher-voltage lamp. GPIO pins are control outputs, not power supplies.
4. Join the grounds where appropriate. A conventional non-isolated driver needs a common ground between its supply and the Arduino.
5. Avoid supply back-feeding. Do not connect two regulated outputs together or feed an external lamp voltage into the Arduino’s USB power rail.
6. Define a safe start-up state so all channels remain off while the board resets or its pins are still inputs.
7. Switch the old colour off first before enabling the new colour in each unit. This prevents red and white glowing together during a change.
8. Balance red and white brightness with suitable resistor values or a driver capable of PWM control.

Common-anode LEDs normally use active-low control, while common-cathode LEDs normally use active-high control. Getting that polarity wrong is the usual reason every lamp appears reversed or glows during reset.

How do you connect an Arduino to MSFS through SimConnect?

A small Windows bridge application should connect to SimConnect, calculate one complete PAPI pattern and send it to the Arduino as a line-delimited serial command.

1. Write the lamp firmware first. It should accept four explicit colour states, such as PAPI,RRWW, plus an OFF command.
2. Bench-test the parser with a serial terminal before starting MSFS. Reject malformed commands rather than partially updating the display.
3. Create the PC bridge in a language that can use SimConnect and a serial port. Subscribe to aircraft latitude, longitude and a suitable geometric or true-altitude value.
4. Load the selected runway configuration, including the PAPI reference position, elevation, approach direction, transition angles and physical lamp order.
5. Open the correct serial device using matching settings. Many Arduino-class boards reset when the port opens, so wait for a ready indication or a short initialisation period.
6. Calculate and transmit a complete state whenever it changes, with a regular heartbeat. A few updates per second are enough for a visual approach aid.
7. Blank invalid indications when the aircraft is behind the PAPI, on the ground, badly misaligned, outside the configured range or supplying invalid position data.
8. Add a firmware timeout that turns every lamp off if commands stop. A frozen all-red or all-white indication is more misleading than a blank display.

Complete-state commands are safer than messages which toggle individual channels. If one toggle is lost, the bridge and hardware can remain out of synchronisation; the next complete-state message corrects the display automatically.

The Arduino firmware only needs to validate the message, turn both channels off for each unit, enable the requested colour and maintain the communications timeout. Runway selection, coordinate conversion, diagnostics and smoothing belong on the PC, where they are much easier to inspect.

How do you calculate the correct PAPI colours?

Calculate the vertical viewing angle from the PAPI optical reference point to an estimate of the pilot’s eye, then compare that angle with four separately configured transition thresholds.

Our explanation of how to interpret all five PAPI colour indications covers their practical use during an approach.

For the geometry calculation, use:

angle = atan2(eye altitude − PAPI elevation, horizontal ground distance to PAPI)

Both heights must use the same datum and units. Do not combine indicated barometric altitude with a geometric runway elevation, and do not use the changing terrain elevation beneath the aircraft as the runway reference.

The aircraft-position altitude supplied by the simulator may refer to the model datum rather than the pilot’s eye. Add a per-aircraft eye-height correction if accuracy matters. This becomes particularly noticeable close to the runway, where a small vertical offset causes a larger angular difference.

Each of the four optical units needs a different transition angle. A mistake we see repeatedly is assigning one target angle to every unit, which creates only all-white and all-red indications. Four staggered thresholds produce the intermediate 3/1, 2/2 and 1/3 patterns.

Use the runway’s published or configured PAPI angle where available. A nominal 3° path is a reasonable prototype starting point, not a universal setting. Add a small hysteresis band around each transition so rounding and minor position changes do not make the lamps chatter.

What runway data does the bridge need?

An accurate geometry-based display needs data for each runway end rather than one record for the entire airport.

• PAPI latitude, longitude and optical elevation, or the best available approximation.
• Inbound runway direction for calculating signed along-track distance and detecting the reciprocal end.
• Four transition angles arranged around the installation’s target path.
• Lamp order and PAPI side so the red-and-white sequence matches the physical display.
• Operating gates for maximum distance, lateral displacement and heading misalignment.

A runway threshold coordinate and elevation are acceptable for an early prototype, but the result will not exactly match a PAPI positioned beside and some distance beyond the threshold. Published airport information may provide the visual slope and threshold-crossing details without giving the exact optical coordinates; our guide to finding and reading approach charts in MSFS explains the chart side of that research.

Start with one manually selected training runway. Automatic selection must distinguish parallel runways and reciprocal ends, reject an aircraft that has passed the reference point and avoid switching runways merely because another threshold becomes marginally closer.

How do you test and calibrate the finished display?

Test the electrical, serial and geometric layers separately before trying to match the PAPI rendered by MSFS.

1. Run a firmware-only sequence through all-red, 1/3, 2/2, 3/1, all-white and off. Verify every unit individually.
2. Send manual serial commands and check that a malformed or interrupted line cannot leave half of an old pattern displayed.
3. Feed synthetic positions into the bridge to prove all four angular transitions without flying an approach.
4. Select one known runway and fly or position the aircraft on a stable straight-in track.
5. Calculate reference points with eye altitude = PAPI elevation + tan(test angle) × ground distance.
6. Check several distances, not just the flare. Close to the PAPI, tiny position changes produce rapid angular changes and make poor calibration difficult to diagnose.
7. Apply the eye-height correction before changing transition angles. Otherwise, one aircraft may appear correct while another does not.
8. Add hysteresis and light smoothing only after the geometry is right. Excessive smoothing creates visible lag during a genuine path correction.

Do not calibrate the hardware against the ILS glide-slope pointer. The ILS transmitter and PAPI are separate installations and can have different reference points, angles and threshold-crossing characteristics.

The scenery PAPI is a useful comparison, but custom scenery or generic airport data may not reproduce the real installation exactly. Compare it from the normal cockpit view: an external drone camera can change the rendered PAPI colour while your bridge still uses the aircraft’s configured eye position.

Why are the Arduino PAPI colours wrong or flickering?

Most faults become obvious when you identify whether they begin in the lamps, serial protocol, runway selection or angle calculation.

USB port changes and duplicate device assignments are common once a cockpit gains several controllers. Our guidance on avoiding USB and control-profile conflicts with simulator hardware can help keep the Arduino connection predictable.

Is an Arduino display equivalent to a real PAPI?

No. It reproduces the five visual indications for a home simulator but not the surveyed position, precisely aimed optics, intensity control, monitoring or certification of an airfield installation.

Use runway geometry when you want to model a specific MSFS approach and vertical-guidance logic only when a simpler training approximation is sufficient. In both cases, treat the result as simulator hardware rather than equipment suitable for real-world navigation or airfield use.