I'm working on a device for my 1997 Hummer with an LBZ Duramax swapped in. I am using an Arduino and a VPW Transceiver from SwapSmart to access the Class 2 data bus. I have most of the class 2 data working but I'm struggling with one thing, the Oil Life Monitor and Fuel Filter Life. I have identified and can read the messages giving the value but every time I turn the vehicle off the values get set to 0. I've verified the ECM and TCM have power when the truck is off. I've even wired in a BCM and IPC but I get the same result. Does anyone know if there's some type of "handshake" needed with some module when resetting these? I have a VCX Nano and Tech2Win for resetting the values.
Oil Life Monitor Class 2 Data
- Thread starter NickInMN
- Start date
I can't say that I am following what you are doing there.
Are you reading the oil life as a PID from the ECM using a mode $22 message? Like "6C 10 F1 22 11 9F" ??
Or using Class 2 messaging? Like this one where the cluster requests the oil life remaining... "E9 4A 60 14".
Do you mean to say that the ECM itself appears to be losing the value when shut down? And it then reads 0% oil life remaining?
And exactly what ECM is used here?
Are you reading the oil life as a PID from the ECM using a mode $22 message? Like "6C 10 F1 22 11 9F" ??
Or using Class 2 messaging? Like this one where the cluster requests the oil life remaining... "E9 4A 60 14".
Do you mean to say that the ECM itself appears to be losing the value when shut down? And it then reads 0% oil life remaining?
And exactly what ECM is used here?
When the truck is started the following message is sent 0xA8 0x4B 0x10 0x14 0x[XX] (this is oil life, fuel is behaving the same). 00 == 0 %, FF == 100%. I'm not requesting any data. I see this same message when I reset the oil life with my Tech2 clone as well. My ASSumption is that when the PCM has a new value for oil life it will send this message with the updated value.
I don't see any requests with 4A 60 in any of my logs.
Yes, the ECM appears to be losing the data when turned off. Or, it is requesting something at startup that it is not receiving a response to so it is clearing these out.
The ECM is a Bosch. This isn't a picture of my ECM but it is the same was what's in my truck.
I don't see any requests with 4A 60 in any of my logs.
Yes, the ECM appears to be losing the data when turned off. Or, it is requesting something at startup that it is not receiving a response to so it is clearing these out.
The ECM is a Bosch. This isn't a picture of my ECM but it is the same was what's in my truck.
Welcome to GMT Nation...
This is "The Dope" on that Bosch ECM Part# 12606127 ....with more particulars besides...and the idea that if it came the Wrong Calibration... weird Sensor Behaviors-Signals might occur:
www.ecmcustoms.com
Product Description
2006 Duramax equipped vehicles, LLY VIN code 2 (8th digit is “2”). Choose from refurbished A-Grade or B-Grade, as well as factory NEW. Note, B-grade is cosmetically flawed and may have a cracked or chipped receptacle that will not affect durability or function. All grades include applicable warranty when ordered with factory programming (add to cart separately).
GM Service Numbers 12606126, 12606127, 12603623, 12604137, 19260753, 12588335 are interchangeable.
O6 LLY/LBZ NOTE: The lower power rated 06 LLY preceded the 06 LBZ emission certification. The 06 LBZ engine included programming that is more refined and adds 30 HP and 60 ft-lb torque. The upgraded “Factory LBZ programming” is an available option in the drop down menu as a low cost upgrade to the factory program file. IMPORTANT: YOU MUST PURCHASE FACTORY PROGRAMMING to take advantage of this discounted +30HP LBZ upgrade offer.
PS...
Whenever time permits... Filling in "The Dope" on your Vehicle Profile will help us. Also... the ASCII Codes you posted may or may or may not decode in reference to THIS ASCII Chart:
This is "The Dope" on that Bosch ECM Part# 12606127 ....with more particulars besides...and the idea that if it came the Wrong Calibration... weird Sensor Behaviors-Signals might occur:
2006 LLY ECM | ECMCustoms
www.ecmcustoms.com
Product Description
2006 Duramax equipped vehicles, LLY VIN code 2 (8th digit is “2”). Choose from refurbished A-Grade or B-Grade, as well as factory NEW. Note, B-grade is cosmetically flawed and may have a cracked or chipped receptacle that will not affect durability or function. All grades include applicable warranty when ordered with factory programming (add to cart separately).
GM Service Numbers 12606126, 12606127, 12603623, 12604137, 19260753, 12588335 are interchangeable.
O6 LLY/LBZ NOTE: The lower power rated 06 LLY preceded the 06 LBZ emission certification. The 06 LBZ engine included programming that is more refined and adds 30 HP and 60 ft-lb torque. The upgraded “Factory LBZ programming” is an available option in the drop down menu as a low cost upgrade to the factory program file. IMPORTANT: YOU MUST PURCHASE FACTORY PROGRAMMING to take advantage of this discounted +30HP LBZ upgrade offer.
PS...
Whenever time permits... Filling in "The Dope" on your Vehicle Profile will help us. Also... the ASCII Codes you posted may or may or may not decode in reference to THIS ASCII Chart:
Ok, now I know how you are reading the data. That helps.
As far as I know your assumption is correct. I cannot say that your ECM does this but it seems logical. I know my 2002 P10 PCM does this updating of the value. And my 2005 Yukon also does it.
Both vehicles clusters occasionally request the data as well. Here is a snippet from my Yukon where the PCM broadcasts the value, then shortly afterwards the cluster requests the same and the PCM again broadcasts the value.
I have hundreds of logfiles for my two vehicles spanning several years so it is possible for me to catch things that aren't a normal occurrence. But this request from a cluster looks to happen fairly often.
I don't think I have ever reset oil life using a Tech 2. Both my vehicles have the DIC and I use the steering wheel buttons to reset. I would expect the Tech 2 to use a service $AE message to perform such a reset.
That said I just sent a load command to a benchtop test PCM I have here in the house and the PCM did as I instructed. I spoofed a message from the BCM telling the PCM to load the value $FF into the oil life parameter.
I'll need to do some tests to see if it remains there when in the key off state and then later if the battery power is disconnected.
I assume there is just one always on battery power to your PCM?
I looked for some examples of the PCM updating the oil life as it decreased. I discovered that the PCM does sometimes broadcast an oil life of $00 at startup but then jumps up later. I have yet to discover how this works....
In this example the vehicle was shut down and restarted minutes later more than once before the 14:45 timestamp where it sent the $00 value. A decrease is seen between 13:46 and 14:09.
In this example the vehicle was shut down and restarted minutes later more than once before the 14:45 timestamp where it sent the $00 value. A decrease is seen between 13:46 and 14:09.
I reviewed some of these files where the PCM sent an oil life monitor value of zero.
I see that in every case this only happened within a couple seconds of key ON. And in short order the PCM follows up with the real value. Often, the cluster requests the value right after the zero value is sent.
I analyzed one file in my spreadsheet that decodes all serial data traffic and there is no evidence of the value being stored or retrieved anywhere else but the PCM.
I am wondering if this zero value is sent only as some sort of display system initialization.
I see similar traffic for other display related data. For examples, as the key is turned on the BCM repeatedly sends messages to the display system to turn off the high beam indicator and security lamps among other warning or indicator lamps. This is done before the cluster is even displaying anything while the key is at ACC.
These BCM messages are generally acknowledged by the IPC whereas the oil life monitor messages are not.
More random data to float around upstairs.
I see that in every case this only happened within a couple seconds of key ON. And in short order the PCM follows up with the real value. Often, the cluster requests the value right after the zero value is sent.
I analyzed one file in my spreadsheet that decodes all serial data traffic and there is no evidence of the value being stored or retrieved anywhere else but the PCM.
I am wondering if this zero value is sent only as some sort of display system initialization.
I see similar traffic for other display related data. For examples, as the key is turned on the BCM repeatedly sends messages to the display system to turn off the high beam indicator and security lamps among other warning or indicator lamps. This is done before the cluster is even displaying anything while the key is at ACC.
These BCM messages are generally acknowledged by the IPC whereas the oil life monitor messages are not.
More random data to float around upstairs.
Thanks for all your input. I haven't had a chance to test this but I think your data points me in the right direction. My code is currently looking for A8 4B 10 14 as the identifier for the oil life message. I think that's part of my problem, I'm assuming the priority part will always be the same which I now realize is a bad assumption. Hopefully I'll have some time this weekend to do more testing.
Are you just using spreadsheets and filtering for your screenshots? I'm just logging to text files right now and importing that into a spreadsheet. I was hoping to use the logger in Universal Patcher but I can't figure out a way to load an existing file.
Are you just using spreadsheets and filtering for your screenshots? I'm just logging to text files right now and importing that into a spreadsheet. I was hoping to use the logger in Universal Patcher but I can't figure out a way to load an existing file.
I record my logs using am Android device and a free android bluetooth serial terminal app and a Veepeak Mini Bluetooth OBD2 adapter.
All my logs go into a folder on the Android. Many are far too large for a spreadsheet.
I use another older Android app (aGrep) to do a regular expression search of the logfiles. In this way I can quickly scan for messages meeting various criteria.
This is one of the RegEx expressions I used for the screenshots above.
..:..:...[0-9][0-9][0-9] .. 4[A-B] .. 14
This gives me anything addressed to either $4A or $4B with the secondary ID of $14.
If I find I want to further investigate a given logfile I cut/paste either the whole logfile if it is not too large or a snippet to get what I want to see into the spreadsheet.
The spreadsheet is a monster. I am no programmer so I'm sure this can be done better but this is what I am capable of and it works for me.
The spreadsheet (a Google Sheets doc) does some lookups from portions of the SAE J1850 specifications to make the reading/decoding easier.
Here is a small part of what the spreadsheet shows me....
Partially highlighted in light blue the PCM reports oil life of $00, the cluster requests same, and the PCM reports the real value of $47.
I have not seen the message priority vary for a given message except between vehicles perhaps. But in the case of oil life reports both my vehicles use the same priority.
All my logs go into a folder on the Android. Many are far too large for a spreadsheet.
I use another older Android app (aGrep) to do a regular expression search of the logfiles. In this way I can quickly scan for messages meeting various criteria.
This is one of the RegEx expressions I used for the screenshots above.
..:..:...[0-9][0-9][0-9] .. 4[A-B] .. 14
This gives me anything addressed to either $4A or $4B with the secondary ID of $14.
If I find I want to further investigate a given logfile I cut/paste either the whole logfile if it is not too large or a snippet to get what I want to see into the spreadsheet.
The spreadsheet is a monster. I am no programmer so I'm sure this can be done better but this is what I am capable of and it works for me.
The spreadsheet (a Google Sheets doc) does some lookups from portions of the SAE J1850 specifications to make the reading/decoding easier.
Here is a small part of what the spreadsheet shows me....
Partially highlighted in light blue the PCM reports oil life of $00, the cluster requests same, and the PCM reports the real value of $47.
I have not seen the message priority vary for a given message except between vehicles perhaps. But in the case of oil life reports both my vehicles use the same priority.
Interesting, so there are quite a few steps involved. You've piqued my interest in that regard. I started writing an application that will parse a log file line by line and break it out into easier to read data. Would you be willing to share the j1850 lookup data you have?
For the task at hand I think I'm still missing something. I did a short log and I see the oil life message (4b 10 14) twice and it has a value of 00 both times. The first one is shortly after key on, the second one seems to be in response to the cluster's 4A 60 14 message. Basically the same as what you're seeing above except my value is always zero. I do have a BCM in place but I don't have anything plugged into that. So my class 2 network consists of ECM, TCM, IPC and BCM. Maybe something is expecting something from the TCCM and that is causing the values to go to zero. I'll keep looking.
For the task at hand I think I'm still missing something. I did a short log and I see the oil life message (4b 10 14) twice and it has a value of 00 both times. The first one is shortly after key on, the second one seems to be in response to the cluster's 4A 60 14 message. Basically the same as what you're seeing above except my value is always zero. I do have a BCM in place but I don't have anything plugged into that. So my class 2 network consists of ECM, TCM, IPC and BCM. Maybe something is expecting something from the TCCM and that is causing the values to go to zero. I'll keep looking.
I've been distracted with other things but I finally got back to this yesterday. I have ruled out this being a power issue. If I send a reset message through the Tech2, by doing the pedal dance or through the Arduino the IPC shows 100%. However, as soon as I make a request for the data (E9 4A 60 14) I get a value of 0 back from the PCM. I hadn't thought about this before but the truck is tuned with a DSP5 (5 tunes, switch on the fly). I'm starting to wonder if this is the source of my problems. I'm trying to find a reasonably priced PCM that I can flash a stock tune on and see if that resolves the issue.
Does this mean there are instances where the IPC displays 100% when simultaneously a request through serial data returns 0% ??
And what does a mode 22 request for the PID return?
When I reset the oil life via the pedal dance I see the "Oil Life Reset" message on the DIC. The Oil Life then shows 100%. As soon as I make the request for oil life the PCM responds with 0. That results in the oil life showing as 0% in the DIC.
I don't follow what you're asking with respect to a mode 22 PID request. That sounds like a CAN request.
I don't follow what you're asking with respect to a mode 22 PID request. That sounds like a CAN request.
I suppose it may be with your powerplant and PCM. I am not familiar with that.
On our older GM vehicles that use only the single wire class II serial data bus I send a node-to-node message, "6C 10 F1 22 11 9F 01" and the PCM responds with "6C F1 10 62 11 9F XX" where "XX" is the oil life as a percentage expressed in hexadecimal where $00 = 0% and $255 = 100%.
I have essentially zero knowledge of ISO 15765-4 CANBUS operations but I assume there is some similar method there?
I was just wondering if the Oil Life PID displayed the same behaviour as the DIC and functionally addressed messages do. I would expect it to do so.
This EE Thread is *Spot-On* for understanding and comparing the differences between Class II Network PIDS and CAN-Bus ID Traffic:
electronics.stackexchange.com
Further... on UDS:
en.wikipedia.org
Understanding the difference between CAN IDs and PIDS on OBD-II
I am trying to understand the CAN protocol for reading the diagnostic information from a car. For example, I know that on the car I am working on uses CAN identifier 0x7E0 as a query and 0x7E8 is the
electronics.stackexchange.com
Further... on UDS:
Unified Diagnostic Services - Wikipedia
Last edited:
Oh, I see what you're saying. I see PID and immediately think CAN. I can try sending that request. I'm not sure if that same request will work on my hardware but I can give it a try.
Well if your ECM/PCM uses CAN (ISO 15765-4) you could try that route. I really do expect that the response will be the same, I just like to cover all bases.