Claude-Code

The OVMS module talks to the car over two buses. CAN2 handles powertrain — BMS, gear selector, VIN. CAN3 handles the body network — speed, GPS, clima, locks. The J533 gateway sits between them and bridges selected frames. Not all traffic. Specific IDs it’s programmed to forward. Early captures used a script with a bus-labeling bug. Powertrain frames from CAN2 were written to the capture file with bus tag 3 — the body network tag. In the logs, frames like 0x131 (SoC), 0x187 (gear selector), and 0x191 (BMS current) appeared to be arriving on CAN3. ...

There’s a lot of writing about how to prompt an LLM. Very little about what happens on the other side — the code the model reads every time it opens a file. When Claude Code works in a repository, it reads source files. It reads CLAUDE.md on every turn. It reads whatever documentation you’ve pointed it at. Every comment in every file it touches gets fed into context. Most of that happens invisibly, in the background, before you’ve typed a single word. ...

The cabin temperature post was about recognising a pattern. These two are about what happens after — writing code that’s actually correct, and knowing when it is. The GPS frame Frame 0x486 decodes latitude and longitude from four bytes each. The original code had a TODO where the hemisphere sign bits should be, and wrote the metrics unconditionally — no check on whether the values made sense first. The DBC showed 55 of 64 bits in use. The remaining bits were the sign flags. Bit 55 negates latitude for the southern hemisphere. Bit 56 negates longitude for the western hemisphere. The original code never read either of them. ...

The first thing I did after setting up the repo was ask Claude to have a look at the e-Golf decoder code and the metrics I’d pulled from my own module. No specific question — just a first pass to see if anything looked off. It flagged the cabin temperature. Pinned at 77°C. That’s not a plausible cabin temperature. It’s hot enough to kill. My first thought was a unit mix-up — 77°F is about 25°C, which is a completely normal interior reading. Reasonable suspicion. ...

The OVMS development manual has a section on AI. It’s worth reading in full, but the short version: “Vibe” submissions will be rejected and closed without comment. And: Submitting unvalidated “AI” output is a waste of our time and an insult to our dedication to the Open Source idea of sharing knowledge and helping each other to grow. The maintainer isn’t wrong. The PRs he’s seen from people pointing an LLM at the repo and submitting whatever comes out are, by his account, consistently bad — wrong function calls, invented APIs, code that compiles but misunderstands how the framework actually works. OVMS is a custom embedded environment running on ESP32. It has its own event system, its own metric types, its own CAN poller, its own naming conventions. Nothing in an LLM’s training data maps cleanly onto it. ...

I’ve been running a 2019 VW e-Golf since late last year. It came with Car-Net — VW’s remote access app. Nothing fancy, but useful: you could start the climate pre-conditioning, check the charge level, see where the car was. It worked well enough that you missed it when it was gone. VW pulled the plug on Car-Net when mobile operators started decommissioning their 2G networks. The app ran over 2G. In Sweden, Telenor went down first of December last year — VW had built on Telenor’s infrastructure, so that was that. Telia still has 2G running until 2027, but it didn’t matter. The back end was gone. ...