ELM327 & Class 2 Serial Data

iddqd

Member
My logs are gathered with Android App "Bluetooth Serial Terminal" by Kai Morich in the Google Playstore. Timestamp is an available option there.

View attachment 98096

Hey mate,

Sorry for a silence, I am a bit busy with work right now. I will get back to our research shortly.

Pavel
 

briesey

New Member
Hey guys, I've been diving into class 2 data as an attempt to run a custom cluster in my 1985 Range Rover that I have converted to LS1-4L60 with the standard 0411 P59 ECM thats out of a 2003 Yukon that ran a LM7-4l60 combo.

The car runs and drives as a standalone conversion, and I have been reading data from the ECM via an ELM 327 blutooth dongle and the Torque app on my android phone. I have since purchased an ELM327 USB device and have read the data over the OBD Request-Reply through a python library and displayed the data on my laptop screen. This was a big step forward but the data was rather laggy. With the want to lower latency, would it be less laggy to read the class 2 data stream and pick out the values I need, then re-display? 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?

My ultimate goal is to read the data from the elm over serial with a microcontroller and re-broadcast the info over CAN bus to a late model Land Rover cluster (I've programmed modules to convert GM lan to Land Rover CAN bus before to run clusters in engine conversion). I'm very well acquainted with CAN, but the class 2 stuff is proving more convoluted haha.

Any info would be HUGELY apreciated!

Cheers!
 
OP
TJBaker57

TJBaker57

Well-Known Member
have read the data over the OBD Request-Reply through a python library and displayed the data on my laptop screen.

By this do you refer to the use of service 22, Read Data by Parameter ID?


The only module in the steam is the ECM.

I have no experience with standalone systems. I would expect there to be a near constant stream of requests from the ECM for things such as "network status". This is what I have seen when I have observed a PCM on the bench with no BCM present. How is vehicle security, which is normally handled by the BCM overcome?


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?

In the few vehicles I have tinkered with, RPM has been a direct line transmitted from the PCM to the cluster. I have thought this was done for speed/accuracy and perhaps to reduce network traffic on the class 2 bus? I see RPM transmitted on the bus but only sporadically. Some other data points appear to be transmitted on the serial class 2 bus only when there is a change in value.

I suspect that the speed would be the same where either message at its basic level is just another message on the bus and goes through the same message arbitration, etc.

Now if I understand correctly you are doing these things programmatically, right? There is another way to get data from a module. Test instruments such as the Tech 2 use another service, '2A' as opposed to service 22. With service 22 a single request is made and a single response is received. With 2A a request is made to return a data 'packet' which has been configured by the use of another service. The packet can hold up to 6 bytes of data. The Tech 2 uses service 2C to configure the data packet(s). Additionally these packets can be streamed at various speeds using a sub function of service 2A. This streaming would require the sending of a 'test tool present' message periodically to keep the stream active, otherwise the stream lasts for just a few seconds.

Now here is the thing I don't know. For some operations a test tool alters the normal operation of the module. For example, when entering into the EBCM to view data, the Tech 2 warns that ABS will not be available. I do not know if this is the result of a specific command sent by the Tech 2 or is it simply calling up data by the use service 2C/2A?? I would not want to disrupt normal module operations where they may interfere with matters of safety. This looks not to be a concern in your specific case as there is but the one module, the ECM.

If we want to discuss the use of service 2C, 2A for polling data we should start another thread as I don't think there is anything existing in that realm here in the forums.
 
OP
TJBaker57

TJBaker57

Well-Known Member
Thus far I have resolved or at least identified the following values in the class 2 serial data:

*Front Wheel Speed
*Vehicle Speed
*Odometer
*Incremental Odometer??

Well it took me quite some time, and several attempts but I finally cracked the "incremental odometer" nut. My 02 Trailblazer with 4.2 & P10 PCM does not report this value but my 05 Yukon with LM7 and I believe a P59 PCM does. The value is a 2 byte value that rolls over and reports miles at a resolution of 4000 bits per mile. The frequency of reports is about 4 times per mile.

Might this be the source of the odometer value accumulated in the IPC?? Or elsewhere? I have no idea.
 
like i said in the old thread, im trying to ask data out of the elm 327. im currently using hyperterminal to isolate data but it seem like i cant ask for those value back.


68 EA 10 0A 01 AE

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)
What engine and what ECM/PCM are you working with?
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.

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...


isnt there a way for those software to listen to specific data and use them ? that would solve a lot of trouble.

else i like the way you can read the code, is there any pdf / web that i could read to understand code better ?

i dont know if you have time to scool me up but i would be really thanksfull . i can pay too if you want, thats some new thing to me and i really want to dig in further into the stock ecm before going the easy aftermarket way...
 
Last edited:
OP
TJBaker57

TJBaker57

Well-Known Member
its on a p59 ecm, 2004 silverado with the 6.0

