VPW-Bus Scantool-Accessible Vehicle Data

[AmpOverload]

Based on a discussion with @TJBaker57 starting here in the popular "More PIDs for Torque App" thread, I'm starting this new, related thread to discuss various ideas related to communicating with VPW-protocol nodes on the SAE J1850 bus on GM vehicles, mostly for things that transcend the intentionally limited topics of that thread (typically Mode $22 Parameter IDs aka "PIDs").

This thread is intended to include any vehicle which has 1 or more nodes that speak the VPW protocol. Typically, this will involve GM model year vehicles roughly from 1996 until 2008 (at least in the USA).

Specific discussions about CAN-protocol nodes and related matters should be discussed elsewhere, please.

Discussions about functionally addressed VPW vehicle queries/data are generally handled in the "ELM327 & Class 2 Serial Data" thread but could also be appropriate in this thread in some cases.

I intend for this new thread to include notes about various vehicle data points which don't apply to the "More PIDs for Torque App" thread. This might include OBD Mode $2A (Dynamic Parameter IDs aka "DPIDs"), Mode $3C ("Block" IDs), and possibly even Mode $23 ("Memory Addresses") and Mode $06 ("TID"/"CID" aka Test ID / Component ID) and Mode $09 ("InfoTypes").

 

[AmpOverload]

To start this thread off, I'll note that I found something interesting last night related to the ABS node on some GM vehicles (specifically a 2004 Buick Century, but it applies to other GM vehicles too).

The ABS/EBCM node seems to keep track of multiple DTCs that can be queried via Mode $2A (i.e. by DPID) in addition to the conventional way of using Mode $19 (non-emission-related DTCs).

On the 2004 Century, a single ABS DTC is reported via a Mode $2A DPID $51 command. A 2nd ABS DTC is (oddly, skipping a "slot") reported via a Mode $2A DPID $53 command. Not ever having seen a vehicle with 3 ABS DTCs, I'm not sure where the 3rd DTC's data is kept. ABS-node DPID $52 is not supported on this vehicle, so DPID $50 or $54 would be good guesses.

For the record, on this vehicle and others like it, low-precision Wheel Speed Sensor (WSS) data is reported via ABS DPID $20 and high-precision WSS data via DPID $60.

At a time when these 2 ABS DTCs were present (via conventional Mode $19 query):

C1226:10 ($5226:10)
C1233:10 ($5233:10)

the vehicle response to these 2 DPID commands was:

ATSH: 6C 28 F1   Node: 0x28   Mode: 0x2A   DPID: 0x51   Reply #1: { 6C F1 28 } 6A 51 52 33 01 00 01 2E [7A]

ATSH: 6C 28 F1   Node: 0x28   Mode: 0x2A   DPID: 0x53   Reply #1: NO DATA
                                                        Reply #2: { 6C F1 28 } 6A 53 52 26 10 04 26 00 [E2]

The DTC (without status byte) is clearly shown in the 2 bytes after the echo of the DPID. The next 4 bytes ("01 00 01 2E" and "10 04 26 00") have been a mystery to me for a long time now. But something I saw last night suggested that the ABS stores these 2 pieces of information along with the DTC:

1. number of drive cycles since the DTC last occurred
2. number of occurrences for the DTC since the scan tool DTC information was last cleared

I investigated other cases in the past on various GM vehicles that reported ABS DTCs and it seems like the middle 2 of those 4 mystery bytes represent a "trip counter" value (basically an ignition cycle, IIUC) and not an actual "drive cycle" (which is more involved and can occur over 1 or more "trips"). But why there are 2 bytes that seem to represent that is unclear.

Also, I don't know the meaning of the 1st and 4th bytes, but I would expect/hope that one of them might be the "number of occurrences for the DTC since the scan tool DTC information was last cleared" value mentioned earlier.

Anyway, just wanted to get this behavior documented for now. Maybe someone else might have ideas and/or data to share. I hope to do more testing of this the next time I see a GM vehicle with an ABS DTC, if I don't get impatient and induce one first!

 

[TJBaker57]

The ABS/EBCM node seems to keep track of multiple DTCs that can be queried via Mode $2A (i.e. by DPID) in addition to the conventional way of using Mode $19

I have used service $2A for retrieving data parameters from EBCM but never looked for DTC info there, nor had I looked for such factory enabled DPIDs in other modules.

I did not see a 'Data Rate' byte in your queries. My vehicles appear to require this and the options seem to vary from module to module.



Our recent talk of service $2A made me wonder how much data might there be there. So today I scanned several modules to see what I could learn. I queried EBCM, HVAC, Airbags, BCM, PCM, etc.

I requested all possible DPIDs from $00 to $FF. ((Are they still called DPIDs when they are factory programmed in and not really 'dynamic' or configurable ??))

I found some modules had only the DPIDs used for data retrieval by dealership level scantools. These are commonly seen in the area of $FE to $F7 though at least one I looked at went as low as $EF I think.

A few modules have a good number of 'Factory DPIDs'.

Our TrailBlazer EBCM, which by the way is node $29 for the GMT360/370 platform, has only 3. There are 6 bytes per DPID here. I was already aware of these 3 from previous exploration.

Bytes 1, 2, and 3 of the 2002 TrailBlazer EBCM service $2A:01 contain the wheel speeds of front left, front right, and rear wheel speed. The rear wheel speed it gets from a VSS signal from the PCM. Later years added individual rear wheel speed sensors.

Prior to today I was unaware the my 2002 TrailBlazer EBCM allowed a standard 'Data Rate' value of $01. All my previous noodling about with service 2A resulted in a streaming response from the module. The support of an $01 'Data Rate' makes it possible to use this in Torque Pro for reading the individual wheel speeds.

