More PIDs for Torque App

OP
OP
T

TJBaker57

Well-Known Member
Tried to make the memory address service $23 work with OBD Fusion. No dice so far. Am corresponding with their tech support about that now.

For some unknown reason OBD Fusion seems to turning my service $23 request into a service $02 request. If memory serves that's a freeze frame request. Instead of sending the "6C1AF12300009001" string it is sending "6C1AF10230009001" which generates a negative response.
 
OP
OP
T

TJBaker57

Well-Known Member
For some unknown reason OBD Fusion seems to turning my service $23 request into a service $02 request.
Turns out I was a zero short in my 'PID' entry!! I had entered 0009001 instead of 00009001. "Missed it by that much!"

I still had work to do after correcting that error though. At least for this purpose OBD Fusion is beginning the assignment of tokens (A,B,C...) earlier in the response than does Torque. What Torque represents as A in the equation OBD Fusion is calling C. Perhaps the app does not recognize a service $23 response. Anyway, adjusting the equation did the trick

Screenshot_20200522-155545.png
 

Mooseman

Moderator
That is way cool! This could help many that are having issues with the 4x4 system.
 
OP
OP
T

TJBaker57

Well-Known Member
I've got to give a tip of my hat to a member of both the 'old site' TV and later here as well, for the post that got me started on this. User name @blurry whose wife had an 02 TrailBlazer with a 4wd issue.


His research got me started reading and talking to the trailblazers class 2 network. It has become much easier and cheaper to do what that post from 9 years ago describes.

One big convenience for me has been the discovery of an Android Bluetooth serial app that supports macros, line delays, and between-character delays, log the session, and so on..


This allows me to assign a series of commands to a single button and not have to manually type in stuff. I've recently run macros of 500 lines to query memory addresses!!

My biggest inconvenience is that Android Bluetooth frequently sucks at maintaining a connection!!
 

Mooseman

Moderator
So true. Have you thought of trying the wifi version? I have found that connection better but haven't tried either on my new Android HU yet.

Is there a way to package these up and have them available as a "download and install" type deal? I haven't delved super deep into Torque but it does have the install custom PIDs.
 
OP
OP
T

TJBaker57

Well-Known Member
I find that if use an old Windows XP netbook and hyperterminal the Bluetooth connection holds just dandy. That tells me the trouble lies in Android.

As I understand it a WiFi version results in no internet connection on your Android device while using the wifi OBD2 adapter. I have experienced this with a WiFi inspection camera I have. That device requires me to disable mobile data on my Android whenever I want to use the wifi camera! If I leave mobile data active the silly camera app looks to the internet for the camera and cannot find it. Doesn't know enough to look locally.


Something on my back burner is to make a csv file for import to Torque containing these additional PIDs and such. That is something I do for myself quite regularly during testing. Just need to put together a public/GMTN version!
 

Mektek

Well-Known Member
I did some testing and found the root of the problem. Older versions of Torque limit the PID entry length. V1.6 is limited to 6 hex characters, while v1.10 works as TJBaker57 indicates. I haven't tested v1.8 so I don't know when the change to long PIDs was made in that or v1.10
Mystery solved!:celebrate:
 

YUKON87

Active Member
Well here goes.....this is not technically a "PID" but I am going to post it here nonetheless.

A true PID is usually requested from a module by use of service $22, request data by PID. You send a properly formatted request to the module, the module takes the PID number and looks up that PIDs details in an internal table where it gets the memory address where the PID data is stored as well as other details needed to retrieve and process the PID data. This is the general method used by Torque and others. Works great for the majority of interests.

But what about the Transfer case and HVAC modules?? I discovered sometime last year that our TCCM and HVAC modules do not support service $22 so we cannot request live data from these using the normal methods. Most unfortunate since the 4WD system seems to generate so much grief for owners.

