# BMW E8x EPS — standalone operating protocol

How to power up, control and monitor the E8x/E9x electric power steering
(EPS) unit outside the donor car — e.g. in a custom EV conversion.

Everything here was derived by observation from a working car and verified
against the real unit on a bench. Where something is inferred rather than
proven, it says so explicitly: **[A]** proven on hardware, **[B]** strongly
indicated, **[C]** inference worth testing. Trusting a **[C]** without
checking it is how you end up debugging the wrong layer.

Source material: `eps-comms/findings.md` (chronological log),
`files/PTCAN_protocol.md` (whole-bus reverse engineering), and the capture
and bench logs in `captures/`.

---

## 1. What the EPS actually needs

The short version, and the surprise of this project: **two CAN messages and
one 12V wire.** Not the 69-message firehose the car puts on the bus.

| Requirement | Detail | Confidence |
|---|---|---|
| 12V enable signal | Discrete wire, not CAN. Unit stays dead without it | **[A]** |
| `0x130` CAS terminal status | 100 ms cycle. Brings the unit up | **[A]** |
| `0x1A0` DSC road speed | 20 ms cycle. Sets assist level | **[A]** |
| CAN bus @ 500 kbit/s | 11-bit identifiers, classic CAN 2.0 | **[A]** |
| A second node on the bus | See §2.3 — CAN needs someone to ACK | **[A]** |

Everything else the car transmits (engine data, wheel speeds, diagnostics,
VIN, cluster, comfort modules) turned out to be unnecessary for steering
assist. That was established by loading progressively smaller transmit sets
and watching whether the unit still came up and assisted.

---

## 2. Electrical and bus setup

### 2.1 Power and enable

The EPS needs its main power feed **and** a separate 12V enable/wake signal.
With power but no enable, the unit is completely inert: no CAN transmission,
no assist. **[A]**

This creates a chicken-and-egg worth designing around: until the EPS is
enabled it is not on the bus, so a lone controller has nobody to ACK its
frames and every transmit fails (see §2.3). Your controller must therefore be
able to assert the enable line *without* depending on successful CAN traffic.

### 2.2 Bus parameters

```
Bitrate      500 kbit/s
Identifiers  11-bit (standard)
Frame format classic CAN 2.0A
Termination  120 Ω at each end of the segment (~60 Ω measured across H/L, powered down)
```

### 2.3 The ACK requirement

CAN requires at least one *other* node to acknowledge a frame. On a bench
with only your controller and an unpowered EPS, every transmission fails
arbitration and the controller reports timeouts — with the ESP32 TWAI
peripheral this surfaces as `ESP_ERR_TIMEOUT` on every send. **[A]**

This is normal, not a fault. It resolves the moment the EPS is enabled and
joins the bus. Design implication: don't gate your enable logic behind
"CAN is working", and don't treat early TX failures as a hardware problem.

---

## 3. Messages you must transmit

### 3.1 `0x130` — CAS terminal status · 5 bytes · 100 ms **[A]**

The message that brings the unit up. Byte 0 carries the terminal (ignition)
state; the rest is supporting state plus a counter and checksum.

| Byte | Contents | Confidence |
|---|---|---|
| 0 | Terminal state — see table below | **[A]** |
| 1 | `0x00` when terminal is off, `0x40` in every other state | **[A]** |
| 2 | Supporting flags. 9 distinct values observed, `0x21` and `0xD0` dominate | **[B]** |
| 3 | Supporting flags. 9 distinct values, `0x8F`/`0x0F` dominate | **[B]** |
| 4 | Low nibble: alive counter 0–14, skips 15. High nibble: checksum | **[A]** / **[B]** |

Terminal states, all observed in the donor car:

| `b0` | Meaning | Use |
|---|---|---|
| `0x00` | Everything off | Resting state |
| `0x40` | Terminal R (accessory) | First step of a wake-up |
| `0x41` | Terminal 15 (ignition on, engine off) | Unit powers up here |
| `0x45` | Engine running | **Normal operating state** |
| `0x55` | Cranking (starter engaged) | Transient; assist inhibited |

### 3.2 `0x1A0` — DSC road speed · 8 bytes · 20 ms **[A]**

Controls how much assist the unit provides — more speed, less assist, the
standard speed-sensitive steering behaviour.