My 2002 TrailBlazer airbag module responded positively to about 70 service $2A queries. Quite a few of these were populated with no more than $FF or $00. Many have data in them including the module part##. One of these can be used to get the bytes needed to be written into a specific BCM data block to set the SDM key used by the airbag module at startup.

A BCM I scanned had about 14 service $2A DPIDs. Most of these exhibited odd behaviours when queried, first responding with a 7F:23 followed by a positive response. But the positive response was sometimes a repeat response for a previous query!! Rarely did I get an immediate query/response behaviour. This could be the result of the 'Data Rate' I used. The ata Rate' is the result of trial and error. More study is needed.

 

[AmpOverload]

There's often some interesting data in the non-dynamic ("factory") Mode $2A DPID replies. For example, the SRS node on the 2004 Century reports a "driver's seatbelt buckled" flag via Mode $2A DPID $11 formula "F:0". The IPC (instrument panel) reports the trip odometer switch status and various other dashboard lamps' status via various Mode $2A DPIDs. I've often thought of using the trip odometer switch (or, say, a cruise control switch on the steering wheel) as a way to trigger something in my data collection computer, e.g. a screenshot or as a way to toggle logging (or whatever!).

On a regular basis, I take what I refer to as a "snapshot" on all vehicles that I maintain or have access to. In addition to logging the usual DTC info (both from Modes $03/$07/$0A and [on GM] from Mode $19), this process uses previously determined per-VIN lists to gather all known "vehicle data points" (or "VDPs" as I refer to them), covering everything that the vehicle reports from Modes $01, $02, $06, $09, $22, $23 [selected values only], $2A, and $3C. This way, even though I might not understand what any particular VDP represents, I've logged the vehicle's reply for possible future analysis. This is what allowed me to go back in time and see what ABS Mode $2A DPIDs were saying about these entries with unknown meaning.

I requested all possible DPIDs from $00 to $FF. ((Are they still called DPIDs when they are factory programmed in and not really 'dynamic' or configurable ??))

A good question. Looking into it (SAE J2190), I think I've developed a bad habit of calling DPID "Dynamic Parameter ID" (because, as I'm sure you're well aware, of the Mode $2C ability to dynamically define a Mode $2A DPID [from 0xF7 to 0xFE, IIRC]) when it seems that I should be calling it "Data Packet ID". I'll try to stop doing that from now on!

For the record, I don't think I've ever used Mode $2C to dynamically define a DPID on any GM node except the PCM. I'm not even sure it's possible. A quick check of my logs shows that only the PCM node replies to DPIDs up in that range, specifically $F4 to $FE on the 2 Buicks (2004 Century and 2005 LeSabre) that I usually work with. So if you're seeing non-PCM nodes reply to Mode $2A DPID commands in the $F7 - $FE range (with the Tech2, presumably?), I'd like to think that maybe I could unlock the non-PCM nodes and scan the full DPID range, in case some DPIDs are "hidden behind the lock"; however, the PCM is the only node of those that report a valid "seed" which I've been able to unlock. 😞

[EDIT: Deleted large section in here about 'data rate' that was written in a state of obvious confusion! ]

The airbag node on the 2004 Century (referred to as "SRS") is at address $58 and supports about 45 Mode $2A DPIDs.

A BCM I scanned had about 14 service $2A DPIDs. Most of these exhibited odd behaviours when queried, first responding with a 7F:23 followed by a positive response. But the positive response was sometimes a repeat response for a previous query!! Rarely did I get an immediate query/response behaviour. This could be the result of the 'Data Rate' I used. The ata Rate' is the result of trial and error. More study is needed.

As for getting odd responses, this happens altogether too frequently on GM nodes for me. Like you, I've frequently seen a reply to a command where the "echo" part of the "payload" makes it obvious that the reply was from the previous command! Again, "WTH, GM?!?". I'm tempted to start a thread to document all the weird (etc) replies I've seen over the years.

I'd like to experiment with a lot of this stuff some more too. Someday...

 

[AmpOverload]

I deleted a large section from my previous post because I was confused and it was erroneous. The 'data rate' on a Mode $2A command comes before the DPID, not after (as I was erroneously thinking)!

After re-reviewing (🤪), my Mode $2A commands to GM nodes always specify "01" for the data rate. Sorry for the confusion.

 

[AmpOverload]

Restoring the part of my deleted text that did actually make sense:

On some (but not all!) GM nodes, I found that I have to append a suffix of 5 $FF bytes on Mode $2A commands for them to work. And even on the same vehicle, it can differ node-to-node! Another "WTH, GM?!?" moment, one of many. For example, here's a command set sent to the PCM node on a 2004 Century:

Command: ATSH 6C 10 F1
  Reply: OK
Command: 2A01F4FFFFFFFFFF
  Reply: 6C F1 10 6A F4 00 00 00 00 00 00 04

 

[TJBaker57]

often thought of using the trip odometer switch (or, say, a cruise control switch on the steering wheel) as a way to trigger something

Cool idea there! Since my explorations do no involve coding anything it is not presently a possibility. But maybe for a future arduino sketch perhaps.

So if you're seeing non-PCM nodes reply to Mode $2A DPID commands in the $F7 - $FE range (with the Tech2, presumably?), I'd like to think that maybe I could unlock the non-PCM nodes and scan the full DPID range, in case some DPIDs are "hidden behind the lock"; however, the PCM is the only node of those that report a valid "seed" which I've been able to unlock. 😞

In my 2002 - 2005 GM vehicles, if memory serves, I see all nodes except the EBCM make available user configurable DPIDs up in the $Fx range. All are unlocked. I do my messages either in an app, manually in a serial terminal, or with a macro in same serial terminal at a stated per-line timing. I have never attempted to unlock modules as that would seem to require some programmable interface as opposed to my simple approach.

