Menu:

• Main
  

Build a Compact Digital OBD-II Speedometer Gauge

What happens when sunshine on your dashboard stops you from seeing how fast you're going? I came up with a cheap solution to this deadly serious problem on my Mitsubishi Pajero. This design can also form the basis of
all sorts of other OBD-II based gauges for your car.

Introduction

I reckon Mitsubishi might just be trying to kill me.

OK, sure, that’s something of an exaggeration. But, after driving my new Mitsubishi Pajero for a few days, I was rapidly coming to that conclusion. Mitsubishi seemed to have made a car that could, just maybe, get me very quickly killed around here.

A little background. I work in Saudi Arabia, and when it comes to driving, Saudi Arabia is a world leader. It’s probably one of the most dangerous countries in the world to drive a car. On average, 24 people die every day on the roads here. Some think this count to be understated. I've been told that if a traffic accident-related death occurs in the ambulance or after the injured party has reached hospital, that death not included in these numbers. If that’s true, then the actual number of deaths from driving might be as high as 30 per day, or perhaps even more.

But let’s assume those official figures are correct. By the way, that number is up from 17 deaths per day about five years ago. Clearly, then, the efforts to improve road safety in Saudi Arabia, such as new red light and speed detection cameras, are having an effect. Maybe not in quite the direction that might be assumed.

But just how bad is it really? Table 1 suggests driving in Saudi Arabia may be up to fifteen times more deadly than my home country, and perhaps over twenty times more lethal than the UK. Yikes!




But what’s all this got to do with my 2015 Mitsubishi Pajero? Well, just before summer (2015), I needed to buy a new car. After a lengthy search, I decided to purchase the Pajero. It looked fine in the showroom. (It’s pretty much impossible to arrange to test-drive new cars in Saudi Arabia, in case you’re wondering, no rentals were available for me to road test, and my mates drive other brands)

Once I got it out on the road, I quickly discovered that it was impossible to read the speedometer while driving almost anytime during the day. Everything else was just fine, thanks. Just that speedo. Turns out, other Pajero owners complain about this too, judging from various web forums.

Unlike most countries where this problem might just be a bit of a nuisance, this can present a deadly risk in Saudi Arabia. Dangerous driving is commonplace here as you might have guesed from those statistics. Basic road rules seem to be largely ignored. The result is driving mayhem, with speeding and unpredictable driving a constant risk. Hardly a day goes by on my regular commute to my office when I do not see at least one significant accident. (140kph on a suburban street? Exiting a motorway using the ON-ramp? Driving on the wrong side of the road? Road bullying at 120kph on busy multi-lane highways? Unannounced turns across multi-lane intersections? Driving through red lights in rush hour during the day? Yes, all regular events here)

And then we have the speed cameras, introduced to address some of these problems. Some camera locations are well known, such as at major city intersections where driving through red lights is otherwise routine. Other speed cameras, however, are randomly moved from place to place along busy highways, and sometimes partially hidden. Many of these are placed periodically at known danger spots.
As cars approach a known fixed camera site, they all obediently slow down. However, with the randomly placed cameras, brakes often get applied late and hard. Cars following too closely, another common practice, abruptly and unexpectedly swerve to avoid the braking vehicles. The results can be quite chaotic. Multiple car pileups are common, frequently close to these speed cameras.

In general, then, it’s vitally important to keep a close eye on your speedometer. The problem I found was that the Mitsubishi’s instrument cluster design makes that practically impossible during the day. The instrument cluster uses black plastic pointers topped with a thin red line set against a greyish background with shadowed pale grey numerals. Mitsubishi’s designers then placed these gauges down the bottom of a pipe-like cylinder. The result in daylight is a shambles. That instrument panel becomes difficult to read, even with the panel backlights turned on. When wearing sunglasses, essential for driving here most of the year round, those instruments become utterly impossible to see.

If a driver is struggling to read the speedo, perhaps looking for a longer than desirable time to check their speed, or trying to keep a close eye on the car’s speed while approaching a speed camera, trying to avoid the erratic drivers around them, you can begin to see my problem. In my opinion, Mitsubishi delivered a gilt-edged invitation to an accident, or worse, with this instrument cluster design.

I had to sort this problem out, and quickly.

Possible Solutions