I set about finding a way to get at this data last year then tabled it for a time after making some progress in identifying PIDs, even though I could not directly use the PID number. Spent the last 3 days poring over documents found on chinese websites and tinkering with my bluetooth elm clone adapter and a serial terminal app that has support for saved macros as well as being able to log the session, the latter being crucial to the task.

OK, lets get to it. I am using service $23 instead of service $22 so the ~pid~ info typed into Torque will begin with 23, not 22. Next comes a 3 byte memory address followed by a single byte memory size. My tests indicate the memory size request can only be 01 which returns 4 bytes beginning at the memory address in the request. Here is the string for the 4WD mode switch on the dashboard of my 2002 TrailBlazer. "2300009001". This will return 4 bytes but we are only using the first byte here, which Torque will label as "A" in the equation. The value returned by the TCCM is a single hex byte which Torque converts to decimal and passes to the equation editor as 'A'.

View attachment 94672

View attachment 94673

The header is important here. It must be as shown so that the message packet is sent to right module. The message priority and type is "6C", the TCCM is node address 1A, and our sending address is "F1" so the full 3 byte header is "6C1AF1".

View attachment 94674
------------------------------

For the encoder motor return voltage the only change besides the names of your choosing is the memory address of $000091. So the 'mode and pid' string is thus "2300009101"

-------------------------------


So again I say, I have no way to know if this will work on anything other than what it has been developed on, my 2002 TrailBlazer.

Someone here once posted they could not enter more than 6 characters in the "mode and pid" field of Torque. I never came up with any reason for this as I can enter almost anything there without any error message. If this is the case for you then this method of retrieving data cannot be made to work for you as the service $23 requires the string as I have shown it here.

Please do post here if you try this method and works for you. I fully expect this to ONLY work for trucks with the very same 4WD system as mine, same TCCM etc. It is quite possible that even other year TCCMs will be different and this will not yield correct data.

I have been using mode 23 as well. From my observation the first of 3 PID bytes or mmeaddress in the pid field seems to be able to contain a module header id (40 for BCM). Regardless a 2 byte memory address or pid attempt (bytes 2 & 3) gets shifted in front of the mode upon an affirmative response. Example,
Send: "23"10"52E101"
Recieve: "6352E101000C48"
Otherwise "7F231052E101XX
I have tons of memory addresses for our vehicles to test.
 

Attachments

Mektek

Well-Known Member
One more observation about the Torque app - to use these long PIDs you need the current version.
Both V1.6 and V1.8 are limited to 6 characters.
The current v1.10 has ballooned in size to 16.3mb from 5.6 with v1.8
It is also possible to edit the privileges to prevent access to network and phone ID/status and google play billing if you don't need it - but v1.10 seems to have a problem with doing that.
 
Last edited:
OP
OP
T

TJBaker57

Well-Known Member
I have been using mode 23 as well. From my observation the first of 3 PID bytes or mmeaddress in the pid field seems to be able to contain a module header id (40 for BCM). Regardless a 2 byte memory address or pid attempt (bytes 2 & 3) gets shifted in front of the mode upon an affirmative response. Example,
Send: "23"10"52E101"
Recieve: "6352E101000C48"
Otherwise "7F231052E101XX
I have tons of memory addresses for our vehicles to test.

What is the 3 byte header you are using for this command seen in the attachment? To my limited knowledge a
Service 23 messages are meant to use physical addressing to one intended target node.

With regards to your 7F general response messages as far as I know the last byte indicates the type of response. "11" = mode not supported, "31" = Request out of range and so on. See negative response codes here...

The single positive response in your screenshot is interesting.
 

YUKON87

Active Member
What is the 3 byte header you are using for this command seen in the attachment? To my limited knowledge a
Service 23 messages are meant to use physical addressing to one intended target node.

With regards to your 7F general response messages as far as I know the last byte indicates the type of response. "11" = mode not supported, "31" = Request out of range and so on. See negative response codes here...

