How do I build Arduino PAPI lights for MSFS?

To build Arduino PAPI lights for Microsoft Flight Simulator, use the Arduino as a four-lamp USB controller and run the PAPI logic in a PC bridge. The bridge reads aircraft and runway data through SimConnect, calculates the red-and-white pattern, then sends the complete state to the board over serial.

Does “play way” mean PAPI lights?

No. “Play way” is not the aviation term for these lights; the four red-and-white glidepath units beside a runway are called a PAPI, short for Precision Approach Path Indicator and commonly pronounced “pappy”.

Four white lights mean the aircraft is high, two white and two red indicate the correct approach path, and four red mean it is well below the path. PAPI is a visual glidepath aid, not the same system as the runway’s approach-light array.

Can Microsoft Flight Simulator drive real PAPI lights directly?

The generic SimConnect interface does not expose the four rendered PAPI colours as a ready-made hardware output. A normal build therefore calculates the indication outside Microsoft Flight Simulator rather than trying to read the scenery lamps themselves.

The geometry method is the better model because a PAPI is tied to a physical point beside the runway, not to the aircraft’s ILS receiver. An ILS glide slope and PAPI may be close without producing identical indications.

This arrangement requires Microsoft Flight Simulator on a Windows PC with access to SimConnect and a serial device. An Xbox installation does not provide the normal local SimConnect-to-Arduino workflow.

Our implementation walkthrough for PAPI wiring, SimConnect-to-serial logic and calibration covers the same layers as one complete hardware project.

What parts do you need for Arduino PAPI lights?

A reliable build needs four independently controlled light boxes, suitable LED drivers and a stable USB connection; the Arduino itself does very little processing.

• Arduino Uno, Nano or similar board with enough outputs for the chosen lamp arrangement.
• Four three-lead red-and-white LEDs, or separate red and white LEDs in each box.
• One resistor per LED channel, selected for the supply voltage, LED forward voltage and safe operating current.
• Transistors, logic-level MOSFETs or a suitable driver board for high-brightness LEDs and lamp modules.
• A regulated 5 V or 12 V supply matching the lights, with enough current capacity for every channel that may be illuminated.
• USB cable, wiring, circuit board and connectors.
• Four partitioned housings with hoods or diffusers to prevent one colour bleeding into the neighbouring unit.

Ordinary indicator LEDs are adequate for a breadboard prototype. Brighter modules are easier to see in a cockpit shell, but they should have their own supply and drivers; an Arduino output pin is a control signal, not a power source.

Three-lead bi-colour LEDs are easier than two-lead types. A two-lead red-and-white LED changes colour by reversing polarity, so it requires an H-bridge or carefully controlled opposing outputs. With a three-lead common-anode or common-cathode part, each colour has a separate channel, although the output logic may need to be inverted.

How should the four PAPI boxes be wired?

Use one independently switched red channel and one white channel for each box, giving up to eight controlled outputs.

1. Label the physical order from the leftmost to the rightmost unit as seen on approach. Keep that order consistent in the firmware.
2. Fit a resistor to every colour channel. For simple low-current LEDs, calculate resistance from R = (supply voltage - LED forward voltage) / current and use the next suitable higher standard value.
3. Add a driver stage where required. High-power LEDs and 12 V modules must not be connected directly to GPIO pins.
4. Use a common ground between the Arduino and a conventional non-isolated external driver supply.
5. Prevent both colours illuminating together. Set a unit’s old channel off before enabling its new channel, and define safe output states during start-up.
6. Test all five patterns without MSFS: four white, three white, two white, one white and four red.
7. Adjust each colour separately. White LEDs often appear much brighter than red ones, so use resistor selection or PWM to balance them.

A strip containing eight exposed LEDs may prove the circuit, but four divided and hooded boxes produce a much clearer PAPI display.

How do you connect an Arduino to MSFS?

A PC bridge is the practical connection between SimConnect and the Arduino’s USB serial port.

1. Load simple lamp firmware that accepts complete, line-delimited commands such as PAPI,4, PAPI,2 and OFF. The number can represent how many units should be white.
2. Open the correct serial device from the bridge using the same baud rate and line ending expected by the firmware.
3. Allow for board reset. Many Arduino-class boards restart when the serial port opens, so wait until the firmware is ready before sending its first state.
4. Connect the bridge to SimConnect and read the aircraft position, altitude and any data required by the selected calculation method.
5. Select the arrival runway manually for the first version, or load its PAPI reference data from a configuration file.
6. Calculate and transmit the full state at a modest fixed rate, or whenever it changes with a regular heartbeat.
7. Add a timeout that blanks the lights if serial or simulator data stops, preventing a stale indication from remaining displayed.