One option for me was to buy one of the many “head’s-up display” (HUD) speedometers advertised on well-known websites. These display speed and other vehicle parameters by reflecting the light from a bright LED or LCD digital display onto a special semi-transparent film placed on the inside of the vehicle’s windscreen. Reviews are mixed, some noting blurred displays, and others noting the display is often washed out by bright sunlight. A further common complaint is the slow update rate – About once per second, too slow for my application. And they are not particularly cheap.

Another option was to mount a small cellular phone on the dashboard to show the required information. This could be connected with some form of interface to determine my car's speed. However, I was not able to find a phone small enough to fit neatly on the dashboard nor software that could display just one or two parameters clearly.

One design I came across during my search of a solution used a low cost GPS receiver module, a small processor, and a display to report vehicle speed. Again, the relatively slow once-per-second update rate and the need to display speed accurately in tunnels, under bridges and in long underpasses, places where GPS satellites cannot be seen by the GPS receiver, ruled it out for me. Speed cameras are located in such spots in Saudi Arabia, or worse, just on the bright sunlit exit of a dark tunnel. (Amazing to see how far up the tunnel wall a large 4WD crashing at 100+kph can climb before gravity takes over...)

So, after a fairly comprehensive search, I decided to design and build this simple low-cost design. It uses a compact high contrast OLED LCD, a small microcontroller, and a widely available OBD-II  interface. A purpose-designed 3D-printed enclosure I made for the display completes the package. Its small size and ultra-thin form-factor allows it to be placed almost anywhere around the dashboard to suit the driver.

The OBD-II Interface

All vehicles built since about 2008 are required to be fitted with an OBD-II interface. “OBD” stands for “On-Board Diagnostics”. The OBD-II system follows a set of industry standards, including the connector and its location, close to the driver. It uses a high speed two-wire bus which connects a variety of subsystems. Communications across this bus typically run at 500kbps although bus speeds may range from 125kbps to 900kbps. This OBD-II bus can therefore be used to access a wide variety of vehicle information including vehicle speed, engine rpm, oil temperature, and a variety of other details.

Low cost OBD-II interfaces are available from the usual Chinese sources. These allow users to obtain information from the OBD-II system via USB and Bluetooth. One of these, an ELM327 compatible OBD-II to USB interface, was purchased for this project. it cost me about $US5. Simple serial data commands can be used with this interface to interrogate the car’s ODB-II systems, typically at 9600bps or 38,400 bps, although serial speeds up to 115,000 bps are also possible.
















Either of these OBD-II modules can be plugged into the car’s OBD-II system. The OBD-II connector is usually located under the dashboard, near the driver. Depending on the type of OBD-II module purchased, it then connects either via a USB cable or Bluetooth (or occasionally WiFi) to a laptop, tablet or mobile phone, as appropriate.

In my case, I decided to use the USB cable version. I removed the USB cable, and mounted an additional microcontroller into the module. A short cable was added to connect the new microcontroller to a tiny LCD mounted on the instrument cluster. Then I wrote some software to make it all work.

You can see the display operating in the photo at the top of the page. This bright LCD display shows the required information immediately in front of the driver (me!). While it’s a small LCD, the contrast on these OLED graphics LCDs is simply superb. It readily permits the required information to be seen at a glance, or from the corner of my eye, without effort.

The interface with the OBD-II module is handled by an Atmel ATtiny85 8-pin microcontroller. This is fitted inside the original OBD-II module. Its compact 8-pin package, along with the slim LCD and the compact 3D printed purpose-designed 3D-printed display enclosure, makes for a safe, cheap and easily readable dash-mounted accessory. The unwanted USB cable from the ODB-II module was discarded.

Inside the ODB-II Interface Hardware

Almost all OBD-II ELM327 USB interface contains three chips; A chip to handle the hardware level interface to the vehicle’s CAN bus, the ELM327 microcontroller and a USB interface chip. Functionally, it boils down to this:



This ELM327 module is modified slightly in my design to allow the ELM microcontroller’s serial lines to be connected to the new ATtiny85 instead of to the serial/USB chip. That chip is typically a Chinese-made PL2303 or CH340. After the modification, this USB chip is no longer used.




