FLM1 vs FLM2
FLM = Front Light Module. Each headlight has its own controller wired to the car's bus.
- FLM1 — older module, used in F-series (F30, F10…). Smaller animation buffer, simpler protocol.
- FLM2 — newer module, used in G-series (G20, G30, G80…). What this app targets.
BimmerCode addresses the two sides separately: 0x43 = left, 0x44 = right.
Stage1 / Stage2
Each FLM2 side stores its animation in two staging buffers. Concatenated, they form the full byte stream:
Staging1 — up to 252 bytes+Staging2 — up to 168 bytes=420 bytes total
Why two? Hardware limit on the FLM2 — each buffer is written via a separate diagnostic job. BimmerCode and Esys expose them as two fields.
The byte format
The 420 bytes encode a list of sequences. Each sequence:
[id] 00 [pairCount] [dur, bri] [dur, bri] …
- id — channel identifier
0x01–0x0F. Maps to a physical zone (DRL, indicator, low beam, …) — exact mapping varies by car & firmware. - pairCount — number of (duration, brightness) pairs that follow.
- dur — duration in 10 ms units.
0x32 = 50 × 10 ms = 500 ms. - bri — brightness 0–100 (
0x00–0x64).
The list ends with 00 00 00. Adjacent pairs at the same brightness hold; differing brightness ramps linearly between them.
Why "Ch 01, Ch 02…" instead of zone names?
The community hasn't pinned down a definitive sequence ID → physical zone mapping. It shifts between models, firmware versions, and psdzdata releases. So this app shows per-channel rows labeled by sequence ID — honest under every interpretation. Try a hex on your car and watch which lights respond.