ELM327 & Class 2 Serial Data

[TJBaker57]

For some time now I have been pondering whether to start a new thread or update the old thread by @blurry of how to read TCCM codes.
I will start this thread here today but I think I will also add an update to the Blurry thread, simplifying things and correcting a few misstatements as well as updating the tools and costs involved. It is today far cheaper and easier to do what Blurry worked out so long ago. Also, very important to note that all of this pertains ONLY to vehicles before 2008 when they switched to CAN bus, at least for the ECM and TCM. I don't know what the TCCM was on for these later years either.


We see and speak of the data bus and vehicle communications somewhat frequently but who here has seen this communication?

After finding Blurrys thread on reading TCCM codes I discovered the cheap chinese knockoffs of the ELM Electronics "ELM327" chip, coupled with the necessary communications hardware/firmware and sold primarily on Ebay and Amazon. I then downloaded the data sheet for the ELM327 and got somewhat familiar with the commands available and found there was a monitor command which simply output whatever was happening on the bus. Wow! I could just eavesdrop! And so it began. 'Talking' to the ELM327 wasn't too difficult for me as the device utilizes a form of the old 'AT command set' we used back in the days of modems.

Fast forward to present day and I've been wasting my time of late by decoding as much as I can of the traffic on the GM single wire bus. Discovering some old SAE documentation was key. I use Google spreadsheets for analysis and display of the data I capture from the bus. The raw data goes through 3 transformations in the spreadsheet to get to the state where I can see what is going on without having too much mental gymnastics of deciphering what this or that bit or byte means.

Is this useful?? Not likely. Let's just say I do not expect much user participation here in this thread outside of maybe @YUKON87 and myself . That said, I have discovered some parlor tricks along the way. If I ever completely lock myself out of my vehicle I can pop the hood, connect 3 jumper wires to my Bluetooth obd adapter and command the door to open!! Of course I would need to have the jumpers and obd adapter with me so that is of limited real use.

So here are 2 screenshots, the first is raw data as captured from the bus and the second is what it looks like after the massaging of spreadsheet. These pictures represent about 15 seconds of traffic upon opening the drivers door, getting in and inserting the key and turning to run but NOT yet starting the engine. Yes,,, it is a busy bus.

 

[TJBaker57]

Here is one more screenshot showing class 2 messages I have decoded and a few I them from the 05 Yukon.am working on. There is ar least one for my Yukon in here that doesn't apply to my Trailblazer, steering wheel angle, I see no such messages from the 02 TrailBlaer but I see them from my 05 Yukon.

 

[6716]

That is sweet! I'm working on Arduino serial communication for a garden automation setup, so I have some appreciation for sorting out data on the wire. I have been interested in the OBD port on the truck for a while, but never jumped into it like you have here.

I'm glad you are doing it so I can follow along.

 

[TJBaker57]

So these are things that I puzzle over.

"Why would the liftgate module be asking if the engine is running? "

Sometimes it happens when I have the key on but engine off while I am recording data. Other times it is shortly after having started the engine. Have not yet seen it happen other than in the early stages of operation. Have seen it happen just a second or two after the PCM has just announced the engine is running. And what possible reason does the liftgate have for wanting to know if the engine is running or not? Puzzling, puzzling.


To make this post a little more useful to anyone who may be following.... I think my first glimpse into the J1850VPW format was this post at Fastfieros.com. I think @blurry may have linked to it or I searched using some text from Blurrys post. I think some of this info is not quite correct but it got me started well enough. For sure there is a mistake near the end where it states "$80+$10+$02 = $C2". Well....no it doesn't. And this snippet has been copied all over the web (including this site) and I have never seen anyone mention the error before!

VPW Communication Protocol

 

[YUKON87]

Very interesting indeed. As a return to the information you have shared this is what I've had for some time. I believe this works for my 03 Yukon. One of the reasons I believe this is monitored is for example when you put the vehicle in drive this locks the doors and if the back hatch or any access is open normally you get a warning chime. This also probably works with the "Passenger Presence System" for the airbag system and other systems. This is not something I achieved from another source this was hard earned. Don't know if anyone else has discovered this particular information but figured you would find this useful TJBaker57.

 

