Skip to content

Home

Jump to bottom
magerbak edited this page Jul 8, 2026 · 5 revisions

Introduction

This wiki provides some documentation on how I incorporated this NMEA 2000 dashboard project into a 3D printed panel for my sailboat along with a battery monitor using an identical ESP32-S3 board in the same panel.

CAD files were generated using FreeCAD and printed using a Bambu Labs P1S using the generic PLA profile. Circuit diagrams were generated using Fritzing.

Last updated 7/7/2026. V1.1.0

Design

Motivation

When I purchased my sailboat it had a broken chartplotter at the nav station taking up space and an old VHF radio that was DSC capacble but not connected to the NMEA 2000 (N2K) bus so it did not display GPS position. I found myself wanting to know my position and basic instrument data when writing logbook entries or making VHF calls to other vessels, or just monitoring outside conditions when down below.

All my cockpit instruments were on the N2K bus, so I knew all the data I was interested in was available, I just needed a device at the nav station that could connect to the bus and display it.

Building my own solution meant that I could choose exactly what I wanted to display and gave me full control of how it was presented. It also meant I could adapt the design and add new features based on my experience over time.

Hardware Selection

The N2K bus is essentially a standard CAN bus operating at a fixed 250kbps rate with a dedicated set of message definitions for marine instruments. The N2K standard defines the core messages needed for interoperability between devices, and although this standard is not public, many of the message definitions have been reverse engineered.

To interface with the bus a device needs a CAN controller (message framing, checksums, collision detection, acknowledgements and retransmits) as well as a transceiver (converting between the CAN bus analog differential signals and the digital logic signals used by the CAN controller).

Keeping up with a busy N2K bus can be a challenge for older microcontrollers. Fortunately, most recent microcontrollers are more than adequate and several (such as the newer Espressif ESP32 CPUs and the Renasas RA4M1 used in the Arduino Uno-R4) have built-in CAN bus controllers that simplify external hardware requirements and facilitate efficient message buffering. Since I knew I needed a display, I narrowed my search for modules that packaged a microcontroller with built-in CAN support and an appropriately sized display.

Adafruit sells a cost-effective ESP32-S3 module with a built-in 1.8" TFT display which seemed like a reasonable platform for this design. The display is a little smaller than I would like, but the module has good documentation and development support and the Adafruit Feather form-factor supports a variety of plug-in accessory 'wings' for future expansion. Additionally, the ESP32-S3 itself has WiFi and Bluetooth LE built-in which allows for wireless integrations with networked devices or mobile apps in the future.

The only other hardware required is a CAN transceiver module. The transceiver used in this design does not incorporate electrical isolation. This means power for the transceiver and the microcontroller module can be provided directly from the N2K bus with a buck converter to step down the nominal 12V to the 5V expected by the ESP32-S3 on its USB-C connector which then passes through a 3.3V regulator. However, a consequence of using an unisolated design is that it is important to avoid connecting any other unisolated ground signals which would introduce the possibility of a ground loop.

A battery-powered laptop has a floating ground so it's ok to connect that to the USB-C connector for programming and debugging.

Mechanical Design

I had a roughly 5"x5" space in my nav station panel where the new dashboard could be mounted in place of the broken chartplotter. I planned to 3D print a panel mounted enclosure for my design with a connector on the back for a N2K spur cable.

As the project progressed, I expanded it to include a second ESP32-S3 module for monitoring my batteries. This module is electrically separate but shares the same enclosure and mechanical design.

An early prototype using a bulky automotive DC-DC converter:

PXL_20251112_212046210

One aspect of the design that proved challenging was figuring out how to cleanly present the display and buttons to the user while still being able to screw-mount the module to the enclosure and access the USB-C connector and GPIO pins on the other side of the module.

I built up a mounting platform to accommodate threaded inserts on the inside face of the enclosure with cutouts for the recessed display and buttons.

PXL_20260218_155105101

The recess required 3D printing captive button actuators to drive the buttons through the cutouts. The actuators have a finger pad that is super-glued on outside the enclosure. The actuators are narrow and more fragile than I would like but the cramped spacing of the buttons made it challenging to make them larger.

PXL_20260708_135247195

The user interface is driven by the three buttons to the left of the display. To the right of the display is a reset button which is left accessible through a pinhole.

The back of the enclosure has a circular cutout for mounting the N2K connector. This needed to clear the 1/2" plywood panel that the enclosure is mounted on with enough clearance from surrounding electronics and obstructions for the N2K spur cable to be connected. I chose a front-mounted connector since this allows it to be unscrewed and withdrawn inside the enclosure without disconnecting any internal wires when sliding the enclosure in and out of the panel.

The current enclosure design includes a snap-on lid at the back. This design has proved inadequate and a different snap design is needed to withstand the vibrations on a boat.

Final assembly with both modules, using smaller inline shrink-wrapped DC-DC converters:

PXL_20260503_231817814

Installation at the nav station:

PXL_20260512_180706282

NMEA 2000 Integration

Core N2K protocol support is provided by the NMEA2000 library. The ESP32-S3 required a custom NMEA2000 ESP32 companion library for interfacing with the on-board CAN controller.

Currently, the dashboard just monitors existing bus traffic and does not operate as a standalone device on the bus which means that it never transmits on the bus (and can enable silent mode if the transceiver supports it). One exception to this is if for testing you use it with a single other device sending N2K messages - in this case the dashboard needs to be able to transmit acknowledgements.

The NMEA2000 library simply expects to be called in a tight loop to process incoming messages. A switch statement can then select any messages of interest and extract the relevant data, converting it to appropriate units if necessary. Basic wind and boat data was straightforward to represent.

Some iteration was required to determine which messages (PGNs) were used since the standard has evolved over time and there is overlap between the payloads of some messages. Another challenge is that multiple devices may transmit the same type of information (for example, heading) and sometimes one device has invalid or incomplete data. Some experimentation may be required on your own boat.

For AIS targets, a list of active targets needs to be maintained and aged out. Additionally, the information from each target is received and updated incrementally via several messages.

For the true wind and AIS closest point of approach (CPA) calculations it was helpful to represent wind and boat velocities as vectors. Currently the CPA is updated whenever the local or target boat position is updated. This seems to work well enough but potentially its position could be interpolated based on last known course and speed.

Testing

For testing during development I used the NMEA2000 library's ListenerSender example application to record the bus traffic on my boat for several minutes and save it via USB to my laptop as Actisense binary files. I also wrote some of my own tools for inspecting and parsing these recorded files to learn how information is sent. Reversing this process at home, I was able to play the recorded files back to the same device and have it send each message onto a test N2K bus on my workbench where my dashboard device could be monitoring the traffic.

It would be helpful to have a tool for synthetically generating N2K traffic files. They exist commercially, but I haven't found a free one yet (especially for Linux).

CAD Files

Schematics

n2k_dashboard_schem

n2k_dashboard.fzz

Bill of Materials

Clone this wiki locally