Height sensors - Revision history

Aran Dokoupil: /* The sensors */

2026-08-17T21:12:22Z

The sensors

← Older revision		Revision as of 21:12, 17 August 2026
Line 39:		Line 39:
	== The sensors ==		== The sensors ==

	We use ~~cheap~~ '''DYP A02''' RS-485 ultrasonic sensors. The sensor does all the timing itself: it is a Modbus RTU slave that answers a register read with a distance in millimetres, so the interface board never sees a raw echo.		We use '''DYP A02''' RS-485 ultrasonic sensors. The sensor does all the timing itself: it is a Modbus RTU slave that answers a register read with a distance in millimetres, so the interface board never sees a raw echo.

	* [https://www.dypcn.com/uploads/A02-Datasheet.pdf A02 datasheet]		* [https://www.dypcn.com/uploads/A02-Datasheet.pdf A02 datasheet]

Aran Dokoupil at 21:12, 17 August 2026

2026-08-17T21:12:04Z

← Older revision		Revision as of 21:12, 17 August 2026
Line 1:		Line 1:
	The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew and the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look down at a slight angle outward from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Dashboard\|display]], [[~~Autopilot~~]], and the [[Datalogger\|datalogger]] pick it up.		The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew and the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look down at a slight angle outward from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Dashboard\|display]], [[autopilot]], and the [[Datalogger\|datalogger]] pick it up.

	[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]		[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]

Aran Dokoupil at 21:11, 17 August 2026

2026-08-17T21:11:54Z

← Older revision		Revision as of 21:11, 17 August 2026
Line 1:		Line 1:
	The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and ~~eventually~~ the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look ~~straight~~ down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Dashboard\|display]] and the [[Datalogger\|datalogger]] pick it up.		The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew and the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look down at a slight angle outward from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Dashboard\|display]], [[Autopilot]], and the [[Datalogger\|datalogger]] pick it up.

	[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]		[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]

Aran Dokoupil at 21:10, 17 August 2026

2026-08-17T21:10:33Z

← Older revision		Revision as of 21:10, 17 August 2026
Line 1:		Line 1:
	The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[~~Instrumentation Panel~~\|display]] and the [[Datalogger\|datalogger]] pick it up.		The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Dashboard\|display]] and the [[Datalogger\|datalogger]] pick it up.

	[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]		[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]

Aran Dokoupil at 18:45, 17 August 2026

2026-08-17T18:45:00Z

← Older revision		Revision as of 18:45, 17 August 2026
Line 1:		Line 1:
	The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Instrumentation Panel\|display]] and the [[Datalogger\|datalogger]] pick it up.		The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the [[Autopilot]] — how high the boat is flying on its [[Foils\|foils]]. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus\|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Instrumentation Panel\|display]] and the [[Datalogger\|datalogger]] pick it up.

			[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]

	== At a glance ==		== At a glance ==
Line 47:		Line 49:

	== Interface board ==		== Interface board ==
	~~[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]~~

	The board is the Altium project <code>AKD-CAN_Interface</code>. It is the '''same PCB as the e-paper dashboard''' in the cockpit — that board fits a display on SPI2 where this one fits the RS-485 channels. The height-sensor unit itself lives under the deck, a little forward of the throttle near the pilot cabin.		The board is the Altium project <code>AKD-CAN_Interface</code>. It is the '''same PCB as the e-paper dashboard''' in the cockpit — that board fits a display on SPI2 where this one fits the RS-485 channels. The height-sensor unit itself lives under the deck, a little forward of the throttle near the pilot cabin.

Aran Dokoupil: /* Interface board */

2026-08-17T18:42:12Z

Interface board