| Bits | Signal | Format | Confidence |
|---|---|---|---|
| b0 + low nibble of b1 | Road speed | 12-bit unsigned, **0.1 km/h per bit** | **[A]** |
| b1 bit 7 | Standstill/validity flag — set while stationary | flag | **[B]** |
| b2–b5 | DSC state (all constant in the reference capture) | — | **[C]** |
| b6 high nibble | Alive counter | 0–14 | **[B]** |
| b7 | Checksum | See §6 | **[B]** |

Decoding, and the encoding used by `gateway/eps_control.py`:

```python
speed_kmh = (b0 | ((b1 & 0x0F) << 8)) * 0.1

raw = int(round(speed_kmh / 0.1))          # 0..4095
b0  = raw & 0xFF
b1  = (b1 & 0xF0) | ((raw >> 8) & 0x0F)    # keep the flag nibble
# clear bit 7 of b1 when moving, set it when stationary
```

---

## 4. Messages the EPS transmits

Useful for health monitoring and fault detection. None of it needs to be
consumed for the unit to function.

### 4.1 `0x1FB` — alive counter · 2 bytes · ~4 Hz **[A]**

The cleanest health indicator available.

| Byte | Contents |
|---|---|
| 0 | High nibble constant `0xF`; low nibble = alive counter, 0–14, skipping 15 |
| 1 | `0xFF` constant |

**If this counter stops advancing, the EPS has stopped.** It is the single
best signal to watch in a control loop.

### 4.2 `0x4B0` — status heartbeat · 8 bytes · ~1 Hz **[B]**

| Byte | Contents | Confidence |
|---|---|---|
| 0 | Checksum — high entropy, 5 values observed | **[C]** |
| 1 | Low nibble counter-like; high nibble flags (`0x0`, `0x1`, `0x4` seen) | **[C]** |
| 2 | `0xFE` constant | **[A]** |
| 3 | Normally `0xFF`; briefly `0x01` during start-up | **[B]** |
| 4–7 | `0xFF` constant (unused) | **[A]** |

### 4.3 `0x5B0` — power-up state · 8 bytes · event-driven **[B]**

Only two payloads ever observed, which makes this a clean state marker:

| Payload | Meaning |
|---|---|
| `01 03 80 FF FF FF FF FF` | Initialising, immediately after enable |
| `40 81 01 15 FF FF FF FF` | Ready / settled |

---

## 5. Bring-up and shutdown

### 5.1 Startup **[A]**

Order matters. The unit prefers to wake into a bus that is already
populated, rather than into silence:

```
1. Begin transmitting 0x130 with b0 = 0x00 (off) and 0x1A0 at 0 km/h
   → the bus is alive before the EPS joins it
2. Wait ~1 s
3. Assert the 12V enable
4. Wait ~0.5 s   → 0x5B0 "initialising" appears
5. 0x130 b0 → 0x40 (terminal R),      hold ~1.5 s
6. 0x130 b0 → 0x41 (terminal 15),     hold ~1.5 s
7. 0x130 b0 → 0x45 (engine running),  hold ~2 s
8. Confirm 0x1FB is advancing and 0x5B0 reports "ready"
```

Expect the unit to answer within a few seconds of the enable. Keep
transmitting continuously from step 1 — a gap is treated as sender failure.

### 5.2 Shutdown **[B]**

Walk the states back down before removing power, rather than cutting the
enable outright:

```
1. 0x130 b0 → 0x41 (terminal 15),  hold ~1 s
2. 0x130 b0 → 0x40 (terminal R),   hold ~1 s
3. 0x130 b0 → 0x00 (off),          hold ~1 s
4. Remove the 12V enable
5. Stop transmitting
```

---

## 6. Counters and checksums — the honest status

Both required messages carry an alive counter and a checksum. **The counter
scheme is solved; the checksums are not.** This is the main open problem for
a fully synthetic implementation.

### 6.1 Alive counters **[A]**

Universal on this bus: a 4-bit counter running **0 → 14, skipping 15**,
incrementing once per transmitted frame.

| Message | Counter location |
|---|---|
| `0x130` | byte 4, low nibble |
| `0x1A0` | byte 6, high nibble |

A frozen counter is read as a stale or faulty sender and the message is
ignored — this was the single biggest cause of "the unit won't come up"
during development. Retransmitting a captured payload verbatim does not
work; the counter must advance.

### 6.2 Checksums — unsolved

Brute-forced across sum, one's-complement sum and XOR, every byte range, all
256 constants, with and without counter contribution:

| Message | Checksum byte | Best fit found | Match rate |
|---|---|---|---|
| `0x1A0` | b7 | fold(sum(b2..b6)) + `0x22` | **87.5 %** |
| `0x130` | b4 high nibble | sum of nibbles(b0..b3) + counter + `0x6` | **64 %** |

