ODB II vehicle diagnostics circuits?

[GeoffS]

Has anyone here played around with ODB II interfaces and CAN protocols?
Another forum (car) has gotten me interested in this. There are readily available, low cost interfaces available (and some very expensive ones!) but thought is would be more fun to build one.


ODB II is the interface to your vehicles ECU and is used to report diagnostic codes and vehicle status.
Controller–area network (CAN or CAN-bus) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer.

[Uncle Vernon]

ODB II is relatively easy to implement and there is plenty of pre-built hardware available to support it. Silicon chip did an ODB to PC interface a few months ago.

Basic fault code data is able to be found with a little effort but from there on it's an uphill battle getting hold of any useful information. Vehicle manufacturers jealously protect every aspect of their data. Onerous NDIs or outright refusal being the normal response. Welcome To the time consuming world of reverse-engineering on a model by model basis.

I have some products that are capable of fairly comprehensive CAN interaction, however with the exception of some heavy vehicle applications it's been a commercial dead end to pursue any kind of vehicle interconnection. 

Good luck and if you do succeed please let us know how you get on.

[DavidDLC]

Look at this link:

http://www.nerdkits.com/videos/obdii/

[Fraser]

Uncle Vernon describes the situation perfectly.

I have owned several OBDII K & CAN type scanners, most of which were made in China and sold at varying prices.

There are several types of 'scanner' and I list common ones that I have owned below:

1. Small handheld types that read out the only limited OBDII generic codes. These normally cover the Engine, Gearbox and ABS.
2. As above, but with the ability to also reset certain functions like fault memory and 'time to service'
3. PC/MAC based types that can read the fault OBDII Generic codes, reset some flags and/or functions and provide definitions of the fault codes.
4. PC/MAC based OBDII analysis systems that support reading OBDII generic codes AND manufacturer specific codes in the extended code range.
5. As in 4 but with the ability to also configure modules within a vehicle i.e the ability to read and write to the cars systems.

This isn't an exhaustive list but you will get the idea. Modern car diagnostic systems should be able to interface with both the old K type and modern CAN protocol based car computers.

As Uncle Vernon has stated, the OBDII interface is the relatively easy part of the design process as there have been several designs openly published for K and CAN interfaces. The problem occurs when you wish your fault code scanner or analysis software to read and display anything but the very basic generic fault codes. Manufacturers use an extended code list in most modern cars and these are not normally published and are considered Commercial Confidential to protect their business. There is no standard for the extended codes and what they mean, each manufacturer may use their own proprietary codes. If you wished to write configuration data to the vehicle computers, as well as read codes, you enter a whole new layer of difficulty. In order to configure a cars computers you need to know the access protocols and often access codes. Manufacturers do not publish these so they are often discovered via reverse engineering of an official tool. Random attempts to ‘guess’ codes are dangerous in the modern vehicle. Damage to configuration is possible.  

To get a feel for what the marketplace already offers by way of third party diagnostic systems, have a search on auction sites that sell products from China. Another two systems that come to mind are ELM and VAGCom. I use VAGCom regularly and it’s an excellent piece of analytical and configuration software that has taken many years to perfect and is considered by many car Techs, superior to the official Audi/VW system in terms of user friendliness !

IMHO the Chinese have the OBDII generic and manufacturer specific scanner market sewn up. They can provide a great little self-contained OBDII scanner for around £30 delivered. OBDII kit capable for configuration costs a little more and often relies upon either pirated software from Western vendors or shareware that can be a little risky to your vehicle if you are not very careful.

OBDII diagnostics can be a very interesting topic and my OBDII equipment has so far saved me a lot of money as failures in my cars have been easily identified and repaired by me without the need to visit a garage.

An example for you…. My Audi A4 suddenly suffered a failure of the wing mirror motors, central locking, alarm system and drivers electric window. I wouldn’t have known where to start with such a fault but VAGCom immediately identified that communication had been lost with a module in the drivers door. The fault code was in the manufacturers extended code range and would not have been seen on a generic OBDII scanner. I took a look and tested wiring etc but was amazed to discover that the drivers door window motor contained the motor, drive electronics and a microprocessor board ! The said microprocessor board is a sub system controlling the parts of my car that no longer worked. I would never have expected that ! The fault turned out to be a dry joint on the microprocessor board power rail so it was completely ‘off the air’. A cheap and relatively easy repair as opposed to Audi’s price which would have been eye watering for sure.

Now the killer… I was lucky and repaired my module BUT many vehicles ‘marry’ sub system modules to the main controller and this can only be done by a dealer or a suitably clever, normally PC based, OBDII configuration system like VAGCom. OBDII ‘scanners’ cannot do this. In order to ‘marry’ a new module or set parameters within such, you need to know the manufacturers specific protocols and the software must have the correct codes for access etc.  If you were to buy a new module it would be useless until married to the vehicles main controller. This has been used to reduce car radio theft as the radios will only work with a specific vehicle computers chassis number.

