Navico / Simrad alarms and commands over NMEA 2000

This note explains how alarms and the broader event/command channel work on a Navico-family network — Simrad, B&G and Lowrance displays, autopilot controllers and instruments. It is based on observing real bus traffic while raising/clearing alarms, running race and trip timers, driving an autopilot, and triggering a man-overboard, and is meant to help interpret the decoded PGNs in canboat.

It is not part of the NMEA 2000 standard alert mechanism (PGNs 126983/126984/ 126985). Navico devices use their own proprietary PGNs, disambiguated by the manufacturer code in the first two data bytes (Simrad 1857, Navico 275).

A note on "alarm" vs "alert". The NMEA 2000 standard and Navico's newer Ethernet/MQTT generation (Neon — the SRX/SR displays) call these alerts. The older generation that emits the proprietary PGNs documented here (Triton, the AP controllers, the NOS displays) calls them alarms. canboat follows the emitting devices and uses "alarm" for these proprietary Simnet/Navico PGNs and their fields, reserving "alert" for the standard NMEA alert PGNs.

PGN 130850 — the Simnet command channel

PGN 130850 is a single Simrad-proprietary message that carries all of these event/command families — alarms, race/trip timers, autopilot commands, MOB and more. Despite canboat historically modelling it as several differently-shaped variants, every 130850 frame on the wire uses one fixed 12-byte layout:

There is no "proprietary id" in 130850, and the address does not move between byte positions — earlier canboat variants that placed Address at byte 3, or matched byte 4 as a "proprietary id", were mis-framed and produced wrong decodes for anything outside the default group.

Byte 5 — the command type (SIMNET_EVENT_TYPE)

Byte 5 is the single discriminator. The values seen on the wire:

The autopilot command type and the alarm/event type are the same field — they are mutually-exclusive values of this one byte, not separate fields. Byte 4 is always the network/display group, independent of which family byte 5 selects.

Byte 4 — the network group

Byte 4 (SIMNET_DISPLAY_GROUP) scopes the command to a display/alarm group: 1 = Default, 2 = Group 1, etcetera (and 0xff = all groups, used for ship-wide events like MOB). A device assigned to "Group 2" emits and reacts to byte 4 = 3; a listener that assumes byte 4 = 1 will silently miss those frames.

The alarm families

A single alarm shows up on the wire through up to three cooperating PGNs, each with a distinct job, all tied together by the same small alarm id:

Thresholds — PGN 130845 (Simnet: Key Value)

Alarm limits are published as key/value pairs keyed by SIMNET_KEY_VALUE. Each display group broadcasts the current limit for every configured alarm. For example the "True wind low" limit (key 516) is a SPEED_UFIX16_CM value:

Simnet: Key Value  Key=516 "True wind low"  Value=12.86   (= 25.0 kn)

Changing the limit on one device re-broadcasts the key with the new value, and the other devices (including autopilot controllers) pick it up — which is why a threshold edited on one display immediately appears on another. Related limit keys live next to each other in the lookup, e.g. key 517 "Low boat speed".

Display unit preferences — PGN 130845 (Simnet: Key Value)

The same Key Value channel also carries the unit-of-measure preference for each quantity a display can show (Distance, Speed, Wind speed, Depth, Temperature, Volume, Pressure, Barometric pressure, Heading reference). Each quantity is its own key, but all of them share command group 20 (the low byte of the composite key), e.g.:

Simnet: Key Value  Display Group=Group 1  Key=5127 "Distance unit"  Value=Kilometers

Confirmed live against a Triton head (source 48) by starting a capture filtered to 130845 from that source and cycling every option in its Units menu, one at a time, correlating each Set frame with the button just pressed. Findings:

• Like the alarm thresholds above, a unit change is broadcast per Display Group — switching the head to a different group (e.g. "Group 2") and changing a unit there produces a Set frame tagged with that group, using the same key and the same value encoding, so unit preferences are independent per display group rather than a single global setting.
• Distance (key 5127) always broadcasts together with a second key (5174, "Distance unit (companion)") that was only ever observed at value 0; its purpose is unconfirmed.
• Distance has a second, short-range unit (key 36871, "Distance unit (small)") for readouts like depth/anchor/waypoint proximity, distinct from the main Distance unit.
• Pressure (key 5163) and Barometric pressure (key 5164) are separate keys — the Triton menu has one setting for general/engine pressure and another for barometric pressure — and only some of their enum values were observed during the capture (see SIMNET_PRESSURE_UNIT / SIMNET_BARO_PRESSURE_UNIT in lookup-generated-data.h), so gaps remain (e.g. mbar/hPa/mmHg/atm variants not yet captured for the general Pressure key). See #729.