← Older revision		Revision as of 18:42, 17 August 2026
Line 69:		Line 69:
	\|}		\|}

	Each channel is one half-duplex transceiver (TI '''SN65HVD3088E''', 20 Mbit/s, 1/8 unit load) running from the board's '''5 V''' rail, with DE and RE tied together so the part either drives or listens. The microcontroller runs at 3.3 V, so the transceiver's receiver output and the detect line both present 5 V logic to it — every pin in the table above is a 5 V-tolerant FT pin~~, which is why this is allowed rather than merely lucky~~.		Each channel is one half-duplex transceiver (TI '''SN65HVD3088E''', 20 Mbit/s, 1/8 unit load) running from the board's '''5 V''' rail, with DE and RE tied together so the part either drives or listens. The microcontroller runs at 3.3 V, so the transceiver's receiver output and the detect line both present 5 V logic to it — every pin in the table above is a 5 V-tolerant FT pin.

	'''Note:''' the schematic symbol is named <code>ISL83078E</code>, but the BOM's part choice is the TI <code>SN65HVD3088E</code>. Both are 5 V, 8-pin, pin-compatible RS-485 transceivers, so the sheet is right either way — but check the fitted part before quoting a datasheet number.

	=== Sensor connector ===		=== Sensor connector ===

Aran Dokoupil: /* Interface board */

2026-08-17T18:41:22Z

Interface board

← Older revision		Revision as of 18:41, 17 August 2026
Line 49:		Line 49:
	[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]		[[File:Height-Controller.jpeg\|thumb\|The RS485-to-CAN interface board that polls the height sensors]]

	The board is the Altium project <code>AKD-CAN_Interface</code>. It is the '''same PCB as the e-paper dashboard''' in the cockpit — that board fits a display on SPI2 where this one fits the RS-485 channels. The height-sensor unit itself lives under the deck, a little forward of the throttle near the pilot cabin~~, not in the cockpit~~.		The board is the Altium project <code>AKD-CAN_Interface</code>. It is the '''same PCB as the e-paper dashboard''' in the cockpit — that board fits a display on SPI2 where this one fits the RS-485 channels. The height-sensor unit itself lives under the deck, a little forward of the throttle near the pilot cabin.

	=== RS-485 channels ===		=== RS-485 channels ===

Aran Dokoupil: Created page with "The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the Autopilot — how high the boat is flying on its foils. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-CAN interface board polls them and rebroadcasts each reading on the bus, where the display and the..."

2026-08-17T18:39:57Z

Created page with "The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the Autopilot — how high the boat is flying on its foils. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-CAN interface board polls them and rebroadcasts each reading on the bus, where the display and the..."

New page

The '''height sensors''' measure the distance between the hull and the water surface, which is what tells the crew — and eventually the [[Autopilot]] — how high the boat is flying on its [[Foils|foils]]. Two ultrasonic sensors look straight down from the nose of the hull. They are not read directly by anything: a dedicated RS485-to-[[CAN-bus|CAN]] interface board polls them and rebroadcasts each reading on the bus, where the [[Instrumentation Panel|display]] and the [[Datalogger|datalogger]] pick it up.

== At a glance ==

{| class="wikitable"
|+ Height sensing summary
|-
! Property !! Value
|-
| Sensors || 2 × DYP A02 ultrasonic, RS-485 / Modbus RTU
|-
| Reading || Distance to the water surface, in millimetres
|-
| Sensor positions || As far forward as possible, port and starboard of the hull nose
|-
| Update rate || 8 Hz per sensor (16 Hz combined, staggered)
|-
| Interface board || RS485-to-CAN interface, STM32L471RGT6 — 4 channels, 2 in use
|-
| Board location || Under the deck, just forward of the [[Throttle|throttle]], near the pilot cabin
|-
| Bus || CAN 2.0A, 1 Mbit/s, 11-bit standard identifiers
|-
| CAN identifiers || <code>0x011</code> front left, <code>0x012</code> front right
|-
| Application type || <code>0x02</code> — its address in the bootloader protocol
|-
| Firmware || Rust, <code>embassy</code>, binary <code>height-sensor-controller</code>
|-
| Firmware source || <code>firmware/</code> in the [https://github.com/Engineers-of-Innovation/eoi-can eoi-can] monorepo
|-
| Hardware source || Altium project <code>AKD-CAN_Interface</code> (Altium 365)
|-
| Field update || Over CAN, no debug probe needed
|}

== The sensors ==

We use cheap '''DYP A02''' RS-485 ultrasonic sensors. The sensor does all the timing itself: it is a Modbus RTU slave that answers a register read with a distance in millimetres, so the interface board never sees a raw echo.

* [https://www.dypcn.com/uploads/A02-Datasheet.pdf A02 datasheet]
* [https://www.dypcn.com/uploads/A02-Output-Interfaces.pdf A02 output interfaces]

Both sensors are mounted as far forward as they fit, one to port and one to starboard of the nose, pointing down at the water. Each one passes through the hull on a '''miniature 5-pin Binder connector''' which is watertight even when unmated, so a sensor can be unplugged without opening the hull up. Wire colours for that harness are listed on the [[Foils]] page.

'''What the number means.''' It is the raw distance from the sensor face to whatever the ultrasonic pulse hit — nothing more. It is not corrected for pitch, roll or sensor offset, and a wave crest passing under the nose reads as the boat dropping. Treat it as a ride-height indication, not a calibrated altitude.

== Interface board ==
[[File:Height-Controller.jpeg|thumb|The RS485-to-CAN interface board that polls the height sensors]]

The board is the Altium project <code>AKD-CAN_Interface</code>. It is the '''same PCB as the e-paper dashboard''' in the cockpit — that board fits a display on SPI2 where this one fits the RS-485 channels. The height-sensor unit itself lives under the deck, a little forward of the throttle near the pilot cabin, not in the cockpit.

=== RS-485 channels ===

The schematic repeats one RS-485 channel sheet four times, so there are '''four identical sensor channels''', numbered 2 to 5 after the USART each one lands on. The firmware only uses two of them.

{| class="wikitable"
|+ RS-485 channel allocation
|-
! Channel !! USART !! TX !! RX !! DIR (DE) !! Detect !! Used for !! CAN ID
|-
| 2 || USART2 || PA2 || PA3 || PA1 || PA0 || Height sensor front '''left''' || <code>0x011</code>
|-
| 3 || USART3 || PC4 || PC5 || PB1 || PB2 || Height sensor front '''right''' || <code>0x012</code>
|-
| 4 || UART4 || PC10 || PC11 || PA15 || PA12 || ''unused'' || <code>0x013</code> (reserved)
|-
| 5 || UART5 || PC12 || PD2 || PB4 || PB5 || ''unused'' || <code>0x014</code> (reserved)
|}

Each channel is one half-duplex transceiver (TI '''SN65HVD3088E''', 20 Mbit/s, 1/8 unit load) running from the board's '''5 V''' rail, with DE and RE tied together so the part either drives or listens. The microcontroller runs at 3.3 V, so the transceiver's receiver output and the detect line both present 5 V logic to it — every pin in the table above is a 5 V-tolerant FT pin, which is why this is allowed rather than merely lucky.

'''Note:''' the schematic symbol is named <code>ISL83078E</code>, but the BOM's part choice is the TI <code>SN65HVD3088E</code>. Both are 5 V, 8-pin, pin-compatible RS-485 transceivers, so the sheet is right either way — but check the fitted part before quoting a datasheet number.

=== Sensor connector ===

One 5-contact M8 female panel-mount connector per channel.

{| class="wikitable"
|-
! Pin !! Signal !! Notes
|-
| 1 || Sensor supply || '''5 V.''' Selected by a 0603 link: one jumper to 5 V, an alternative to 24 V. Fit '''one''' — populating both shorts 5 V to 24 V.
|-
| 2 || RS-485 A / Y ||
|-
| 3 || RS-485 B / Z ||
|-
| 4 || Presence detect || 100 kΩ pull-up to 5 V. Pull to ground to signal "sensor connected"
|-
| 5 || GND ||
|}

'''This is the board's own pin order.''' It is not necessarily the order of the Binder connector in the hull, and it is not the A02's own cable colour code — check the harness rather than assuming the numbering carries across.

