Platform · Bus
Every app reads from one place.
Every sensor on a boat speaks a different language. NMEA-2000 (Network + Multimedia Equipment Association) Protocol Data Units. Bluetooth binary. WiFi JSON. Vendor-specific formats across instruments from a dozen manufacturers.
The 32°N bus reads all of it, translates it into clean typed events — wind.tws 14 kn at 295°, battery.soc.house 87%, position.gps.primary 36°27'N — and serves those events to every app and agent on the hub. Apps subscribe to what they need. The bus handles the rest.
Why build it natively
Not a protocol bridge. A data layer.
The 32°N bus is not a protocol translator bolted onto an existing message broker. It is the data exchange layer I designed from the start to be the thing all the other layers depend on. The schema is open and versioned in the public repo.
Reads every protocol on the boat.
NMEA-2000, Bluetooth Low Energy, WiFi — the bus speaks them all so the apps do not have to. A new protocol joins through a typed adapter and every app gets the data without any changes on the app side.
Turns raw signals into typed events.
The wind sensor sends PGN 130306 bytes. The bus delivers
wind.tws: 14 kn at 295°
to subscribers. Apps ask for what they need, not how it was encoded on the wire.
Every app sees the same boat.
The chartplotter, the anchor watch, the AI assistant, the logbook — they all subscribe to the same bus topics. Cross-app integration is the default, not a heroic act of custom wiring.
Add a device — every app sees it.
Plug a tank sensor into the NMEA-2000 backbone. The bus picks it
up, translates the values, and every app that subscribes to
tank.*
now has the data. No app-by-app integration required.
The event shape
Typed. Versioned. Source-tagged. Timestamped.
Every event on the bus carries four required fields beyond the payload. These are the structural guarantees the bus makes to every subscriber — not optional, not advisory.
Topic examples
Real topics, real values.
Topics follow a hierarchy: category, device, instance. The schema for each topic is versioned and documented in the public repo. A handful of representative examples:
What this changes
N connections → 1 connection.
In a typical marine setup, each app that needs data from another app has to negotiate a direct connection. Five apps with data dependencies need up to ten direct connections, each one hand-wired, each one a different protocol.
With the bus, every app has one connection: to the bus. It subscribes to the topics it needs. When a new app joins or a new sensor is added, nothing is rewired. The bus is the integration layer by design — not an afterthought. That is how the passage planner can consume polars, weather, fuel level, and crew brief data without anyone wiring those four apps together. The AI assistant gets everything it needs to answer "is this a good window to leave?" without reading a screen or parsing a log file.
Cross-cutting observability
Every event is visible, queryable, replayable.
Because every data point on the boat flows through the bus, the bus gives you something you never had with a fragmented marine stack: a complete, queryable history of everything that happened.
Live stream
Every topic publishes in real time. Any subscriber — app, agent, or developer tool — sees events as they happen. Latency from NMEA-2000 to bus delivery is under 50 milliseconds on the hub.
History replay
Events are persisted to the local data store. Query any topic over any time window. The logbook, the AI's context, and the security audit log all draw from the same event history.
Source attribution
Every event carries its source tag — which physical device, which adapter, which protocol. When GPS accuracy degrades or a sensor starts reporting anomalous values, the source tag tells you exactly where to look.
Schema versioning
Every topic has a schema version. When the shape of an event changes, both the old and new schemas are supported during a migration window. Apps that have not updated yet keep working.
Cloud sync
The bus event stream replicates to the cloud layer when you have a connection. Your phone and tablet see live boat state via the same subscribe model — not a polling REST endpoint.
Agent triggers
OS-level agents subscribe directly to bus topics. The anchor watch
agent subscribes to
position.gps.*
and triggers on position drift. No polling loop required.
See the bus in action, or read the schema.
The demo shows live bus events flowing from simulated instruments to the chartplotter and cockpit display. The developer docs have the full schema reference, adapter guide, and the subscribe API.