Marine Firmware & Tools

Hardware + Software

Supporting firmware libraries, desktop utilities, and integration helpers for chartplotter testing, autopilot development, vessel telemetry, and navigation electronics workflows.

Marine Firmware & Tools is an umbrella for the embedded code, helper apps, and test harnesses that sit alongside RayVessel and RayNmeaSimulator. These pieces turn NMEA2000 / NMEA0183 data, custom HAT hardware, and lab fixtures into a repeatable development and validation environment.

The goal is simple: make it easier for marine electronics developers, integrators, and advanced hobbyists to wire up, test, and ship reliable systems without starting from scratch every time.

Publication varies by component. RayNetworkBridge v0.1.0 is publicly released below; other components remain subject to individual review.

What Is “Marine Firmware & Tools”?

Rather than a single monolithic application, this initiative covers a family of small, focused components:

  • Embedded firmware templates for Teensy, ESP32, and similar MCUs.
  • Helper libraries for NMEA2000 and NMEA0183 parsing, routing, and testing.
  • Desktop-side utilities (Qt / .NET) for logging, visualization, and scenario playback.
  • Configuration and calibration tools that pair with RayVessel and RayNmeaSimulator.

Many of these tools started life as “lab helpers” for Ray’s own boat and test bench, then evolved into reusable building blocks that others can adopt.

RayNetworkBridge v0.1.0

RayNetworkBridge v0.1.0 is an open-source Python TCP/IP-to-SocketCAN bridge for NMEA 2000 development and controlled bench testing. It supports compatible RN2K/1 clients, including RayNmeaSimulator, with authenticated transmission, configurable network access, and matching-source retrieval.

Open Source Public Engineering Reference — AS-IS AGPL-3.0-or-later

A small bridge for a configured test bench

Expose an existing Linux SocketCAN interface to compatible RN2K/1 TCP clients, including RayNmeaSimulator. The bridge transports Classic CAN frames; NMEA decoding and device identity remain the client's responsibility. Physical operation requires Linux with SocketCAN, Python 3.9+ and iproute2, plus suitable CAN hardware, drivers, wiring and termination.

No pip dependencies or compiled installer are required. Extract the complete source archive and follow its README; keep the source, documentation and tests together. The bridge does not configure CAN or install a managed service. CAN FD and NMEA 0183 are not implemented. A CAN-free virtual hub supports development tests without claiming physical interoperability.

Authentication and network access

Transmission and bounded service sessions require shared-key HMAC-SHA256 authorization using a fresh challenge. The shared key is not sent, but all key holders have the same transmit authority. RX is intentionally unauthenticated; binding and optional CIDR allowlists restrict who can reach the listener. Without a nonempty key, transmission and service authorization are disabled.

The default listener binds to loopback. The protocol provides no TLS, traffic encryption or server authentication. Keep it on loopback and use an SSH tunnel for untrusted paths; do not expose the raw listener directly to the Internet. With no allowlist, any client able to reach the listener can connect. Service PGN filtering is coarse and is not a safety boundary.

Matching source from the running deployment

The bridge greeting offers matching deployment source at no charge from the same listener, without a TX key but subject to the RX IP allowlist. The supplied retrieval helper verifies order, size and SHA-256 without extracting or executing the ZIP. A checksum does not authenticate the server. A modified deployment's source can differ from the public release; operators must retain the source offer and complete preferred source, including their changes.

Controlled bench testing only

Use an isolated, controlled test network. Generated data can appear genuine to connected equipment. Do not rely on this bridge or a connected simulator for real-world navigation, steering, collision avoidance, propulsion or alarms.

Sending requires explicit client authorization; reconnecting must not silently resume it. Stopping software cannot recall queued or transmitted CAN data and is not an emergency-stop system. Normal CAN reception is not electrically silent. Hardware, network isolation and safe configuration remain the operator's responsibility. Provided as a Public Engineering Reference — AS-IS, without warranty.

Use RF StateSide's Download action for the software entry when available; until that entry exists, it opens the Downloads index. Source and tests are AGPL-3.0-or-later; separately installed runtime dependencies retain their own licenses.

v0.1.0 release notes and verification (opens in a new tab)

Where This Fits in Your Workflow

Chartplotter & MFD Testing

  • Generate repeatable NMEA2000 / 0183 traffic patterns from the lab bench.
  • Inject simulated engine, tank, GPS, and weather data into OEM displays.
  • Validate alarm behavior, annunciators, and custom pages before going on the water.

Autopilot & Navigation Development

  • Pair firmware modules with RayNmeaSimulator local Vessel Movement to exercise route-following logic.
  • Record and replay tricky conditions for regression testing.
  • Prototype new control strategies without touching a live vessel.

Vessel Telemetry & IoT

  • Use firmware examples that bridge analog sensors, digital I/O, and NMEA buses.
  • Push normalized data into dashboards, loggers, or cloud backends.
  • Leverage the same patterns used in RayVessel for your own projects.

Bench & Factory Testing

  • Spin up self-contained test fixtures for production or repair benches.
  • Automate “go/no-go” checks for sensors, gateways, and bridge devices.
  • Standardize scripts so multiple technicians can repeat the same tests.

Who Is This For?

  • Marine electronics developers building bespoke systems for clients.
  • OEMs and integrators who need a repeatable lab for regression testing.
  • Advanced hobbyists who enjoy instrumenting their own vessels.
  • Anyone already using RayVessel or RayNmeaSimulator who wants deeper hooks into firmware and tooling.

Example Components on the Roadmap

  • NMEA Bridge Firmware – reference sketches that forward, filter, and log NMEA2000 / NMEA0183 traffic between buses and TCP/IP endpoints.
  • Sensor HAT Templates – firmware patterns for MacArthur HAT, Waveshare RS485/CAN boards, and custom Pi/MCU carrier designs.
  • Desktop Log Viewer – tools to visualize PGNs, sentences, and alarms over time, with export to CSV/JSON for deeper analysis.
  • Calibration & Configuration Utilities – helper apps for mapping analog inputs, scaling factors, and channel labels to real vessel systems.
  • Example Lab Setups – published wiring + firmware + config bundles for common “mini-lab” layouts (single engine, dual engine, nav + weather, etc.).

Not every item will become a standalone application—some will be shared as reference designs, GitHub examples, or lab notes for other builders.

Want to Shape Marine Firmware & Tools?

If you have a specific integration, lab setup, or test workflow in mind, Ray would love to hear about it. Early conversations help decide which firmware examples and utilities get packaged first.