[YUKON87]

One of my interpretations includes the status "In Gear" which seems to be accurate for this PID. I'll have data stream records to share as well if I can ever get the time. Thank You TJ. Edit: I believe that this PID has been translated to be shared with my 2005 Envoy along with my 2003 Yukon. This along with the aformentioned PID directly relates to the question: "Why would the liftgate module be asking if the engine is running? "

 

[YUKON87]

So these are things that I puzzle over.

"Why would the liftgate module be asking if the engine is running? "

Sometimes it happens when I have the key on but engine off while I am recording data. Other times it is shortly after having started the engine. Have not yet seen it happen other than in the early stages of operation. Have seen it happen just a second or two after the PCM has just announced the engine is running. And what possible reason does the liftgate have for wanting to know if the engine is running or not? Puzzling, puzzling.


To make this post a little more useful to anyone who may be following.... I think my first glimpse into the J1850VPW format was this post at Fastfieros.com. I think @blurry may have linked to it or I searched using some text from Blurrys post. I think some of this info is not quite correct but it got me started well enough. For sure there is a mistake near the end where it states "$80+$10+$02 = $C2". Well....no it doesn't. And this snippet has been copied all over the web (including this site) and I have never seen anyone mention the error before!

VPW Communication Protocol

To address the errors on that website I noticed this as well, however, at the time, I wasn't 100% sure. This kind of threw me for a loop trying to understand it before I realized something wasn't correct.

 

[mrrsm]

Post#4 ...

"Why would the liftgate module be asking if the engine is running? "

Perhaps the LGM needs to know whether or not the SUV is actually In Motion on the Road... and the PCM & BCM have an Algorithm that senses this in order to Prevent the Side Doors and Rear Hatch and Window from opening up under Unsafe Conditions....

 

[YUKON87]

Post#4 ...

Perhaps the LGM needs to know whether the SUV is actually In Motion on the Road...and the PCM & BCM have an algorithm that senses this in order to prevent the Side Doors and Rear Hatch and Window from opening under unsafe conditions....

I believe that you're on the right track.

 

[TJBaker57]

Very interesting indeed. As a return to the information you have shared this is what I've had for some time. I believe this works for my 03 Yukon. One of the reasons I believe this is monitored is for example when you put the vehicle in drive this locks the doors and if the back hatch or any access is open normally you get a warning chime. This also probably works with the "Passenger Presence System" for the airbag system and other systems. This is not something I achieved from another source this was hard earned. Don't know if anyone else has discovered this particular information

Well I have not seen this elsewhere. What you have here is another PID for the BCM which is a bitmapped representation of the status of the door ajar switches.

bit 0 = drivers door
bit 1 = pass. door
bit 2 = Driver rear door
bit 3 = Pass. rear door
bit 4 plus bit 5 = rear hacth OR glass

The same PID works for the trailblazer however for this vehicle the rear glass and rear hatch are separate, bit 4 being the glass and bit 5 being the hatch.

Now what I am working here in this thread is a different arena than PIDs, however that PID information is most welcome!

The focus of this thread will be the general communications across the serial bus that is not the result of a data request by a tool (though that is also possible) but the normal operational messaging needed for the system to function as a whole. As a quick example, the HVAC system needs to know the AC High pressure. But that sensor is hooked to the PCM, not the HVAC module. So as we are tooling down the highway the PCM makes very frequent status reports not to a specific node but a 'functional address'. These are a pair of IDs assigned to particular area of operation that is monitored by the modules that need that data. The address pairs are further broken down to more specific items within that more broad area. For the Climate Control area the Primary ID Pair is $C2 & $C3. The high side pressure is further specified as Secondary ID $11. So in this screenshot below at line 431 the PCM ($10) is posting a message to the functional address of $B3 with a Secondary ID of $11, the value is $30 and the final byte is the checksum. Take the value of $30 convert that to decimal and then from its' native kPa to PSI and we have 87.84 PSI. Some of the more important such messages are acknowledged by the module(s) that use the report data but this particular one is not.

 