There are several similar designs described on the web. However, these all assume the ELM327 USB interface contains a standard ELM327 processor. This is very rarely the case now, most having been replaced by low cost Chinese clones. Several of those other designs I came across also made a similar modification to the serial I/O lines on the processor, but they also added a further change to force the ELM processor to slow its serial comms down to 9600bps. Here's the problem: That’s does not appear to be possible with the latest clone processors. With their different pinout, as far as I could determine, it did not appear possible to make the same change to reduce the serial I/O speed. So, my design rose to the challenge of using the very much faster standard 38,400bps serial speed.

All of the graphics information for the OLED LCD must be sent to it by the ATtiny85. Unlike low cost 2 line x 16 character alphanumeric LCDs, the OLED LCD contains no character or graphics lookup tables. However, it can take some time to send all of the required data to the display over its I2C bus. To speed up the process, the ATtiny85's internal clock operates at 16MHz, and LCD data is only sent to the areas of the display which require a change. This ensures a swift flicker-free display.

The 128 x 64 pixel OLED display can support a wide range of display graphics. I designed the large speed digits using a 40 x 32 pixel per digit format for high readability. The associated “kph” or “mph” units, selected using an on-board jumper, are displayed within a similar pixel space, but using a slightly smaller font size. The speed digits are updated around ten times per second to ensure the best possible response time.

The remaining 128 x 24 pixel space is used for a bar-graph display. This is used to show a slowly changing parameter. I chose to show the engine coolant (i.e. oil) temperature. A small “thermometer” icon completes this section of the display. Because oil temperature changes gradually, the bar-graph is updated about once every 30 seconds.

This bar-graph also features an expanded temperature display format. Temperatures are compressed slightly at the hot and cold ends of the bar-graph to provide more detail over the "normal" temperature range of interest. That means the driver will be able to react more quickly to significant changes in oil temperature.

The OBD-II system allows oil temperature to be reported over a range from -40C to +215C. Mitsubishi’s manuals indicate that the ‘normal’ range for the engine oil temperature is around 70C to 90C. That normal range is centred within an expanded 60C - 120C range across about 50% of the bar graph. (The upper numeric values shown in Figure 4 are not shown on the OLED, only the lower C, H and normal boundary markers)
 

Schematic and Circuit Description

The schematic shows the circuit details for the ELM327 interface modification. It's a very low compoment count modification.


Power for the ATtiny85 is obtained by tapping onto the onboard 5V regulator inside the ODB-II USB interface. It has a more than adequate margin to cope with the very modest additional current requirements of the ATtiny85 and the OLED LCD. Protection against potential voltage spikes on the incoming 12V OBD-II supply, particularly when starting the vehicle, is already fitted in the OBD-II interface. This also protects the ATtiny85 and the LCD from possible damage during vehicle starting.

The ELM327 processor’s RxD and TxD lines connect directly to the ATtiny85 microcontroller after the modification. Commands are send via this serial interface to the ELM327 chip by the ATtiny85 to request speed and other information. The response from the ELM327 chip returns from its serial output. The data is then checked and processed by the ATtiny85 and sent to the LCD for display. The OLED LCD uses a standard I2C two-wire interface comprised of a serial data (SDA) and a serial clock (SCL) line.

A small jumper is available on one ATtiny85 pin (Pin 6) to determine if the speed is displayed in metric (kph) or legacy (mph) units. Leaving this link open places the speedometer in the metric (kph) mode.

One problem remains unsolved. Power to the OBD-II interface and add-on electronics must be manually turned on and off. The OBD-II connector does not contain any wiring to indicate when the ignition switch is on. The battery supply is wired directly to the OBD-II socket and is always on. If the OBD-II interface is left powered up at all times, the car’s battery will eventually run flat. For simplicity, a simple miniature toggle switch turns power on and off to the OBD-II hardware.

There is a spare pin remaining on the ATtiny85 which is reserved for a possible future update to this arrangement.

Parts List

These are the parts you’ll require:



All the parts required should come to less than $20 if purchased new. In my case, only the ELM327 USB module and OLED LCD had to be purchased. The remaining parts came from my parts bin.

Disclosure Statement: I get no commission, free stuff, or any preferential treatment from any of the companies mentioned here. There are other suppliers who are probably equally suitable. This table is simply a useful way to show examples of the parts used.

Construction