In a second incident, my Audi A4 suffered an engine ‘alarm’ with  associated rough running. A quick check with a £30 Autek OBDII VAG CANBus scanner immediately revealed that cylinder number 3 had suffered a misfire and ignition failure. The cylinder number 3 ignition coil pack had failed. I was at the side of the road in the middle of nowhere, yet fixed the problem using my spare coil in a matter of minutes. Without an OBDII scanner I would have either had to guess that it was a coil fault (they have a bad reputation), and started swapping them out one at a time, or awaited a recovery service at great inconvenience. A generic OBDII CAN scanner would have identified this fault as the fault code is in the Generic OBDII code list. Note that I have manufacturer specific OBDII handheld scanners in my cars tool kit (remember tool kits ?) and these are far more convenient than a PC and offer the manufacturer specific fault diagnostics that are needed for many engine related break downs. An OBDII scanner is like a screwdriver these days... your car needs one when you break down.

I have waffled on long enough but this is a very interesting field if you are into car electronics systems. It can also be a nightmare if you don’t have the right equipment and/or manufacturers specific protocols, codes and access codes.

[GeoffS]

Uncle Vernon is indeed correct!

There are readily available PIC based OBD II solutions (Sparkfun have one) but all they do is to provide the interface and sniff out which of the many protocols may be in use. The mandatory ODB codes that all vehicles must have (at least in North America) are pretty well documented. It's the vendor specific ones that are difficult/impossible to get.
Some of the manufacturers will sell you protocol/code details but for the price they want, it would be cheaper to buy a new car!.
There are a number of after market OBD diagnostic tools but the average price for these is around the $US1200 mark.
These are still limited compared to the factory/dealer diagnostic equipment.

I might get the Sparkfun device. For $40 and some open source software, I should be able to get it to do the same as the Scangauge device.

[saturation]

That's a great idea for a project. I've always thought of getting a scan gauge but I get mixed reviews for its durability; so someone should do it better.

Uncle Vernon is indeed correct! ...

I might get the Sparkfun device. For $40 and some open source software, I should be able to get it to do the same as the Scangauge device.

[GeoffS]

I'd guess that the Scangauge hardware is not much more than is found on the Sparkfun board with a PIC to drive the LCD.
The STN1110 chip that is the heart of the Sparkfun board (and the Scangauge) is apparently based on the PIC24HJ128GP502.

First step, buy a car!

[Alex]

http://www.elektor.com/magazines/2011/april/wireless-obd-ii.1738885.lynkx?tab=1
www.elektor.com/090451
www.elektor.com/080948
www.elektor.com/090918
www.elektor.com/080804

[vl400]

I generally play around with older vehicles than those with OBD-II (rewritten a few custom operating systems for the delco ECU found in aussie GM vehicles) but recently started get into later vehicles, and really the older stuff can be harder. Here in Oz the early LSx vehicles run with J1850 interface, its all documented as a SAE standard. Super easy to find all the commands and modes to do various operations, the early ALDL vehicles used a proprietary data interface so had to reverse engineer these. We ended up adding new modes and can now read and write to the PCM in realtime over the vehicle data interface.

Security to gain access to some GM PCMs is so simple in the earlier OBD-II vehicles. Not sure what we can or cant post in here, but google for GM Seed/Key algo to see how they did it.

The simplest way to see how it all works is to sniff the data bus when using a scan tool. Then using the SAE papers look up the various modes that were used. The beauty of OBD-II was the standardisation - to a point.

[insurgent]

GeoffS

I thought about rolling my own with a micro a while back but after researching, I ended up just getting an ELM327 interface instead. I'd spend a lot of time implementing the single protocol my car used and would be SOL if I bought a different car or wanted to use it on the wife's care.
If you decide to not roll your own decode, for $30 or so you can get an ELM327 module that does these protocols:
SAE J1850 PWM (41.6 kbaud)
SAE J1850 VPW (10.4 kbaud)
ISO 9141-2 (5 baud init, 10.4 kbaud)
ISO 14230-4 KWP (5 baud init, 10.4 kbaud)
ISO 14230-4 KWP (fast init, 10.4 kbaud)
ISO 15765-4 CAN (11 bit ID, 500 kbaud)
ISO 15765-4 CAN (29 bit ID, 500 kbaud)
ISO 15765-4 CAN (11 bit ID, 250 kbaud)
ISO 15765-4 CAN (29 bit ID, 250 kbaud)