[TJBaker57]

To address the errors on that website I noticed this as well, however, at the time, I wasn't 100% sure. This kind of threw me for a loop trying to understand it before I realized something wasn't correct.

So people who didn't understand and just grabbed the $C2 were actually requesting and getting $80 (MIL) + $40 (Pending) + $02 (Current). BTW, the Tech 2 seems to request $92, not $C2. $92 being $80 (MIL) + $10 (History with Freeze Frames) +$02 (Current). I suspect this is what was intended at Fastfieros.



So having looked at the fastfieros link,,,, if you have tried (and/or succeeded) doing the mode $19 request trouble code by status then you have, likely without knowing it as did I, break into this arena of "Functional Addressing". The $6A & $6B spoken of and used to request the DTCs are precisely what I just posted about. $6A/$6B are assigned to "Legislated Diagnostics".

 

[YUKON87]

So people who didn't understand and just grabbed the $C2 were actually requesting and getting $80 (MIL) + $40 (Pending) + $02 (Current). BTW, the Tech 2 seems to request $92, not $C2. $92 being $80 (MIL) + $10 (History with Freeze Frames) +$02 (Current). I suspect this is what was intended at Fastfieros.



So having looked at the fastfieros link,,,, if you have tried (and/or succeeded) doing the mode $19 request trouble code by status then you have, likely without knowing it as did I, break into this arena of "Functional Addressing". The $6A & $6B spoken of and used to request the DTCs are precisely what I just posted about. $6A/$6B are assigned to "Legislated Diagnostics".


View attachment 95454

Agreed ty. Honestly understanding in-depth the data were looking at AIDS everyone willing to study and learn. I will study this in my spare time and let you know what I find on my vehicles

 

[TJBaker57]

actually In Motion on the Road

In that case I would have expected it to request vehicle speed!

Here is a sample where precisely one half second after the PCM announces the engine is not running the Liftgate asks if the engine is running. I'll get into how this is interpreted as time allows.

edit: I had mistyped BCM where PCM should have been.

 

[TJBaker57]

Agreed ty. Honestly understanding in-depth the data were looking at AIDS everyone willing to study and learn. I will study this in my spare time and let you know what I find on my vehicles

I intend to simplify the requesting of DTCs by status using todays available tools and apps over in the thread that began that discussion.

 

[mrrsm]

@TJBaker57 ...Do have this linked setup as part of your Diagnostic Tool Set...and if so... is this one worth having?

Download OBD2 port Lookup - Car's DLC APK Full | ApksFULL.com

OBD2 port Lookup - Car's DLC APK: You can't find the OBD2 diagnostic socket in your car? Use our search engine to locate your OBD connector! The norm states that the OBD port must be the vehicle...

apksfull.com

 

[TJBaker57]

Honestly understanding in-depth the data were looking at AIDS everyone willing to study and learn

One reason I chose to pursue this is those many instances where we get a no start or a no crank situation and we suspect security or similar issues. If we knew in depth what is actually happening on this bus during startup it could help in diagnosing such issues.

 

[TJBaker57]

@TJBaker57 ...Do have this linked setup as part of your Diagnostic Tool Set...and if so... is this one worth having?

Download OBD2 port Lookup - Car's DLC APK Full | ApksFULL.com

OBD2 port Lookup - Car's DLC APK: You can't find the OBD2 diagnostic socket in your car? Use our search engine to locate your OBD connector! The norm states that the OBD port must be the vehicle...

apksfull.com

Honestly,,,if one cannot even find the diagnostic port just maybe one is in over their head!

 

[mrrsm]

Sorry... I chose a Very Poor Neophyte Example of what I was really looking for... Which was more a Less a List of what your Arcane Diagnostic Tools happen to be... if they exist as such.

 

[TJBaker57]

@YUKON87

