why I'm building my own vehicle telemetry system
I own a Hyundai Ioniq 6. Outside Turkey the car ships with BlueLink, a factory telematics modem that lets you check charge status, lock doors, and precondition the cabin from your phone. Hyundai Turkey stripped BlueLink from every Ioniq it imported, citing BTK telecom regulations. No modem, no app, no remote anything. As of this writing the facelifted Ioniq 6 still hasn't launched here, so no Turkish Ioniq owner has ever used BlueLink.
That gap, and the fact that the head unit runs open-source software, made me curious enough to start poking at the car.
the gap
Remote vehicle access is table stakes now. Tesla set the expectation, and everyone from BMW to BYD followed. How much charge do I have? Are the doors locked? Where did I park? Is a window open? These are questions that most modern EVs answer from a phone. Mine answers none of them unless I'm sitting in it.
The car's CAN buses carry hundreds of signals: individual cell voltages, battery health, coolant temperatures, door states, window positions, charge connector status. The driver's display shows maybe six of these. You can see more with a BLE OBD dongle and an app like Car Scanner, but only while the phone is in Bluetooth range with the ignition on. That's diagnostics, not telemetry.
What I wanted was something closer to what BlueLink would have been: a device that stays in the car, connected over LTE, reporting state whether I'm in the cabin or across the city.
what exists, and why it wasn't enough
OVMS is the closest thing to what I want. Open source, community-driven, supports dozens of vehicles. But there's no Ioniq 6 module, the hardware is a generation behind, and adding a new vehicle means reverse engineering the CAN protocol anyway. If I have to do the RE work regardless, I'd rather build on hardware I control.
Commercial fleet solutions target companies with 500-truck fleets. Priced accordingly, designed accordingly. Individual EV owners are not the customer.
ELM327 dongles are $15 and work well for what they are. But they're passive -- phone must be nearby -- have no LTE, no storage, no autonomy. They're a diagnostic tool, not a telemetry platform.
Nothing I found did what I wanted without requiring either a subscription or my location history sent to someone else's server.
what I'm building
An ESP32-S3 board with a CAN transceiver, LTE modem, and GPS, roughly the size of a phone. It lives behind the dashboard, wired to the OBD port, always on.
The firmware is C on ESP-IDF. The backend is Go. The iOS app talks to the device over BLE when nearby and to the backend over HTTPS when not. OTA firmware updates are signed and delivered over LTE.
The car speaks CAN bus and UDS. Every signal the system decodes was reverse engineered by hand: driving with a laptop, capturing frames, correlating byte changes against physical state, validating against known-good sources. There is no public DBC file for this car. The Ioniq 6's B-CAN carries 397 distinct CAN IDs. The firmware currently decodes 34 of them.
The details of how all of this works are the subject of the rest of this series.
why now
It's been nine months. I started with a $15 BLE dongle and a Python script reading OBD PIDs in a parking lot. That turned into passive CAN decoding, then a custom PCB, then a Go backend, then an iOS app, then signed OTA updates, then a fleet management console, then secure boot with burned eFuses.
Along the way I cracked a CRC polynomial only to have the BCM ignore my injected frames. I desoldered a capacitor to fix a PSRAM bus conflict. I discovered that my car's OBD port has non-standard pin assignments. I mined 2.1 GB of CAN logs with a correlation scanner and found a speed signal with r=0.997. I bricked a board with a bad OTA and watched the boot-loop rollback save it.
The project has been closed source so far. I'm planning to open parts of it up. But first, the story.
In the next post: I sit in my car at night with a terminal full of hex, and by morning I've decoded more battery data than Car Scanner shows.