=== Power and bus ===

24 V arrives on the [[CAN-bus]] connector through a resettable PTC fuse (30 V, 100 mA hold) and feeds two Würth fixed step-down modules, one producing 5 V for the RS-485 side and one producing 3.3 V for the microcontroller. The CAN transceiver is an MCP2542FD. The safety line passes straight through between the two CAN connectors and is not connected to the microcontroller, so this board neither reads nor breaks the safety circuit.

=== Board temperature ===

A Würth WSEN-TIDS sensor on I²C2 (PB10/PB11, address <code>0x3F</code>) reports the PCB temperature once per second on <code>0x210</code>, in hundredths of a degree. This is a board health measurement — it is how you tell whether the sealed compartment under the deck is cooking.

== How the firmware reads them ==

Each sensor is a Modbus RTU slave at address <code>0x01</code>, spoken to at '''9600 baud, 8 data bits, no parity, 2 stop bits'''. One read is a single holding register at <code>0x0101</code>, and the response is the distance in millimetres.

Sending the request is what starts the ultrasonic ping, so the request and the measurement are the same event. A read normally completes in about 100 ms, which is also used as the response timeout.

'''The two sensors are never pinged at the same time.''' A sequencer alternates front-left, front-right, front-left, … and only starts the next sensor once the previous read has finished, because two overlapping ultrasonic pings at the front of the hull can hear each other and produce a plausible but wrong distance. When reads complete promptly the sequencer paces itself to a 62.5 ms slot, giving 8 Hz per sensor and 16 Hz combined; if reads run to the full timeout the combined rate falls back toward 10 Hz on its own.