So here is another snippet that helps tie your 220C pid to this thread. Your 220C PID is called up from the BCM. But how does the BCM get the data to put into the 220C pid to begin with? Only the left rear and right rear door ajar switches are connected to the BCM (speaking Trailblazer here but is likely the same). Rear access ajar switches connect to the liftgate module and the drivers and passengers door switches connect to their respective modules. So here is the connection.... the BCM gets the information across the serial data bus in normal traffic which I am striving to decode here.

Here is a screenshot of just about 2 seconds of traffic as I opened the drivers door while the truck network was asleep. I left my adapter plugged in and paired up and began recording before touching the truck.



So as I opened the door....

Line 1) the DDM sends a Network Control wakeup message.
Line 2) (.062 seconds later) the DDM sends a status message to "External Access" at $C7 that the drivers door is open.
Line 3) BCM sends a network control message. (this details a number of parameters bitmapped in Data bytes 2,3,4)
Line 4) BCM acknowledges the door open message on $C6, External Access
Line 5) The Liftgate send a status report that the rear glass is closed to External Access on $C7
Line 6) DDM repeats door open message (redundency?)
Line 7) BCM repeats Network Control message.
Line 8) PDM reports pass. door closed on External Access, $C7
......modules $A0, $A1, $A2 report their door switch status at $C7 then slightly later downscreen the BCM acknowledges these reports at $C6.

So this is how information is passed around the modules.

 

[Mooseman]

Man, if all this could be rolled up into an easy to use app, I think you'd be rich.

 

[TJBaker57]

Man, if all this could be rolled up into an easy to use app, I think you'd be rich.

Well I still don't see this as being all that useful. Most of what I've decoded can be seen just looking at the dash gauges! As for the 'decoding' the message structure is laid out in SAE 2178. And other stuff can be read with the right PIDs in Torque or other Apps.

I just like knowing how things work!

 

[YUKON87]

@YUKON87

So here is another snippet that helps tie your 220C pid to this thread. Your 220C PID is called up from the BCM. But how does the BCM get the data to put into the 220C pid to begin with? Only the left rear and right rear door ajar switches are connected to the BCM (speaking Trailblazer here but is likely the same). Rear access ajar switches connect to the liftgate module and the drivers and passengers door switches connect to their respective modules. So here is the connection.... the BCM gets the information across the serial data bus in normal traffic which I am striving to decode here.

Here is a screenshot of just about 2 seconds of traffic as I opened the drivers door while the truck network was asleep. I left my adapter plugged in and paired up and began recording before touching the truck.

View attachment 95458

So as I opened the door....

Line 1) the DDM sends a Network Control wakeup message.
Line 2) (.062 seconds later) the DDM sends a status message to "External Access" at $C7 that the drivers door is open.
Line 3) BCM sends a network control message. (this details a number of parameters bitmapped in Data bytes 2,3,4)
Line 4) BCM acknowledges the door open message on $C6, External Access
Line 5) The Liftgate send a status report that the rear glass is closed to External Access on $C7
Line 6) DDM repeats door open message (redundency?)
Line 7) BCM repeats Network Control message.
Line 8) PDM reports pass. door closed on External Access, $C7
......modules $A0, $A1, $A2 report their door switch status at $C7 then slightly later downscreen the BCM acknowledges these reports at $C6.

So this is how information is passed around the modules.

Sounds like you've gained a head start with your knowledge base on this subject. Not so easy for the light minded to follow. So it sounds like everything ultimately goes to external access C7 as the middleman in this case, and from there is communicated directly with BCM on C6? What's amazing to me, is how intricate and complex this information sent around. Quite interesting to me to observe the actual behavior of the data itself. The value in this, which most people do not realize, is learning this system is thus in term learning old Tech, which all new tech is built upon. In a way it's a simple system yet complex. Very intrigued am I. With the information you have shared it will help me with our specific vehicles should I get the time. Wanted to share a raw data log playing with the radio mostly, and see what you think about each byte of data. This was done on my Yukon with the Bose non Lux system, a while back. As for document SAE 2178, I have jotted through all four sections, but never got the chance to really focus on the details, however, I am familiar with much of this information the rest I can only guess. If my memory serves me well, I do believe "header printing" was turned on. I want to say "allow long messages" was enabled. Some of this data may include cycling the power on my rear view mirror. Playing with the mirror was done when it was malfunctioning before I re soldered and repaired it.

 

