If you are working with OBD2 hardware or software, it’s easy enough to access test data, simply plug into a motor vehicle with an OBD2 socket. If, however, you wish to test OBD2 software under all possible fault conditions likely to be experienced by an engine, you are faced with a problem in that it becomes difficult to simulate all faults on a running engine without breaking it. This led [Fixkick] to create an OBD2 simulator using a secondhand Ford ECU supplied with fake sensor data from an Arduino to persuade it that a real engine was connected.
The write-up is quite a dense block of text to wade through, but if you are new to the world of ECU hacking it offers up some interesting nuggets of information. In it there is described how the crankshaft and camshaft sensors were simulated, as well as the mass airflow sensor, throttle position, and speedometer sensors. Some ECU inputs require a zero-crossing signal, something achieved with the use of small isolating transformers. The result is a boxed up unit containing ECU and Arduino, with potentiometers on its front panel to vary the respective sensor inputs.
We’ve brought you quite a few OBD2 projects over the years, for example, there was this LED tachometer, and a way into GM’s OnStar.
Thanks [darkspr1te] for the tip.
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.