Learn how to enable X-Plane UDP data output, decode DATA packets, choose ports, use RREF or DREF, and fix missing or corrupt telemetry.
To use X-Plane’s UDP data output, enable the required rows under Settings > Data Output, tick their network output boxes, and set the receiver’s IP address and UDP port. Your application then listens for datagrams beginning with DATA\0 and decodes each indexed block as one integer followed by eight 32-bit floating-point values.
How do I enable UDP data output in X-Plane?
- Open Data Output. In X-Plane, open
Settings > Data Output. If the layout is unfamiliar, our guide to finding X-Plane’s Data Output controls shows where this panel sits. - Select the required data sets. Find each numbered row you need and tick its network-output box. The row number becomes the index carried in the UDP record, so record it alongside the row’s field meanings and units.
- Set the destination. Enter
127.0.0.1when the receiver runs on the same computer. For another computer, enter that machine’s LAN IPv4 address. Depending on the X-Plane version, these destination fields may be on the Data Output page or under Network settings. - Choose the receiver’s port. Configure X-Plane to send to the exact UDP port on which your application listens. Do not confuse this destination port with X-Plane’s own inbound or “receive on” port.
- Limit the output. Select only the rows you need and use a modest network rate if X-Plane provides a rate control. Excess rows increase processing and can create large, fragmented UDP datagrams.
X-Plane does not discover the receiving application automatically. A common mistake we see is entering 0.0.0.0 as the destination: that is a valid local bind address for the receiver, not an address to which X-Plane should send.
How should an X-Plane DATA packet be decoded?
An outgoing DATA datagram has a five-byte header followed by one or more fixed-size 36-byte records.
| Offset | Length | Contents |
|---|---|---|
| 0 | 4 bytes | ASCII header DATA |
| 4 | 1 byte | Protocol separator, normally a NUL byte |
| 5 onward | 36 bytes per record | One 32-bit integer index followed by eight 32-bit floats |
Decode each record as little-endian int32 + 8 × float32, with no structure padding. In Python’s struct notation, that is <i8f. After removing the five-byte header, a valid payload length should therefore be divisible by 36.
One datagram may contain several selected rows. Do not assume there is one row per packet, and do not identify a data set by its position in the datagram; use the integer index. Check the index and units against the Data Output list in the same X-Plane generation because data-set definitions should not be treated as universal across versions.
- Create the socket. In Python, use
socket.socket(socket.AF_INET, socket.SOCK_DGRAM). - Bind the receiver. Use
sock.bind(('0.0.0.0', LISTEN_PORT)), whereLISTEN_PORTexactly matches X-Plane’s configured destination port. - Validate each datagram. Receive with
packet, sender = sock.recvfrom(65535), verifypacket[:4] == b'DATA', then reject the packet if(len(packet) - 5) % 36is not zero. - Decode every record. Set
payload = packet[5:]and iterate in 36-byte steps. For each offset, useindex, *values = struct.unpack_from('<i8f', payload, offset). - Route values by index. Store a map from each selected index to its eight field names and units. Never assume every number is in SI units; X-Plane’s output includes a mixture of feet, knots, degrees and other units depending on the row.
UDP provides no acknowledgement, ordering or guaranteed delivery. Treat each record as a fresh telemetry sample, tolerate dropped or duplicated datagrams, and do not use packet arrival as a precise clock because the output rate can vary with simulator performance and settings.
Should I use DATA, RREF, DREF or a plugin?
Use DATA for the predefined grouped rows on X-Plane’s Data Output page; use another interface when you need individual datarefs or tighter integration.
| Interface | Choose it when | Main limitation |
|---|---|---|
DATA | You need standard groups such as position, speed or control data | Fields come in fixed groups of eight and depend on numbered data sets |
RREF | You need selected datarefs at requested update rates | The dataref must exist, and aircraft-specific datarefs may appear only after that aircraft loads |
DREF | You need to write a specific writable dataref | Read-only datarefs reject writes, while the simulator or aircraft logic may overwrite accepted values on the next frame |
| Plugin | You require in-process access, callbacks or deeper aircraft integration | It requires plugin development and deployment rather than a standalone UDP receiver |
If a plugin is the better fit, follow the correct X-Plane plugin folder structure and installation method; plugins belong under the appropriate Resources/plugins structure rather than in an aircraft or scenery folder.
X-Plane can accept supported DATA messages as input, but output and control are not interchangeable for every row. Send input to X-Plane’s configured inbound port, supply all eight float slots in each fixed record, and use the protocol’s documented ignore-value convention for fields you do not intend to alter. Zero-filling unused slots can reset controls or other values unexpectedly.
Why is X-Plane UDP data output not working?
Most X-Plane UDP failures come from a mismatched port, an incorrect destination address, an unticked network-output box or a receiver parsing the packet at the wrong offset.
- No packets arrive: confirm that network output is ticked for at least one Data Output row, verify the destination port, and allow inbound UDP through the receiving computer’s firewall.
- Local output works but LAN output does not: use the receiver’s actual LAN address in X-Plane. Bind the application to
0.0.0.0or the relevant local interface, and check that a VPN or router is not sending traffic elsewhere. - Values are nonsense: skip all five header bytes, decode fields as little-endian 32-bit values, and disable native structure padding.
- Only the first selected row appears: loop over every 36-byte record after the header rather than unpacking the datagram as a single record.
- Numbers look plausible but are wrong: verify the data-set index, field order and units against the running X-Plane version. Do not reuse an index map blindly from another major version.
- Packets arrive intermittently: reduce the number or rate of selected rows, keep logging off the receive thread, and design the application to tolerate normal UDP loss.
- Writes have no effect: make sure packets are going to X-Plane’s inbound port, not the telemetry destination port. The target may also be read-only or continuously replaced by the flight model or aircraft plugin.
Keep X-Plane UDP traffic on a trusted local machine or LAN. The protocol does not provide authentication or delivery guarantees and should not be exposed directly to an untrusted network.