[YUKON87]

Well I still don't see this as being all that useful. Most of what I've decoded can be seen just looking at the dash gauges! As for the 'decoding' the message structure is laid out in SAE 2178. And other stuff can be read with the right PIDs in Torque or other Apps.

I just like knowing how things work!

Despite being able to see this in the IPC, this would be useful at any rate, for example, in the event that one of your gauges malfunctions. The data doesn't line up with what the Gauge is being driven to do. Maybe this could be used as a method of ruling out gauge versus circuit Etc.

 

[TJBaker57]

sounds like everything ultimately goes to external access C7 as the middleman in this case, and from there is communicated directly with BCM on C6?

Well,,, close. Think of these "Primary ID" pairs of addresses sort of like a chalkboard on the wall of the network. A place to exchange information about a specific subject area. $C6/$C7 is about external access. If you have something to share with others about this matter you send a 'report status' message type up there to typically to $C7. If you need to know something about the current status of external access things like door switches you post up a 'status request' message type to $C6. Additionally, if external access matters are something that you need to know about then you listen for messages at $C7 and $C6. So $C6 & $C7 or (other Primary ID pairs) don't actually ever send out or receive a message.

I think this is a loose way of describing it!

 

[TJBaker57]

As for document SAE 2178, I have jotted through all four sections

It is in section 4 that you will find these "Primary ID" pairs and the "Secondary ID" values that were assigned at the time of printing, mine being 1999. Having some knowledge of spreadsheets has helped tremendously in translating the raw network capture file to something more understandable. Training wheels of a sort to learn the language. Believe you me it took me a very long time indeed to get the basic understanding I think I have now.

 

[YUKON87]

It is in section 4 that you will find these "Primary ID" pairs and the "Secondary ID" values that were assigned at the time of printing, mine being 1999. Having some knowledge of spreadsheets has helped tremendously in translating the raw network capture file to something more understandable. Training wheels of a sort to learn the language. Believe you me it took me a very long time indeed to get the basic understanding I think I have now.

Same here. As Always, thanks. And as always, should I have something new and relevant to share, I will follow up on this post for things pertaining to the DLC for function.

 

[TJBaker57]

my memory serves me well, I do believe "header printing" was turned on. I want to say "allow long messages" was enabled. Some of this data may include cycling the power on my rear view mirror.

So with a bit of editing I was able to use data from your screenshots in the spreadsheet. Your Yukon has a couple of nodes the spreadsheet doesn't have yet as they are not in the Trailblazer. $A6 and $9A at least so the source name might not be correct but the Target name is correct. I see no mirrors here. The black background cells are merely network heartbeat messages, modules confirming they are awake. the 25 29 97 in tan is something to do with the wheels. I haven't figured that one out yet but know it is not a wheel speed. I do not have any navigation in either truck so that's a mystery, maybe coordinates, direction of travel, that sort of thing? The FF 40 06 seen first at spreadsheet row 16 is 3 bytes of bitmapped status in columns M, N & O. The value in M tells me your key is in the run position. (6 is acc, 8 is start, 3 is off and there actually is a position between off and acc, at least confirmed on the trailblazer where that first click before the acc position powers up at least 2 circuits, fuse #50 and #47) I think this is done to give the PCM and BCM a headstart before the ACC position is reached. Moving on, 2 entries to target address (Primary ID pair) $73 & $72 are the BCM reporting the current voltage to the IPC. Your value is $053A which equates to 13.38 VDC. The next new thing seen is at spreadsheet row 23 (leftmost in pic) and this is the PCM reporting a fuel system value. While I cannot pin it down yet I have a hunch it is fuel used to be added to the fuel used variable in the IPC. On longer sessions in my Yukon this value has risen up to the max of $FF then restarts at $00. The only guess I could make is a consumption count of some item and the Primary ID pair is designated as fuel system. The next new item is at spreadsheet row 29 and is the PCM reporting engine oil pressure, Primary ID $4B, Secondary ID of $11 (as seen in SAE 2178 section 4). Your value there is $3A. SAE 2178 sec 2 gives us the scaling of 1 bit=4 kPaG so a little math yields 33.65 PSI. The rest seems repetition of previous lines for the most part.

