The Tesla OBC hardware already publishes 9 temperature probes (3
modules × {tmp1, tmp2, tmpin}) on CAN 0x237/0x239/0x23B which the
teslacharger receives as c[123]tmp[12,in]. Until now none of these
were forwarded downstream — the Polarity VCU's STATUS_SCREEN OBC-temp
and DCDC-temp fields rendered 0 °C on OI-OBC cars.
This commit:
- Adds Param::tmpobcmax — derived value computed each Ms100Task tick
as the max across the 9 probes, skipping any that read -40 °C
(sensor absent / module not present).
- Maps it to 0x211 byte 7 (previously reserved, the last unused byte
of the 7-byte frame). Wire encoding uses the Tesla OBC convention
of offset 40 (wire = °C + 40), matching c[123]tmp* upstream so
receivers can decode with the same formula.
- Bumps VERSTR to -S5 so the right firmware is visually confirmable
in the OpenInverter web UI.
The new byte is purely additive — existing 0x211 consumers that read
only bytes 0-6 continue to work unchanged.
The Polarity VCU's 0x211 RX handler grows a corresponding decode +
display path in a paired stm32-hal-vcu commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pairs with stm32-hal-vcu PR #42. Adds a runtime "vcuchglim" param that
the VCU broadcasts every 200 ms; on receipt, the param's Change()
callback translates 20-100% to the charger's udcspnt (DC voltage
setpoint) using a linear cell-voltage ramp.
Without this, the teslacharger had no path for the user's app-set
charge limit to actually limit charging — udcspnt was effectively
a compile-time setpoint.
What's added
------------
- Param::vcuchglim in include/param_prj.h:
PARAM_ENTRY(CAT_CHARGER, vcuchglim, "%", 20, 100, 80, 23)
- Range 20-100 (matches VCU validation)
- Default 80% if VCU never connects
- ID 23 (next free per the comment, bumped to 24)
- Saveable so a flashed charger paired with a silent VCU still
behaves predictably across reboots
- can->AddRecv(Param::vcuchglim, 0x212, 0, 8, 1) registration in
ChargerCAN::MapMessages() — libopeninv's CanMap dispatches to the
Change() callback on each received frame.
- Param::Change(vcuchglim) handler in src/main.cpp:
cell_target = 3.30 + (4.15 - 3.30) * (pct - 20) / 80
udcspnt = cell_target * 96
Endpoints chosen to be safe across Tesla LDU / VW MEB / Volt2:
20% → 3.30 V/cell × 96 = 316.8 V (deep-cycle storage floor)
80% → 3.94 V/cell × 96 = 378.0 V (recommended daily ceiling)
100% → 4.15 V/cell × 96 = 398.4 V (matches existing udclim default)
Tuneable here as constants if a particular pack needs a tighter range.
- VER bump 1.19.R → 1.20.R. Combined with the pre-existing -S1 suffix
the OI web UI shows "4=1.20.R-S1", visually distinct from upstream
and from the previous Skudak build.
Build
-----
text=25288, links clean. The "RWX LOAD segment" linker warning is
pre-existing on this template, unrelated. No new warnings from this
change.
Version string in the binary verified as "4=1.20.R-S1".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bench capture on the green car showed a non-Polarity module also
broadcasting at 0x210 (DLC=8 frame with mostly-zero payload, byte 5 = 0x85
static — likely a Tesla OEM DI module). Even after a clean reflash + 'can c'
to clear persisted maps, the rogue 0x210 frame keeps appearing on the wire,
racing our intended frame and intermittently corrupting the VCU's read.
Confirmed via 'can p' on the OBC that this firmware's CanMap has exactly
one 0x210 entry with the 5 expected fields — the conflict is external.
Moves all five AddSends to 0x211, an adjacent free ID. The VCU's
CHARGER_CAN_ID_OI_OBC_AUX constant is updated to match in a paired
stm32-hal-vcu PR. Same 7-byte expanded layout (state/udc/idc/uaux@5/soc),
same 100ms cadence — only the arbitration ID changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the single uaux-at-byte-0 broadcast (commit d209a47) with a
7-byte expanded telemetry frame. Bench capture on green car showed dual
0x210 frames colliding (DLC=8 simple + DLC=7 expanded) because Kyle's
flashed image had both AddSend sets active; standardising on the
expanded layout eliminates that ambiguity.
Byte layout:
byte 0 state (0=Off, 1=WaitStart, 2=Enable, 3=Activate, 4=Run, 5=Stop)
bytes 1-2 udc (V, gain=1)
bytes 3-4 idc (0.1A, gain=10)
byte 5 uaux (decivolts, gain=10) — 12V aux battery rail
byte 6 soc (%, gain=1)
byte 7 reserved
Consumed by stm32-hal-vcu Core/Src/main.c CHARGER_CAN_ID_OI_OBC_AUX
handler. The state byte enables future VCU_IsCharging integration via
state == 4 (Run) without requiring a second CAN ID.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds AddSend for Param::uaux at CAN ID 0x210, bit 0, length 8, gain=10.
Transmits 12V aux battery voltage in decivolts/0.1V steps (e.g. 125 = 12.5V).
VCU reads byte 0 of 0x210 for 12V battery protection logic per SKUDAK-448.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bastian de Byl
Kyle