Neither is good enough to generate frames blind. A CRC-8 search over all 256
polynomials and seeds also found nothing (`files/PTCAN_protocol.md`).

**One useful consequence of the `0x1A0` result:** the best-fitting range is
**bytes 2–6, which excludes the speed field in bytes 0–1**. If that is
correct, changing road speed does not invalidate the checksum. `eps_control.py`
relies on this, and it holds in testing — but it is **[C]**, so verify on
your own unit by watching `0x1FB` when you move the speed slider.

### 6.3 The workaround that actually works **[A]**

Rather than synthesising checksums, **replay genuine captured frames**:

- For `0x130`, record the car sending each terminal state and keep those
  frame sequences. Changing state means switching which recorded sequence
  you are cycling. Counters and checksums are then exactly what the car
  produced.
- For `0x1A0`, patch the speed field into a captured frame and leave bytes
  2–7 untouched (per §6.2).

This is what `gateway/eps_control.py` does, and it drives the unit reliably.
The frame inventory available in `captures/replay_car_to_eps_20260829.csv`:

| Terminal state | Captured frames |
|---|---|
| off (`0x00`) | 230 |
| terminal R (`0x40`) | 21 |
| ignition (`0x41`) | 121 |
| engine running (`0x45`) | 456 |
| cranking (`0x55`) | 8 |

For a production build, solving the checksums properly is worth the effort —
the replay approach ties you to a recording, and cannot express a state the
donor car never produced.

---

## 7. Timing requirements

Underestimated during development, and the cause of most of the
intermittent faults seen along the way.

| Message | Period | Rate |
|---|---|---|
| `0x130` | 100 ms | 10 frames/s |
| `0x1A0` | 20 ms | 50 frames/s |
| **Minimum total** | | **60 frames/s** |

Late frames look identical to a faulty sender. A PC-hosted controller
transmitting the full 69-message set needs ~1330 frames/s and struggled to
sustain it, producing exactly the intermittent dropouts that looked like an
EPS fault. The two-message set needs 60 frames/s — trivial for any
microcontroller, and far more reliable.

**Design guidance for a custom EV:** generate these messages on a
microcontroller with a hardware CAN controller and a timer-driven loop. Do
not put a PC, USB-serial link or non-realtime OS in the path.

---

## 8. Minimum viable controller

What a standalone implementation has to do:

1. Drive a 12V enable output, independently of CAN state.
2. Transmit `0x130` every 100 ms with the desired terminal state, an
   advancing counter and a valid checksum.
3. Transmit `0x1A0` every 20 ms with the current road speed, an advancing
   counter and a valid checksum.
4. Monitor `0x1FB` — if its counter stops advancing, the EPS has dropped
   out; re-run the startup sequence.
5. Follow the startup and shutdown sequences in §5.

Optional but recommended: watch `0x5B0` for the ready transition, and log
`0x4B0` for post-mortem fault analysis.

---

## 9. Verification checklist

Before trusting this on a moving vehicle:

- [ ] Confirm assist actually varies with the `0x1A0` speed value, across
      the range you intend to use. Only 0 km/h is proven from the donor car.
- [ ] Confirm the `0x1A0` checksum inference (§6.2) by sweeping speed and
      watching `0x1FB` for dropouts.
- [ ] Establish what the EPS does when CAN stops entirely at speed —
      does assist fade, or cut abruptly?
- [ ] Establish behaviour on counter/checksum errors: ignored frame, or
      latched fault needing a power cycle?
- [ ] Confirm whether `0x45` (engine running) is required for full assist,
      or whether `0x41` (ignition) is sufficient.
- [ ] Solve the checksums (§6.2) if you need states the donor car never
      produced.
- [ ] Check for a torque-sensor or steering-angle input requirement under
      load — the bench testing was done stationary.

---

## 10. Tooling in this repository

| Tool | Purpose |
|---|---|
| `gateway/gateway_app.py` | Four-tab UI: live relay, replay, bench, EPS control |
| `gateway/eps_control.py` | Minimal two-message controller — the reference implementation |
| `gateway/eps_bench.py` | Transmit arbitrary message sets to find what's needed |
| `tools/analyze_bench_session.py` | Enable-vs-online timing, dropouts, TX rate health |
| `tools/analyze_startup_order.py` | What preceded the unit coming online |
| `tools/solve_checksum.py` | Brute-force checksum solver |