The single positive response in your screenshot is interesting.
I am running a broadcast header of 8CFEF8. I thought you would take interest in the positive response. I was interested to hear your thoughts or anyone else's on that matter. I am familiar with the error codes. The reason there were so many was because of that broadcast header. I have been issuing commands: AT AL, AT H1, with my test runs as of late as well, although you will not witness that in the responses in that instance. The result is very interesting indeed. Thoughts?
 
Last edited:

YUKON87

Active Member
Heres one to observe. This was on my 2003 Yukon SLT.

Edit - With Send: "AT AL" (Allow Long Messages) , and Send: "AT H1" (Turn Header Printing "On") , with "FE" (Broadcast to all Nodes).

P.S. Pay attention to the printed headers. This gives anyone viewing the image a brief list of some of the module ID addresses, highlighted in Red, for my 03 Yukon. Which directly relates to "Pid's".
 

Attachments

Last edited:
OP
OP
T

TJBaker57

Well-Known Member
Heres one to observe. This was on my 2003 Yukon SLT.

Edit - With Send: "AT AL" (Allow Long Messages) , and Send: "AT H1" (Turn Header Printing "On") , with "FE" (Broadcast to all Nodes).

P.S. Pay attention to the printed headers. This gives anyone viewing the image a brief list of some of the module ID addresses, highlighted in Red, for my 03 Yukon. Which directly relates to "Pid's".

I also add the command AT S1. Makes it easier for me to use the session log in spreadsheets.

My next question is where did you come up with the address 01 13 DE?? I think the TrailBlazer gave no positive responses to this but the Yukon gave a few, though not every time. Also I got non zero values from the ECM and node $97.

My efforts have been primarily directed towards the TCCM. Purpose driven here. The 4WD systems give a lot of owners headaches and since the standard mode $22 is not supported I wanted to find a way to monitor a few selected items such as the mode switch and encoder returns signals. Also the front actuator switch. While you can check these things with a DMM it is better to observe the parameter longer term to watch for voltage fluctuations you may not see with a spot-check.

Now as I look for a couple other data points I am beginning to think I got lucky finding the first 3 with relative ease.
 

Mektek

Well-Known Member
I have some strange results from the tccm pids. The axle lock indicator is exactly opposite and shows locked when unlocked. The 4wd sw indicator rapidly cycles from near 0 to 5v and back. The encoder slowly cycles from 0-5 and back.
 
OP
OP
T

TJBaker57

Well-Known Member
I have some strange results from the tccm pids. The axle lock indicator is exactly opposite and shows locked when unlocked. The 4wd sw indicator rapidly cycles from near 0 to 5v and back. The encoder slowly cycles from 0-5 and back.
In light of the non-standard way we are getting this data I would suggest a check of both of these values ( one at a time) with an actual DMM, done while all the various connections and assemblies are together in driveable condition. Backprobing the connections at the TCCM works well for me. If the value from the switch is in reality fluctuating like the PID display then there is clearly an issue there with wiring or a bad switch. Similarly, the encoder return signal should be relatively stable.
 
OP
OP
T

TJBaker57

Well-Known Member
The axle lock indicator is exactly opposite and shows locked when unlocked.
Thanks for posting this. I just ran out and verified my equation on my 2002 TrailBlazer. I thought I may have reversed the values of bit 0 in the equation but the equation works for mine as pictured above in this thread.

If you would, double check the equation you have entered for me when you get the chance?? When I started checking these memory addresses I wondered if different years or firmwares might relocate the address where parameters are stored but we have the same year and presumably the same firmware.
 

Mektek

Well-Known Member
I have an exact match with your screenshot. If the voltages were actually fluctuating like that it would probably set a "service 4wd" light and I would be watching the mode lights on the switch lights cycling back and forth. When I have the encoder motor installed I'll do the backprobe test and confirm that.
I know you're already considering it - it would be nice to have all the TCCM codes together in a single post :celebrate:
 

