Rcm

RCM — Relay Control Module

A CAN-controlled relay driver for a car. 21 universal channels, each of which is simultaneously a low-side output and an input — so the same board builds as a relay controller or as a switch panel, decided in firmware rather than by a different PCB.

Designed for a rusEFI bus (uaEFI SUPER ECU + uaDASH display), but nothing about it is rusEFI-specific beyond the choice of message IDs.

A note on how this was built

This project is largely AI-developed. The schematic, PCB layout, firmware and documentation were written by me working with Claude, and much of the text and code here came out of that. It is called out up front because some people would rather know, and because it should colour how much you trust it.

What it does not mean is unreviewed or untested. The board exists and has been brought up on the bench; the claims in the Status section below were measured rather than asserted, and where something has only been reasoned about it says so. The firmware has a host-side unit test suite. Bring-up still found real bugs that review had missed — which is rather the point of the Status section.

Treat it as you would any one-person hobby project: read the schematic before you build it, and don't put it in charge of anything you can't afford to have fail.

Status — read this first

revA has been built, powered and brought up. Every subsystem has run on real hardware: the MCU and its 8 MHz crystal (in use only since 2026-10-26 -- see "The core runs from the crystal" in firmware/README.md), USB, the DIP straps, the EEPROM, CAN through the transceiver onto a real bus, the IMU, the 12 V sense, the self-latching power, the watchdog, the output drivers under a real relay load, a stored configuration surviving a full save-reset-read cycle, and the board switching itself off. 289 host unit tests pass alongside that.

What that does not mean is that it is proven in a car. Specifically, still untested:

• board-to-board peer mirroring — the keypad role strap is proven and a board does come up as a keypad, but only one board has ever been powered, so the peer link has been exercised only with a PC pretending to be the other board
• more than two channels under load at once, and nothing thermal

One genuine hardware flaw has been found, and it is a missing capability rather than a functional fault: revA cannot reach USB DFU. BOOT1 is PB2, which this board uses for SR_OE_N and holds high at reset, so lifting BOOT0 boots from SRAM instead of the ROM bootloader. The J_BOOT header is fitted and works; the pin conflict defeats it. Firmware therefore needs an ST-Link on J_SWD. Configuration is unaffected — that is all over CAN. DESIGN.md has the analysis and the one-net revB fix.

Bring-up found three real firmware bugs that no amount of desk testing had: a %f in printf corrupting memory, a strap display that could never show a change, and a short press on the ignition button switching the board back off. DESIGN.md records those and everything else found along the way, which is a fair guide to how much is probably left.

What happens when it resets

This is a PDM. Running a main relay, a fuel pump and an injector feed is the job, not an edge case. But there is one behaviour to design around:

On any reset, R_OE parks all 21 channels high-impedance until firmware re-enables them. Every channel drops. The firmware adopts failsafe_state and goes live as its first act, and on revA hardware that is 22 ms, measured by the self-test build's W command rather than estimated. Add a few ms of pre-main() crystal and PLL startup that millis() cannot see, so call it ~25 ms. That applies equally to a cold start and to a watchdog reset, so a main relay behind this board closes with the key rather than after a timeout.

Most of the 22 ms is the EEPROM: the board cannot apply failsafe_state before it has read failsafe_state, so cfg_load() is unavoidably inside the dropout. A scope on any channel gives the true figure including pre-main() time.

So the question for each load is not "is this engine-critical" but "what does 25 ms off do to it?"

failsafe_state is the board's resting state, not just a bus-timeout behaviour: it is what gets applied at power-up, after a watchdog reset, and whenever the bus goes quiet — anything a CAN command has not overridden. It defaults to all-off, which is right for lighting and wrong for anything that should be on by default. It is per-channel, so one board can drop its lighting and hold its engine loads. Set it deliberately.

Brake lights are a different argument. Not dropout time — a hardwired brake switch is simply simpler and more reliable than anything running on a microcontroller, and there is no upside to inserting one. Wire the switch straight through, and tap the switched feed into a spare channel set to CH_INPUT if you want the board to know about it. 1.2 mA, and it cannot affect the lamps.

Roadworthiness and legal compliance of anything you build with this are yours.

What it does

Ratings

The channels switch relay coils, they do not carry load current — that is the whole architecture. DESIGN.md has the worked numbers, including why 600 mA is not an all-on figure.