The prototype was assembled onto a 12 x 10mm scrap of prototyping board. The ATtiny85, bypass capacitor and the LCD connector are all fitted on this board. I used a socket for the processor. A four-way pin connector is then fitted to the board for connection to the display. I cut down a 4-pin header from a longer 20-way strip, and cut down a matching 4-way connector for the cable-side from its matching 20-way socket. Other options exist, including simply soldering the cable directly to the board.

I didn’t design a PCB for this project – It was so simple, it just wasn’t worth it for a one-off project like this. In any case, it's nearly impossible to make a PCB here. Of course, if I was making 100 of these, I certainly would whip up a PCB, and I’d probably use SMD parts to make it even near-microscopic in size.Anyway, back to my story...

The ELM327 OBD-II USB interface is then opened and modified. The front panel artwork is peeled off to reveal the four screws that hold the assembly together. The OBD-II connector and USB cable each plug into the PCB. Take a careful note of which way around the OBD-II connector goes, and then remove both it and the USB cable from the PCB. The PCB can then be removed from the enclosure.

The next step is to disconnect the USB chip’s TxD pin from the circuit. If you have a module fitted with a PL2303, then carefully heat pin 1 of the PL2303 chip with a soldering iron fitted with a fine tip, and then very gently lift the pin up off the PCB track. (If you have the CH340G USB chip, lift pin 2 off its PCB pad instead)











Figure 6 : Modification to pin 1 of the PL2303 USB chip in the ELM327 USB module





This modification ensures there is no contention between the TxD output of the now-unused USB chip and the added TxD output coming from the ATtiny85.

Now, drill a small hole in the enclosure cover for the small toggle switch. I used the smallest switch I could find, and it easily fitted into the box. Then modify the +12V supply wiring as shown in Figure 7.


I found it easiest to begin by removing the white wire from pin 16 of the OBD-II connector. This wire normally connects directly to the 8-way connector which plugs into the ELM327 board (I removed it from its box during this step) I then soldered the wire to the switch. I then added a short piece of stranded yellow hookup wire between the other side of the switch and pin 16 of the ODB-II connector.

Solder four short wires to the ELM327 PCB for the ATtiny85’s +5V, ground, RxD and TxD connections, and connect these to the ATtiny85 board. This wiring is shown in Figure 8 and Figure 9.

That green wire (RxD) is soldered on to the SMD part as shown, and then goes to pin 2 on the ATtiny85. The white wire (TxD) is soldered onto the adjacent part, and then goes to pin 3 on the ATtiny85. The brown wire is soldered into the centre hole on the left hand edge of the ELM board above, and it then goes to pin 4 (ground) on the ATtiny85.

Pause if necessary now to program the ATtiny85 and to make the 3D printed enclosure for the display.

Programming the ATtiny85

There are (at least) two ways to do this. The first option I’ve used is to build and use the Ponyprog programmer. However, this requires your computer to have an RS-232 interface. Those are exceedingly rare these days, although I have made the programmer work using a USB-RS232 interface cable.

I strongly recommend you use the second method, using a USBasp programmer.

Ready-to-use USBasp programmers can be purchased from any number of Chinese suppliers over the web, usually for less than $US3 delivered. Examples include Banggood (SKU064451 or SKU131560, for example) and Hobbyking (e.g. Part 381000147). Note: These part numbers vary periodically.

GUI software to drive the programmer is available (free) from various websites. I have used Khazama extensively, but more recently, I’ve also found Extreme easy to use with this USBasp programmer.

Unfortunately, these websites seem to provide very limited support for anything more than a limited range of basic AVR processors. For that reason, I’ve either had to locate or, in many cases, had to develop several updated files for these software packages to add a number of the more commonly used processors. To help others in the same situation, I’ve included the updated files below in the Download section for the Extreme software. Once the original Extreme software has been downloaded and installed on your computer, just unzip the ExtremeFiles.zip file I’ve included below, and copy the two unzipped files (chips.xml and fuselayout.xml) into your <Program Files/eXtreme Burner – AVR/Data> folder (That’s the location of these two files on my Windows 7 computers anyway. Other installations may vary this) to replace the original files of the same name found in that directory.

Note: Computers vary, and nothing is guaranteed for you and your computer. Take care to backup your existing files before adding any new software like this to your computer. I make no warrantees or guarantees for any of this stuff. It’s all at your own risk. It worked for me, and it should work for you. Not all software I try works, and the same thing will certainly be the case for you.

