This started the way most of my projects start: with a problem in the driveway. The S60 had a check-engine light I wanted to actually understand, and I wanted always-on GPS and diagnostics without handing my car's location history to some subscription app. The commercial telemetry dongles that do this are capable little devices — but they're black boxes you rent access to, and I've never been able to leave a black box alone. So I studied the best one I could find (a Freematics ONE+) to learn exactly what "good" looks like, and then set out to build our own — equal in capability, and then better.
Then the project did the thing projects do when they're good: it refused to stay small. Somewhere between cracking the GNSS wiring and watching live telemetry stream off the highway onto my own dashboard, the goal stopped being "log my Volvo" and became something much bigger: build the whole platform ourselves. Our own hardware, our own dashboards, our own cloud — and an open-source developer library so the device is programmable by anyone, not just us.
That platform is Drivon.
What Drivon is
Drivon is a car-telemetry platform being built from the ground up, as a family of pieces that snap together:
- Drivon Link — the in-car device. ESP32-class, reads the car over OBD-II/CAN, carries its own GNSS and motion sensing, and pushes live telemetry over wireless.
- Drivon Core — the open-source Arduino C++ library that powers it, and the part you can use today. This is the developer surface: write a sketch against Drivon Core and the same code runs on supported off-the-shelf hardware now and on Drivon Link later.
- Drivon Dash — live gauges, maps, trip history, and diagnostics in the browser.
- The car emulator — a bench dongle that pretends to be a car: it answers OBD-II requests with a configurable simulated drive (RPM, speed, coolant, fault codes), so you can develop and test telemetry hardware at a desk without a vehicle. It's the companion tool to the unit — and useful to anyone building against OBD-II, not just us.
The philosophy borrows from what made the best dev-tool companies work: sell polished hardware, but keep the programming surface open. Your telemetry unit shouldn't be a black box you rent access to. It should be a dev board that happens to live in your car.
Earned the hard way: what the prototype taught us
We've spent the last month proving the concept in a real car on a real cellular connection, and the lessons are the kind you only get with a device rattling around in traffic:
TLS doesn't survive weak cellular. Our early builds pushed telemetry over HTTPS and mysteriously died in the car while working perfectly at the desk. The culprit: the TLS handshake to the CDN edge, over an LTE hotspot at highway speed, would stall for seconds per push. The fix that made the whole thing rock-solid was almost embarrassing — drop TLS, POST plain HTTP with a bearer token, cache the resolved IP so DNS (the flakiest step of all) happens once instead of every second. Pushes went from multi-second coin flips to sub-second, every time, even at terrible signal.
Never let the car bus block the network. Talking OBD-II to an ECU can stall — for seconds, or forever if the ignition's off. If your firmware initializes OBD before WiFi, a sleepy bus bricks your connectivity. So the architecture splits the work across the ESP32's two cores: sensors and OBD polling on one, a dedicated network task on the other, with OBD brought up lazily in the background. The car can sulk all it wants; telemetry keeps flowing.
Trust the wiring, not the datasheet. A GNSS module "didn't work" — until it turned out its TX/RX were swapped relative to what the stock firmware probed, on a different pin, at a baud rate nobody documented. Twelve-satellite fix indoors once we found it. Every hardware project has one of these; this was ours, and it's exactly the kind of thing you only learn by owning the whole stack instead of trusting someone else's firmware.
Drivon Core is on GitHub now
All of those lessons are now baked into Drivon Core, released this week under MIT. It's a clean Arduino library — works in the Arduino IDE and PlatformIO — and the developer experience is the whole point:
#include <Drivon.h>
Drivon car;
void setup() {
car.begin(); // OBD + GNSS + IMU up
car.wifi("MyHotspot", "password");
car.cloud("http://yourserver.com/api/ingest", "TOKEN");
car.onDTC([](const char* code){ Serial.println(code); });
}
void loop() {
car.update(); // pump sensors + push
if (car.obd().connected()) Serial.println(car.obd().rpm());
DrivonGPS g = car.gps();
if (g.fix) Serial.printf("%.5f, %.5f\n", g.lat, g.lng);
}That's a complete telemetry unit: engine data, trouble-code alerts, GPS, and a cloud push that survives bad cellular — in about fifteen lines.
Under the facade there's a hardware abstraction layer, and that's the strategic piece. The primary target is our own hardware — a plain ESP32 wired to a $2 CAN transceiver, where Drivon Core speaks the OBD-II protocol itself with a from-scratch ISO 15765-4 stack on the ESP32's built-in CAN controller, including the multi-frame reassembly you need to pull a VIN. The same library also has a board for the commercial dongle we benchmark against, so we can prove parity and then pull ahead. When Drivon Link hardware ships it's just another board entry — nobody rewrites their sketch.
What we're aiming to provide
The end state we're building toward:
- A telemetry unit you own — plug it into the OBD-II port, get live gauges, trip logging, fault-code decoding, and geofencing on your own dashboard. No subscription seat on someone else's cloud unless you want one.
- An open developer platform — Drivon Core now; Drivon Script, a higher-level automotive language on top of it, later. If you can write a sketch, you can make the device do something we never thought of.
- The bench emulator as a first-class product — because everyone building car tech has the same problem: the car is in the driveway and the desk is not. A configurable ECU-in-a-box fixes that for us and for anyone.
- Honest engineering in public — the library ships with its design decisions documented, including the unglamorous ones like "plain HTTP on purpose, here's why."
Where it stands
Version 0.1.0 of Drivon Core is real code that compiles today — the facade, both board layers, four examples — and it was put through an unusually brutal review before release (more on that process in a future post; short version: dozens of independent adversarial passes over the protocol code, and every confirmed finding fixed before shipping). We've already streamed live OBD + GNSS + motion data from a moving car to this site's private telemetry dashboard. Now the real build begins: our own hardware. We're wiring virgin ESP32 and Teensy boards into proper OBD-II plugs and cases — an in-car unit and a matching car-emulator "car in a box" — so we can flash our own firmware and run the whole loop on gear that's ours end to end, no borrowed dongle in sight.
Build with Drivon Core. Program with Drivon Script. Connect through Drivon Link. Visualize in Drivon Dash. That's the plan — and the first piece is now yours to play with.