CANboat and a reverse-engineered NMEA 2000 database you can actually query

The database was reverse engineered, and that shapes everything

CANboat provides NMEA 2000 and NMEA 0183 utilities, containing an NMEA 2000 PGN decoder that can read and write N2K messages. The repository description is explicit about its purpose: it is not meant as an end-user tool but as a discovery mechanism for delving into NMEA 2000 networks.

The reason it exists in this form is a licensing constraint. The NMEA 2000 database and implementation is copyrighted by the NMEA, the National Marine Electronics Association, and access is restricted to members and parties that pay for it. Those parties are not able to divulge the content of the database, which makes it impossible for open source developers to get access to it.

So the project reverse engineered the NMEA 2000 database by network observation and assembling data from public sources. And because it reverse engineers rather than licenses it, the project also covers the proprietary PGNs of Navico, B&G, Airmar, Garmin, Raymarine, Furuno, Fusion, Maretron and Victron among others.

That last point is the practical value. A boat's CAN bus carries a mix of standard NMEA 2000 messages and vendor-specific ones, and a tool that only understood the standard subset would be blind to half of what is on the wire. Covering the proprietary messages is what makes it usable for discovery on a real network.

The audience is a developer working on boat electronics, or an installer who needs to know what a vessel is talking about.

Two implementations, both tier 1

CANboat ships two implementations, and the README says both are tier 1, meaning supported, tested and released together, and that they are interchangeable for the jobs they both do.

The C tools are the originals. The analyzer and the gateway drivers are small, dependency-light, and build with nothing but make and a C compiler. The analyzer decodes NMEA 2000 into text or JSON. The gateway drivers cover the Actisense NGT-1 and W2K-1, the Digital Yacht iKonvert, Linux SocketCAN and the Maretron IPG100. There are also converters and helpers: candump2analyzer, replay, iptee, nmea0183-serial and analyzer-j1939.

The Rust binary is one executable with subcommands. canboat convert decodes a capture between any supported formats. canboat interface bridges a live gateway, with a long list of supported hardware: NGT-1, iKonvert, Maretron, Yacht Devices, W2K-1, PRO-NDC, SocketCAN, CANalyst-II and USB-CAN-A. canboat n2kd multiplexes an analyzer-JSON stream to TCP clients, and canboat server puts the whole device to analyzer to n2kd pipeline into one process. canboat tui is an interactive terminal browser for a live stream or a capture. canboat format-message builds a single frame from field values for any PGN, and canboat replay paces a capture at its original wall-clock rhythm.

That last pair is what turns the tool from a decoder into something you can test with. Building a frame from field values and pacing a recorded capture are both things you need to write a test or to reproduce a fault, and the fact that replay honours the original timing makes it usable for simulating a live bus.

The shims keep the old command names working

There is a small compatibility detail that tells you how the project handles its own history.

canboat install-shims drops symlinks so the subcommands answer to the old names, analyzer, n2kd, actisense-serial and the rest. And it never takes a name that another program already holds, so it is safe to run in a directory that has the C tools installed, and it reports what it left alone.

That is a careful piece of design. The alternative, which is what most projects do, is to break the old names and tell users to update their scripts. The shim approach means a machine with both the C tools and the Rust binary on the PATH keeps working, and the tool tells you exactly which names it did not claim rather than silently shadowing something.

The wider migration is documented too. The remaining C converters, the helper scripts in util/, which are PHP, perl and ksh, and the Python tooling will most likely move to Rust in time, and the C n2kd and n2kd_monitor already have, having been removed in v8.

So the direction of travel is clear: the Rust binary is becoming the implementation and the C programs are the compatibility layer. That matters for anyone planning to build on this, because the C tools are described as staying tier 1, but the effort is going into Rust.

The definitions are a public contract you can pin

The PGN definitions are not buried in the code. They are published in docs/ as canboat.json and canboat.xml, with the J1939 and Quick PCS ones next to them, and the README explicitly invites other projects to use them.

The guidance is to pin your copy to a release, because semantic versioning warns you of major, x.0.0, and minor, 0.x.0, changes to the definitions. That is an unusually explicit statement for a project that started as a set of personal tools, and it tells you two things: the definitions are treated as a versioned interface that other software depends on, and a change to them is a deliberate act rather than an accident.