It is accessible via RS232 with an modem AT command set. There are other interface types available besides RS232 such as bluetooth. Most of the already available software out there uses the AT command set via a serial port.
The "standard" information available via the interface is rather limited. Commonly available "standard" items:
Coolant Temp, Intake Air Temp, MAF, Oxygen sensor, RPM, TPS, VSS, Spark advance, Load calcs. Diagnostic Trouble Codes (DTC's) are standard of course.
Even common items may not show under the "standard" PID's and only show in the "extended" PID's.

Extended information is, as mentioned above, accessible if you know the PID's (Parameter Identification) values. I still haven't found a list of extended PID's for my vehicle (Dodge SRT-4) yet and unfortunately the items I'm currently interested in are only available in the extended PID's

I don't think the "ELM" units are single IC's that can be purchased but there may be equivalent ones out there that are.

I've attached the PDF that describes the programming of the ELM327 for you to take a look at.

[GeoffS]

insurgent,
Thanks for the info, every bit helps here.

Both the older ELM327 and the newer STN1110 chip are PIC based and from what I can tell, use the same command set.. The STN1110 is firmware upgradeable where as the ELM327 isn't. In both cases, the chip just provides the protocol decoding and an AT command set. All interpretation of codes has to be done via an external source. The signal levels from the STN1110are either 3.3V or 5V (didn't check) so a level conversion is needed as well.
The Sparkfun board provides the STN1110 and a OBD level converter.

As to software, there's a lot of open source stuff available as well as commercial applications. ScanXL from scantool.net seems to interface to any ELM327 compatible device and is reasonably priced - pity it only runs on Windows  .

