OBD-II (On-Board Diagnostic) project idea

[RobG 1,892]

Here's a nice project idea, MSP430 based OBD-II reader.

Ever since my car's "Check Engine Soon" indicator started to light up, I wanted to buy or build my own OBD reader to see what's going on.

I am thinking something simple would do the trick: MSP430, small LCD, and a couple of opto-couplers.

This shouldn't be too hard, though there are several standards involved.

Has anyone done anything with OBD?

I would take that on, but I have several things in progress and just don't have enough time.

 

Some useful references:

Wiki

OBD-II site

OBD-II protocols

Vehicle database

[chibiace 46]

Is it similar to how a CAN bus works? i see alot of PICs have CAN buses.

[bluehash 1,581]

I have done this. I reverse engineered most of my Mazda3's codes using the Stellaris controllers with hardware CAN. I could read from only one ECU for some reason. Implementing it is a no brainer once you know what to ask for. I was able to do up the CAN code in about 4 hours using Stellarisware.

[chibiace 46]

I have done this. I reverse engineered most of my Mazda3's codes using the Stellaris controllers with hardware CAN. I could read from only one ECU for some reason. Implementing it is a no brainer once you know what to ask for. I was able to do up the CAN code in about 4 hours using Stellarisware.

 

nice.

[jim940 28]

I am thinking something simple would do the trick: MSP430, small LCD, and a couple of opto-couplers.

 

You'll have to use something like a MCP2515, which will convert the SPI from the MSP430 to a hardware CAN enabled port. Level shifting alone will not actually cut it for the way the CAN Bus was designed, error detection, collision detection etc is hardware not software level on every CAN Bus implementation.

 

CAN Bus network packets (which OBD-II is just one of many subsets of message structures with known variables), are nice to work with, only oddity compared to other addressable message systems is that your not supposed to assign devices "addresses" instead CAN protocols use message ID's that are supposed to identify the data in the packet itself, its up to every individual node on the bus to decide where or not the data in the packet is useful to them or not.

 

Really its how a embedded networking protocol should work, atleast in my mind. Especially when you have different products with different features and you do not honestly want to program millions of ECU's with different firmware.

 

I could read from only one ECU for some reason.

 

On cars with a OBD-II port, which were designed to comply with the Californian laws, tend to separate the ECU (Engine Control Unit) from the OBD-II port using a ECU (Electronic Control Unit) with 2 CAN Bus ports on either end, filtering out the non-service/emissions related codes from the car's CAN Bus. Yes 2 names for a ECU, both in cars, cause I guess Automotive EE's are not creative.

 

Both to protect the cars functions but also because depending on the car, you can have quite a number of ECU's in a car doing things in the background with sensors for your cars every move, and a lot of that data is typically kept very closed source. Bosh, and other OEM's tend to not even reply to emails about their CAN Bus protocols for their specific products unless your already a known automotive customer.

 

If TI watches these forms ... I'd give my first born to them if they made a G2553 and/or a FRAM MSP430 with built in CAN hardware. :thumbup:

 

Jim

[bluehash 1,581]

Well explained.

If TI watches these forms ... I'd give my first born to them if they made a G2553 and/or a FRAM MSP430 with built in CAN hardware.

 

That will certainly open up avenues. OBD readers for $5.

[jim940 28]

I just realized I forgot the "u" in forums. :oops:

 

Anyways, I know more about the CAN Bus now then any other network protocol, spent a entire semester at my college studying it (first Semester of Project Design) so that when I did my project the next semester (Semester 2 we are supposed to build and make work the project) I was decently well versed in it:

 

http://www.northerndtool.com/bionx

 