I would add the command ATS1 to your logging initiation string to keep the bytes separated and far easier to read. What are you using to record?

 

[YUKON87]

So with a bit of editing I was able to use data from your screenshots in the spreadsheet. Your Yukon has a couple of nodes the spreadsheet doesn't have yet as they are not in the Trailblazer. $A6 and $9A at least so the source name might not be correct but the Target name is correct. I see no mirrors here. The black background cells are merely network heartbeat messages, modules confirming they are awake. the 25 29 97 in tan is something to do with the wheels. I haven't figured that one out yet but know it is not a wheel speed. I do not have any navigation in either truck so that's a mystery, maybe coordinates, direction of travel, that sort of thing? The FF 40 06 seen first at spreadsheet row 16 is 3 bytes of bitmapped status in columns M, N & O. The value in M tells me your key is in the run position. (6 is acc, 8 is start, 3 is off and there actually is a position between off and acc, at least confirmed on the trailblazer where that first click before the acc position powers up at least 2 circuits, fuse #50 and #47) I think this is done to give the PCM and BCM a headstart before the ACC position is reached. Moving on, 2 entries to target address (Primary ID pair) $73 & $72 are the BCM reporting the current voltage to the IPC. Your value is $053A which equates to 13.38 VDC. The next new thing seen is at spreadsheet row 23 (leftmost in pic) and this is the PCM reporting a fuel system value. While I cannot pin it down yet I have a hunch it is fuel used to be added to the fuel used variable in the IPC. On longer sessions in my Yukon this value has risen up to the max of $FF then restarts at $00. The only guess I could make is a consumption count of some item and the Primary ID pair is designated as fuel system. The next new item is at spreadsheet row 29 and is the PCM reporting engine oil pressure, Primary ID $4B, Secondary ID of $11 (as seen in SAE 2178 section 4). Your value there is $3A. SAE 2178 sec 2 gives us the scaling of 1 bit=4 kPaG so a little math yields 33.65 PSI. The rest seems repetition of previous lines for the most part.

I would add the command ATS1 to your logging initiation string to keep the bytes separated and far easier to read. What are you using to record?

View attachment 95479

Interesting indeed, well thought-out and well presented. This helps me tremendously as I hope it further helps you. I noticed the ID pairs. But this was done with about 2 minutes time provided. All I could do was screenshot. I'll take your suggestion of ATS1. For some reason it seemed like I knew that command but it got lost in Daily duties and time. I have struggled with Sheets for data logging in terms of format. Although I can produce a proper spreadsheet of a future data log as I will include this so you won't have to do any footwork from an image. The idea is to refresh what I already know and delve deep into this. I love to learn and I love a challenge and this intrigues me. Another point of learning this is I expect both of my vehicles to go into hyper mile. I may do two separate logs with the first one setting a header just for my BCM which is where my vehicle can get very interesting as I have flex fuel. Second to that, I may try a short broadcast header. So I'll have more data to share and I'll try to interpret everything as best I can before I submit that on this page. Thank you very much. I usually learn very quickly and as we converse over this data I am learning more.
Edit: was easier to screenshot and circle the combination. I've used other apps in the past.

 

[YUKON87]

Well,,, close. Think of these "Primary ID" pairs of addresses sort of like a chalkboard on the wall of the network. A place to exchange information about a specific subject area. $C6/$C7 is about external access. If you have something to share with others about this matter you send a 'report status' message type up there to typically to $C7. If you need to know something about the current status of external access things like door switches you post up a 'status request' message type to $C6. Additionally, if external access matters are something that you need to know about then you listen for messages at $C7 and $C6. So $C6 & $C7 or (other Primary ID pairs) don't actually ever send out or receive a message.

I think this is a loose way of describing it!

