Onboard Diagnostics (OBD)
Today I made the Digital Dashboard widget. Ok it isn’t very digital since it’s analog dials, but communicated in a digital way at least! It didn’t take long to create this since I already had the dial widgets from before. The widget’s themselves could look a lot better but it will do for now.
It has been a long day but I finally got the monitoring working the way I wanted it! First of all, you are given a choice of supported sensors on your car. You can add as many as you want (Only one of each however which makes sense!) and you can set the frequency of update. The frequency of update, is how often Automon will poll the ECU for the sensor value. Engine RPM changes rapidly, so need to update this every cycle. However, there is no point checking the coolant temperature that often. In the screen shot above, I set it to 10Hz, so every time Automon cycles through the list of sensors to check, it will check RPM, but every 10th time it will check the coolant temperature sensor.
Below that are available rules. Rules can be added to the monitor. However, you will only be able to start the monitor if all sensors that are listed in the rules are added. For example, If I had a rule added that included the Fuel Level input, I would first of all have to add this sensor to the list of monitoring sensors before being able to monitor.
The rule editor can also be launched from here. Any changes made to rules in the rule editor, will immediately be reflected in the monitoring widget. So for example, if I add a new rule in the rule editor, it will be listed in the available list. If I added a rule to the list of rules for monitoring and if I launched the rule editor, and deleted this rule, the rule will also be automatically deleted from the rule list in the monitoring widget. Big confusing but it works!
In the screenshot above you can see that the values are getting updated. This allows you to see values changing in real time.
When a rule is satisfied, it will highlight the rule in a green background on the cell. I also want it to emit a sound so the driver can hear it but this is a bit complicated on this device. It does have a speaker though which is a start!
Today I done the GUI for the diagnostics. It displays any diagnostic trouble codes (DTCs) that it finds. It allows the user to continuously check for DTCs when they wish by clicking the Check ECU button. It also allows the user to clear the malfunction indicator lamp (MIL). This option provides a verification prompt to the user since this also deletes all DTCs and any freeze frame data.
One piece of funcionality I would have licked to include was display the freeze frame data but I just didn’t have the time. Implementing it would take another few days.
Over the past 2 days I successfully implemented the checking and loading of DTCs. I have used the Scantool.net’s code database file for all the codes. This is loaded into my program. I can then do something as simple as:
qDebug() << automonApp.getNumberOfCodes();
This will let me know if the MIL is on and the number of DTCs currently stored on the ECU. There are 4 types or categories of codes:
- Powertrain Codes – eg. P0133
- Chassis Codes – eg. C0100
- Body Codes – eg. B0200
- Network Codes – eg. U0122
The most common codes are the Powertrain codes. A code starting with P0 is SAE defined, while P1, P2, P3 are manufacturer defined, SAE defined, jointly defined respectively. It is a similar naming scheme with the C,B and U codes.
My simulator gives 6 DTCs if you press the malfunction button. This also illuminates the MIL. Reading these codes was a little difficult as there are 3 ECU’s in the simulator, ECU, ABS and Transmission unit. So I ended up getting codes from other ECUs as well but knowing where the delimiter was, proved to be difficult. The response to a 03 mode command responds with 43, but 43 can be a valid code as well. The 4 represents a chassis code so 43 00 would be C0300. I could not use 43 as a delimiter so I turned headers on using the ATH1 option and this gave back the sender/receiver/priority and CRC header bits. Using this information I successfully interpreted the correct bytes.
Resetting the MIL is very simple, just a matter of sending a mode 04 command.
This evening I managed to successfully create a command and parse the result to come up with a nice ASCII string of the vehicle’s identification number (VIN). The VIN will allow Automon to know what car it is plugged into and if it is a new car. This will allow me to create a profile for each car, and if necessary keep statistics of it. Of course this requirement may never be implemented with the tight time constraints associated with the project but it is an essential part of the Automon kernel nevertheless.
I also successfully implemented the sensor monitoring architecture. I can now create a “RealTimeSensor” by inheriting this class and overriding the convertResult formula as every sensor handles the hex response in its own way. These real time sensors can easily be added to the monitoring system. eg: automonObj.addActiveSensor(CoolantTempSensor). I can also set the sensor’s frequency. This sensor for example should not be updated every cycle as it doesn’t change that quick. RPM on the other hand needs much higher priority. This system is also proven to work.
I can also pause monitoring by going to sleep, I can stop it by terminating the thread. These functions will be very important further down the line. I’m quite happy with the way my kernel’s archiecture is going now. Below is a code snippet of sending the VIN command and parsing a response. Of course this is still just quick code, all will be cleaned up before final release.
qDebug() << “Attempted to get VIN but SerialHelper is currently monitoring. Returning failure message”;
return QString(“Result could not be obtained. You must stop monitoring first!”);
QString returnedBuffer = vinCommand.getBuffer();
/* Remove spaces to make it easier to parse */
QRegExp rx( ” “ );
/* Split each Line */
QStringList lineList = returnedBuffer.split(“\x0D”);
Next for each line, we will cut out the "49020n" so simply a
sub string from 6 to line.size()
for (int i = 0; i < lineList.size(); i++)
QString thisLine = lineList.at(i);
thisLine = thisLine.section(“”,7,thisLine.size());
fullLine += thisLine;
if (fullLine.size() % 2 !=0)
qDebug(“The returned string for VIN was not of equal bytes. Error”);
return QString(“The Returned Number of Bytes for VIN was not even. Read Error”);
for (int i=0; i < fullLine.size(); i += 2)
QString hexByte = fullLine.section(“”,i+1,i+2);
vinNumber += QByteArray::fromHex(hexByte.toAscii());
The Automon kernel will be responsible for all the lower level ELM327 serial communication. It will provide a easy to use interface to communicate with any ECU encapsulating all ELM327 commands.
One of the design issues problems I am encountering is that not all responses from the ELM327 are “simple”. Most sensor commands result in a few bytes represented in hexadecimal and you apply a formula to get the actual human result in volts, rpm, degrees etc. Some results however are bit encoded. For example a request to Mode 3 of “03″ without a Pid results in a stream of bytes, with the first byte meaning how many DTCs are present and the remaining types of DTCs, where each is encoded to a special type, P, U, B codes etc and which are pending or not is also encoded into the bytes. I wanted to create a generic PID base class but the complications is causing problems. I want to allow the user to provide proprietary codes as well. To do this I would read the codes from a file but how do I specify the formula and the logic in the formula if it exists? – For example, some formula’s have, If Byte B == 0xFF (all 1s), then it means this, other wise take byte A and do something else. One solution would be to using scripting. QT provides a useful scripting engine in the QScript module. I might look into this and get a better understanding of it.
Alternatively, if I want to make my system less flexible, I could create a Sensor class and derieve each sensor over writing a “convert formula” method so each class of sensor has its own defined formula.
Since the data structure holding these is so vague and none standard across all sensors, I thought XML would be a great way of representing this data for parsing later.
Today I managed to convert my GUI prototype app into one that can handle a QList<Sensor> of sensors. I also implemented a way of how frequent sensors get updated. For example, RPM,MPH are the main ones that change down in milliseconds but something like coolant temperature would only need to be checked maybe every few sensor cycles. A sensor cycle is where my serial comm thread iterates through a list of sensors. Every time it comes to a sensor, it evaluates if it time to check that sensor, otherwise skip to next. This makes adding sensors quite handy. I also created signals in my sensors, so once their value changes, they automatically emit a signal with the new value. This is very useful since I can connect sensors to GUI slots very simply. Here is an example:
sensor = new AGenericSensor();
sensor->setEnglishMeaning(“Engine Revolutions per minute”);
sensor2 = new AGenericSensor();sensor2->setEnglishMeaning(“Engine Coolant Temperature”);
connect(sensor, SIGNAL(changeOccured(QString)), this, SLOT(updateLCDText(QString)));
connect(sensor2, SIGNAL(changeOccured(QString)), this, SLOT(updateLCDText(QString)));
I decided it was time to actually start designing Automon and stop playing around with proof of concepts. The way I am going to approach this project is to develop a library separate from the GUI that will act as the kernel so to speak. It will provide an object oriented interface to the ELM327.
I spent a while writing down what methods would be needed and soon realised that this project might be a lot bigger than thought! However, it should be do-able. It will be a soft real time system, where timing will be down to milliseconds.
Here is an idea of a class to interface Automon. Just very basic idea at moment. It will probably change quite a bit from this.
Today I received my ECU EOBD simulator from Turkey. It only took a day to get here! – very fast delivery.
It didn’t come with a transformer to plug it in so I looked up the data sheet for the power specifications. It requires a 12VDC supply with 500mA current. I purchased one in my local electrical store and this done the trick grand.
The device works great. It has 5 variable sensor values, RPM, MPH, Coolant Temp, o2 Sensor Voltage and MAF. Other PIDs are also on board with fixed values. It includes a DTC switch that allows you to turn on the MIL along with logging a few DTCs. It even includes freeze frame data and a VIN. Resetting the MIL and erasing the DTCs works perfectly by sending down a mode 4 request.
This should make life a lot easier now as I won’t have to be in the car much. But when I get into a proper testing phase, I’ll do weekly tests on my car and maybe another OBD II standard car to ensure that it works on them.
The device is one version of the OBD II protocols, KWP2000 (Keyword Protocol). It is in a lot of European Cars including my MG. Ideally I should probably have chosen a board that had a different protocol. The ELM327 can handle all.
The ElmScan 5 tool I received a few days ago from scantool.net seemed a little strange. I attempted to connect it to my laptop and the car and communicate with it but I kept getting interface not found.
I tried hooking it up with hyper terminal to the virtual USB com port and as soon as I made a connection, the power LED on the scantool would go.
I found it quite strange that none of the other LEDs were even attempting to light. Doing some research, I discovered that when you plug the scantool into the ECU, that a LED sequence should occur to show correct operation of it.
I spoke to one of the main guys at scantool.net and he was quite surprised since each tool is tested fully before it leaves the warehouse (excellent QA from that company).
So the ElmScan was not getting power, but how is it that my other ‘fake’ ELM327 device gets power and my hand held fault code reader gets power. I was told by the guy I was talking to that the ElmScan uses pin 5 of the DLC connector as ground and pin 16 to get power. Doing more research into the pin outs, it appears Pin 16 is Battery power and Pins 4 & 5 are grounds, chassis ground and signal ground respectively. I had a +12 voltage across Pins 16 and 4 but nothing across 16 and 5. This clearly was the problem.
So then I got out my volt meter and investigated. I had a +12 voltage across Pins 16 and 4 but nothing across 16 and 5. This clearly was the problem.
The guy I was speaking to from Scantool.net kindly gave me a hint suggestion to short jumper 1 on the ElmScan. This means that it will take Pin 4 as the ground which is all my car will offer as ground. Opening the tool was surprizingly simple, no glue or anything. I took the circuit board out and grabbed a jumper from old computer parts and placed it on the create the short.
Alternatively if you don’t have a spare jumper, you can soldier the pins together with a piece of wire.
I hooked it up to my OBD connector on the car and it worked instantly. I loaded up the software and connected USB just to be sure and it connected fine. The tool was sending out 4 samples a second which isn’t too bad. When I revved the engine, the response time was satisfactory. As far as I know the more parameters that I add to request, the slower the response will be but I’ll have to investigate that over the next few weeks.
So in fact MGs/Rovers don’t seem to be 100% EOBD/OBD II compliant – only on a physical level though. Most scanning hardware would work but some don’t and the reason is that pin 5 is not used by MGs/Rovers.
Today I decided to look for a proper OBD II/EOBD simulator. This would save so much hassle as I wouldn’t have to be going out to the car every second checking if a change made works. Further more, currently my SBC is plugged into a mains so it awkward getting it powered up in the car.
I decided to go with the KWP2000 protocol simulator as this is the same one in my car. I guess I really should pick another one and get tested on both types but I can simply just plug into another car later on anyways.
The one I went with cost 99 euro and is on this page: http://www.ozenelektronik.com/?s=products2&group=eobd-obdii-ecu-simulators
This project is costing me a fortune! – Hopefully everything will pay off in the end now.
Today I received a genuine ELM327 Tool (ElmScan 5 ) from Scantool.net. These guys kindly offered me a free one worth 130 dollars since I was doing it for my final year project. Unfortunetely they sent me the USB version and I wanted the RS232 serial version so I may send this back. Technically though it should work away by using /dev/ttyUSB0 since the kernel is 2.6 and supports the FT232RL chip that is in the USB version that gives a virtual USB com port.
Anyways I think I’ll be better off going with all serial at this stage just incase it causes problems down the line so might send it back to them. Thanks Vitaliy!
Scantools are located here: http://www.scantool.net/scan-tools/. It is important to buy the ELM327 Scantools from here as ones on ebay and other places are generally fake replicas and do not work fully. Poor quality etc. I know myself since I bought one for 50 euro and it gives up randomly.
First of all I had to cross compile QExtSerialPort for ARM Linux. To do this I downloaded the tarball, unzipped it to my home directory. I set my PATH variable to point to qmake in QTEmbedded-4.4.3-arm. Then I ran qmake and make and it successfully compiled for ARM. In the build folder there is a libqextserialport.so.1.0.0 and libqextserialport.so.1 and few more. I copied all up to /usr/local/lib on my Device.
Next I ftp’d my project from windows to vmware, the one I discussed previously. I had to modify the .pro project to the new location of qextserialport libraries (in my home directory) and I had to add an extra line: libs += /home/donal/qextserialport/build -lqextserialport. I also had to modify the main.c file to point to /dev/ttyAM1 which is COM1 on the board. Then I navigated to my test folder and done a qmake followed by make and resulted in a automon binary. Doing file automon , I confirmed that it was an ARM binary. I ftp’d this up to my device.
I set the whole lot up in my car as you can see in the pictures above. Connecting the ELM327 to COM1. I ran the automon program off the device redirecting the output to the screen by doing
$ cd /home/eclipse
$ ./automon > /dev/tty0
And out comes the revs in the car perfect. It only does a snapshot every 1/2 second but it is enough for me now. Now I have done all my proof of concepts. Just to build the project now in QT!
Today I decided to write a simple console application that would read the RPM of my vehicle in real time.
Obtaining the RPM of the engine requires sending a Mode 1 PID of 0C to the ELM327. By default the ELM327 echos back the command to you along with the result to confirm that the command you sent was received correctly by the IC. To turn off this echo, you must first send a ATE0 command to the IC. Any internal configurations that is done to the IC is done via AT commands so once the ELM327 receives an ‘A’ followed by a ‘T’, it will interpret the following as internal configuration and not send the command to the ECU on its bus. Next after doing that I continuously sent the command “010C” to get a result (in hex) from the ECU.
The ELM327 won’t execute the command you sent until it reaches a carriage return bytes ‘x0D’ so this is appended to the string I send.
The response will always be: 1st byte the mode + 40, so we should get our first byte as “41″ and the next will be the PID of “0C”, the following bytes are the ones we want to interpret. The ELM327 separates each bytes with a character space for readability but this can be turned off using “ATS0″ but I will parse by these spaces.
My program worked successfully, however the timing was an issue. I done a continuous while loop with a sleep of 500ms in between using QThread but anything less, the response came out of line and I got a result of 0 rpm. By right using the sleep is not the correct implementation. I should be using QTimer and creating a slot that gets called periodically on a timer signal. I will work on timing later but I am happy just to get a real time output even if there is a second delay between each output. Newer versions of the ELM327 supports an adaptive timing feature that I will exploit later on to get more samples per second thus making it more real time.
I used the strtol function to convert the hex bytes to decimal equivalents which is quite useful. Below is the output of my car as I varied the throttle.
Having to be in close proximity of your car all the time, within a metre of the ECU is not very practical for me so I’ve two options: Find a Software Emulator that will emulate the ELM327 interface or else set up a physical ECU standalone out side of the car.
The idea of setting up a standalone ECU was interesting and doing some research into the MEMs ECU system of my MG I figured out the input and output pins of the ECU.
Looking on Ebay I didn’t see many offers for ECU’s that are modern enough to support OBDII protocol so done a little searching for emulators.
I came across this site: http://www.geocities.com/darkyp/eng/ecuemulator.html. ECU Emulator (ECUEmu) is a handy piece of software that simulates or more emulates the actions of the ELM327 chip and the Jeff interface. I came across Jeff’s interface previously but opted out for the ELM327 as it supported much more. The ECU emulator requires that you have two computers, each with serial port. ECUEmu attaches to one and you can use hyperterminal at the other end to get the ELM327 > prompt. I attempted to create a virtual emulated port pair using com0com but unfortunately it didn’t seem to work with ECUEmu. Fortunately though I have 2 usb->serial adaptors for the laptop and a null modem cable so I done a loop back between the two. Laptop->USB->Serial->nullmodem->Serial->USB->Laptop. I set up ECUEmu on one side and used the default settings for hyperterminal on the other (9600, 8N1). I got a prompt. Next to test it, I set the value of the engine RPM to 1A1Ch and done a look up using hyper terminal by typing in hex 010C (Mode 01 with PID code of 0C. Click here for more details). The returned value then was 2 bytes, 1A1C. The 1A1C is the value we set above and to convert this to a real value you use the conversion formula: ((A*256)+B)/4. Here A is the decimal equivalent of the first byte 1A h (26) and B is the decimal equivalent of the other byte 1C (28) so we get ((26*256) + 28/4) = 1671 so our value for RPM is 1671rpm at least it should be!. To confirm I opened up a OBD Program and connected it to the com port associated with the other end of the null modem cable. The results I obtained from it did indeed match so success!
So there I have it, an obtained RPM value from the ECU Emulator. This should save a lot of trouble and not having to be next to a car all the time. However by the looks of the program it only supports OBD Mode 0, these values such as RPM, Speed etc. I’ve to figure out how to test Diagnostic Trouble Codes (DTCs) as well. This may require me to set up a proper ECU later on and simulate something like a miss fire, how I’ll do that I’ve no idea.
Modes of OBD
There are 10 modes specified by SAE J1979 OBD standard:
- $01. Show current data
- $02. Show freeze frame data
- $03. Show stored Diagnostic Trouble Codes
- $04. Clear Diagnostic Trouble Codes and stored values
- $05. Test results, oxygen sensor monitoring (non CAN only)
- $06. Test results, other component/system monitoring (Test results, oxygen sensor monitoring for CAN only)
- $07. Show pending Diagnostic Trouble Codes (detected during current or last driving cycle)
- $08. Control operation of on-board component/system
- $09. Request vehicle information
- $0A. Permanent DTC’s (Cleared DTC’s)
(Taken from Wikipedia)
I will be mainly dealing with the first few modes.
So I will still require the use of a ECU at some stage and some way of simulating changes of values. I believe by hooking up a 12volt power supply and doing the neccessary groundings that I should be able to get something up and running. However, without any sensors I will get readings of 0volts, 0rpm etc so I may have to develop a variable sensor, probably a variable resister, that will change the resistance on the circuit to simulate changes in coolant temperature for example. Some day however I’ll get around to that.