Instrument damping — PGN 130845 (Simnet: Key Value)

The same channel also carries damping (averaging time) for individual instrument readouts: Heading, Apparent wind speed, True wind speed, Boat speed, SOG, COG, Heel angle, Trim angle, Tide. All of these share command group 5, and unlike the unit preferences above they are broadcast with Display Group = Default regardless of which display group is active:

Simnet: Key Value  Display Group=Default  Key=1280 "Heading damping"  Value=00:00:09

Confirmed live against a Triton head (source 48) the same way as the unit preferences — cycling each damping setting and correlating the Set frame with the value just chosen.

• The raw value is the displayed number of seconds scaled by a per-quantity factor that doesn't reduce to a round SI resolution: most quantities use ×11 (1/11 s ≈ 90.9 ms resolution), but True wind speed damping uses ×111 (1/111 s ≈ 9.0 ms) — why that one differs is unconfirmed. Modelled as two new field types, DURATION_UFIX16_1_11S and DURATION_UFIX16_1_111S.
• Most quantities are limited to whole seconds 0–9 (raw 0–99), the same 0–99 raw-range convention already seen in SIMNET_BACKLIGHT_LEVEL. Tide damping is the exception, with a wider enum: Off, 15s, 30s, 45s, 1/2/3/4 min (raw 0–2640).
• **True wind direction damping is the one exception — it does not use the 130845 Key Value channel at all. It rides PGN 130822, Command 3 "Navico: Configuration Set" (formerly documented as "Bulk Report 3"), Section 10, Item 1, as an object with Source Setting Id 24 (0x18) — the same {00, SSI, 00 00 00, token, valueLen, value} object shape already documented for the "Measured sources" objects in #727 (SSI 17–22), just a higher SSI in the same Section 10 space. Unlike the other damping keys it is not scaled** — the value byte is the literal number of seconds (0 = Off, 1 = 1s, 9 = 9s). Found by diffing a live capture of all traffic from the Triton before and after the change, since it doesn't stand out in a 130845-only filter.