As for specifying the "data rate" byte on the commands, the Buick ABS nodes do not need it (and might not even tolerate it, I cannot recall ATM). Here's the actual raw command/reply (taken from the human-unfriendly equivalent log file that I keep) for the 2 ABS-node DPID examples I used in post #2 of this thread:

Command: 2A01511
Reply: 6C F1 28 6A 51 52 33 01 00 01 2E 7A

Command: 2A01531
Reply: 6C F1 28 6A 53 52 26 10 04 26 00 E2

You lose me here a bit. I will break one of your commands thusly:

"2A 01 51 1".

By my reading of J2190 the "01" is the 'Data Rate' which I did not see reference to in your post #2 example.

As you can see, I do specify a trailing "1" nybble (single hex character) for what I call the "VRWO" ("Vehicle Reply Wait Optimization"), since (as I know you're aware, just stating things explicitly for other/future readers) the ELM327 datasheet defines and supports this capability but never gives it an actual name or acronym!

I find in my GM explorations I have to use "01" in place of this nibble. I have not fully explored the ELM327 datasheet so I haven't seen this stated. What I am seeing may be a limitation of the clone ELM327 devices that I use. And I find it is sometimes needed and sometimes not.

some (but not all!) GM nodes, I found that I have to append a suffix of 5 $FF bytes on Mode $2A commands for them to work

I see similar. Sometime I need 3 trailing bytes of either $FF or $00. This makes a total of 4 data packet IDs given as arguments to the $2A message. I need 5 of these for the SRS node $58.

No VRWO "1" nybble is sent there, but I cannot recall if that's intentional. I should probably look into that someday.

I found I did not need to use a trailing $01 in my $2A scans yesterday.

guess you could say that, in those cases, I'm sending a "data rate" command of $FF, but why does the command have to be further padded with 4 more $FF bytes?!?

In my experience, at least for the non SRS nodes, the GM implementation of $2A allows for 4 data packets to be requested in a single message. These packets are then streamed per the 'Data Rate'. Without a "test tool present" message being recived by the responding node the atream lasts about 5 seconds. Here is an example from a 2005 P10 PCM...




You see I am using a 'manufacturer specific' data rate here of $14. Most GM nodes I have explored don't offer the SAE standard data rates so I am forced to use rates found by trial and error. Lots of error. Using these mystery data rates may explain the unexpected responses from previous message queries.

 

[AmpOverload]

Just a quick reply here since I need to get back outside soon...

Cool idea there! Since my explorations do no involve coding anything it is not presently a possibility. But maybe for a future arduino sketch perhaps.

On my next electronics parts order, I intend to finally buy an Arduino.

In my 2002 - 2005 GM vehicles, if memory serves, I see all nodes except the EBCM make available user configurable DPIDs up in the $Fx range. All are unlocked. I do my messages either in an app, manually in a serial terminal, or with a macro in same serial terminal at a stated per-line timing. I have never attempted to unlock modules as that would seem to require some programmable interface as opposed to my simple approach.

That's really interesting to me. I'll have to double-check that I've made the necessary tests on non-PCM nodes and maybe play around a bit.

BTW, I think you mean all are "locked" (i.e. because you have not unlocked them), right? (I frequently get this backwards, loading my "locked" PCM 'PID scan' when I meant to load the "unlocked" [i.e. more complete] file!) Some nodes do not reply to a Mode $27 security "seed" request, which ostensibly makes them "unlocked" in a sense, but this is a more involved subject than I have time for ATM. Let me know if you'd like to delve into this more, now or in the future. (It's possible to unlock the PCM node even with your setup.)

You lose me here a bit. I will break one of your commands thusly:

"2A 01 51 1".

By my reading of J2190 the "01" is the 'Data Rate' which I did not see reference to in your post #2 example.

That's purely my fault, sorry! My post #2 included the human-friendly log output, where such details are not shown. The "Command:" and "Reply:" format I showed in a later post is the raw command/reply output and is what I should have probably shown initially. I use the 1st format for a general audience because it's easier to comprehend; you're way "smarter than the average [OBD2] bear" so I can use the "ugly" format with you.

I find in my GM explorations I have to use "01" in place of this nibble. I have not fully explored the ELM327 datasheet so I haven't seen this stated. What I am seeing may be a limitation of the clone ELM327 devices that I use. And I find it is sometimes needed and sometimes not.

If that's what you're using, I have a suspicion that it's not having the desired effect (i.e. optimizing the wait for the vehicle reply), but I could easily be wrong. If you're interested, we could pursue this more in the near future. I wrote something in that initial part that I deleted that I should probably re-word and re-submit.

I see similar. Sometime I need 3 trailing bytes of either $FF or $00. This makes a total of 4 data packet IDs given as arguments to the $2A message. I need 5 of these for the SRS node $58.

It's entirely inconsistent from what I've seen, but I've learned to work around it.

I found I did not need to use a trailing $01 in my $2A scans yesterday.

Same comment as above. I think I may have some useful advice (soon) about the trailing suffix used by ELM327.

In my experience, at least for the non SRS nodes, the GM implementation of $2A allows for 4 data packets to be requested in a single message. These packets are then streamed per the 'Data Rate'. Without a "test tool present" message being recived by the responding node the atream lasts about 5 seconds. Here is an example from a 2005 P10 PCM...

View attachment 109706

Need to look into this more when I get a minute.

You see I am using a 'manufacturer specific' data rate here of $14. Most GM nodes I have explored don't offer the SAE standard data rates so I am forced to use rates found by trial and error. Lots of error. Using these mystery data rates may explain the unexpected responses from previous message queries.