I believe I understand. The rules are a little more specific on VPW. I had observed that report and request usually was one hexadecimal number down or up. It's just a pathway to a junction to exchange information in this case C6 / C7. Correct me if I'm wrong kind of like a two-way Road.
Edit: to add to this they may not be wheel speed. I don't know if you noticed but I mentioned on another post that I had "levels" in each of the mirrors. "4WAL". So for whatever reason my vehicle needs to see something in relation to that. Maybe it has something to do with that who knows. I also have what I think is referred to as Hydro steer. As far as navigation / OnStar, all that is routed at some point through my rearview mirror along with compass and OAT. So compass gets its direction through the data through OnStar likely.

 

[TJBaker57]

one hexadecimal number down or up.

I think here you are referring to the 'W' bit detailed in 7.2.2 SAE 2178 -1. That would be bit 0 of the target address. That bit, plus the 'C' bit (bit 6 of the Secondary ID) and the message type determine the action/operation of the message. You may have noticed columns E, F
, G in my spreadsheet pics where the W, Q, and C bits are listed?

I could likely do a lookup column that would list the message operation. I had considered that but thought the sheet was getting too wide but no I am thinking maybe to go ahead with that idea. Might make the sheet more easily followed.

My spreadsheets are Google sheets so they are online and shareable as well as easily copied so as this progresses I will have links to them. They can be viewed in the Sheets app or simply seen in HTML.

 

[YUKON87]

I think here you are referring to the 'W' bit detailed in 7.2.2 SAE 2178 -1. That would be bit 0 of the target address. That bit, plus the 'C' bit (bit 6 of the Secondary ID) and the message type determine the action/operation of the message. You may have noticed columns E, F
, G in my spreadsheet pics where the W, Q, and C bits are listed?

I could likely do a lookup column that would list the message operation. I had considered that but thought the sheet was getting too wide but no I am thinking maybe to go ahead with that idea. Might make the sheet more easily followed.

My spreadsheets are Google sheets so they are online and shareable as well as easily copied so as this progresses I will have links to them. They can be viewed in the Sheets app or simply seen in HTML.

I did notice the binary. Magic is in the details. So the lookup would be welcomed in my mind.

 

[TJBaker57]

I have struggled with Sheets for data logging in terms of format.

What I did with my sheet layout is thus;

I begin with the tab Sheet1. In here I simply drop the text of my data log in its' entirety. (Note the spaces between the bytes)



Sheet2 runs a formula that pulls the data from Sheet1 and breaks it out into separate columns. Optionally here I can filter such things as the heartbeat message and so on to reduce lines needing processing further towards the final result.



Next up is a sheet where my final display resides but I call up data first way over to the right of the sheet, normally out of view but handy to reference if needed. This data call is filtered by means of an SQL query seen at the top of my final display screenshots.The data appears the same as in sheet2 but is sometimes filtered to my current area of exploration.



Next is my working display on the same sheet. Here I break out the details like W bit, Q bit, C bit etc and do some conditional coloring to help draw my eye to whatever I am investigating. Byte 1 of the 3 byte header is split out to display priority and type (dec). Priority has a color scale applied so the highest priority messages are seen as red while lowest are blue. Target and Source have lookup columns displaying the names.




There is one more area of display that is in this final sheet, located to the near right of the picture just seen. In this area I break out the results of status messages I have identified and ones I am working on. Things such as AC high pressure and engine RPM.






There are a few other sheets that hold the data used for lookups like nodes, Primary ID names and message types. What I like is the processing is largely automated by the Spreadsheet, in simplest form all I need to do is copy/paste in a fresh data log and go on to see what it holds. There are a few embellishments I didn't detail here. An example would be I can load multiple logs in Sheet1 and then select which column to work with.

 

[TJBaker57]

Magic is in the details. So the lookup would be welcomed in my mind

Better??

 

[TJBaker57]

was easier to screenshot and circle the combination. I've used other apps in the past.

Might I suggest you have a look at "Bluetooth Serial Terminal" by Kai Morich on the Google Play Store.

What drew me this app is:

Supports up to 35 macros such that you can write out your command strings and have them ready to send at the push of a button.

Save your data either straight to clipboard or a timed & dated text file.

Very simple setup, I just set a line delay of 1000 ms, a between character delay of 5 ms, enabled timestamps, pick a directory for log file saving and I may have needed to set the end of line character(s).

My biggest issue in doing any of this is an apparently inherent instability of Android Bluetooth.

 

[YUKON87]

As a reply to all of the above. I greatly thank you for the detail you have put into this. This is beyond helpful as I've known for a long time I needed to get this down. And this is just as helpful for anybody to learn and as anyone interested learns data can be shared here. I like the style of the spreadsheets and I will likely follow your suggestion to the letter. This would be a good route both for Simplicity and to set a certain standard for anyone interested in Sharing data. Thanks again will spend what free time I have to get this set up properly. I will definitely take your app under advisement as the one I use works well enough but seems to lack option such as what you have mentioned with the other app.

 

[TJBaker57]

I noticed a potentially useful bit here....

Recording during startup captures the voltage drop seen by the BCM. In this filtered view it can be seen at row 2 my voltage drops to 8.21 volts! Happens for a second maybe and way too fast to be seen accurately just watching the dashboard. I suppose a fancy multimeter could capture min and max values. But Hey! I'm getting all this with a $12 adapter!



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??
*Oil Pressure (as faked by PCM)
*Charging Volts DC
*AC High Pressure
*Rear Blower Speed
*Rear Washer On/Off
*Engine Air Intake Temperature
*Outside Temperature
*Engine Torque
*An unresolved incremental value for fuel system (possibly fuel used?)
*Fuel Level as percent
*Engine Coolant Temperature
*Engine RPM
*Transmission Shift position from PCM (PRND321)

 

[Enroute]

Wow! Love this thread. Takes me back to my serial modem days. Just a quick ? My 2002 sil 5.3 LM7 motor is a class 2 (pretty sure). Do I need to modify/edit the (GM) listed PIDS in the Torque pro app to get the correct info such as MAF, misfire, MAP, etc due to it being a class 2 engine/ECM? Being a new member and just confirmed, I am looking forward to reviewing the extensive info you all have provided. Thanks again for sharing this knowledge as it makes me think all that learning I did in the early years of serial communication was not wasted.

 

[TJBaker57]

Wow! Love this thread. Takes me back to my serial modem days. Just a quick ? My 2002 sil 5.3 LM7 motor is a class 2 (pretty sure). Do I need to modify/edit the (GM) listed PIDS in the Torque pro app to get the correct info such as MAF, misfire, MAP, etc due to it being a class 2 engine/ECM? Being a new member and just confirmed, I am looking forward to reviewing the extensive info you all have provided. Thanks again for sharing this knowledge as it makes me think all that learning I did in the early years of serial communication was not wasted.

I also have an LM7 in my 2005 Yukon. If we are speaking of the [GM] extended PID set that comes with Torque Pro and needs to be imported....some of those will work and some won't. As for Class 2 vs CAN bus the PIDs will not need modification as the ELM327 obd adapter will handle that matter of message formatting. You may have discovered the "More PIDs for Torque" thread here. I have uncovered a raft of PIDs for the 4.2 LL8 that were previously unknown to the public. I seem to remember some for the Yukon LM7 also but would need to check my records.
I may even have some that never got posted! (I'm not the most organized individual)

 

[Enroute]

You are amazing with this stuff and yes I watch that thread too (to say these two threads are great is not even close to blowing enough smoke). My ELM327 should be here on Wednesday of next week and I am really looking forward to “getting good” with it. Any LM7 PIDS help would be greatly appreciated. Can you advise which of the [GM] extended PID set do not work for my LM7 so I can steal clear of those. Are the non-working PIDS not for class 2 or need to be edited to pull the correct information or just do not work for other reasons? Love to learn! Thanks again

 

[Enroute]

Should we be making a new thread for this? What to keep with site rules since we have moved away from the 4.2 and on to the 5.3. Your call as i am new to this forum.