You're right about getting information on PID's. For the vehicle I'm looking to buy (Mercedes), the information is just not available unless you buy one of Mercedes OBD systems - which they won;t sell you unless you're an authorised dealer/repairer with lots of money 
If I do get the vehicle (it's an auction tomorrow, fingers crossed) then, thanks to another forum, I'll have access to Mercedes diagnostic equipment for a reasonable fee so wouldn't need to build or buy one of my own. It's just that it seemed like and interesting hardware/software project to waste invest my time in. 

[ToBeFrank]

I created my own hardware for Harley Davidson motorcycles. Even though I'm not a hardware guy, as others have said the hardware is the easy part. The reverse engineering of the Harley ECU firmware took hours and hours. Unfortunately, motorcycles in the US are not subject to the same mandates as cars so all of the logging/programming is Harley specific. I open sourced the code to do the programming.

http://tunemyharley.com/HOSSTune/forum/index.php

[GeoffS]

I'm still interested in the Sparkfun board but it will have to wait until after I move.

In the meantime, I bought one of these - ScanGaugeII. It plugs into the OBD plug in the vehicle and reports on all of the standard OBD-II codes. Just what codes you can scan or report on will depend on just what information the vehicle manufacturers have released.

I also bought this to go with the ScanGuage 

[Uncle Vernon]

I also bought this to go with the ScanGuage 

You'll be able to move in soon as you get the water , sewer and power on.   

[saturation]

Nice wheels!  Give us a review on both when you are able; looks like a for long road trip type vehicle.

[GeoffS]

Installing the scangauge is proving to be a bit more difficult that planned. The Van has an OBD connector but it's a round 14 pin one, not the 16 pin one as provided on the scanguage. The 16 pin connector is standard but wasn't when the van was made (2004). I was able to find an adaptor cable (in China of course) which I've ordered.
The plan is to use the scangauge as a trip computer to calculate fuel economy, trip times etc. but it would be nice to be able to use it's diagnostic capability as well. A bit more research is required for that.

Re the van. I bought in in Hobart and drove it up to Sydney (not across Bass Strait of course  , used the ferry for that), a total of about 1340 kms driving. Ran like a dream, cruising at 110Km/h.
As soon as I load all my worldly possessions into it, I'm off back to Hobart to live.

http://maps.google.com/maps?f=d&source=s_d&saddr=Haberfield,+New+South+Wales,+Australia&daddr=-35.27578,149.13016+to:Hill+St,+Bellerive+TAS+7018,+Australia&hl=en&geocode=FWMF-_0d7DICCSnNPhPJBrASazFwuTIWaH0BBQ%3BFfy75f0dsIvjCCn57fz9Zk0WazGgTUBtbuoAEw%3BFdvMcf0d8eDICCn3Qt3alN9tqjGD3Sxryo4ivQ&mra=dpe&mrsp=1&sz=9&via=1&sll=-35.518814,148.831787&sspn=1.888991,2.05719&ie=UTF8&ll=-38.048091,147.524414&spn=14.607467,16.45752&t=h&z=6

[saturation]

Enjoy!  That should be a good test of the car and the scan gauge.

[GeoffS]

Finally found a supplier of the adaptor cable I needed (in China of course)
Installation was painless and the Scangauge started reporting what it should straight away..

It has to be one of the worst designed products I've seen in some time. Not technically but aesthetically.
It's just a small oblong box with a simple two line LCD display.
 .
So much more could have been done with a graphics LCD. A way to download the trip data to a PC would be nice too.

[ToBeFrank]

It has to be one of the worst designed products I've seen in some time. Not technically but aesthetically.
It's just a small oblong box with a simple two line LCD display.
So much more could have been done with a graphics LCD.

People like me want it that way. I have one on my truck that sits above my steering column. Anything bigger would not fit. A graphics LCD would also make it more expensive.

[awh4992]

So I realize this thread is a little on the old side, but if anyone is still interested in the "make your own" OBDII reader and such, I have an open-source hardware design available that is a OBDII to Bluetooth adapter based on Scantool.net's STN1110.  Altium sources, PCBs, and even assembled units are available for those that want them.  Schematics are also in PDF format for those that don't have an Altium viewer. 

Here's where my open-source adapter lives:  http://batman.homelinux.com/blog/bluetooth-obdii-adapter/

[ToBeFrank]

So I realize this thread is a little on the old side, but if anyone is still interested in the "make your own" OBDII reader and such, I have an open-source hardware design available that is a OBDII to Bluetooth adapter based on Scantool.net's STN1110.  Altium sources, PCBs, and even assembled units are available for those that want them.  Schematics are also in PDF format for those that don't have an Altium viewer. 

Here's where my open-source adapter lives:  http://batman.homelinux.com/blog/bluetooth-obdii-adapter/

It looks like only the OBD chip adapter design is open source? I don't see a pdf for the bluetooth part, which I assume also has the power supply circuit. And why open source a design that requires a $5000 piece of software to modify it? Sorry, that always annoys me.

[awh4992]

It looks like only the OBD chip adapter design is open source? I don't see a pdf for the bluetooth part, which I assume also has the power supply circuit. And why open source a design that requires a $5000 piece of software to modify it? Sorry, that always annoys me.

So you want a PDF for the RN-42?  Use google, there's no point in me hosting the datasheet for Roving Network's product, as it could easily become outdated.  The RN-42 only does one thing: translate back and forth the UART data going to/from the STN1110 chip.

If you actually looked at the schematics for the design, you'd see the power supplies to generate 5V, 3.3V, and 8.5V.

So...you want the RN-42 (the Bluetooth module) open sourced, which while you're correct in saying that it requires loads of $$$ in licensing, it also requires a lot of money invested in RF design and in wireless certifications not to mention the software development involved.  FCC and CE certifications aren't free and a simply paying their fees and bringing them a device to be certified doesn't guarantee you'll get the certification.  You'd also need to know how the CSR BC4 chip onboard interacts w/ the rest of the stuff on their unit to be able to change the software...etc.

Oh yeah, and the STN1110.  That's obviously not open source either.  Sure, someone could write the tons of code required to emulate the ELM327, test it to make sure it complies w/ all the vehicle protocols and buy all the SAE/ISO/whatever standards to make sure you're correctly implementing communications w/ those standards?

All I'm saying is my adapter is open-source hardware.  The stuff I've designed is there for others to see and use if they'd like.  When you find a open-source hardware and software Bluetooth serial module (oh ya, that has FCC and CE certifications too) and a open-source ELM327 compatible part, let me know and I'd be more than happy to use them.

[ToBeFrank]

If you actually looked at the schematics for the design, you'd see the power supplies to generate 5V, 3.3V, and 8.5V.

I looked at your PDF schematic files since I don't have Altium. There are no power supply circuits in there.

[awh4992]

If you actually looked at the schematics for the design, you'd see the power supplies to generate 5V, 3.3V, and 8.5V.

I looked at your PDF schematic files since I don't have Altium. There are no power supply circuits in there.
[/quote]

Ooh I think I know what's going on.  You're probably not looking at the schematics for the correct board where the power supplies are located.  As stated on my blog right above where you can download the designs, two PCBs are needed to make a complete module, a bluetooth board and a driver board.  Since there are 2 boards, there are also 2 schematics.  Look at the schematics for the STN1110 Universal Driver Board (http://batman.homelinux.com/blog/obdii/STN1110_Driver_Board_R3.zip).  In those schematics, you'll see the power supplies and all the driver circuitry for interfacing the STN1110 to the vehicle.  The RN-42 schematic only shows the connections between the STN1110 and the RN-42.  The 2 boards make a stack as shown in this pic (BTM-182 BT module here): http://batman.homelinux.com/blog/wp-content/uploads/2011/09/STN1110_top.jpg Sorry for the confusion.

The intent w/ the 2 boards is that the driver board can be used w/ any of my Bluetooth boards that has a STN1110 chip on it (I think I have 3 different Bluetooth boards, although the only Bluetooth module you can get now is likely the RN-42).  Likewise w/ my ELM327 designs, there' s a driver board that's common amongst all the ELM327 Bluetooth boards.