I've seen this too, but I cannot recall when/where/why ATM. Your last sentence above made the light go on -- I think you're right about those unexpected replies we talked about in the "Torque PIDs" thread, but I need to review that and try to remember which OBD Service Modes for which I've seen this in the past.

 

[TJBaker57]

BTW, I think you mean all are "locked" (i.e. because you have not unlocked them), right?

I think what I am trying to say is that nothing I do or show here requires any sort of "unlocking", No seeds, no keys, no hidden messages, that sort of thing. So other areas of the module are likely locked away, but I don't pursue such things.
About the only time I have encountered the 7F/33 (security access denied) response was an attempted service $23 query of IPC diagnostic memory.

If that's what you're using, I have a suspicion that it's not having the desired effect (i.e. optimizing the wait for the vehicle reply), but I could easily be wrong. If you're interested, we could pursue this more in the near future

Where I use the trailing $01 most is for service $22 queries. For many PIDs if I do not include the trailing $01 I get a 7F/12 response. ( Sub-Function Not Supported or Invalid format) I also need it with service $23 queries.

 

[AmpOverload]

I think what I am trying to say is that nothing I do or show here requires any sort of "unlocking", No seeds, no keys, no hidden messages, that sort of thing. So other areas of the module are likely locked away, but I don't pursue such things.
About the only time I have encountered the 7F/33 (security access denied) response was an attempted service $23 query of IPC diagnostic memory.

Gotcha! Let me know if you ever change your mind. IIRC, you'd need an unlocked PCM to do things like turn on the fuel pump, but that's not something most people need.

Where I use the trailing $01 most is for service $22 queries. For many PIDs if I do not include the trailing $01 I get a 7F/12 response. ( Sub-Function Not Supported or Invalid format) I also need it with service $23 queries.

Yes, that matches my experience too. In fact, I was taking too long to compose the following post (which goes into this in depth) when I saw your post ....

About the "data rate" byte in various commands...

Since I often get mixed up myself, just to set the record straight, per SAE J2190, the "data rate" byte is mandatory in Mode $2A commands. It's supposed to be "optional" in Modes $21, $22, and $23. I read "optional" as meaning "node should handle it being present or absent". GM, unfortunately, seems to read "optional" as meaning "it's our option to decide to force the user to include it always... or not"! So with GM, at least for all the vehicles I've tested, it's mandatory for Modes $22 and $23 (and probably Mode $21 -- I've just never tested/used it since it would require manufacturer-specific, node-specific knowledge).

Data rate bytes of "00" to "04" are defined by SAE J2190. Values from "05" to "FF" are manufacturer-defined with mostly unknown meaning.

Looking back at old logs, I see where I experimented with various values for the "data rate" byte on Mode $2A commands and the results are anything but logical! Among the manufacturer-defined values that return a valid reply, I see 13, 14, 22, and 23 for the PCM nodes, but that could be entirely different on a different GM vehicle and/or node!

I don't know if I've ever experimented with a "data rate" other than "01" on GM Mode $22 commands, though. I guess I never had much reason to use such a command, but the test results would be interesting.

After review of my logs, I can confirm that your experience of "the GM implementation of $2A allows for 4 data packets to be requested in a single message" matches my experience. (I rarely use/test Mode $2A manually, so I get very foggy about the operation.)

On to a semi-related issue (another command "suffix")...

The GM "01" data rate specification (1 byte, 2 hex characters) is a separate issue from the ELM327 "VRWO" [defined below] nybble (1 hex character).

Copied directly from an old log, here's a typical command that I use on a Buick when I take "snapshot" data, using a common GM PID in a Mode $22 command to query the Transmission Fluid Temperature (TFT):

Command: 221940011
  Reply: 6C F1 10 62 19 40 40 FF

Broken down for readability, that's "22 1940 01 1".

The "01" is because GM insists on specifying the "data rate" byte, even though SAE J2190 says it's "optional".

The trailing "1" is what I call the VRWO (Vehicle Reply Wait Optimization) nybble, since the ELM327 datasheet defines and supports this capability but never gives it an actual name or acronym. It's only defined by and relevant for ELM327 (and compatible) chips and means that the scantool should assume that the vehicle will only send 1 line of reply data and should not wait any longer after that before sending the ELM327 "user input prompt" character (">").

So, contrary to what I implied in my previous post, I don't think you're sending any erroneous VRWO nybble -- you're sending the GM-required data rate in cases where GM decided that it's mandatory. But as you can see in my command above, you can send both the "01" data rate and the VRWO nybble. It certainly speeds up the ELM327 readiness after a vehicle-targeted command.

In fact, I think you'll find that if you send an erroneous VRWO value (either a whole byte instead of a nybble or the wrong value for the nybble), you'll see the lag in the ELM327 response. I'm sure I've tested all this years ago.

I try to use a VRWO nybble wherever I can when commands are sent under computer control. On my "snapshots", where I'm doing tons of commands to query vehicle data points, it speeds things up nicely. But there are cases where I'm not sure where if a VRWO nybble can be used, so I don't use it 100% of the time.

Back to "data rate" for a second...

I thought that the weirdness we talked about in this post might have been due to a non-standard "data rate" byte. But the screenshot in that post clearly shows that the Mode $22 commands were being sent with a common "01" data rate, so I'm still baffled by that initial Mode $7F reply with a Response Code of $22!

 

[TJBaker57]

IIRC, you'd need an unlocked PCM to do things like turn on the fuel pump,

Not on these P10 controlled LL8 engines I can confirm. For diagnostic purposes at least I can activate the fuel pump using a service $AE (request device control) message. I have done all sorts of things in this manner, essentially mimicking a Tech 2 with no more than my phone, a serial terminal app and an OBD2 adapter.

