Sorry for a silence, I am a bit busy with work right now. I will get back to our research shortly.
have read the data over the OBD Request-Reply through a python library and displayed the data on my laptop screen.
The only module in the steam is the ECM.
I guess my real question is, would I have to send a data request to the ECM to get things such as RPM, coolent temp, current gear selector position etc. And at the end of all this, will it be quicker then the PID method of data acquisition?
Thus far I have resolved or at least identified the following values in the class 2 serial data:
*Front Wheel Speed
he sample you posted "68 EA 10 0A 01 AE" breaks down as this...
68 means a priority 3 type 8 message.
EA (&EB) are the Primary ID Pair for the functional address for "Displays".
10 is the node address of the source of the message, in this case the PCM.
0A is a secondary ID of the Functional address Primary ID pair of EA & EB, (Displays). I do not know the official name of this secondary ID parameter "0A" but you are correct that it carries the data of what the current gear selection is to be displayed by the instrument cluster.
01 is the data byte. I have most often seen this to be 01=P, 02=R, 03=N, 09=D, 08=D3, 07=D2, 06=D1, however I have also seen 00 as P under certain circumstances.
AE is a checksum only. (Not of any value to us)
its on a p59 ecm, 2004 silverado with the 6.0 as for data byte you are right on touch thats exactly what i got figured. but like i said i dont seem to be able to "ask" ecm for those data like i would do for a regular pid, and then feed them back to torque/real dash.What engine and what ECM/PCM are you working with?
its on a p59 ecm, 2004 silverado with the 6.0
but like i said i dont seem to be able to "ask" ecm for those data like i would do for a regular pid, and then feed them back to torque/real dash.
im wondering if im just lacking of decode knowledge or if its just a "poping message" on bus whenever you put the gear on. im pretty sure it dont but well.. i mean original cluster would have to catch it everytime else it wouldnt display right ?. there gotta be a back and forth operation...
We might not get you all the way there but we can surely set you off in the right direction.Hi,
I've been reading this thread with great interest! I have been wanting to do a project where I replace all the warning chime sounds in my 2007 Corvette. I upgraded the head unit recently and by that you lose all the warning chimes (the old head unit took care of those). I got a converter, the RP5-GM11, that interfaces/converts many of the functionalities from the old head unit. It even comes with a separate chime module, that sounds awful though.
My plan is to splice in an arduino or rpi to the class 2 serial line on the head unit and listen for audible warning commands. From J2178-4 I can see there is an address for audible warnings (96/97), but in order to be able to play different chimes based on different warnings (door ajar, seat belt etc) I need to know how to identify and differentiate the warnings. I have not been able to find any detailed information on how these warnings are processed. Do you know where I could maybe find additional information on this?
Thanks for this thread! It's really getting me started.
We might not get you all the way there but we can surely set you off in the right direction.
Some of what you will need is an understanding of "extended addressing" it is in the J2178-4 you have, in the 1999 version have a look at I think it's page 34. You will see a listing of extended address assignments for doors and door locks. So in the case of your example of door ajar switches. Here is a sample snippet from a spreadsheet of mine...
View attachment 100048
Have a look at row 12. There we have a priority 4, type 10 message which uses extended addressing. The message is from module A1, the passenger door module and the target of the message is C7, External Access which you will find in J2178-4. Data byte 1 is a secondary ID of 21 which is 'ajar sw active', also found in J2178-4 Table 34 of the 1999 edition. In Table 34 it can be seen that this secondary ID of '21' uses external addressing listed as 8.5. That is a typo, the ext addr assignments are actually in section 9, not 8 so they are really at 9.5! So going down to section 9, find Table 56 and we will find the next data byte, the extended address of '26' is for the passenger side front door.
I think I have done a horrible job of explaining this here but just maybe you get the gist of it?
This much just identifes what the message is for, it still leaves the deciphering of is the switch open or closed to be discussed.
This was a combination of first seeing this post which very well may be where I got my start on this endeavor....Where did you originally see that A1 is the passenger door?
One thing that I noticed in your OBD2_Class2_TrailBlazer_Startup is line 28 to 34, specifically 30 and 31, it has a target address of 96 and 97 (AudibleWarning).
Assuming you have most of the data already so this will be a trial & error exercise. Monitor the bus traffic as you cycle each window up & down using the switches on the driver's door with the key on and the engine off (minimizes bus traffic). Judging from the data it looks like A0 is the Drivers Door Module and CB is the Windows (not sure if it is a Command, Request or Query). Looking forward to hearing about your observations.Windows:
68 CB A0 09 02 11 00 00 70 41
68 CB A0 09 08 11 00 00 70 E2
68 CB A0 09 04 11 00 00 70 20
68 CB A0 09 01 21 00 00 70 90
68 CB A0 09 01 41 00 00 70 4E
68 CB A0 09 01 12 00 00 70 45
68 CB A0 09 01 14 00 00 70 2C
Question: what data do you see when cycling just one window other than the right front?
I will try to experiment with these bytes next week.My analysis suggests that Bytes 2 & 3 are combined to produce the the desired motion (Up, Down) in the desired window (front/rear, left/right).
I tried different combinations, substituting byte 2 and 3 with these numbers. I can only move the front right window with several different commands (i.e., there is more than one command for the up and down movement). Today we (me and my friend) did the following: we hooked up the Arduino setup that I built for J1850 sniffing, to the pin#2 of the OBD port. Also,we connected the friend's GM Tech2 tool to the OBD port and activated the front windows from the GM Tech2 menu. At the same time, we montored the traffic on the serial data bus with the Arduino. Amoung the sniffed commands, we found two commands that moves the front left and right windows up:All window data traffic is of the form of 68 CB A0 09 XX YY 00 00 70 QQ
Data Byte 2 (XX) = 01, 02, 04
Data Byte 3 (YY) = 11, 12, 14, 21, 41
Check Byte (QQ)