Do not send separate toggle messages such as “lamp two off” and “lamp three on”. A full-state message is easier to inspect and cannot become permanently desynchronised after a lost command.

Why should the PAPI maths run on the PC?

Keeping the calculation on the PC makes runway selection, coordinate conversion, smoothing and diagnostics easier while leaving the Arduino firmware small and predictable.

It also separates faults cleanly. You can test the lamp controller with a serial terminal, test the bridge by logging its calculated states, and change the PAPI model without rewiring or reflashing the board.

What logic should an external PAPI use?

The correct model uses four staggered transition angles so the units change from white to red one at a time as the aircraft descends through the approach path.

For a geometry-based model, calculate the viewing angle with the same units and altitude datum throughout:

angle = atan2(aircraft altitude - PAPI elevation, horizontal distance to PAPI)

Compare that angle with four separately configured transition thresholds. Each unit is white above its threshold and red below it. Using one threshold for every unit is a common coding mistake: it produces only all-white and all-red states instead of the expected five-step sequence.

If the runway’s PAPI angle is known, configure that installation rather than assuming a universal value. Otherwise, a nominal 3° path is a sensible starting point, with four transition thresholds arranged around it. Add hysteresis around each boundary so small altitude changes do not make the indication chatter.

The left-to-right lamp mapping belongs in the Arduino firmware or bridge configuration. If the serial message sends only the number of white units, define the physical order once and do not silently reverse it when moving the PAPI to the other side of a model runway.

Do you need runway data for every airport?

Yes, if the geometry-based display must work accurately at every runway; a first build is far easier to validate against one manually configured approach.

For each runway end, the bridge needs the reference position, elevation, approach direction and ideally the actual PAPI position and target angle. A threshold coordinate is usable for a rough prototype, but it will not perfectly match a PAPI installed some distance along and beside the runway.

• One training runway: hard-code its geometry and use it as a repeatable test case.
• Several favourite runways: store each runway end in a small configuration file and select it manually.
• Automatic operation: add airport data and select by approach alignment, runway end and aircraft position rather than merely choosing the nearest runway.
• No runway database: use available vertical guidance as a training approximation and accept that it may disagree with the scenery PAPI.

Do not substitute the terrain elevation directly beneath the aircraft for runway elevation. Terrain rises and falls during the approach, which would move the calculated glidepath. Use a fixed elevation for the PAPI or runway reference point.

Automatic selection also needs a signed along-track distance. Without it, the bridge may continue displaying a plausible pattern after passing the PAPI, choose the reciprocal runway end, or jump to a parallel runway. Blank the display when the aircraft is behind the reference point, badly misaligned or outside the intended operating area.

How do you test and calibrate Arduino PAPI lights?

Test the electrical, serial and geometry layers separately before comparing the hardware with the PAPI rendered in MSFS.

1. Run a bench sequence and confirm that every unit can show red and white without cross-lighting or flicker.
2. Inspect the serial commands with MSFS disconnected, then use fixed test values in the bridge to generate all five indications.
3. Choose one familiar runway and create a repeatable straight-in arrival. You can set up the same runway and approach with the built-in flight planner for each calibration flight.
4. Check known points on the target path. A useful reference is target altitude = PAPI elevation + tan(target angle) × horizontal distance, with any aircraft-reference or eye-height correction applied consistently.
5. Test above, on and below the path at several distances. Do not calibrate only during the flare, where small position changes cause rapid angular changes.
6. Tune the four thresholds until two white and two red cover a stable, useful on-path band.
7. Add smoothing and hysteresis only after the underlying geometry is correct. Excessive smoothing makes the display lag during genuine corrections.
8. Set day and night brightness so the unit remains readable without becoming distracting.

The simulated scenery PAPI is a useful comparison, but it is not an infallible calibration source. Custom scenery, a generic 3° model, different PAPI siting and an aircraft altitude reference point can all create a small disagreement.

A detached drone camera can also change the on-screen view of an angle-dependent scenery light while the external bridge still follows the aircraft position. Return to a cockpit-relative view before comparing indications; our guide to controlling and resetting the MSFS drone camera explains the relevant camera controls.

Why are the PAPI colours wrong or flickering?

Most faults can be isolated by proving the lamps first, the serial protocol second and the simulator calculation last.

Is an Arduino display a real PAPI?

No. It is simulator display hardware that reproduces PAPI indications; it does not reproduce the precisely aimed optics, intensity control, surveying or certification of an airfield installation.

Use vertical-guidance logic when the aim is simple approach practice. Use runway geometry when matching a specific MSFS runway matters, then account for the PAPI’s actual position, elevation, angle and aircraft reference height. In either form, treat the result only as a home-simulator training aid, never as equipment for real-world navigation or airfield use.