[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fMeL6NEpu2LjaYHmzmkWfeCOaJsKogYzlxHiqFglLwyk":3,"$f__g4JYrlHmOg0i4Teaq8Qm143TKrTIWccjYptQjiklk":17,"shop-vat-rates":60},{"article":4},{"id":5,"slug":6,"title":7,"summary":8,"visibility":9,"isPublished":10,"categoryId":11,"categorySlug":12,"categoryName":13,"updatedAt":14,"bodyMd":15,"legacy":16,"createdAt":14},"c9717955-eee3-4027-b634-f1fd59364d8f","lx-nmea-sentences-for-developers","LX NMEA sentences: a reference for developers and integrators","Where the protocol runs, sentence anatomy and the checksum rule, the broadcast and request-response families with their command groups, a worked exchange, task declaration, and the NAVIA open platform for anyone building their own.","public",true,"92b87517-c814-4237-b180-19df9cb80b16","connectivity","Connectivity","2026-09-10T11:36:59.828Z","If you are writing software that talks to an LX navigation instrument — a logger front end, a glass panel of your own, a piece of test gear, a soaring app that wants real sensor data instead of a phone's guesses — this is the protocol you will be speaking. It is called **LX NMEA 2.0**, it is ASCII, it is comma-separated, and it will not take you an afternoon to learn.\n\nThis article is an orientation rather than a field-by-field reference. It tells you where the protocol runs, how a sentence is built, what the two sentence families are for, which command groups exist, and where the exhaustive document lives. The last section covers NAVIA, which does not use this protocol at all and is worth reading even if you never touch an Era.\n\n## Where the protocol runs\n\nThree outputs carry the selected sentences — the user port, the FLARM port and Bluetooth — and two of them are worth describing. The **user port** is an RS232 UART serial interface — 8 data bits, no parity, baud rate anywhere from 4800 to 115200, with `38400` the default on an Era, LX 10K or Colibri X. The **Bluetooth** interface, on instruments that have one, serves the identical stream once the instrument is put into `Bluetooth server` mode.\n\nWhich sentences the instrument emits is a set of tick boxes under `Setup › NMEA`, and for anything you are developing against you want all of `GPGGA`, `GPRMC`, `GPRMB`, `LXWPx`, `LXDT`, `LXBC` and `PFLAx`. Note that `LXDT` is the one enabling **input as well as output**. Without it your requests go nowhere and you will spend an hour blaming your checksum routine.\n\n## What else is on the wire\n\nYour parser will see more than LX sentences, because the instrument forwards standard traffic alongside its own:\n\n| Prefix | Source | Carries |\n|---|---|---|\n| `$GPGGA` | GNSS module | Fix information |\n| `$GPRMC` | GNSS module | Recommended minimum GPS data |\n| `$GPRMB` | Instrument | Recommended minimum navigation info |\n| `$PFLAx` | Connected FLARM | `PFLAU`, `PFLAA`, `PFLAC`, `PFLAE`, `PFLAL`, `PFLAQ` — see FLARM's own documentation |\n| `$LXWPx` | Instrument | `LXWP0` flight data, `LXWP1` device info, `LXWP2` basic and `LXWP3` detailed parameters |\n\nThe `LXWP` family belongs to the older **LX NMEA 1.0** protocol, which is still documented and still emitted; LX NMEA 2.0 is an extension of it rather than a replacement, so a robust parser handles both.\n\n## Sentence anatomy\n\nEvery sentence starts with `$`, names a data type, carries zero or more comma-separated parameters, and ends with `*`, a two-byte checksum in hex, then `\u003CCR>\u003CLF>` (`0x0D 0x0A`). Two data types exist.\n\n```\n$LXBC,\u003Csentence_code>,\u003Cparameter_1>,...,\u003Cparameter_n>*\u003CCRC>\u003CCR>\u003CLF>\n$LXDT,\u003Csentence_action>,\u003Csentence_code>,\u003Cparameter_1>,...,\u003Cparameter_n>*\u003CCRC>\u003CCR>\u003CLF>\n```\n\n`LXBC` is **broadcast** — the instrument talking without being asked. `LXDT` is **data transfer** — a request\u002Fresponse conversation. Parameters are typed but untagged — position is everything. An invalid or unconfigured value is sent as an **empty field**, not as a zero or a sentinel, so `$LXBC,AHRS,,,,,0.8,-0.3,-0.6*3e` is a perfectly valid sentence saying the attitude solution is not available but the accelerometers are.\n\n## The checksum\n\nEight-bit XOR of every byte between the `$` (excluded) and the `*` (excluded), transmitted as two ASCII hex characters:\n\n```c\nuint8_t byCRC = 0;\nfor(int32_t i=0; i\u003CiN; i++)\n{\n    byCRC ^= pString[i];\n}\n```\n\nThat is the whole algorithm. It is a XOR, not a hash, so collisions are ordinary rather than remarkable — `LXDT,GET,INFO` and `LXDT,ANS,OK` both come to `5c`. Do not use the checksum to identify a sentence.\n\n## `$LXBC`: the broadcasts\n\nFour broadcast sentences, each carrying a different slice of the aircraft's state.\n\n| Code | Carries | Interval |\n|---|---|---|\n| `AHRS` | Pitch, roll, yaw, slip, and G-force in three axes | Settable |\n| `SENS` | OAT, main and backup voltage, current and recommended flap, gear position, SC\u002Fvario mode | Settable |\n| `FAST` | IAS, TAS, altitude, vario, netto, fusion vario, SC\u002Fvario mode — up to 10 Hz | Settable, **off by default** |\n| `FUSION` | Fusion netto and smart vario, instant and average wind, solution confidence and status | Fixed at 2 s, not configurable |\n\nTwo traps live in that table. `FAST` is disabled by default and **its interval is not remembered across a power cycle**, so your software must enable it on every connection. `FUSION` requires a valid fusion licence, rides along with the `LXWP` block (so `LXWPx` output must be enabled), has no `GET` request at all, and leaves its value fields empty until the solution locks.\n\nIntervals are read with `GET,BC_INT` and written with `SET,BC_INT` as `\u003Ctype>,\u003Cinterval>` pairs — keywords `AHRS`, `SENS`, `FAST`, or `ALL` to set them together, as in `$LXDT,SET,BC_INT,AHRS,0.5,SENS,2,FAST,0.1*7e`. The value is seconds as a float, minimum `0.1`, and `0` disables the broadcast.\n\n## `$LXDT`: GET, SET and ANS\n\nThree actions, and the whole conversational model fits in one line each: **`GET`** — your device asks the instrument for data. **`SET`** — your device sends data to the instrument. **`ANS`** — the instrument answers, either way.\n\nThe instrument responds to everything. A `SET` it accepted returns `ANS,OK`; a `GET` returns the corresponding `ANS,\u003Ccode>`; anything it did not understand returns `ANS,ERROR`.\n\n### The command groups\n\n| Code | GET | SET | What it covers |\n|---|---|---|---|\n| `INFO` | Yes | — | Device name, serial, software and hardware version |\n| `TP`, `ZONE` | Yes | Yes | Task turnpoints and observation zones |\n| `GLIDER`, `PILOT` | Yes | Yes | Glider registration, competition ID, class; pilot name |\n| `TSK_PAR` | Yes | Yes | AAT time and finish altitude |\n| `MC_BAL` | Yes | Yes | MacCready, ballast, bugs, volume — also emitted automatically on change |\n| `SENS` | Yes | — | The sensor block, on demand rather than broadcast |\n| `SC_VAR` | Yes | Yes | Speed-command \u002F vario mode state |\n| `NAVIGATE` | Yes | Yes | Current destination: name, position, elevation, distance, bearing, and for airports the frequency and runway direction |\n| `RADIO` | Yes | Yes | Active and standby frequency, volume, squelch, VOX — emitted on any change |\n| `R_SWITCH`, `R_DUAL`, `R_SPACING` | — | Yes | Swap frequencies, dual watch, 25 \u002F 8.33 kHz spacing |\n| `FLIGHTS_NO`, `FLIGHT_INFO` | Yes | — | Logbook contents |\n| `EVENT` | — | Yes | Trigger a pilot event in the IGC log and on the CAN bus |\n| `ERROR`, `OK` | — | — | Response codes only |\n\nNote that `NAVIGATE` exposes the destination's frequency; the instrument's own `Send APT freq.` setting is what pushes it to the radio. If you are building anything that touches the radio, read [connecting a radio to an LX instrument](\u002Fkb\u002Farticle\u002Fconnecting-a-radio-to-an-lx-instrument) alongside this.\n\n## A worked exchange\n\nAsk the instrument what the radio is doing:\n\n```\nTX: $LXDT,GET,RADIO*03\u003CCR>\u003CLF>\nRX: $LXDT,ANS,RADIO,128.800,118.475,10,5,33*1c\u003CCR>\u003CLF>\n```\n\nThe request has no parameters, so the checksummed span is exactly `LXDT,GET,RADIO`; XOR its 14 bytes and you get `0x03`. The response reports active `128.800`, standby `118.475`, volume `10`, squelch `5`, VOX `33`, over a span checksumming to `0x1c`. Both verify against the algorithm above — worth doing once by hand, because it settles any doubt about which bytes you should be including.\n\n## Declaring a task\n\nTask declaration is not a single command. It is a sequence: each point via `SET,TP` (takeoff, start, turnpoints, finish, landing — indexed from zero), each observation zone via `SET,ZONE`, then `SET,TSK_PAR` for AAT time and finish altitude, then `SET,GLIDER` and `SET,PILOT` for the header. Every one gets its own `ANS,OK` before you send the next. The protocol document ends with a complete communication log of exactly this, for a task with takeoff, start, one turnpoint, finish and landing — copy its shape rather than guessing at it.\n\n## Errors, and the silence that means a bad checksum\n\nAn error response carries a human-readable description, which is more than most binary protocols manage:\n\n```\nRX: $LXDT,ANS,ERROR,Parameter count mismatch*02\u003CCR>\u003CLF>\n```\n\nThe failure that catches people out is the one with no sentence attached at all. If a request draws **no response whatsoever**, the cause is almost always an incorrect checksum: the instrument discards what it cannot verify rather than complaining about it. Silence is a failure mode here, not an idle link.\n\n| Symptom | Cause | Fix |\n|---|---|---|\n| No response at all to a valid-looking request | Incorrect checksum | XOR every byte between `$` and `*`, excluding both |\n| `SET,SC_VAR` ignored | SC mode not `Manual`, or SC switch not `Toggle` | Set `Setup › Vario\u002FSC › SC mode = Manual` and `Setup › Glider › SC switch = Toggle` |\n| `ANS,ERROR` to `GET,RADIO` | No radio connected, or radio disabled in settings | Check `Setup › NMEA › Radio` |\n| `FAST` broadcasts stop after a power cycle | The interval is not remembered | Re-send `SET,BC_INT` on every connection |\n| No `FUSION` sentence at all | `LXWPx` output off, or no fusion licence | Enable `LXWPx`; check the licence |\n| `FUSION` fields empty | Not locked — status low byte is not 3 | Check the status field before parsing the values |\n| Error from `GET,FLIGHTS_NO` | Logbook access is refused in flight | Expected behaviour — wait until the flight has ended |\n| `AHRS` pitch, roll, yaw and slip blank | Attitude solution invalid | Not a parse error; the G-force fields are still good |\n\n## NAVIA is a different animal\n\nNAVIA does not extend this protocol; it replaces the whole idea. The Core Pro was designed around an open data concept, and everything the system captures — AHRS telemetry, engine parameters, live traffic, GPS — is available over the local network through a **bidirectional WebSocket and REST API**.\n\nBidirectional is the interesting word. NAVIA does not only serve data, it **accepts** it: build a custom sensor or an unusual piece of hardware, push its telemetry into the API, and the Core Pro processes and routes it alongside its own. For people who want to build the hardware too, there is a dedicated development board for prototyping devices that talk natively to the ecosystem.\n\nAPI documentation, integration guides and sample code are public at `https:\u002F\u002Fgithub.com\u002FLXNavigation\u002Fnavia-open-platform`. The platform itself is described in the [NAVIA Core Pro documentation](\u002Fnavia\u002Fcore-pro).\n\n## Where to go next\n\n- The full field-by-field protocol document, with every parameter, data type and range, is a PDF in the [download centre](\u002Fdownloads).\n- Getting a device physically connected first: [connecting XCSoar, Oudie and other PDAs](\u002Fkb\u002Farticle\u002Fconnecting-xcsoar-oudie-and-pdas).\n- Background on what the numbers mean: [GNSS](\u002Facademy\u002Fgnss) and [the CAN bus](\u002Facademy\u002Fcan-bus).\n- Building something and stuck on a detail the document does not cover: [talk to us](\u002Fcontact).\n",null,{"categories":18,"articles":45,"search":59},[19,25,31,34,39],{"id":20,"slug":21,"name":22,"description":16,"sortOrder":23,"articleCount":24},"42232637-6088-4100-9314-0b4986098818","getting-started","Getting started",20,7,{"id":26,"slug":27,"name":28,"description":16,"sortOrder":29,"articleCount":30},"9d0897b6-42d0-4643-8ceb-e8a02ce4a854","navia","NAVIA",25,10,{"id":11,"slug":12,"name":13,"description":16,"sortOrder":32,"articleCount":33},30,3,{"id":35,"slug":36,"name":37,"description":16,"sortOrder":32,"articleCount":38},"db776f9a-4f67-42bf-94bc-171c93f10cea","service-repairs","Service & repairs",1,{"id":40,"slug":41,"name":42,"description":16,"sortOrder":43,"articleCount":44},"48e22b59-26c1-477f-b136-3d3728b6dc22","device-guides","Device guides",40,12,[46,52,58],{"id":47,"slug":48,"title":49,"summary":50,"visibility":9,"isPublished":10,"categoryId":11,"categorySlug":12,"categoryName":13,"updatedAt":51},"9984420d-34f3-4de1-80a2-94f35ddf5f2d","connecting-xcsoar-oudie-and-pdas","Connecting XCSoar, Oudie and other PDAs to Era, LX 10K and iris","Sending flights over WiFi, putting the instrument into Bluetooth server mode, pairing an Oudie or an Android phone, the NMEA sentences and baud rate to set, the wired user port, and configuring iris over CAN2WiFi.","2026-09-10T11:36:59.813Z",{"id":53,"slug":54,"title":55,"summary":56,"visibility":9,"isPublished":10,"categoryId":11,"categorySlug":12,"categoryName":13,"updatedAt":57},"e8d7615e-a71c-4599-b4fa-8055d06a5886","connecting-a-radio-to-an-lx-instrument","Connecting a radio to Era, LX 10K, Colibri X and NAVIA","What it means for a navigation display to control a radio, which radios are documented on which platform, wiring and menu setup, the audio and push-to-talk job that is separate from the data link, and what is documented about transponders.","2026-09-10T11:36:59.820Z",{"id":5,"slug":6,"title":7,"summary":8,"visibility":9,"isPublished":10,"categoryId":11,"categorySlug":12,"categoryName":13,"updatedAt":14},false,{"AT":23,"BE":61,"BG":23,"CY":62,"CZ":61,"DE":62,"DK":29,"EE":63,"ES":61,"FI":64,"FR":23,"GR":64,"HR":29,"HU":65,"IE":66,"IT":63,"LT":61,"LU":67,"LV":61,"MT":68,"NL":61,"PL":66,"PT":66,"RO":62,"SE":29,"SI":63,"SK":23},21,19,22,24,27,23,17,18]