Open OBD2 datalogger
This is a fully open-source car datalogger that reads engine data using the OBD2 interface in real time and stores it on an SD card. It also stores GPS data. All communication is done directly by the MCU without a translator chip like ELM327 or STN1110. The datalogger supports all CAN and K-Line OBD2 protocols. All hardware fits into an off-the-shelf OBD2 connector enclosure.
This project is available on Github.
Example log
This is a sample log from a hybrid car (that is why it may look strange in some places). All ODB2 PIDs can be automatically detected. Visualization is done in local web application using HTML5 and JavaScript.
Hardware
The device is designed to fit an off-the-shelf enclosure from Aliexpress. If the link breaks - search Aliexpress for "OBD enclosure" and look for a white model with 3 LED holes and a right angle through-hole connector.
Because of the small size of the enclosure the PCB has components on both sides. The only "dangling" thing is the backup battery for GPS (to speed up time to fix) that has to be mounted on top of the SD connector with double-sided tape.
Some major components:
- Kinetis KE06 microcontroller with 128KB flash
- PA6C GPS module + backup battery
- SD card slot
- CAN transceiver
- K-Line and L-Line transceivers built from discrete components
- LEDs
- voltage regulators
There is no radio so the device is physically "unhackable" remotely (unlike hardware that has for example Bluetooth or GSM modules). The datalogger can be plugged all the time in the car. It uses aggressive power saving when engine is not running so should not drain the battery much (some cars power the OBD2 port all the time).
First prototype PCB required some extra wires to work properly :) The published PCB is fixed. There is an extra pin header (hidden below the GPS module when looking at the top side) that has two UARTs some GPIO and 12V. It could be used with a daughterboard to add wireless connectivity, for example to implement tracking and telemetry.
Software features
The device has just 3 LEDs for indication (they show: SD status, car connection, GPS fix), apart from that all the interaction with the datalogger is done via an SD card. Daily operation is fully automatic. SD cards up to 32GB are supported. They must be formatted with FAT32.
When the datalogger senses voltage higher than 13.3V it wakes up. This voltage threshold is exceeded when the engine drives the alternator and the battery is getting charged. After waking up the device initialized the SD card, tries to read configuration file (if present) and reads last used OBD2 protocol (if present) to speed up initialization. Establishing connection with the car usually takes less than 3 seconds.
All data is stored in "OBDLOG" directory. The log is written to a temporary file first. When GPS fix becomes valid that file is renamed with current date and time. New firmware can also be read from the SD card. Update is automatic and takes several minutes (due to firmware verification and decryption).
Internally the device runs FreeRTOS. It sounds like an overkill to have an operating system for a device that reads data with one interface and writes it to another interface. I have chosen FatFS library to handle the filesystem. FatFS API is blocking, ie. the function returns when an operation is done. A write()
for example includes several SPI transfers to the SD card. This would effectively block the whole application while the SD card is busy. FreeRTOS solves this problem, because when SPI transfer is started the filesystem storage task can be blocked and wait until the (interrupt driven) transfer is done. This frees up time for the acquisition task that can now communicate with the car. After sending a request the acquisition task also has to wait and block itself until the car replies. Both tasks are connected with a queue. Overall using FreeRTOS in this case leads to more maintainable code that is easier to follow.
Feel free to contact me if you have questions or want a commercial license for this project.