The documentation set is thorough about how to consume them. doc/definitions.md covers using the XML and JSON definitions in your own project and how to write a decoder, and there is a sibling project, canboatjs, a pure JavaScript NMEA 2000 decoder and encoder, which is the clearest evidence that the definitions are meant to be portable across languages.

The Rust library used to live separately as canboat-rs, and was merged into this repository in v8 as the canboat crate, with its quick start and features in crates/canboat/README.md and the API reference on docs.rs.

The downstream table in the readme, a survey of other projects using the CANboat PGN definitions, exists precisely because the definitions are a dependency. The table is a snapshot taken from GitHub on 7 October 2026, with the note that the versions will drift, and it asks maintainers of dependent projects to open an issue to correct their entry or to be notified of new major and minor releases.

The database tool, and why the Rust build is opt-in

The repository layout is extensive, and two things stand out for anyone deciding how to build it.

The first is the keel directory, the database tool. The Cargo.toml comments are unusually explicit about why it is a workspace member: so that a cargo build at the repo root builds it too, and so the whole tree shares one lockfile and one target directory, and its dependency closure is guarded by tools/check-keel-deps.sh, because it must never gain the runtime's tree. The separation between the database tool and the runtime is enforced by a script rather than by convention.

The second is the Makefile, which states that the Cargo workspace at the repo root, covering crates/* and keel/, is deliberately opt-in and is not a dependency of all, compile or tests. A plain make of the C tools must never invoke cargo, so C-only contributors and packagers need no Rust toolchain, and Rust contributors just use cargo directly.

The comments explain a related trap. The Rust schema tables are generated from database/ by keel and committed, so a cargo build alone will happily compile against a stale table after a database edit, and the fix is to regenerate first. That is a real footgun for a project where the database is the product.

The Dockerfile is the simplest thing in the repository: it starts from ubuntu:26.04, installs build-essential, python3 and xsltproc tooling, and sets the entrypoint to make.

Where CANboat stops being the right tool

The limits are stated plainly in the documentation, and the first one is the licence.

The NMEA 2000 database and implementation are copyrighted by NMEA, and this project has reverse engineered the database rather than licensing it. For a developer building a diagnostic tool, a research project or an open source marine tool, that is a workable position. For a product that will be certified or sold into a production vessel, the absence of a licensed database is a problem you have to solve elsewhere, and the project is direct about the fact that it is a discovery mechanism rather than an end-user tool.

The second limit is scope. The suite analyses NMEA 2000, and the readme notes that this is currently the only CAN network version the suite can analyse. NMEA 0183 support exists but the emphasis is on N2K, and the tool is a network analyser rather than a full marine electronics stack. It decodes and it writes frames, but it does not drive instruments, and it does not know anything about the semantics of a particular vessel.

The third limit is the hardware. To use the programs on a live bus you need a supported CAN interface, either a marketed-as-such NMEA 2000 gateway or a plain CAN adapter, and doc/gateways.md lists the ones canboat drives. The gateway list is long, but it is a list of specific models, and a bus with something unusual on it may need a different approach.

On maintenance, the repository is not archived and the last push was on 2026-10-19, the same day as the v9.0.0 release, with v8.3.0 on 2026-09-25 and v8.2.1 on 2026-09-23. The licence is listed as a custom one that GitHub cannot classify, so read the LICENSE file rather than the badge before you ship anything.

Editorial conclusion

CANboat is a good fit for a marine electronics developer who needs to see what is actually on a boat's CAN bus, because the PGN database was reverse engineered by network observation and covers the proprietary messages of Navico, B&G, Garmin, Raymarine, Furuno, Fusion, Maretron and Victron, and because the Rust binary can both decode captures and write to a live gateway. It is a poor fit for a certified marine product, because the project is explicitly not meant as an end-user tool and the database is not licensed from NMEA. Before adopting, read the readme's table of projects that use the CANboat PGN definitions, decide whether you need the C programs or the Rust subcommands, and note that the definitions live in docs/ and should be pinned to a release since semantic versioning warns you of major and minor changes to them.

Frequently asked questions

Official sources

1. canboat/canboat on GitHub
2. Issues
3. README
4. Releases