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:
 

Online statistics

Members online
4
Guests online
219
Total visitors
223

Members online

Forum statistics

Threads
20,357
Messages
593,799
Unanswered questions
2
Answered questions
2
Members
13,388
Latest member
ADRasmus
Top Bottom