This also means "Bulk Report 3" was a misnomer for at least this traffic: the frame we captured is a single small per-object update (Item = 1), change-driven — sent only when the value changes, unlike Source Report (Command 1) which continually re-broadcasts its whole table — not a bulk/multi-item transfer. An earlier capture in this same session had already logged this exact SSI 24 update (during unrelated background traffic) and it was misread as unrelated "Measured sources" noise before the correlation was made. A companion Item = 0 record fires alongside each change with a different, not-yet-understood 10-byte layout (doesn't match the SSI/token/value shape) — possibly a token/sequence header rather than a value.

See #730 (and #727 for the shared Section 10 SSI/token/value wire shape).

The lifecycle command — PGN 130850 (Simnet: Alarm)

When byte 5 = 255 (Alarm), byte 6 carries the lifecycle command (SIMNET_ALARM_COMMAND), and bytes 8–9 carry the alarm id:

When an alarm fires, the participating devices broadcast Activate for that id (several devices within a second or two). User actions then broadcast Acknowledge / Silence, and the clear broadcasts Deactivate. So a single alarm id is seen cycling Activate → … → Deactivate. Because these are broadcast commands, acknowledging an alarm on one display clears it on the others — that is the network mechanism behind cross-device acknowledge.

The alarm record — PGN 130825 (Navico: Alarm)

The alarm status is a small fixed record:

In practice 130825 mainly re-announces Active while the condition holds — it is the state view of the alarm. The actual lifecycle (acknowledge, silence, clear) is driven by the 130850 commands above, not by 130825 state changes, so a listener watching only 130825 sees it stay Active even after an acknowledge. Watch 130850 for the transitions and 130825 for the steady-state severity. The companion PGN 130856 carries the same id with the human-readable text.

Timers — PGN 130850, byte 5 = 23

Race and trip timers ride the same 130850 with byte 5 = 23 (Timer); byte 6 is the timer event (SIMNET_TIMER_EVENT):

The trip enable/disable commands carry the trip index in the parameter bytes, and a trip started on one display is picked up network-wide (the distance/time/average fields then appear on other displays). A partial reset of a single field on a display does not go on the wire — only the enable/disable and full-reset commands are broadcast.

Man overboard — PGN 130850 + 127233

A man-overboard is an alarm-class event (byte 5 = 255) with byte 6 = 107 MOB Activated / 108 MOB Cancelled, broadcast to all groups (byte 4 = 0xff, no alarm id). Unlike depth/wind alarms — which burst from several devices — the MOB is emitted only by the originating display and is not re-broadcast by the other devices.

The MOB position does not ride 130850; it rides the standard NMEA 2000 PGN 127233 (Man Overboard Notification), emitted by the same source at the same instant. So a complete MOB is a pair: 130850 carries the lifecycle (Activated/Cancelled) and 127233 carries the latitude/longitude. To follow a MOB in a capture, watch for the 130850 MOB Activated and read the position from the paired 127233.

Autopilot commands — PGN 130850, byte 5 = 10

Autopilot mode changes (Auto, Wind, Nav, No Drift), heading/course adjustments and the like ride 130850 with byte 5 = 10 (AP Command). These share the same 12-byte frame and the same byte-4 network group as the alarm and timer families.

Finding the autopilot

Every device broadcasts PGN 60928 (ISO Address Claim) at startup and after renumbering; the autopilot is the one claiming Device Function 150. Beware that DEVICE_FUNCTION is an indirect lookup — the function number only has meaning together with the Device Class. Function 150 is Autopilot only in class 40 (Steering and Control surfaces); in other classes the same 150 means Camera (class 20), Bridge (25), Function Controller (30) or Engine Controller (50). Matching on the function alone will latch onto the wrong device:

on PGN 60928:
    if Device Class == 40 and Device Function == 150:
        autopilot_address = message.src

The autopilot's address also appears in byte 2 of every 130851 reply, so watching the replies is an alternative to address-claim tracking.

The command set

Byte 6 carries the action, from SIMNET_AP_EVENTS. The commands canboat models as their own 130850 variants:

The mode commands carry no parameters — bytes 8–11 are 0xff. Only Change course uses the trailing bytes:

The angle is an unsigned magnitude; the sign lives in Direction. 10° to port is Direction = 2, Angle = 1745 (0x06d1), because 10 × π/180 = 0.1745 rad.

The autopilot acknowledges — PGN 130851

An addressed 130850 AP command is acknowledged: the autopilot echoes it back on PGN 130851 (Simnet: AP command Reply) byte-for-byte, exactly one reply per command, within roughly 20–70 ms, with byte 2 set to its own address. Commands sent to Address 0xff (broadcast) are not acknowledged.

So the reply is the direct success/failure signal, and is more reliable than inferring the outcome from state broadcasts. Watching only the state PGNs is still useful as a cross-check:

• PGN 65341 (Simnet: Autopilot Angle) — current mode (SIMNET_AP_MODE) and angle.
• PGN 127237 (Heading/Track Control) — the standard PGN, carrying the active heading-to-steer.

An accepted command does not mean the mode engaged: the autopilot refuses Heading/Wind/Nav when its sensor stack is incomplete (a Triton² logs "Reduced functionality" when a heading or wind source is missing), so confirm the mode actually changed rather than trusting the acknowledgement alone.

Frame length. Every 130850 AP command variant is modelled as the full 12 bytes, matching the fixed layout above. This was not always so: the mode commands carried a 24-bit trailing Reserved and so came to only 11, while the catch-all simnetApCommand carried two Reserved bytes too many and came to

1. Both were corrected against the captured frames.

Propagation — why an alarm sometimes stays local

An alarm is only network-wide if it is actually broadcast. The same alarm type can behave differently depending on where it is enabled:

• Raised through a display/instrument that broadcasts: every configured device reacts (audible/visual alarm) and the PGNs above appear on the bus.
• Enabled locally on a single controller without broadcasting: it alarms only on that device, and other displays stay silent — there is no traffic on the bus.

So when troubleshooting "device A beeps but device B does not", first check whether the alarm PGNs appear on the bus at all.

Correlating a capture

To follow an alarm in a capture:

1. Watch 130845 for the configured thresholds (and any live edits).
2. Follow the 130850 commands (Activate / Acknowledge / Silence / Deactivate) — note the alarm id (bytes 8–9), the command (byte 6) and the network group (byte 4).
3. Match that id in 130825 for the state and severity (and in 130856 for the alarm text).

The same alarm id ties the records together, and the manufacturer code in bytes 0–1 keeps the Simrad and Navico variants of these PGN numbers distinct from the unrelated uses by other manufacturers.