As for a data rate byte GM seems to require it as the 2nd byte in service $2A and as byte #4 in service $22 and byte #5 in service $23. This has been my experience.

I don't know if I've ever experimented with a "data rate" other than "01" on GM Mode $22 commands, though. I guess I never had much reason to use such a command, but the test results would be interesting.

I just tried out a few possibilities with service $22 and $23 messages and only $01 worked. This is with a 2005 P10 PCM.

I can confirm that your experience of "the GM implementation of $2A allows for 4 data packets to be requested in a single message" matches my experience

The unexpected one for me was the SRS needing 6 data packets in the $2A request message.

 

[AmpOverload]

Not on these P10 controlled LL8 engines I can confirm. For diagnostic purposes at least I can activate the fuel pump using a service $AE (request device control) message.

Sorry, I was wrong. As I just verified with a real-world (Mode $AE) test (2004 Century), P04 PCMs are just like your P10 -- i.e. you do not need an unlocked PCM to control the fuel pump.

I was thinking of Ford, where an unlocked PCM is required. (You think it's hard to master "old" GMs with SAE J1850 VPW? Try adding "old" Fords with SAE J1850 PWM, Ford-customized ISO 9141-2, and a bit of CAN thrown in for amusement! ) BTW, Ford PWM uses a different OBD Service Mode ($B1) than GM VPW ($AE) for device control.

In GM's case, I confirmed that they only run the fuel pump for about 3 seconds, even when I'm actively sending a Mode $3F command ("Test Device Present") every 3 seconds. I guess that's probably for safety. For the record, I did confirm that I can shut the fuel pump off via Mode $AE before the timeout expires.

Also, for fun, I tried unlocking the PCM before sending the Mode $AE command to turn the fuel pump on, but (with or without 3-second Mode $3F commands), it still times out and shuts off after about 3 seconds.

Another observation from my test: The vehicle requires a "pump off" command before an "on" command will make it run again.

Lastly, I suspect that anything done with the Tech2 would automatically unlock the PCM when needed, but that's just a guess.

Anyway, sorry for the distraction. I find all of this stuff interesting, nevertheless.

I just tried out a few possibilities with service $22 and $23 messages and only $01 worked. This is with a 2005 P10 PCM.

As for Mode $22 and Mode $23 "data rate" specification, I did some more testing on a P04 PCM and my results were like yours.

Mode $22 doesn't like anything but $01 for a "data rate".

Success:

Command: 22 1100 01
  Reply: 6C F1 10 62 11 00 76 1D

Failure:

Command: 22 1100 02
  Reply: 6C F1 10 7F 22 11 00 02 12 67

In fact, Mode $22 even rejects a command with a $00 data rate:

Command: 22 1100 00
  Reply: 6C F1 10 7F 22 11 00 00 12 FF

That's probably indicative of a complete lack of support for a data rate other than $01.

In fact, every data rate other than $01 that I tested (00, 02-16, 22, 23) yielded a Mode $7F reply with Response Code $12 ("Sub-Function Not Supported or Invalid Format").

Mode $23 was just like Mode $22 (tested on all the same values for 'data rate')...

Success:

Command: 23 070100 01
  Reply: 6C F1 10 63 01 00 00 00 00 00 B7

Failure:

Command: 23 070100 02
  Reply: 6C F1 10 7F 23 07 01 00 02 12 E8

Failure:

Command: 23 070100 00
  Reply: 6C F1 10 7F 23 07 01 00 00 12 70

For fun, I threw in a test of Mode $21 (format is different from above because this test was run manually, not "scripted"):

>21 00 01
6C F1 10 7F 21 00 01 11 5C 

>21 00
6C F1 10 7F 21 00 11 98 

>21 01
6C F1 10 7F 21 01 11 D4 

>21 01 01
6C F1 10 7F 21 01 01 11 D3

All replies were Mode $7F Response Code $11 ("Mode Not Supported"). No point looking any further there!

 

[TJBaker57]

Try adding "old" Fords with SAE J1850 PWM, Ford-customized ISO 9141-2, and a bit of CAN thrown in for amusement! )

Nope, not going there! There's a reason I stick with just J1850 VPW.

 

[kastein]

Not on these P10 controlled LL8 engines I can confirm. For diagnostic purposes at least I can activate the fuel pump using a service $AE (request device control) message. I have done all sorts of things in this manner, essentially mimicking a Tech 2 with no more than my phone, a serial terminal app and an OBD2 adapter.

Now I'm curious, you have a command to turn on the secondary/transfer pump on a dual tank GMT800/600? I'm trying to get my aux pump working at the moment and I'm not sure if I'm going to need to swap my fuel segment in the ECU with hptuners, or if my calibration is just wrong.

It's wired to pin 3 on connector C2/green via a relay, but that is all I know.

 

[TJBaker57]

Now I'm curious, you have a command to turn on the secondary/transfer pump on a dual tank GMT800/600? I'm trying to get my aux pump working at the moment and I'm not sure if I'm going to need to swap my fuel segment in the ECU with hptuners, or if my calibration is just wrong.

It's wired to pin 3 on connector C2/green via a relay, but that is all I know.

I only have such things for vehicles that I own.

These "Request Device Control" messages are not transferrable between vehicles, I suspect they vary greatly in both form and function between years, vehicles, engines and even perhaps controller calibrations.

Anyone fiddling around with these messages is taking a risk. One time I tried a message and my torque converter clutch engaged while idling in the driveway. Fortunately the only thing that happened was the engine stalled.

 

[AmpOverload]

As of late last week, I'm the proud owner of a new VXDIAG VCX Nano!