Its Arduino I know, (don't kill me), but that is what I was asked to work with, so that is what I did. :shh:

 

One thing that confused me as I learned about it, knowing the OSI model, is that technically the CAN Bus forgets about that style of operation. For example, for layer 1, connector types etc should be specified, instead, the higher OSI layers that are implemented on top of the CAN Bus Specifications (such as OBD-II) specify the connectors themselves, and while the OSI model relies heavily on the addressing of the node you wish to speak to, the CAN Bus system, is designed so that each and every node will get the same packets and will use the Message ID as a means to detect whether or not the data is useful to them.

 

Say you have a home monitoring system running on the CAN Bus, you have a master home controller, a secondary back up controller, and a dozen temperature probes, a couple thermostats, a humidity sensor, oxygen sensor, a couple of smoke sensors and a dozen door sensors.

 

You'd assign the smoke sensors, lower message ID's, to give them priority, as the CAN Bus will detect "on the fly" if there is a collision, and the lower the message ID bits, the higher priority it gains and wins out arbitration. As in the case of a fire, you want the data to always reach your main controller. So each message ID will be unique to the sensor itself and not its address, instead its what the smoke sensor will use to broadcast its data.

 

 

Now, your worried about a B&E, so the next lowest set of ID's will go to your door sensors, followed by your oxygen sensor, humidity sensor, thermostats and temperature probes etc. or your own unique priorities.

 

Since it doesn't rely on a messaging format such as IP routing in your home, BOTH your main controller and your back up controller will receive every packet from every sensor, however, while your programming the main controller regularly, your back up controller is programmed as a watch dog, so that, you'll have code such as, if (Temperature_probe1 < setpoint) && (main_con !sending_messages) then take over the bus and assume the main controller is "dead". And since all the probes, scattered throughout the house can be "dumb", and not actually know who they are sending the packages to, you can have any combination of back up systems in place that will allow your system to survive any number of failures. So any back up "master" nodes, just need to listen as my above example for the sensors (dumb devices) sending requests and the "master" nodes responses. If the master node is not responding, and the back up takes over, the furnace wouldn't know the difference between a packet from the master node, or from the back up master, it will just do what its told, and the system will not be compromised cause of a single (or multiple) failures.

 

This is one of the reasons why, one of the neat things that the CAN Bus is being used for, beyond the typical industrial automation and automotive sectors, is aerospace, for both planes and space bound satellites, due to its redundancy which doesn't require human intervention to correct itself when properly implemented.

 

Jim

[bluehash 1,581]

Good explanation.

Aren't we limited on the number of mailboxes in the microcontroller's hardware?

[jim940 28]

Good explanation.

Aren't we limited on the number of mailboxes in the microcontroller's hardware?

 

Yes and no, its a lot like a UART with a buffer, typically your stuck with 2-4 messages in the buffer at most with the CAN controllers I've seen. But programming wise, you check the buffer using a interrupt routine when the buffer flags a message is incoming. Even the external MCP2515 SPI<->CAN Bus has a additional pin to be connected to what ever uC's interrupt pin to flag that there is a message.

 

So, similar to a lot of the MSP430 projects I see around here implementing the power modes, a interrupt routine that wakes up due to the CAN Bus Interrupt, would allow relatively low power, and all the routine would have to do is check with a if or case statement if the message is one the controller wants, if so use the data and then clear the interrupt, otherwise just clear the interrupt and go back to sleep. More or less its the same as any UART interrupt routine because of the way it was designed.

 

Typically, a CAN Bus doesn't bombard the network all the time with useless data (trying to send files/large hunks of data over it), only packets of the specific preprocessed data as required.

 

So your thermometer in my previous example isn't blasting away messages as fast as it can, instead you may get it to broadcast only once a minute or more (due to the time it takes to actually change the room temperature in the first place), freeing up a large portion of the Bus, and at the same time, your not sending uncalibrated temperature or other data to the master, your sending something it can directly work with in a simple math function or if statement, allowing it to not be burdened with the grunt work.

 

Plus, at 250Kb/s or 500Kb/s with most automotive protocols, data takes a while for it to become available compared to the processing ability of the uC (such as running a MSP430 at 8Mhz or better), especially when unwanted message ID's would just be dropped before the rest of the packet is even read/used in the uC's code. As if you know the contents of the message, you can avoid the CPU time of trying to figure out if the data itself is relevant. Which is one of the benefits of a CAN Bus style message ID, verses a address which requires the local device with the same address to work with the data before realizing if some node is just wasting its time.

 

Jim