Two steps are then required to program the ATtiny85 with the USBasp programmer – The flash memory must be programmed with the program software, and the processor’s fuses must also be correctly programmed. Details of the fuse settings are found at the start of the source code file.

I programmed the ATtiny85 using a secondary board which has a socket for the chip and the 6-pin programming header. There was no room for the programming header on the little board I added to the ELM327 module but you are free to add the programming socket to your version if you wish. The circuit diagram for my adapter is shown in Figure 10 just in case you need to duplicate it. The resistor and LED are optional. They were added to show me when power has been applied to the programming adapter.
(Note: The ATtiny85 to be programmed goes into socket SKT1. The USBasp programmer is plugged into the 6 pin plug J2. 5V power comes from the programmer via J2 so J1 is normally unused)

If all of this remains a mystery for you, there are some helpful tutorials on this topic that can be found on the Adafruit and Instructables websites.

Making the 3D Printed Enclosure

In order to retain the advantages of the compact OLED LCD, I also designed and made a simple plastic enclosure to hold the display. When it clips shut, it also clamps onto the connecting cable. I printed it using standard black PLA plastic. The chosen colour (black) as well as the overall compact size of the enclosure allows the display to be placed almost anywhere around the instrument cluster.


The front and back sections comprising the display enclosure were printed on a low cost Printrbot Simple Metal 3D printer using PLA fibre (No heated platform). It took less than 20 minutes to produce the required parts. The required STL-format files are available for download below.

The cable running to the ATtiny85 board in the modified OBD-II module is first soldered to the OLED display. The OLED display then drops directly into the front half of the display enclosure. There is no need for any additional hardware. The back panel then just clips into place and holds the assembly together. It simultaneously clamps the 1.2m long connecting cable. (The cable cutout/slot in the case goes to the bottom-right corner when viewed from the front) 

I used standard 4-conductor telephone cable initially because it was to hand.  I later swapped it for a less-visually intrusive small black cable. As noted earlier, the other end of the cable should be soldered to a 4-way socket to plug into the ATtiny85 board.

You may need to make your cable slightly longer or shorter depending on where you decide to place the display. Measure first (I used a piece of string to work out the cable route and length), then cut your cable to the right length allowing a little extra for the connector and board connections.

Completing the Construction

Carefully plug the display cable into the ATtiny85 board. Check it’s the right way around! Then replace the OBD-II PCB and ATtiny85 board into place  and close up the OBD-II enclosure. If necessary, use a drop or two of hot glue to hold everything. I didn’t require it in my version, but you might find it useful.

Finish up by mounted the display in place on the dashboard with a scrap of double-sided sticky foam.

Operation

Make sure the power switch is off on the OBD-II module before plugging it in. Turn the power on and confirm the power-on “splash” screen is shown on the LCD. It briefly shows a suitable logo and label. The display then reverts to the speed and bar-graph display. Start your car and do a careful test drive. (Do I need to add a warning about testing this in an area without other drivers, small children and large camels?) The module will now report your speed and oil temperature.

The oil temperature bar graph display is initially blank since no data is reported by the OBD-II system. After about 30 seconds, the bar graph is updated to show the initially ‘cool’ engine oil temperature. The temperature rises steadily into the ‘normal’ area of the graph within a minute or two, at least for my car.
When I arrive at my destination and turn the ignition switch off, I then turn off the toggle switch to turn off the speedo.

Here’s a picture of it all running during my first tests with a temporary ugly white cable.

The engine is running, the instrument cluster backlights are on (Yes, you CAN see the instruments clearly here, but it was about 5pm, close to dusk, and almost no sunlight was falling onto the dashboard). The speedo is reporting 0 kph (I was stationary while taking the photo!) and the oil temperature is nearly centred in the ‘normal’ range.

I later tested it against my GPS-derived speed at a range of speeds (with a helpful assistant) and found it to be within 1kph across the range. Adequate for my purposes.

Changes and Modifications

Yes, it’s possible to change the software to display all sorts of other OBD-II parameters. However, the car’s OBD-II system must support the specific parameters you wish to display.

VERY IMPORTANT:

OBD-II parameter support varies between vehicle manufacturers. While all manufacturers seem to support the basic set (i.e. speed, rpm, oil temperature, and so forth), other OBD-II parameters may not be supported.

