Telemetric devices for vehicles, better known as black boxes, cracked the consumer scene 25 years ago with the premiere of OnStar. These days, you can get one for free from your insurance company if you want to try your luck at the discounts for safe driving game. But what if you wanted a black box just to mess around with that doesn’t share your driving data with the world? Just make one.
[TheForeignMan]’s DIY telematics box was designed to pull reports of the car’s RPM, speed, and throttle depression angle through the ODBII port. An ODBII-to-Bluetooth module sends the data to an Arduino Mega and logs it on an SD card along with latitude and longitude from a NEO-6M GPS module. Everything is powered by the car’s battery through a cigarette lighter-USB adapter.
He’s got everything tightly wrapped up inside a 3D printed box, which makes it pretty hard to retrieve the SD card. In the future, he’d like to send the data to a server instead to avoid accidentally dislodging a jumper wire.
If this one isn’t DIY enough for you to emulate, start by building your own CAN bus reader.
I like the idea. One thing that could be interesting to compute in there is fuel economy. For cars that have ODBII, but aren’t that new, you don’t get a fancy display of real-time (or near real-time) fuel consumption. Part of me like the idea of retrofitting newer features to older vehicles.
Part of me wonders if data coming from a device like this could be used in court to fight a traffic ticket, if you were in the right. The problem with that is making sure that you wouldn’t be able to edit the data part way through a series of measurements. I wonder if you could take a hash of the previous values in the chain, and then that hash is used in the next measured point, and so on – any tampering of the data would require tampering with the entire chain. I suppose another option would be to upload the data to something like Dropbox where you don’t have control over the created dates on the 3rd party service – essentially relying on someone else to verify the audit log. A bit like mailing yourself a sealed envelope, relying on the postal service to timestamp the sealed document.
” (or near real-time) fuel consumption. ”
SWMBO’s car has an MPG readout, over the years I’ve logged Date, Miles, Gallons, Price per Gallon, Total Price of Fillup, on an OpenOffice spreadsheet. With that input I calculate overall MPG, Total Gallons Used, Total $ Spent (on gasoline).
Let’s just say, that the manufacturers readout is a bit optimistic.
Given the stack up of errors and tolerances that are probably inherent within either method you compared, I wouldn’t expect them to agree. I have recorded similar data for decades, but have always considered the results as relative at best, far from precise.
I do that with the aCar app
I would like to go one step further (which probably means I’ll never get started! B^) and log GPS time as well as DashCam footage.
Or just buy an autonomous vehicle and have the press and online bloggers defend your reputation.
You can easily get consumption data from any “classic” fuel injected gasoline engine.
The injectors are controlled by either applying a voltage or leaving them open (with a clamping diode).
You can detect the pulses delivered by the ECU to the injectors with basically any MCU (just adapt the 12/24V to your logic-levels). While there are some non-linearities in the opening and closing they do cancel out quite well and all you are left with is a “dead-time” for each pulse where there is voltage on the injector but no flow.
All you have to do is count the time (eg timer-cycles) for each injection pulse (timer-capture events are very useful here), subtract a fixed value (injector-dependant, ~1ms) and integrate the result over time.
If you want l/100km you just count your speedos speed-pulses and divide accordingly.
You only need to capture one injector as the ECU just fires the sequentially with the same pulses.
In modern engines (especially direct-injected but also some MPI) the pressure of the fuel-rail and subsequently the flow-rate is often varied by the ECU making it harder to pull useful data.
Thanks DerMax1993,
Ah, this used to be my main area of expertise from time of my uni thesis 1982 for “Electronic Fuel Injection and Transmission Control”. Bit optimistic at the time, the transmission control aspect didn’t eventuate except in terms of EFI stability feedback issues upon gear changes. Running CP/M on a Z80 with the non markable interrupt delivering trigger for efi, though things have advanced a lot since I adapted VW Kombi parts onto a carbie 1600cc Kent motor in a 1972 Ford Escort. Went well used to rally in hills east of Perth, Western Australia…
The point in respect of your comment about the clamping diode, they are generally not used due to it lengthening the minimum injection opening time and due to diode characteristics re temp affectingvariability which affects ECU stability. Instead they either let the flyback collapse along the length of the cables and/or with likely use of Metal oxide varistors (MOVs) set at over 100v or so. Of course the switching transistor with higher voltage ratings, in earlier days 200v BJTs with some snubbers until about 15yrs back power MOSFETs rated at 400v or so but, with MOVs too. So when u want to reliably measure pulse width be aware vehicles can be very different on flyback noise snubbing depending on age, wiring corrosion over time (PVC degradation), cable routing affects sensors and even adding a hobby instrument can induce more sensor noise by varying the dynamic which affects overall ECU stability and maybe when you really need it.
Get a cro with a good frequency response and likewise probes also compensated and watch the narrow high volt pulses when injectors fire on older vehicles and even back at the battery as the ostensibly low DC impedance there not nearly enough to provide any useful attenuation. So also then accept your 12v DC power source likely not at all clean.
Not certain these days ie from about 10 yrs ago, I’ve moved into food science and microbiology crafting my own supplement formulations though still dable in industrial instrumentation and remote area power systems.
The android app Torque pro and a wireless OBDII module is super functional in this regard. You can make an electronic dashboard with a number of given OBDII parameters and computed parameters like instantaneous fuel per distance. You can make a log of what parameters you want and have it emailed or whatever at the end of each trip. There is an extension that can take video and overlay parameters, but it is a little clunky. I was hoping to use it as a dashcam with an overlay that constantly rewrites the previous minute of footage and sends the previous minute plus the trip log if an acceleration spike is recorded but that was asking too much of it.
“An ODBII-to-Bluetooth module sends the data to an Arduino Mega and logs it on an SD card along with latitude and longitude from a NEO-6M GPS module.”
Use to do something similar. Combined with maps and altitude one could certainly see how one’s engine was doing.
A couple of years ago I was intrigued by the engine temperature of my 1977 VW Kombi so ran the speedbox app on my phone to log speed and altitude. A temperature logger in the oil. I had to manually corolate the data after a 300km trip and it was quiet interesting to see how engine temp was effected by speed and gradient and also that the temp would rise when stopped to refuel.
Why black box is not orange?
he’s not fighting the combine this time. just some good ol’ engineering.
It’s because of the unforeseen consequences of not being able to count beyond 2.
Because it is not designed as flight hardware :-)
Why didn’t they build the rest of the car out of the same material as the black box?
Hmm, I might consider something like this when my kid hits driving age in a few years. I’d probably go with a RasPi, small SSD, dash cam, and GPS. Could all be installed in a small enclosure under the hood except for the cam.
How dare you spy on that innocent child!
Just Kidding!
Such a setup might just save you a mint if there is an accident. I was in an accident where I went through a green light and was plowed in the side by an older woman. After her husband came up to me and said “I don’t know what she was thinking” she lied to the cops and told them it was green. The cops didn’t write either of us a ticket, I just had
liability(older truck) so i was stuck with a screwed up truck. If I had had this setup I could have made her insurance pay. Nowdays, you can by this essentially premade.for about $50 USD.
Just make sure the child isn’t a geek and can disable it!
I was “always” (at least from teenage age on) better in electronics and computer stuff than my father. And pulling a fuse is not that difficult.
A lot of the nicer dash cams now already have GPS built-in for speed tracking
A few dashcams have had GPS for years, it’s g-sensors and OBD logging thats just started becoming more popular often via Android dash radios and ELM BT adapters, I’am just starting research into OBD data and it’s a rabbit hole of standards and non compliance , matched with misleading information or NDA’s, throw in on top of that teritorial’s differences and you got a load of fun and games ahead. btw if anyone if curious I’am making a open source replacement firmware for a commercial cheap OBDII scanner
https://hackaday.io/project/158560-om127-reboot
I still have a lot of documentation to update but all the sources are up so dig into this rabbit hole we call OBD standard. also the is a sister project called J2534-pic which is ment to be a replacement ELM327 clone firmware for pic18f25k80 devices.
But then you have to be sure, that this data does not come into wrong hands (police).