The channel trick

Each channel's terminal connects to three things at once — a driver output, a permanently connected 1M/270k sense divider, and a fitted 10k pull-down:

• As an output it sinks a relay coil to ground.
• As an input a button wired to +12V pulls it high; the pull-down gives 1.2mA of wetting current, enough to keep switch contacts from going oxide-flaky.
• As a diagnostic, because the divider never disconnects, an idle channel reads battery voltage through a healthy relay coil and 0V through a blown fuse. Fuse detection falls out of the same wiring — no extra parts.

Getting all three from one resistor took a few goes. A pull-up would have been the obvious choice and it silently breaks fuse sensing: blown and healthy both read high, 20mV apart.

The same pull-down has a sting worth knowing: an un-driven channel is not open, it is 10k to ground, and it will pass ~1mA from anything pulled up to 12V. Relay coils ignore that. Optocouplers and MOSFET gates do not — so a generic "active low" relay module wired straight to a channel sits with its relays energised. DESIGN.md has the fix.

Configuration

An 8-way DIP sets what can't be fixed over the bus once it's wrong:

Four relay modules and four keypads can share a bus. Everything else — channel modes, bitrate, message IDs, failsafe states — lives in EEPROM and is changeable over CAN.

Firmware

PlatformIO + STM32duino, in firmware/ — see firmware/README.md for the detail.

• 21 channels, in or out per channel as a software table, changeable over CAN
• Coil-circuit diagnosis — blown fuse, missing relay, open coil or broken wire, all reported per channel, and a short-to-12V too
• Input behaviours: momentary, toggle (a momentary button driving a latching load), and hold-to-arm (true only once held, for things a knock must not arm)
• Output behaviours: steady, flash on a shared period so several channels stay in phase, single pulse, and delay-off
• CAN at 500 kbps by default and any exact bitrate you like. Bit timing is solved at runtime for an 87.5% sample point; if a rate cannot be produced exactly, it refuses to start rather than running the bus 1% out
• Node addressing for 8 boards, CAN-loss failsafe, ignition-off shutdown, watchdog
• Everything is configurable over CAN, and readable back over CAN — every setting has a getter as well as a setter, so a tool can ask a board what it is rather than infer it
• Optional keypad → relay peer mirroring, so a button panel can drive a relay module with no ECU in the middle

pio run -d firmware                     build
pio run -d firmware -e selftest -t upload   bring-up console over USB-C
pio test -d firmware -e native          289 host unit tests

Two bring-up paths. A USB-C console needs nothing but the cable — it proves the DIP, the EEPROM, the CAN controller via internal loopback, the IMU, and walks all 21 channels. A PC-side CAN tool (firmware/tools/rcm_bench.py, any python-can interface) does monitoring, commanding and the same channel walk over the bus.

The unit tests compile the firmware's own source against a model of the board — the shift register chains bit by bit, each channel's electrical behaviour, and the EEPROM including its page-wrap misbehaviour. They exist because the shift-register byte order is the one thing in this design that cannot be checked by reading the code back.

rusEFI

Message IDs were checked against rusEFI's own source rather than guessed. The board sits at base 0x300, clear of everything rusEFI uses (0x100/0x102, 0x130/0x131, 0x190, 0x200–0x20B, OpenBLT, OBD2). The base is configurable if it clashes with something on your loom.

docs/rcm.dbc is generated from the firmware headers, so uaDASH and TunerStudio can render channel state, inputs and faults with no custom display code.

The board can drive channels from the ECU's own decisions, and ask the ECU to act. rusEFI broadcasts what it thinks its relays should be doing — main relay, fuel pump, both fans, O2 heater, check-engine, rev limiter — as single bits. Any of those can be bound to a channel, so the ECU decides and this board switches, which matters because rusEFI has far fewer outputs than this board has channels. In the other direction, a button can send any TunerStudio command: start/stop the engine, or one of rusEFI's Lua command counters, which is how you get traction control, launch control or a map switch without either side needing new firmware.

The BMI270 publishes as a Bosch MM5.10 at 0x174/0x178/0x17C — frames rusEFI already decodes. Set imuType = IMU_MM5_10 and yaw rate plus lateral, longitudinal and vertical G appear in the ECU with nothing else to configure.

Enclosure

