Bridge Data Network Basics: NMEA 0183, NMEA 2000, and IP Gateways

This article applies to yachts where bridge, navigation, monitoring, AV, owner-dashboard, or shore-support systems exchange navigation data.

Applicability depends on the bridge equipment fitted, type approval, flag and class expectations, whether ECDIS or VDR feeds are involved, whether navigation data is exported outside the bridge, and whether the network touches radio, alert, conning, automation, OT, cloud, or guest-facing systems.

From a bridge technician's point of view, the hard part is rarely the name of the protocol. The hard part is proving which sensor owns the data, where it is converted, who is allowed to receive it, and whether the value on screen is fresh, correct, and safe to use.

Bridge data starts simple. A GNSS receiver sends position. A gyro sends heading. A depth sounder sends depth. AIS sends identity and target information. ECDIS, radar, conning displays, VDRs, alarm systems, and monitoring pages all want a copy.

The mess starts when a yacht grows around the original installation. A refit adds a new bridge display. The owner wants vessel position on a dashboard. AV wants AIS or chart-style data on a guest screen. Engineering wants machinery status on the bridge. A fleet portal wants a small data feed ashore. Nobody sets out to create a fragile network, but after several upgrades the bridge may have converters, serial splitters, NMEA 2000 bridges, Ethernet gateways, vendor boxes, and undocumented laptop connections.

When I troubleshoot this, I avoid starting with the display that looks wrong. I start with the data path:

• what is the original source,
• what protocol leaves that source,
• where the data is converted,
• whether the conversion is one-way or two-way,
• which systems are allowed to receive it,
• whether any system can send data back,
• where the evidence is recorded.

Until that path is clear, every fault call becomes guesswork.

NMEA 0183 is the older serial data standard that still appears all over yacht bridges. It is common for GNSS, AIS, heading, depth, wind, speed, and legacy instrument feeds.

The useful mental model is "one talker, one or more listeners." One device talks; other devices listen. That makes NMEA 0183 predictable, but it also means you need to be disciplined when splitting, combining, or converting data.

Common practical issues include:

• wrong baud rate,
• reversed pair or poor termination practice,
• too many listeners on one output,
• old converter left in the path,
• AIS data on the wrong speed,
• missing sentence type,
• duplicated sentences from two sources,
• poor isolation between devices,
• no label showing what the feed carries.

NMEA's own public page describes NMEA 0183 as a 4800-baud serial data bus for one-way transmission from a single talker to one or more listeners, and notes that NMEA 0183-HS uses 38.4K baud. On yachts, that speed difference matters. AIS data, for example, is often where a wrong serial setting first shows itself.

If the ECDIS says AIS is missing after a service visit, do not assume the AIS unit has failed. Check the gateway, baud rate, selected input port, sentence filter, and whether another device was added to the line.

NMEA 2000 is a CAN-based marine data network. It is common for sensors, displays, engine data, tank data, wind, depth, GNSS, and smaller bridge or monitoring integrations.

The practical attraction is that multiple devices can share data on one backbone. The practical risk is that people start treating it like a magic bus where anything can be plugged in anywhere.

For a technician, the first checks are physical:

• backbone layout,
• correct termination,
• power injection,
• voltage at the ends,
• drop cable lengths,
• connector condition,
• water ingress,
• certified or non-certified devices,
• recent additions.

Then check the data layer. Which device is sending heading? Which GNSS source is preferred? Is the same value coming from two places? Is a gateway translating only what is needed, or is it forwarding too much?

NMEA's public NMEA 2000 page describes the standard as CAN-based, multi-transmitter, multi-receiver, self-configuring, and without a central network controller. That is useful, but it does not remove the need for design control. A self-configuring network can still be badly installed, poorly documented, or full of conflicting sources.