I've been learning about and playing with OBD2 data for many years now. Sadly, finding new information about "vehicle data" (PIDs, etc) tends to happen less with each passing year. But the VCX Nano with Tech2Win software is already opening up interesting and useful new information!

Here's one example...

OBD Mode $12 (Freeze-Frame Data)

I knew that some GM vehicles supported Mode $12 (defined in SAE J2190, as "Request Diagnostic Freeze Frame Data") because I'd tested it in the past and saw a Mode $7F reply with a Response Code of $12 ("Subfunction Not Supported or Invalid Format"), which suggests that Mode $12 was supported but that I was just not using the proper command. If a given OBD Mode is not supported, GM vehicles are pretty consistent in correctly reporting a Mode $7F reply with a Response Code of $11 ("Mode Not Supported"). So I knew that I needed to experiment more but, as others here will probably attest to, it was one of many interesting OBD-related things that one sees that simply gets "pushed to the back burner" and often forgotten about!

Well, thanks to running Tech2Win + VCX Nano with my vehicle simulator, I discovered a Mode $12 command that demonstrated the proper format and later tried it on a real vehicle -- a 2004 Buick Century:

Command: ATSH 6C 10 F1
  Reply: OK

Command: 12 00 FF FF
  Reply: 6C F1 10 52 00 00 02 00 00 C7
         6C F1 10 52 00 00 03 02 00 D0
         6C F1 10 52 00 00 04 0C CF
         6C F1 10 52 00 00 05 79 B3
         6C F1 10 52 00 00 06 80 ED
         6C F1 10 52 00 00 07 74 AA
         6C F1 10 52 00 00 0B 23 50
         6C F1 10 52 00 00 0C 11 ED 05
         6C F1 10 52 00 00 0D 2A 10
         6C F1 10 52 00 00 10 02 D5 D5
         6C F1 10 52 00 00 11 01 9B
         6C F1 10 52 00 11 72 3C 8C
         6C F1 10 52 00 11 88 3A E2
         6C F1 10 52 00 11 93 00 C9 E8
         6C F1 10 52 00 11 9E 93 B7
         6C F1 10 52 00 12 35 01 F9 A1
         6C F1 10 52 00 12 36 01 F9 2D
         6C F1 10 52 00 12 37 00 5D
         6C F1 10 52 00 12 38 00 FE
         6C F1 10 52 00 12 39 00 B2
         6C F1 10 52 00 12 51 63 C4
         6C F1 10 52 00 00 0F 2C C6
         6C F1 10 52 00 11 01 00 A5
         6C F1 10 52 00 11 02 00 71
         6C F1 10 52 00 11 03 00 3D
         6C F1 10 52 00 11 05 6F A7
         6C F1 10 52 00 11 06 40 4F
         6C F1 10 52 00 11 07 CE 83
         6C F1 10 52 00 11 29 00 8A
         6C F1 10 52 00 11 41 92 9E
         6C F1 10 52 00 11 52 00 2F
         6C F1 10 52 00 11 70 00 C2
         6C F1 10 52 00 11 75 D8 B3
         6C F1 10 52 00 11 90 01 89
         6C F1 10 52 00 11 9B 00 1A
         6C F1 10 52 00 11 A1 01 55 F8
         6C F1 10 52 00 11 AF 02 CC
         6C F1 10 52 00 11 B0 00 E1
         6C F1 10 52 00 12 C5 06 A7 A8
         6C F1 10 52 00 16 0C 14 00 1B
         6C F1 10 52 00 19 9A 03 7D
         6C F1 10 52 00 00 02 00 00 C7

Eureka! It worked for the PCM! Unfortunately, none of the other nodes on that vehicle support Mode $12.