I have a P59 on a 2005 5.3 LM7. Hopefully what works on mine will work on yours.

I would like to know what your current configuration is in Torque Pro. And yes, you need the Pro version, not the free "lite" version for this. Have you loaded the GM specific set of extended/enhanced/extra PIDs? Do you get any of the other data parameters from these "[GM]" PIDs. I ask this in order to confirm that the Torque Pro app is properly communicating with the vehicle.


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...

Well,,, No. For these purposes there is generally NOT a controlled back and forth, request/answer sort of traffic. For most of these data points the information is broadcast either on a periodic interval or only on a change of status. For example, if you move the shifter the PCM detects the change in the transmission range sensor and then broadcasts a message with this new position. The message is addressed NOT to a specific device (like the network address of the instrument cluster) but instead the message is sent to what is termed a "functional address". A functional address means the message is identified as having to do with a specific system, like the displays, or the fuel system, or parameters related to the HVAC, or even the tires. So in the case of a transmission range position change the PCM sends a message out addressed to "Displays" and any module that needs such information will be monitoring the message traffic looking for just such a message. The instrument cluster will recognize that this message has data it should display and will process the message and make the needed change to the shift position indicator. Some messages also sent to the "Displays" address might be picked up by the radio for display on its screen.

Getting back to using Torque Pro using this communication method... I have had some success doing this. But it is good to remember that Torque Pro was never intended to work this way. Yes, there is a specific message format that would need to be entered into Torque Pro to do a request for the data. It is somewhat complicated. Examples are seen in a few posts on this thread. One such example comes to mind where a fellow with a corvette was trying to call up tire pressure information.

This may seem confusing but I am going to jump back to the Torque PID thread to discuss the use of true PIDs as this thread is primarily intended to discuss Class 2 serial message traffic, not the use of Torque and PIDs. True enough, there will be a great deal of overlap between the two threads but I am going to at least try to keep the two threads focused on the thread title subjects as best I can.
 

ssndk

New Member
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.

Soren
 
OP
TJBaker57

TJBaker57

Well-Known Member
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.

Soren
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...

Screenshot_20210402-165227.png

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.
 

ssndk

New Member
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.

Yes, makes sense, I can see how I can verify the door position this way (with a bit of reverse engineering with the door open and closed.). 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). I guess all data bytes are unknown information? What I was hoping for was that the logic of what audible warnings get raised are done somewhere else and all I have to do is catch calls for audible warnings and then decipher what triggered it. I will of course check this on my car, but looks like line 28 and down (maybe even line 26 and down) the process causing an audible warning is taking place.

One thing that would be great is to script the conversion from the raw data to the format in your excel sheet. I think I will look into this as well. It would make debugging a lot easier. Thanks again!
 
OP
TJBaker57

TJBaker57

Well-Known Member
Where did you originally see that A1 is the passenger door?
This was a combination of first seeing this post which very well may be where I got my start on this endeavor....


And then I captured data from my vehicle and using spreadsheet formulas I isolated a listing of module addresses active in my vehicle. The next step was some simple testing where I would monitor an address on the bus and say press a button like a door lock and see what address sent data out. If you look at the tab 'Nodes' in the spreadsheet there is a listing of what I have identified in my vehicles.
 
OP
TJBaker57

TJBaker57

Well-Known Member
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).


I have a problem in that I have many copies of that spreadsheet. The one shared on this thread at post #117 doesn't have that line in the location you mentioned?? Are you using that link from post #117?

Just this morning I did some testing and I can now turn the chime on and off in my truck by sending the appropriate message.

I added a short data sample to the spreadsheet linked in post #117 as an example of chimes turning on and off and switched the spreadsheet 'Output' tab to display that data sample. This is done by changing the value in cell A1 of the 'Output' tab to correspond to the column letter in tab 'Sheet 1' that contains the desired properly formatted data log and giving it a minute or two to switch over.
 
OP
TJBaker57

TJBaker57

Well-Known Member
Just for the fun of it....

Using an OBD2 adapter and a serial terminal app like Bluetooth Serial Terminal by Kai Morich...

Set your header like this...

ATSH6896F1

Then send this message...

915D01

Your chime will sound once. The final hex byte is a count of the number of chimes to send. Send 915D06 and you will get six chimes, send 915D10 and you will get 16 chimes (it's hexadecimal, remember).

And if you send 915DFF you will be sending chimes for about a minute and a half!!

To cancel if you don't feel the need to wait you must send 115DFF or 115D00 or the like. The last byte doesn't really matter here because the '11' in place of the '91' is turning it off instead of on.

 
Last edited:

Online statistics

Members online
6
Guests online
358
Total visitors
364

Members online

Forum statistics

Threads
21,213
Messages
608,424
Members
14,905
Latest member
Essa89

Secure Browsing

Top Bottom