YUKON87

Active Member
I also add the command AT S1. Makes it easier for me to use the session log in spreadsheets.

My next question is where did you come up with the address 01 13 DE?? I think the TrailBlazer gave no positive responses to this but the Yukon gave a few, though not every time. Also I got non zero values from the ECM and node $97.

My efforts have been primarily directed towards the TCCM. Purpose driven here. The 4WD systems give a lot of owners headaches and since the standard mode $22 is not supported I wanted to find a way to monitor a few selected items such as the mode switch and encoder returns signals. Also the front actuator switch. While you can check these things with a DMM it is better to observe the parameter longer term to watch for voltage fluctuations you may not see with a spot-check.

Now as I look for a couple other data points I am beginning to think I got lucky finding the first 3 with relative ease.
Memory addresses are more Dynamic in nature. That's why I tend to try some of them with success and some with no success using a broadcast header. My studies on the logic and programming of these ECM/PCMs and other modules, to my understanding, would suggest many addresses are broadcast addresses, meaning they may not read out in any conventional way or anyway specific to any Given module. Some addresses are broadcast only. I mean, in all actuality, it's more of a question of how far down the rabbit hole do you want to go? To answer your question, "113de" is a memory address in relation to flex fuel for my 2003 Yukon. Now I have a question for you off subject. I know this is not the proper place to ask probably. Do you have issues with your TC on your 2002 not fully locking up? My 2005 Envoy, at high cruise, doesn't seem to be fully achieving lock up, TCC slip speed rides between 30 and 50 even at 70 mph. You can't tell, as it obviously feels like it's at full lock-up. This was before and after a standard transmission service performed by me. From what I've read recently, they released an update involving the Viscous fan clutch and AC clutch logic, that rolled off the assembly line starting with the 2005 year model. From what I've gathered, it seems like a Band-Aid/hack job in the form of a software update or tune, to Band-Aid a problem with the fan clutch not spinning fast enough and causing earlier models to run too warm. I've observed, assuming this is the case, that it probably affects torque converter lock-up as well as short Cycles the compressor at higher speeds, due to "Fan overspeed" due to update. Highside builds when engaged and it's brought down to quickly, causing an on-and-off behavior with the Envoy A/C Clutch, called short cycling. This causes other odd behaviors as well. Essentially, the update, actually causes fan over speed. I've replaced the water pump and fan clutch assemblies and cleared all codes from all modules and fan over speed DTC continues to be set. Doesn't even seem to take control of the viscous fan clutch unless, for example, the air conditioning is running with the compressor engaging and disengaging. I know it has control as I've noticed a hard snatch at the fan speed to either increase or pull it down to the desired. When it doesn't actually seem to be trying to control this operation, it shows me a desired fan speed of 302 per your PID.
 

Mektek

Well-Known Member
AFIK the TCC is programmed for various degrees of slip, and it never fully locks. So a 30-50 rpm slip is normal.
 
OP
OP
T

TJBaker57

Well-Known Member
AFIK the TCC is programmed for various degrees of slip, and it never fully locks. So a 30-50 rpm slip is normal.
Mine locks solid at as low as 40 mph in both my 05 Yukon and my 02Trailblazer. 0 slip rpm as seen in the PID that is part of the Torque predefined GM extended set.

Now there is a known issue with the 4L60E transmission in our vehicles where a steel valve spool in the aluminum valve body wears the bore and results in a pressure loss of TCC apply pressure. Or something very close to that description. I'm not very well versed in transmission speak!! If you google this up you should come up with a better explanation. There are a few different "fixes" for this condition. I recommend this article ..
 
OP
OP
T

TJBaker57