Not only did it work, but it gives much more information than the standard "Freeze Frame" data, from Mode $02 (or "Service $02" as it's called in SAE J1979, which defines it)! The reply includes the values of several Mode $22 PIDs. This is potentially very helpful when diagnosing DTCs (Diagnostic Trouble Codes)!

Basically, each line of the reply is information about a single Mode $22 PID, in this form:

   52 { 1-byte frame number } { 2-byte PID number } { 'n'-byte value of that PID }

Curiously, however:

1. The line with PID $0002 (with value $0000 [more on that, below]) is sent at both the start and the end. Maybe this is significant somehow?
2. The list of PIDs is not the same for each frame. I suppose it might well depend on which DTC is associated with the frame. I'll have to wait until I get one or more valid DTCs to experiment more, though.
3. On the 2004 Century, PID $0F ("Intake Air Temperature") is not "advertised" as one of the supported Mode $02 PIDs (i.e. via a Mode $02 PID $00 command), but is included in some Mode $12 frames' reply (as a Mode $22 PID $000F). This strikes me as odd. For the record, on this vehicle, PID $0F is "advertised" as a supported Mode $01 PID (i.e. via a Mode $01 PID $00 command).

I also found that the vehicle seems to support 6 frames ("00" to "05"), using these commands:

12 00 FF FF
12 01 FF FF
12 02 FF FF
12 03 FF FF
12 04 FF FF
12 05 FF FF

It's unclear if the "FF FF" is a PID or a DTC (SAE J2190 mentions both possibilities, and others, for Mode $12), but "FF FF" seems to mean "report everything". I tried values other than "FF FF", but they all yielded a Mode $7F reply with Response Code $31 ("Request Out Of Range").

Also, unfortunately, on this vehicle, there are no active DTCs, so the value for PID $0002 ("DTC that caused required freeze frame data storage") is $0000 in every frame, which undoubtedly means that the freeze frame content doesn't apply (much like the case for freeze-frame data from Mode $02). But it's nice to see that all that data should all be there and, presumably, relevant once the vehicle has a DTC.

It makes me wish that I hadn't ignored testing of this capability for so long!

Unfortunately, there seems to be virtually no information about Mode $12 on the Internet, so I wanted to mention it here, in case it helps anyone.

 

[TJBaker57]

I've been learning about and playing with OBD2 data for many years now. Sadly, finding new information about "vehicle data" (PIDs, etc) tends to happen less with each passing year. But the VCX Nano with Tech2Win software is already opening up interesting and useful new information!

Here's one example...

OBD Mode $12 (Freeze-Frame Data)

I knew that some GM vehicles supported Mode $12 (defined in SAE J2190, as "Request Diagnostic Freeze Frame Data") because I'd tested it in the past and saw a Mode $7F reply with a Response Code of $12 ("Subfunction Not Supported or Invalid Format"), which suggests that Mode $12 was supported but that I was just not using the proper command. If a given OBD Mode is not supported, GM vehicles are pretty consistent in correctly reporting a Mode $7F reply with a Response Code of $11 ("Mode Not Supported"). So I knew that I needed to experiment more but, as others here will probably attest to, it was one of many interesting OBD-related things that one sees that simply gets "pushed to the back burner" and often forgotten about!

Well, thanks to running Tech2Win + VCX Nano with my vehicle simulator, I discovered a Mode $12 command that demonstrated the proper format and later tried it on a real vehicle -- a 2004 Buick Century:

Command: ATSH 6C 10 F1
  Reply: OK

Command: 12 00 FF FF
  Reply: 6C F1 10 52 00 00 02 00 00 C7
         6C F1 10 52 00 00 03 02 00 D0
         6C F1 10 52 00 00 04 0C CF
         6C F1 10 52 00 00 05 79 B3
         6C F1 10 52 00 00 06 80 ED
         6C F1 10 52 00 00 07 74 AA
         6C F1 10 52 00 00 0B 23 50
         6C F1 10 52 00 00 0C 11 ED 05
         6C F1 10 52 00 00 0D 2A 10
         6C F1 10 52 00 00 10 02 D5 D5
         6C F1 10 52 00 00 11 01 9B
         6C F1 10 52 00 11 72 3C 8C
         6C F1 10 52 00 11 88 3A E2
         6C F1 10 52 00 11 93 00 C9 E8
         6C F1 10 52 00 11 9E 93 B7
         6C F1 10 52 00 12 35 01 F9 A1
         6C F1 10 52 00 12 36 01 F9 2D
         6C F1 10 52 00 12 37 00 5D
         6C F1 10 52 00 12 38 00 FE
         6C F1 10 52 00 12 39 00 B2
         6C F1 10 52 00 12 51 63 C4
         6C F1 10 52 00 00 0F 2C C6
         6C F1 10 52 00 11 01 00 A5
         6C F1 10 52 00 11 02 00 71
         6C F1 10 52 00 11 03 00 3D
         6C F1 10 52 00 11 05 6F A7
         6C F1 10 52 00 11 06 40 4F
         6C F1 10 52 00 11 07 CE 83
         6C F1 10 52 00 11 29 00 8A
         6C F1 10 52 00 11 41 92 9E
         6C F1 10 52 00 11 52 00 2F
         6C F1 10 52 00 11 70 00 C2
         6C F1 10 52 00 11 75 D8 B3
         6C F1 10 52 00 11 90 01 89
         6C F1 10 52 00 11 9B 00 1A
         6C F1 10 52 00 11 A1 01 55 F8
         6C F1 10 52 00 11 AF 02 CC
         6C F1 10 52 00 11 B0 00 E1
         6C F1 10 52 00 12 C5 06 A7 A8
         6C F1 10 52 00 16 0C 14 00 1B
         6C F1 10 52 00 19 9A 03 7D
         6C F1 10 52 00 00 02 00 00 C7

Eureka! It worked for the PCM! Unfortunately, none of the other nodes on that vehicle support Mode $12.

Not only did it work, but it gives much more information than the standard "Freeze Frame" data, from Mode $02 (or "Service $02" as it's called in SAE J1979, which defines it)! The reply includes the values of several Mode $22 PIDs. This is potentially very helpful when diagnosing DTCs (Diagnostic Trouble Codes)!

Basically, each line of the reply is information about a single Mode $22 PID, in this form:

   52 { 1-byte frame number } { 2-byte PID number } { 'n'-byte value of that PID }

Curiously, however:

1. The line with PID $0002 (with value $0000 [more on that, below]) is sent at both the start and the end. Maybe this is significant somehow?
2. The list of PIDs is not the same for each frame. I suppose it might well depend on which DTC is associated with the frame. I'll have to wait until I get one or more valid DTCs to experiment more, though.
3. On the 2004 Century, PID $0F ("Intake Air Temperature") is not "advertised" as one of the supported Mode $02 PIDs (i.e. via a Mode $02 PID $00 command), but is included in some Mode $12 frames' reply (as a Mode $22 PID $000F). This strikes me as odd. For the record, on this vehicle, PID $0F is "advertised" as a supported Mode $01 PID (i.e. via a Mode $01 PID $00 command).

I also found that the vehicle seems to support 6 frames ("00" to "05"), using these commands:

12 00 FF FF
12 01 FF FF
12 02 FF FF
12 03 FF FF
12 04 FF FF
12 05 FF FF

It's unclear if the "FF FF" is a PID or a DTC (SAE J2190 mentions both possibilities, and others, for Mode $12), but "FF FF" seems to mean "report everything". I tried values other than "FF FF", but they all yielded a Mode $7F reply with Response Code $31 ("Request Out Of Range").

Also, unfortunately, on this vehicle, there are no active DTCs, so the value for PID $0002 ("DTC that caused required freeze frame data storage") is $0000 in every frame, which undoubtedly means that the freeze frame content doesn't apply (much like the case for freeze-frame data from Mode $02). But it's nice to see that all that data should all be there and, presumably, relevant once the vehicle has a DTC.

It makes me wish that I hadn't ignored testing of this capability for so long!

Unfortunately, there seems to be virtually no information about Mode $12 on the Internet, so I wanted to mention it here, in case it helps anyone.

I have previously discovered GM use of service/mode $12. Occasionally I would have a quick look but not in depth. Today I poked around a bit using two vehicles plus a 2005 P10 PCM. GM oddities continue.

FWIW in my tests one can use "12 FF FF FF" and the PCM sends all it has in one go.

For the most part the frames I received were largely the same PIDs per frame/vehicle.

There were no active DTC but it appears that the values from the previous occupants are left in place as 2 or 3 of the lower frames contain PID values but "$00 $00" for $00 $02 ??

For the 2002 model year P10 PCM there were 2 PIDs that were repeated with the same values within the frames #01 through #05. Frame #00 lacked this repetition and also lacked 2 PIDs that frames $01 through $05 included.

Most curiously with the 2002 model year P10 PCM there were 4 PIDs that returned a 2 byte value where the service/mode $22 use of the very same PIDs returns 1 byte. These are for throttle and accelerator pedal position sensors. The 2005 P10 PCM freeze frame only returns one of those PIDs and it is a single byte. Inconsistency seems to be the rule.

 

[AmpOverload]

I have previously discovered GM use of service/mode $12. Occasionally I would have a quick look but not in depth. Today I poked around a bit using two vehicles plus a 2005 P10 PCM.

Many thanks for the added input from your test cases!

A 2015 Chevy Cruze (using CAN protocol on PCM node) that I once tested did not respond at all to a simple Mode $02 PID $00 command. For Freeze-Frame data, I suspect it only supported Mode $12 but wasn't savvy enough back then to try that in the short time I had access.

FWIW in my tests one can use "12 FF FF FF" and the PCM sends all it has in one go.

Ahhhh, excellent idea! I never even thought to try that, but will do so soon.

There were no active DTC but it appears that the values from the previous occupants are left in place as 2 or 3 of the lower frames contain PID values but "$00 $00" for $00 $02 ??

I too am assuming that the PIDs and their values I saw (in each of 6 frames of data) were all from old DTCs given all the "00 02 00 00" entries (2 per frame, 1 at start and 1 at end, for every frame of data). I was just glad to see that the old values were still shown, however inapplicable, because it opened my eyes to how it all works!

Most curiously with the 2002 model year P10 PCM there were 4 PIDs that returned a 2 byte value where the service/mode $22 use of the very same PIDs returns 1 byte. These are for throttle and accelerator pedal position sensors. The 2005 P10 PCM freeze frame only returns one of those PIDs and it is a single byte. Inconsistency seems to be the rule.

Out of curiosity, were any of these 4 PIDs from the common Mode $01 / Mode $22 set (i.e. PIDs $00 to $FF)?

Again, thanks for testing. It really helps paint a more complete picture.

The "script" that I use to periodically and automatically collect all known data from accessible, familiar vehicles has been modified to probe for and use Mode $12 support. And from now on, every other vehicle I test will get some Mode $12 commands thrown at them manually (i.e. in a console), just to see what they have to say.

 

[TJBaker57]

Out of curiosity, were any of these 4 PIDs from the common Mode $01 / Mode $22 set (i.e. PIDs $00 to $FF)?

They were service/mode 22 PIDs, $12B9, $12BA, $12BC, $12BD. TPS sensor #2 Volts, TPS sensor #1 Volts, APP sensor #2 Volts, and APP sensor #1 Volts.

Seen in the P10 and P12 PCMs. Not present in my 2005 Yukon 5.3 PCM (P59?)

The "script" that I use to periodically and automatically collect all known data from accessible, familiar vehicles has been modified to probe for and use Mode $12 support. And from now on, every other vehicle I test will get some Mode $12 commands thrown at them manually (i.e. in a console), just to see what they have to say.

I could save a lot of time by developing and adhering to a standard scan plus repository format. Not likely to happen, but it sure would save me time when I go looking for something I know I have "somewhere".

 

[AmpOverload]

FWIW in my tests one can use "12 FF FF FF" and the PCM sends all it has in one go.

Ahhhh, excellent idea! I never even thought to try that, but will do so soon.

Confirming that Mode $12 command "12 FF FF FF" does indeed send all 6 frames in one shot on 2004 Century and 2005 LeSabre:

Command: 12 ff ff ff
  Reply: 6C F1 10 52 00 00 02 00 00 C7 
         6C F1 10 52 00 00 03 02 00 D0 
            .
         6C F1 10 52 00 00 02 00 00 C7 
         6C F1 10 52 01 00 02 00 00 AD 
         6C F1 10 52 01 00 03 01 00 6E 
            .
         6C F1 10 52 01 00 02 00 00 AD 
         6C F1 10 52 02 00 02 00 00 13 
         6C F1 10 52 02 00 03 01 00 D0 
            .
         6C F1 10 52 02 00 02 00 00 13 
         6C F1 10 52 03 00 02 00 00 79 
         6C F1 10 52 03 00 03 01 00 BA 
            .
         6C F1 10 52 03 00 02 00 00 79 
         6C F1 10 52 04 00 02 00 00 72 
         6C F1 10 52 04 00 03 02 00 65 
            .
         6C F1 10 52 04 00 02 00 00 72 
         6C F1 10 52 05 00 02 00 00 18 
         6C F1 10 52 05 00 03 01 00 DB 
            .
         6C F1 10 52 05 00 02 00 00 18

Very nice! Thanks for the tip, TJ!