Modern bridge systems increasingly move navigation data over Ethernet or through IP gateways. This may involve IEC 61162-450 bridge networks, manufacturer-specific bridge networks, serial-to-IP gateways, NMEA 2000-to-Ethernet gateways, VDR interfaces, or read-only exports to monitoring systems.

This is where the yacht must be careful. Ethernet does not make bridge data ordinary IT traffic. A network carrying GNSS, heading, AIS, radar, ECDIS, conning, VDR, or alert data is still safety-related infrastructure.

The gateway question is not only "does data pass?" The better questions are:

• Is the gateway approved or appropriate for the bridge use?
• Is the path read-only where it leaves the bridge?
• Does it filter data or forward everything?
• Can any downstream system write back?
• Is it on a segregated bridge network?
• Is remote support controlled and logged?
• Is the gateway included in the bridge interface matrix?

Owner dashboards and AV screens should normally receive secondary, read-only data. They should not create a route back into ECDIS, radar, AIS, GNSS, VDR, or bridge-alert systems.

Every critical value should have an owner. That does not mean a person only; it means a defined authoritative source.

For example:

• primary GNSS for position,
• selected heading source for radar and autopilot,
• depth source for display and recording,
• AIS transceiver for own-ship static and dynamic data,
• VDR input list for investigation evidence,
• bridge gateway for read-only external exports.

If two devices claim to provide the same value, the bridge team needs to know which one is actually selected. A duplicated heading feed can look harmless until radar overlay, autopilot behaviour, or conning display values disagree.

The interface matrix should show source, path, conversion point, destination, direction, and owner. Without that, the yacht depends on whoever remembers the last refit.

A bridge data loop happens when data is fed around a system and comes back as if it were new. Sometimes it creates obvious errors. Sometimes it creates subtle disagreement.

Watch for loops when:

• serial data is converted to IP and then back to serial,
• NMEA 2000 data is bridged into Ethernet and then returned,
• two gateways are installed for the same value,
• a monitoring system is allowed to transmit instead of only listen,
• a vendor laptop or temporary device is connected during service,
• old equipment remains connected after a refit.

Loops can create duplicated AIS targets, stale position values, wrong source selection, repeated alarms, or displays that update at different speeds. They also make incident evidence harder to trust because the recorded value may not be the original source.

When bridge data looks wrong, work from the source outward.

1. Confirm the source is powered and healthy.
2. Check whether the source value is correct at the source.
3. Confirm the physical connection and port.
4. Check protocol and speed.
5. Check converter or gateway settings.
6. Check whether data is filtered, renamed, or translated.
7. Check the receiving display or system.
8. Compare with an independent source.
9. Preserve screenshots and settings before changing anything.

This order prevents a common mistake: changing display settings when the real problem is upstream. It also helps when multiple vendors are involved. The bridge manufacturer, AIS provider, NMEA gateway supplier, AV integrator, and IT provider may each see only part of the path.

A 60m yacht adds an owner dashboard that shows position, speed, AIS target count, and wind. The dashboard works during handover, then starts showing stale speed and intermittent AIS after a marina stay.

The AV team says the dashboard app is fine. The bridge vendor says ECDIS is fine. The IT provider says the firewall is fine.

The ETO checks the path and finds the dashboard is reading from a serial-to-IP gateway installed during a previous refit, not from the current bridge data export. AIS data is being forwarded at the wrong serial speed through an old converter. Speed data is coming from a stale source that was never removed from the configuration.

The fix is not just replacing a converter. The yacht updates the interface matrix, removes the stale source, confirms AIS speed and filtering, makes the dashboard read-only, and records who owns the gateway configuration.

That is the point of bridge data documentation. It turns "the dashboard is wrong" into a traceable source-path-destination problem.

Use a small register for each bridge data feed or gateway. At minimum, capture:

• Download resource: Bridge Data Interface and Gateway Register. URL: /resources/bridge-data-interface-and-gateway-register/. Description: Printable register for bridge data sources, protocols, gateway direction, destinations, ownership, test evidence, and known limitations.