Well-Known Member
shows me a desired fan speed of 302 per your PID.
My fan is admittedly not operating correctly. I see a fairly constant 720 rpm at idle with a commanded speed of 496 and around 1200 rpm fan speed at highway speeds. That 496 very seldom changes in my vehicle. While my fan doesn't fully release it releases enough to keep under the threshold for setting an overspeed DTC. I believe that threshold is 1600 rpm while at a zero percent pwm.

When I started this thread I was hopeful for more user participation that might lead to a knowledgebase of sorts for various parameters. I only know what I see on my own vehicle.
 
OP
OP
T

TJBaker57

Well-Known Member
Some addresses are broadcast only
I have been recently monitoring the general class 2 network chatter and deciphering some of that. It began in another thread here about unwanted 4wd operations at speed.

I intend to open a separate thread on that subject in due time (which means when I have something useful).

Thus far I have learned how I can unlock the vehicle from outside with my smartphone if the OBD adapter is plugged in!!

I have enough of an understanding thus far to recognize 'broadcast' messages such as heartbeat messages from all nodes currently active. Also several more 'functional' addresses sent out to whatever node(s) monitoring specific functional addresses, such as the PCM announcing a transmission shift or the TCCM announcing a mode change.
 

Mektek

Well-Known Member
Mine locks solid
Interesting.... according to the sonnax.com writeup:

"Within the EC3 game plan it is generally undesirable to fully lock the TCC. Instead, a consistent slip of about 20 to 40 RPM is aimed for under most operating conditions"
but:
"Under some high-torque or freeway speed situations, the PCM will increase duty cycle to 98% to fully lock the TCC. This eliminates slip and prevents excess heat during high-load conditions. "

I'll have to check mine someday to see what it does.....
 
OP
OP
T

TJBaker57

Well-Known Member
Interesting.... according to the sonnax.com writeup:

"Within the EC3 game plan it is generally undesirable to fully lock the TCC. Instead, a consistent slip of about 20 to 40 RPM is aimed for under most operating conditions"
but:
"Under some high-torque or freeway speed situations, the PCM will increase duty cycle to 98% to fully lock the TCC. This eliminates slip and prevents excess heat during high-load conditions. "

I'll have to check mine someday to see what it does.....
I noted that as well. Both of my vehicles lockup pretty much anytime I am not accelerating and at a steady speed over 40 mph. However, both of these vehicles also have had the transmissions rebuilt with various unspecified 'updates' by the rebuilder. They likely include some change to the aforementioned steel spool valve/aluminum bore issue.
 

YUKON87

Active Member
AFIK the TCC is programmed for various degrees of slip, and it never fully locks. So a 30-50 rpm slip is normal.
Thank you for alleviating some concern and answering my question. Thanks out to TJ as well. I'm familiar with the logic of these things but never noticed this on my Yukon. The Yukon actually reads zero slip under these conditions which tells input transmission and output of Crank are locked in sync. It seems like a bad idea to always have slip, even with lockup, at high cruise. This would normally generate more heat and wear long term. But alas, most of my knowledge is with older GM's and Fords. Well to get back on track with pids. I'll have more to share in the next week just have to have enough time to post them properly.
 
Last edited:

YUKON87

Active Member
I have been recently monitoring the general class 2 network chatter and deciphering some of that. It began in another thread here about unwanted 4wd operations at speed.

I intend to open a separate thread on that subject in due time (which means when I have something useful).

Thus far I have learned how I can unlock the vehicle from outside with my smartphone if the OBD adapter is plugged in!!

I have enough of an understanding thus far to recognize 'broadcast' messages such as heartbeat messages from all nodes currently active. Also several more 'functional' addresses sent out to whatever node(s) monitoring specific functional addresses, such as the PCM announcing a transmission shift or the TCCM announcing a mode change.
Have you tried issuing these commands with success? I know certain commands to move windows up and down. Was curious to hear thoughts on this from someone who has tried these bi-directional commands. I do know that starting a vehicle would have to have key in, adapter in, and it gets more complicated from there despite these things. My understanding that on many vehicles, issuing engine run for example, at least on newer sytems, only lasts for a short period of time before BCM kicks it out, engine is shut off automatically after a short time issuing such a raw command. I look forward to your new thread on bidirectional commands. Nice to know I'm not the only one that can't quit tinkering.
 