Before each request the receive buffer is drained, so a late response from a previous timed-out read cannot be mistaken for the current one.

The presence-detect pin is sampled first. If it reads high the channel is reported as <code>NotPluggedIn</code> and no Modbus traffic is generated at all. Any failure to build, send, receive or parse the Modbus frame reports <code>ModbusError</code>. In both cases the height field is sent as 0 — '''0 mm is not a measurement''', always read the state byte first.

== CAN messages ==

The board joins the bus at 1 Mbit/s with 11-bit identifiers. All multi-byte fields are little-endian.

{| class="wikitable"
|+ Frames the height-sensor board sends
|-
! ID !! Message !! DLC !! Rate
|-
| <code>0x011</code> || HeightSensorFrontLeft || 3 || every 125 ms
|-
| <code>0x012</code> || HeightSensorFrontRight || 3 || every 125 ms
|-
| <code>0x035</code> || Bootloader response || 2–8 || on request only
|-
| <code>0x210</code> || TemperatureHeightSensorsController || 2 || every 1 s
|}

<code>0x013</code> and <code>0x014</code> are reserved for the two unused channels and are not transmitted.

=== 0x011 and 0x012 — height sensor reading ===

{| class="wikitable"
|-
! Byte !! Field !! Type !! Values
|-
| 0 || State || u8 enum || 0 = NotPluggedIn, 1 = ModbusError, 2 = Operational, 0xFF = Unknown
|-
| 1–2 || Height || u16 LE || Distance to the water surface in mm. 0 whenever the state is not Operational.
|}

=== 0x210 — TemperatureHeightSensorsController ===

{| class="wikitable"
|-
! Byte !! Field !! Type !! Values
|-
| 0–1 || Board temperature || i16 LE || Hundredths of a degree Celsius. 2500 = 25.00 °C.
|}

=== Received ===

The application uses an accept-all hardware filter and ignores everything that does not concern it. The only frames it acts on are the bootloader ones: the discovery broadcast <code>0x030</code>, its own command identifier <code>0x031 + (0x02 − 1) × 3 = 0x034</code>, and firmware write data on <code>0x036</code>.

