Aran Dokoupil: Created page with "The '''dashboard''' is the e-paper screen the pilot reads while sailing. It is mounted on the '''left side of the steering wheel''' in the cockpit, and shows speed, battery power, state of charge, temperatures and the clock. It measures nothing itself: it listens to the whole CAN bus and draws whatever the other nodes are saying. The dashboard showing live data == At a glance == {| class="wikit..."

2026-08-17T18:59:32Z

Created page with "The '''dashboard''' is the e-paper screen the pilot reads while sailing. It is mounted on the '''left side of the steering wheel''' in the cockpit, and shows speed, battery power, state of charge, temperatures and the clock. It measures nothing itself: it listens to the whole CAN bus and draws whatever the other nodes are saying. thumb|500px|The dashboard showing live data == At a glance == {| class="wikit..."

New page

The '''dashboard''' is the e-paper screen the pilot reads while sailing. It is mounted on the '''left side of the steering wheel''' in the cockpit, and shows speed, battery power, state of charge, temperatures and the clock. It measures nothing itself: it listens to the whole [[CAN-bus|CAN bus]] and draws whatever the other nodes are saying.

[[File:Dashboard-epaper-interface-with-data.jpeg|thumb|500px|The dashboard showing live data]]

== At a glance ==

{| class="wikitable"
|+ Dashboard summary
|-
! Property !! Value
|-
| Panel || Waveshare 5.79" e-paper, 792 × 272, black and white, SSD1683 controller
|-
| Location || Cockpit, left of the steering wheel
|-
| Controller board || STM32L471RGT6 — the '''same PCB''' as the [[Height sensors|height sensor controller]]
|-
| Bus || CAN 2.0A, 1 Mbit/s, 11-bit standard identifiers
|-
| Transmits || Nothing, except replies to bootloader queries on <code>0x038</code>
|-
| Update rate || At most once per second, and only when the picture actually changed
|-
| Application type || <code>0x03</code> — its address in the bootloader protocol
|-
| Firmware || Rust, <code>embassy</code>, binary <code>dashboard</code>
|-
| Firmware source || <code>firmware/</code> in the [https://github.com/Engineers-of-Innovation/eoi-can eoi-can] monorepo
|-
| Screen source || <code>draw-display/</code> in the same repo, shared with the simulator
|-
| Hardware source || Altium project <code>AKD-CAN_Interface</code> (Altium 365)
|-
| Field update || Over CAN, no debug probe needed
|}

== What is on the screen ==

The screen is a fixed layout — nothing moves, and a value that goes missing is replaced by dashes in the same place rather than disappearing.

{| class="wikitable"
|+ Screen regions
|-
! Region !! Shows
|-
| Left column || '''Net Power''' in watts as the headline, with '''Power In''' and '''Power Out''' beneath it
|-
| Centre || '''Speed''' in km/h, large, with the GNSS fix state under it (<code>3D fix</code>, <code>2D fix</code>, <code>No fix</code>, or <code>---</code> when the receiver is silent)
|-
| Right column || '''State of Charge''' in percent as the headline, over a 2 × 2 grid of temperatures: Motor, Driver, the hottest MPPT, and the hottest battery thermistor
|-
| Under the speed || Four '''warning icons''', each in a fixed slot
|-
| Bottom row || '''Current Time''', '''Race Time''', '''Time to Empty'''
|-
| Top line, small || Firmware version and git hash, centred; the [[Datalogger|datalogger]]'s WiFi IP on the left when it reports one
|}

'''Power.''' Currents leaving the battery are negative on the bus, so the three figures are: ''Power In'' = charge current × pack voltage, ''Power Out'' = (motor + peripherals) × pack voltage, and ''Net Power'' = the sum of all three. '''A positive net power means the battery is charging.'''

'''Temperatures.''' The MPPT cell names the unit it is showing — <code>MPPT F3</code> forward, <code>MPPT R0</code> aft — because it always shows whichever MPPT is currently hottest. The Motor cell reads the standalone NTC node on <code>0x219</code> only; the VESC reports a motor temperature too, but it is broken on this boat and is deliberately never used as a fallback.

'''Missing data.''' Every value has a '''5 second''' staleness timeout. If nothing has arrived for a value within that window it draws as dashes. Dashes therefore mean "not being reported", not "zero".

=== Warning icons ===

Each icon appears only while its condition holds, in its own fixed slot, so a warning is always in the same place.

{| class="wikitable"
|-
! Icon !! Raised when
|-
| Battery || Battery state, charge FET or discharge FET is anything other than normal
|-
| Low charge || State of charge below '''15 %'''
|-
| Over-temperature || Motor above '''50 °C''', driver above '''70 °C''', any MPPT above '''80 °C''', or a battery thermistor above '''45 °C'''
|-
| Throttle || The [[Throttle|throttle]] reports any error flag
|}

A stale or missing value never raises an icon — the dashes already show that data is being lost.

== Hardware ==

The board is the Altium project <code>AKD-CAN_Interface</code>, the '''same PCB as the [[Height sensors|height sensor controller]]'''. Where that board fits four RS-485 channels, this one fits the e-paper panel on SPI2.

{| class="wikitable"
|+ Display connections
|-
! Signal !! Pin
|-
| SPI2 SCK / MOSI / MISO || PB13 / PB15 / PB14
|-
| Chip select || PC6
|-
| Data/command || PC9
|-
| Reset || PC8
|-
| Busy || PA8
|-
| Panel power || PB12, held on for the life of the firmware
|}

SPI runs at '''2.5 MHz''' and is DMA-backed, so a full framebuffer transfer (~86 ms) does not block the CAN receive task. Those DMA channels — <code>DMA1_CH4</code>/<code>CH5</code> — are the only pair SPI2 can use, and they are the ones I²C2 would need, which is '''why this board has no onboard temperature sensor''' where its sister boards do.

24 V arrives on the CAN connector and is stepped down on the board, exactly as on the height sensor unit. The safety line passes straight through and is not connected to the microcontroller.

== Refreshing ==

E-paper is slow and wears with every drive cycle, so the firmware avoids refreshes it does not need:

* The framebuffer is hashed after each render. '''An identical picture is not sent to the panel at all.'''
* Every 60th refresh is a '''full''' refresh, which clears the ghosting that the fast differential refresh accumulates. The other 59 are differential.
* A refresh takes between '''0.7 and 2.5 seconds'''; the render itself costs about half a second. The loop is floored at one second per iteration.

So the screen updates roughly once a second while values are changing, and sits still when they are not.

== CAN ==

The dashboard uses an '''accept-all''' hardware filter — it needs the whole bus — and decodes the identifiers it knows about. Everything else is ignored.

{| class="wikitable"
|+ What the screen is built from
|-
! Source !! Identifiers !! Used for
|-
| [[Battery|BMS]] || <code>0x100</code>–<code>0x107</code> || State of charge, pack voltage, the three currents, temperatures, battery/charge/discharge states
|-
| GNSS || <code>0x200</code>, <code>0x201</code>, <code>0x204</code> || Fix state, speed, clock
|-
| [[Motordriver|VESC]] || <code>0x1009</code> || Driver (FET) temperature
|-
| Motor NTC node || <code>0x219</code> || Motor temperature
|-
| [[MPPT]] / [[GaN MPPT]] || <code>0x400</code>–<code>0x4FF</code>, <code>0x700</code>–<code>0x77F</code> || MPPT temperatures, per-panel power
|-
| [[Throttle]] || <code>0x1337</code> || Throttle error flags
|-
| [[Datalogger]] || <code>0x205</code> || WiFi IP shown on the stamp line
|}

The full bus-wide reference is [https://github.com/Engineers-of-Innovation/eoi-can/blob/main/CAN_MESSAGES.md CAN_MESSAGES.md].

'''The dashboard originates no traffic.''' The only frames it ever sends are answers to the host's bootloader-protocol queries.

== Firmware update over CAN ==

The first 80 KB of flash holds a CAN bootloader, so the board can be updated in the cockpit without a debug probe. It owns application type <code>0x03</code>, giving it the identifier block <code>0x037</code> (command) / <code>0x038</code> (response) / <code>0x039</code> (write data); the bootloader's hardware filter rejects every other block, so a command aimed at another board cannot touch this one.

<syntaxhighlight lang="bash">
eoi-flash-tool scan # what is on the bus?
eoi-flash-tool flash dashboard # target comes from the ELF
eoi-flash-tool --board dashboard version # which build is on it?
</syntaxhighlight>

The version and git hash of whatever is running are also printed along the top of the screen, so the running build can be read off the panel without a laptop.

The protocol, the flash layout and the addressing scheme are shared with the other boards and are documented in full on the [[Rudder controller]] page.

== Working on the screen without hardware ==

The whole layout lives in the <code>draw-display</code> crate and is shared by the firmware, a desktop simulator and a Raspberry Pi framebuffer tool — so a screen change can be seen without flashing anything.

<syntaxhighlight lang="bash">
cd eoi-can-display-simulator
cargo run -- -ccan0 # live, against a real bus
EG_SIMULATOR_DUMP=screenshot.png cargo run # write a PNG instead
</syntaxhighlight>

The layout is checked at compile time: the positions are const arithmetic, and assertions fail the build if two regions would overlap or a value would not fit its cell. Font metrics are pinned by tests, so a regenerated font that drifts breaks the build rather than the picture.

A second layout, '''foiling''', exists for the foiling trim screen and runs on its own board. Same code, same decoder, different arrangement — pick it with <code>--layout foiling</code> in the simulator.

== Diagnostics ==

{| class="wikitable"
|+ Reading the board without a debugger
|-
! Symptom !! Meaning
|-
| Green LED toggling once per second || Application running normally
|-
| Blue LED flickering || CAN frames arriving — it toggles once per frame
|-
| Red LED on briefly || A panel refresh is in progress
|-
| Red LED double-flashing || Sitting in the bootloader, waiting or flashing
|-
| Everything reads dashes || Nothing is arriving on the bus. Check bus wiring and termination before suspecting the board.
|-
| One column reads dashes || That node is silent; the dashboard is fine
|-
| Screen frozen but LEDs normal || The picture has not changed — identical frames are deliberately skipped
|-
| Ghosting or grey smears || Normal between full refreshes; cleared by the next one, at most 60 refreshes away
|}

A 4-second independent hardware watchdog is petted once per second, so wedged firmware resets itself. If no frames arrive for several loop iterations the firmware logs the CAN peripheral state and re-arms the receive interrupts by itself. Detailed logging is available over SWD through <code>defmt</code>.

== Known gaps ==

* '''Race Time is empty.''' The block is drawn and labelled, but nothing on the bus signals a race start, so it always shows dashes.
* '''Time to Empty is empty.''' Nothing calculates or broadcasts it yet. The BMS field exists but is not fed to the screen.
* '''The clock is hardcoded to UTC+2.''' Correct for Dutch summer time and wrong by an hour the rest of the year. There is no time zone handling.
* '''No onboard temperature sensor.''' Unavoidable on this board — SPI2's DMA channels are the ones I²C2 would need. The dashboard therefore reports no board temperature of its own.
* '''No user input.''' The board has a sealed rotary switch fitted, but no firmware reads it. The screen cannot be paged or configured from the cockpit.
* '''Per-panel MPPT power is decoded but not shown.''' The data is collected and available to the layout; there is no room for it on the dashboard screen.

== See also ==

* [[Height sensors]] — the same PCB, in its other configuration
* [[Rudder controller]] — sister board, and the full bootloader protocol
* [[CAN-bus]] — bus wiring, cable pinout and the bus-wide identifier map
* [[Battery]] — where the power and state of charge figures come from
* [[Instrumentation Panel]] — the switch panel in the same cockpit
* [[Datalogger]] — records the same bus the dashboard displays
* [[Altium PCB]] — house PCB design conventions

Dashboard - Revision history