Last edited:
OP
OP
T

TJBaker57

Well-Known Member
someone who has tried these bi-directional commands

Just a quick note,,, I don't think what I am doing would be considered bi-directional. I am merely spoofing a command from an existing module. In the case of opening the doors I just spoof the command from the door or liftgate module. There is no security for messages on the class 2 network. If the header I send says I am the liftgate module all receiving nodes believe it and react as if the liftgate had received the directive from the keyfob and issued the command to open the drivers door.
 
OP
OP
T

TJBaker57

Well-Known Member
I don't know if this is of any use or not but having posted this elsewhere on the site I should add it here.

Not anything that needs monitoring for sure but might be of interest I guess.

TCCM information. Part number, Operating System part number, and Calibration.

Screenshot_20200613-200243.png

The 'PID' isn't really a pid but a memory block read. Or should that be block memory read? Whatever.... It's essentially the same method we read vin numbers with from the PCM, just using different header and block number(s).

Mode and pid: 3C08
Long Name: TCCM Part Number
Short Name: TCCM Part
Min:0
Max:99999999
Unit Type:
Equation: (A<16)+(B<8)+C
Header:6C1AF1


Mode & PID:3C0A
Long Name:TCCM Operating System #
Short Name:TCCM OS
Min:0
Max:99999999
Unit Type:
Equation: (A<16)+(B<8)+C
Header:6C1AF1


Mode & PID:3C0C
Long Name:TCCM
Calibration #
Short Name:TCCM CAL
Min:0
Max:99999999
Unit Type:
Equation: (A<16)+(B<8)+C
Header:6C1AF1
 

Jtfrankfort

New Member
Just a small sidestep, but is there a fix for the displays to keep from getting scrambled up and shifted to one side on Torque Pro?

The layout is correct being on top of each other...just pushed to one side.

The top pic should not have the square gages on the right .....they should be on the left of the bottom pic.

Happens on occasion.

View attachment 93173

View attachment 93174
Not to post to an old thread, but didnt see anyone offer much in the way of possible explanations, the only time my torque display does this is if I change power settings and the power setting includes a change to the screen res. Itll do this and simply switching back fixes it and sometimes a reboot it required.
 

gmcman

Well-Known Member
Thanks Jt, I did try that to no avail. I'm going to perform a factory reset in the very near future anyway to clear the bugs from this phone. At that time I will reload all the gauges.....:crazy:
 

Mooseman

Moderator
Tried to make the memory address service $23 work with OBD Fusion. No dice so far. Am corresponding with their tech support about that now.

For some unknown reason OBD Fusion seems to turning my service $23 request into a service $02 request. If memory serves that's a freeze frame request. Instead of sending the "6C1AF12300009001" string it is sending "6C1AF10230009001" which generates a negative response.
Turns out I was a zero short in my 'PID' entry!! I had entered 0009001 instead of 00009001. "Missed it by that much!"

I still had work to do after correcting that error though. At least for this purpose OBD Fusion is beginning the assignment of tokens (A,B,C...) earlier in the response than does Torque. What Torque represents as A in the equation OBD Fusion is calling C. Perhaps the app does not recognize a service $23 response. Anyway, adjusting the equation did the trick

View attachment 94681
@TJBaker57 , would you have the actual custom PID entries for reading fan desired and actual RPM? We have a member having issues with his fan and this could help him with it.
 

Online statistics

Members online
2
Guests online
234
Total visitors
236

Members online

Forum statistics

Threads
20,447
Messages
595,098
Unanswered questions
2
Answered questions
2
Members
13,549
Latest member
Jdross88
Top Bottom