== Firmware update over CAN ==

The first 80 KB of flash holds a CAN bootloader, so the board can be updated without pulling it out from under the deck. It owns application type <code>0x02</code>, which gives it the identifier block <code>0x034</code> (command) / <code>0x035</code> (response) / <code>0x036</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 height-sensor-controller # target comes from the ELF
eoi-flash-tool --board height-sensor-controller version # which build is on it?
</syntaxhighlight>

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.

== Diagnostics ==

{| class="wikitable"
|+ Reading the board without a debugger
|-
! Symptom !! Meaning
|-
| Green LED toggling once per second || Application running normally
|-
| Red LED double-flashing || Sitting in the bootloader, waiting or flashing
|-
| No LED activity || No power, or a boot hang
|-
| State byte 1 (ModbusError) || No valid reply within 100 ms. Sensor unpowered, A/B swapped, broken cable, or a flooded sensor.
|-
| State byte 0 (NotPluggedIn) || Detect pin reads high, so the connector is seen as empty
|-
| Height plausible but frozen || The sensor is answering with a stale value; power-cycle the channel
|-
| On the bus but dropping frames || Suspect the 16 MHz crystal. The firmware falls back to the internal oscillator, whose ±1 % accuracy is not good enough for 1 Mbit/s.
|}

A 4-second independent hardware watchdog is petted once per second by the heartbeat task, so wedged firmware resets itself instead of sitting silent on the bus. Detailed logging is available over SWD through <code>defmt</code>.

A sensor can be exercised on the bench without any hardware: <code>firmware/tools/height_sensor_sim.py</code> pretends to be the Modbus slave on a USB RS-485 adapter, with a fixed or swept distance.

== Known gaps ==

* '''Half the channels are unused.''' Channels 4 and 5 are fitted and wired, and <code>0x013</code>/<code>0x014</code> are allocated to them, but no position on the boat has been decided yet, so no firmware reads them.
* '''The detect pin's pull direction is contradictory.''' The board pulls the line up to 5 V through 100 kΩ, so an empty connector should read high — but the firmware also enables the microcontroller's internal pull-down on that pin. That pull-down is 40 kΩ typical (25–55 kΩ), which drags the line to somewhere around 1.4 V, below the input threshold, so an absent sensor is likely to be reported as <code>ModbusError</code> rather than <code>NotPluggedIn</code>. The pin wants no internal pull at all — the microcontroller datasheet requires the internal pulls to be disabled on any pin held above VDD anyway. Worth confirming on the bench.
* '''No filtering.''' Each frame is one ping. There is no averaging, no rate limiting and no outlier rejection, so single bad echoes go straight onto the bus. Any smoothing has to happen in the consumer.
* '''The bus-wide reference is out of date.''' [https://github.com/Engineers-of-Innovation/eoi-can/blob/main/CAN_MESSAGES.md CAN_MESSAGES.md] still describes the height field as "raw, unit undecided". The firmware sends millimetres. This page follows the firmware.
* '''The rotary switch is not read.''' A sealed 4-bit hex switch is fitted and wired, but no firmware uses it. It was presumably intended for a node address or a variant selection.
* '''No temperature compensation.''' The speed of sound varies with air temperature by roughly 0.17 % per °C, which is about 2 mm per °C at a 1 m range. The A02 is left to its own internal compensation, whatever that is.

== See also ==

* [[Foils]] — what the ride height is measured for, and the sensor harness wire colours
* [[Autopilot]] — the intended consumer of these readings
* [[CAN-bus]] — bus wiring, cable pinout and the bus-wide identifier map
* [[Rudder controller]] — sister board, and the full bootloader protocol
* [[Instrumentation Panel]] — where the readings are displayed
* [[Datalogger]] — where they are recorded
* [[Altium PCB]] — house PCB design conventions