One example is the OBD-II parameter which reports the fuel tank level. You might think this would be widely supported. Not so. While Mitsubishi measures the fuel level using its on-board computer, and then displays the fuel level on the (impossible to see!!) instrument cluster, the fuel tank level is NOT available via Mitsubishi’s ODB-II interface. Why? Who knows! Other vehicle manufacturers, however, do provide access to  this parameter, but they then omit others.

Prior to starting out on the software for this project, I began by testing the OBD-II USB interface I purchased, using my laptop and some free ODB-II monitoring software I downloaded from the internet. This allowed me to quickly confirm which parameters were available, and the approximate range of values typically reported by the vehicle through the interface. That’s when I discovered the fuel tank level was not available on the Mitsubishi Pajero’s OBD-II system.

It is possible to determine the fuel level by using other available Mitsubishi OBD-II parameters by making a few additional calculations. However, that approach would also have required me to add another user pushbutton to this design, to tell the ATtiny85 when I had just filled the tank. There's no way to detect that remotely. I’d also have had to add some extra software to save the current tank level to non-volatile EEPROM in the ATtiny85 whenever the power was turned off. Adding the fuel tank level meter to the design very quickly started to spiral out of control, even for me, so I dropped that idea, and opted for reporting oil temperature instead.

Assuming the parameter you want is available via the OBD-II interface, and you want, say, to display your engine’s coolant temperature as well as speed, that’s perfectly possible with this design. In fact, that’s obviously just what I did, adding oil temperature as a moving bar graph to the lower third of the OLED display.

The source code is available below for those wanting to make changes to this design, and the comments in the source code should make implementing these reasonably easy. I wrote all of the software using Bascom, a Basic-like language for the AVR family of processors. For me, it’s a much faster method than using assembly code (or C for that matter) and far easier to figure out and modify later when I revisit some software.

So, changes are readily possible. For example, it’s also possible to replace the bar graph with a couple of other, smaller, numeric displays. You could add a numeric display for RPM, say, and the time to reach 100 kph, for example, instead of the speed and oil temperature I used here. All of the code blocks exist in the source code, and they can be reworked to show that detail, if required.

It’s also quite easy to add logging functions to display selected information on a graph on the display. Finally, there is also a spare pin (pin 1) available on the ATtiny85, and free code space, to add more features. Examples include adding a flashing LED to indicate when your speed is above some set value, or a pushbutton to select one of several display screens or display formats. The current code fills about 75% of the available 8k flash memory.

I have thought about adding an automatic power turn-on/off function which, in hindsight, looks pretty simple to add. But that mean I'll have to dive back into the finished module. Again. And I need it every day. Hmmm....

Incidentally, I also purchased a cheap Bluetooth version of the OBD-II module at the same time for another $US5. At the utset, I wasn’t sure whether I’d use the USB or Bluetooth ODB-II module for this design. In the end, I designed and built the USB module version first, which I’ve documented here. However, in the process, I also managed to design a significant proportion of a similar, even more compact, version based on the Bluetooth OBD-II module, complete with auto power-on/off. If I get some time, and if there’s any interest, I might finish it and document it here too.

No, I’m sorry, I am not able to make special one-off software changes for you. I have a regular job and I prefer to use my spare time to develop new stuff. The software for this design is thoroughly commented to allow you (or an experienced programmer friend) to make most changes you might want, quickly and easily.

Conclusions

This low cost compact OLED-based OBD-II display has solved my problem completely. Driving may still be incredibly dangerous in this country, but at least trying to read the Mitsubishi speedo will no longer add to that risk for me. I’ve found that I can easily read this display in all light conditions, including full direct summer sunlight, and through my sunglasses. Success.

All of which makes me wonder how the Pajero’s instrument panel ever got designed and built like this in the first place. Unless Mitsubishi's designers have never seen the sun. Yep, that might explain it. 

Downloads

 Software (HEX file for those just wanting to program their ATtiny85 and the Bascom source code for those wanting to modify the code) (Fuse details are documented near the top of the source code)

 3D printer file for the dash-mounted display enclosure (STL-format)

 Extreme USBasp files (ExtremeFiles.zip)

Want to go back to the main page? Click here to return directly.

© 2015 Andrew Woodfield ZL2PD
Template design by Andreas Viklund