enclosure/ generates a sealed 3D-printable box and two lids — a keypad face carrying eight 25 mm anti-vandal switches, and a blank plate for the relay-control build. Wire entry is DEUTSCH DT, one aperture that fits 2, 3 and 4-way alike.

Like the PCB, it is generated by a script rather than modelled by hand; the .FCStd files are output and are overwritten on every build.

Building one

The schematic and PCB are generated, not drawn:

python gen_spec.py     ->  spec.json        the circuit, and the source of truth
python gen_plan.py     ->  board_plan.json  every part's physical position
tools/                                      schematic, placement, routing, export

Editing rcm.kicad_sch or rcm.kicad_pcb by hand gets overwritten. Change the generator.

mfg/ holds the gerbers, BOM and CPL exactly as ordered, so you can send that folder to a board house without running any of the above. It is set up for JLCPCB assembly: 4-layer, leaded HASL, Standard PCBA (the BMI270's LGA-14 package requires it).

Parts you must supply yourself

The board house builds the board. These are not on the BOM and will not arrive with it — either because they do not mount to the PCB, or because no standard part fits.

The buck module (required — the board does not power up without it)

A Waveshare DC5-36-TO-DC3V3-5 step-down module, socketed onto JB1/JB2. It takes the ignition-latched 12V rail down to 5V, which the on-board LDO then drops to 3V3.

It ships set to 5V output and must stay that way. Getting 3V3 from the module instead needs per-unit pad rework, and forgetting it once puts 5V into a 3.3V MCU. The LDO exists precisely so that step is never required.

Two things go with it:

JB1 needs four individual square pins. They set the module's ride height, so fit them before anything else and get it square.

Mating plugs for every terminal (required to connect anything)

The board carries the header halves; the screw plugs are yours to buy. KF2EDGK-3.5-xP, also sold as 15EDGK-3.5:

About $3.20 a board. Generic parts — any supplier stocks them.

Do not buy these into JLC's Parts Library expecting them to ship with the boards. Confirmed the hard way on the 2026-08-08 order. That library is consignment stock for assembly runs, and JLC will only ship a part if the assembly process solders it down — a loose mating plug does not qualify. They will not add it to the board, and they will not put it in the box for a sane handling fee either. Money spent there is stuck: you own the parts and there is no way to take delivery of them.

Buy the plugs somewhere else entirely.

Optional

Repository layout

gen_spec.py      -> spec.json         circuit definition, the source of truth
gen_plan.py      -> board_plan.json   every part's physical position
jlc_parts.json                        LCSC part per line; stamped into the schematic
tools/                                scripted-board pipeline
mfg/                                  gerbers, BOM, CPL as ordered
firmware/                             STM32 firmware, host unit tests, PC tools
enclosure/                            generated 3D-printable box and lids
docs/rcm.dbc                          CAN database, generated from the firmware headers
SPEC.md / DESIGN.md                   what was built, and why

Honest notes

DESIGN.md is a decision log rather than a specification, and it keeps the mistakes in. Some that seem worth repeating here:

Three faults were caught after the board looked finished and every automated check was green — a missing ground pour, a reverse-polarity diode wired backwards, and stale manufacturing files. Two were spotted by eye, not by tooling. ERC passes a diode in either orientation, and DRC says nothing at all about an absent copper pour.

The unit tests earned their keep before any hardware existed. They caught a mirrored shift-register byte order, a CAN filter that made every other filter decorative, four broadcast frames being handed to three transmit mailboxes, and a multi-second output dropout after a watchdog reset. The pattern in every case was two independent derivations of the same fact disagreeing — which is why the tests model the hardware rather than restating the driver.

JB1 (the buck's input pins, 4 holes at 3.50mm pitch) is hand-fit — no header is made at that pitch. Respacing it to 2.54mm is the obvious fix for a revision.

Credits

firmware/lib/bmi270/ is Bosch Sensortec's own BMI270 Sensor API, vendored verbatim under BSD-3-Clause. It carries the 8 KB configuration image the sensor needs at every power-up, which is not something worth reimplementing.

Licence

MIT — hardware design files included. Copy it, change it, sell it, no attribution burden beyond keeping the notice.

MIT rather than a public-domain dedication for one reason: the "AS IS, WITHOUT WARRANTY" clause. This switches vehicle electrics, and that paragraph is worth keeping.

Bosch's vendored BMI270 driver is separately licensed under BSD-3-Clause.