Class2,J1850-VPW, J2187 Technical Question- Look for a tool

[JSilo]

Hi, This is my first post so I hope I'm doing it correctly. I'm a software engineer and familiar with protocols. I have 4 2002 -2006 GMT800 that have quadrasteer (NYS) and an additional 2 that don't. My goal is to get smart on everything associated with quadrasteer. I'm trying to become literate on what communications and messages are being sent by the quadrasteer module and what messages/services its interested in from the other class2 modules. For example, from the documentation that I've been able to get a hold of, I know that the Quad module wants not only the discrete VSS(Vehicle Speed Signal), it also wants the associated class 2 message. Another example is that the Quadrasteer module describes different behavior as related to how far the rear wheel can turn when in Forward vs reverse. This implies that its interested in knowing what the PRNDL info and since the quad module doesn't have any discrete input for that info, I'm surmising it gets if via a class2 message. To that end, can anyone point me to a tool/scanner/sniffer, etc.. that will capture/log/stream the J1850 frames/messages. If it strips the SOF and CRC's that is even better. With that info, I believe I can decode their details. Longer term once I understand what is going on, I'll ask if there is a tool that I can use to create and send class2 command/status frames/messages out on the bus to test my assumptions. My second question is does anyone know if the 2002-2006 J1850 messages are all 3 byte headers, or did GM use a combination of "Single" and "Consodidated" headers? Thanks in advance. john

I forgot to mention, I have a Foxwell and Tech2 clone. the Tech2 clone allows me to see the Quadrasteer module and all the other modules and been able to monitor some of that data attributes and initiate whatever quadrasteer specific diagnostics it supports, but by no means am I expert on it. Is there a way to use it to monitor class2 messages?

 

[mrrsm]

Welcome to GMT Nation....

These answers come courtesy my Off Line Nomic's "GPT4ALL" Mistral Instruct LLM AI:

"To capture and log J1850 frames/messages, you can use a tool like ScanTool or Autoscan. These tools allow you to connect your computer to the vehicle's diagnostic port (usually located under the dashboard) and scan for available data streams. They also provide options to filter and view specific messages based on their ID and type."

"To strip off the SOF and CRC, you can use a tool like Wireshark or Tcpdump. These tools allow you to capture network traffic in real-time and analyze it packet by packet. You can filter for J1850 frames using their protocol identifier (PID) and then examine the individual bytes of each frame to remove the SOF and CRC fields."

"Regarding your second question, GM used a combination of "Single" and "Consolidated" headers in J1850 messages. Single header messages have a fixed-length header followed by variable-length data, while consolidated header messages have a variable-length header followed by fixed-length data. The specific message IDs will indicate which type of header is used for that particular message."

Hope this Helps...

PS... as an Engineer... You'll appreciate getting you hands on this FREE, Private and Locally "One Button" Installed "AI Stuff" that can often act on your behalf like the Sybil as "The Oracle at Delphi":

https://gpt4all.io/index.html?ref=localhost

Standalone J1850 Controller HELPPPP

Ok guys (and gals), long time listener, first time poster. This is going to be a LONGGG post, so sit down, strap in, and get ready for some babbling. Lets see where to start. I own Olson Kustom Works, we mainly do LSA swap parts for almost every LS platform on the planet. I have an extensive...

gmtnation.com

PS...
From the BBC Series, "I, Claudius" when he was summoned to appear before The Oracle at Delphi to ask her about his Fate... and Rome's, Claudius of the Octavian Family stammered out his Questions, "Oh S,S,S, Sybil ...I've C,C, Come to Question YOU about My Fate...and Rome's..." and these were Her replies:

"What Groans beneath the Punic Curse,
And Strangles in The Strings of Purse,
Before She Mends... Must Sicken Worse...

Ten Years, Fifty Days and Three...
Clau, Clau, Claudius will Give and Be...
A Gift... That ALL Desire...But He.

But When He's DONE...
And No More HERE...
1900 Year...Or Near
Clau, Clau, Claudius... Will Speak CLEAR.

 

[azswiss]

Class 2 Serial traffic can be monitored & logged (as well as generated) using an ELM327 dongle and a Serial Terminal emulator. If you can determine the network functional address of the Quadrasteer control module OBD AT commands can be used to selectively monitor just those messages (note: Table 11, page 17, in the SAE J2178-1 doc below indicates hex addresses for steering controllers are in the range of 30 - 37).

The attached ELM327 pdf gives an excellent overview of the AT commands you will need. I also attached the SAE J2178 specs on Class B Data Communication Network Messages - Detailed Header Formats and Physical Address Assignments.

The guy to talk to is the resident Class 2 Serial SME: @TJBaker57.

 

[JSilo]

Welcome to GMT Nation....

These answers come courtesy my Off Line Nomic's "GPT4ALL" Mistral Instruct LLM AI:

"To capture and log J1850 frames/messages, you can use a tool like ScanTool or Autoscan. These tools allow you to connect your computer to the vehicle's diagnostic port (usually located under the dashboard) and scan for available data streams. They also provide options to filter and view specific messages based on their ID and type."

"To strip off the SOF and CRC, you can use a tool like Wireshark or Tcpdump. These tools allow you to capture network traffic in real-time and analyze it packet by packet. You can filter for J1850 frames using their protocol identifier (PID) and then examine the individual bytes of each frame to remove the SOF and CRC fields."

"Regarding your second question, GM used a combination of "Single" and "Consolidated" headers in J1850 messages. Single header messages have a fixed-length header followed by variable-length data, while consolidated header messages have a variable-length header followed by fixed-length data. The specific message IDs will indicate which type of header is used for that particular message."

Hope this Helps...

PS... as an Engineer... You'll appreciate getting you hands on this FREE, Private and Locally "One Button" Installed "AI Stuff" that can often act on your behalf like the Sybil as "The Oracle at Delphi":

https://gpt4all.io/index.html?ref=localhost

View attachment 116593

Standalone J1850 Controller HELPPPP

Ok guys (and gals), long time listener, first time poster. This is going to be a LONGGG post, so sit down, strap in, and get ready for some babbling. Lets see where to start. I own Olson Kustom Works, we mainly do LSA swap parts for almost every LS platform on the planet. I have an extensive...

gmtnation.com

PS...
From the BBC Series, "I, Claudius" when he was summoned to appear before The Oracle at Delphi to ask her about his Fate... and Rome's, Claudius of the Octavian Family stammered out his Questions, "Oh S,S,S, Sybil ...I've C,C, Come to Question YOU about My Fate...and Rome's..." and these were Her replies:

"What Groans beneath the Punic Curse,
And Strangles in The Strings of Purse,
Before She Mends... Must Sicken Worse...

Ten Years, Fifty Days and Three...
Clau, Clau, Claudius will Give and Be...
A Gift... That ALL Desire...But He.

But When He's DONE...
And No More HERE...
1900 Year...Or Near
Clau, Clau, Claudius... Will Speak CLEAR.

Thanks for the reply. Are "ScanTool or Autoscan" actual products or generic terms for OBD scanner/diagnotics tools. ? when I googled them, I didn't seem to find an actual produc.

 

[JSilo]

Class 2 Serial traffic can be monitored & logged (as well as generated) using an ELM327 dongle and a Serial Terminal emulator. If you can determine the network functional address of the Quadrasteer control module OBD AT commands can be used to selectively monitor just those messages (note: Table 11, page 17, in the SAE J2178-1 doc below indicates hex addresses for steering controllers are in the range of 30 - 37).

The attached ELM327 pdf gives an excellent overview of the AT commands you will need. I also attached the SAE J2178 specs on Class B Data Communication Network Messages - Detailed Header Formats and Physical Address Assignments.

The guy to talk to is the resident Class 2 Serial SME: @TJBaker57.

Ok, I'll read through the info on the ELM tool. I also was able to find J2187 specs online a while back and am familiar with them. Isn't it great what you can find online. On the ELM327 front, I see a lot of ELM327 dongles, but everyone I found that has a USB port, supports J1850-PWM aka ford and not J1850-VPW (aka GM). Is there a ELM327 dongle with a USB interface with support J1850-vpw that someone can recommend? I rather not go the Bluetooth route if a physical wire interface is available Thanks again

 

[azswiss]

I have a WiFi version that works perfectly on my 2003 Suburban. Assuming a proper ELM327 implementation (you want Firmware Version 1.5, not 2.1) you can either automatically scan for or manually define the connection protocol using the AT SP command (see bottom of page 23 in the ELM327 ref for details).

There are USB versions on Amazon so as long as they have pins 2, 4, 5 & 16 and are ELM327 V1.5 you should be OK.

 

[TJBaker57]

rather not go the Bluetooth route if a physical wire interface is available

For sheer simplicity, convenience, and minimum expense a Bluetooth dongle and an Android device with a serial terminal app are hard to beat. Even if only to get your feet wet in becoming familiar with the J1850VPW traffic.

Less that $20 and you can easily monitor and record all or selected serial data traffic. I use devices from Veepeak and can attest to their reliability. For a free serial data app look no further than "Serial Bluetooth Terminal" by Kai Morich.

I have no experience with wired store bought OBD devices. I built an Arduino device for my own use with J1850VPW for the purpose of adding sensors and piggybacking the data on the vehicle data bus. The additional data can be displayed on an Android OBD2 app.

does anyone know if the 2002-2006 J1850 messages are all 3 byte headers,

All GM J1850VPW will be the 3 byte variant.


Here is a sample from a test bench with a PCM, BCM and TCCM.

have a Foxwell and Tech2 clone. the Tech2 clone

Is there a way to use it to monitor class2 messages?

No. A Tech 2 cannot show you the serial data traffic.

 

[AmpOverload]

On the ELM327 front, I see a lot of ELM327 dongles, but everyone I found that has a USB port, supports J1850-PWM aka ford and not J1850-VPW (aka GM).

It surprised me somewhat to hear that. IIRC, the OBDLink EX is like that and one or two of the (expensive) scantools sold by the "OBDX Pro" people, but there were and still are relatively inexpensive USB scantools that provide both J1850-PWM and J1850-VPW.

Is there a ELM327 dongle with a USB interface with support J1850-vpw that someone can recommend? I rather not go the Bluetooth route if a physical wire interface is available

I have 3 Bluetooth and 3 wired (USB) scantools, of varying vintages, going back to 2010.

Whenever possible, I use the wired scantools simply because I want maximum speed and reliability. Having said that, when I'm using an Android phone or tablet, I will grab the appropriate Bluetooth scantool, simply for convenience.

I have the (blue, translucent) Veepeak 'OBDCheck VP11', which is the "official" name of what Amazon sells (for $14.99) as "Veepeak Mini Bluetooth OBD II Scanner". I like it a lot, especially for the price. The only complaint I have is that it won't remember pairing information for more than just the last-paired Bluetooth host, so I have to re-pair it every time I use it with a different Android device.

As for wired scantools, I recently bought a 'vLinker FS USB' by Vgate for $35. It has served me quite well, since it supports these protocols:

1. SAE J1850 VPW (GM)
2. SAE J1850 PWM (Ford)
3. ISO 9141-2
4. HS-CAN
5. MS-CAN (Ford)

The downside is that it does not support GM's SWCAN. But I needed MS-CAN on a wired scantool (since I previously only had that protocol on my OBDLink 'MX Bluetooth' scantool) so it was a worthy investment.

Hope that helps a bit!

 

[TJBaker57]

Whenever possible, I use the wired scantools simply because I want maximum speed and reliability.

I am a little curious about this myself.

Speaking only in regard to J1850VPW systems:

Having simultaneously recorded all data traffic on multiple vehicles with multiple OBD2 devices and finding no evidence of any dropped or otherwise missed message traffic, what is to be gained with a wired device?

Even when I introduce additional message traffic by requesting large numbers of PIDs I don't see any degradation in the recording of all serial data traffic using Bluetooth adapters.

Am I missing something here?

 

[AmpOverload]

I am a little curious about this myself.

Speaking only in regard to J1850VPW systems:

Having simultaneously recorded all data traffic on multiple vehicles with multiple OBD2 devices and finding no evidence of any dropped or otherwise missed message traffic, what is to be gained with a wired device?

Even when I introduce additional message traffic by requesting large numbers of PIDs I don't see any degradation in the recording of all serial data traffic using Bluetooth adapters.

Am I missing something here?

Since I virtually never do any serious data collection with a Bluetooth scantool, I am, paradoxically, unable to easily provide any evidence of the anomalies I've encountered. So, even though I cannot provide hard, scientific evidence for my preference, I will attempt to clarify it, however anecdotal it may be.

I'm not a Bluetooth expert, but I believe that the protocol does provide for "re-tries" after transmission failures. I think this is done at the protocol level and would not always be evident to us, working as we are at the "ELM327" level, if you will. But it would be interesting to have the appropriate hardware (i.e. a Bluetooth protocol analyzer of some sort) to see when such things are happening.

I tend to treat "Bluetooth versus USB" much like I treat "WiFi versus Ethernet" -- I always use a wired connection when I can. I suspect that I'm in a small (and shrinking!) minority, for both of those cases.

Of course, there's the (broader?) issue of how fast the vehicle can respond to data queries, an issue which often makes the point of maximizing interface speed less relevant. But I'll still try to shave off any latency in data collection that I can, everywhere I can, while understanding that it may not be a priority or even an issue for everyone.

In a perfect universe, my curiosity would lead me to investigate this whole thing some more. But, you know how that goes, right?

 

[JSilo]

Since I virtually never do any serious data collection with a Bluetooth scantool, I am, paradoxically, unable to easily provide any evidence of the anomalies I've encountered. So, even though I cannot provide hard, scientific evidence for my preference, I will attempt to clarify it, however anecdotal it may be.

I'm not a Bluetooth expert, but I believe that the protocol does provide for "re-tries" after transmission failures. I think this is done at the protocol level and would not always be evident to us, working as we are at the "ELM327" level, if you will. But it would be interesting to have the appropriate hardware (i.e. a Bluetooth protocol analyzer of some sort) to see when such things are happening.

I tend to treat "Bluetooth versus USB" much like I treat "WiFi versus Ethernet" -- I always use a wired connection when I can. I suspect that I'm in a small (and shrinking!) minority, for both of those cases.

Of course, there's the (broader?) issue of how fast the vehicle can respond to data queries, an issue which often makes the point of maximizing interface speed less relevant. But I'll still try to shave off any latency in data collection that I can, everywhere I can, while understanding that it may not be a priority or even an issue for everyone.

In a perfect universe, my curiosity would lead me to investigate this whole thing some more. But, you know how that goes, right?

My comments for a wired USB interfaced where much simpler. I have Windows PC's and Laptops and all my wireless devices are Apple IOS based. I don't own any andriod based products. And I thought it be simplier to have the class2 Messages logged/streasmed to files on a PC and so I could look at the raw data with simple text editors and/or windows tools. once I get a handle on what is going on and want to manipulate/spoof/filter the class2 content, I'll try to dust off my assembly. C, and C++ skills. for now I just want/need to understand what messages and services are used by the Quadrasteer module. To that end, I'll go look into the wired USB devices that I can connect to a windows laptop. Thanks everyone. john

 

[JSilo]

It surprised me somewhat to hear that. IIRC, the OBDLink EX is like that and one or two of the (expensive) scantools sold by the "OBDX Pro" people, but there were and still are relatively inexpensive USB scantools that provide both J1850-PWM and J1850-VPW.


I have 3 Bluetooth and 3 wired (USB) scantools, of varying vintages, going back to 2010.

Whenever possible, I use the wired scantools simply because I want maximum speed and reliability. Having said that, when I'm using an Android phone or tablet, I will grab the appropriate Bluetooth scantool, simply for convenience.

I have the (blue, translucent) Veepeak 'OBDCheck VP11', which is the "official" name of what Amazon sells (for $14.99) as "Veepeak Mini Bluetooth OBD II Scanner". I like it a lot, especially for the price. The only complaint I have is that it won't remember pairing information for more than just the last-paired Bluetooth host, so I have to re-pair it every time I use it with a different Android device.

As for wired scantools, I recently bought a 'vLinker FS USB' by Vgate for $35. It has served me quite well, since it supports these protocols:

1. SAE J1850 VPW (GM)
2. SAE J1850 PWM (Ford)
3. ISO 9141-2
4. HS-CAN
5. MS-CAN (Ford)

The downside is that it does not support GM's SWCAN. But I needed MS-CAN on a wired scantool (since I previously only had that protocol on my OBDLink 'MX Bluetooth' scantool) so it was a worthy investment.

Hope that helps a bit!

Can I double confirm the "vLinker FS USB" will display/monitor Class2 J1850VPW messages, When I look at the little there is documentation on the amazon and Ebay sites. it doesn't mention J1850-VPW and class2 aka 10.4Kp anywhere, all I see is mention of fords 44kb and J1850-Pwm messages.

 

[AmpOverload]

Can I double confirm the "vLinker FS USB" will display/monitor Class2 J1850VPW messages, When I look at the little there is documentation on the amazon and Ebay sites. it doesn't mention J1850-VPW and class2 aka 10.4Kp anywhere, all I see is mention of fords 44kb and J1850-Pwm messages.

I don't blame you one bit for wanting to confirm VPW compatibility. I almost didn't buy it because of the total lack of clear communication about the protocols that the device supports (on Amazon, on the company's website, and elsewhere, IIRC). It's an incredibly poor job by the marketing department!

So I took a bit of a risk in buying it (from Amazon, FWIW). Luckily, I was pleased when I began testing it.

But to put your mind at ease that it does indeed support SAE J1850 VPW (GM) protocol, here is a snippet of output from one of my Linux apps that takes what I call a "snapshot" of data about a vehicle. This is for a 2005 Buick LeSabre, whose nodes speak only VPW protocol:

Vehicle:
   Nodes:
      #1:
         Bus Address: 0x10
         Name: 'PCM' = 'Powertrain Control Module'
         Protocol: 0x2 = 'SAE J1850 VPW (10.4 Kbaud)'
   .
   .
   .
Scantool:
   ATI: ELM327 v2.3
   AT@1: OBDII to RS232 Interpreter
   AT@2: ?
   STI: STN1170 v4.3.2
   STDI: vLinker FS r2
   STMFR: Vgate.com.cn
   ATDP: SAE J1850 VPW
   ATDPN: 2
   .
   .
   .

As you can see from the queries made directly to the scantool ('STDI', 'STMFR'), this is the Vgate 'vLinker FS USB'.

And, from that same session, proof that it did an actual (Mode $01, PID $00) vehicle query:

Command: ATSH 68 6A F1
  Reply: OK
Command: 0100
  Reply: 48 6B 10 41 00 BE 3F B8 11 75

For the record, I have never used this scantool under Windows because I'm a full-time Linux guy. But I have no reason to suspect that you'd have any problems under Windows.

Hope that helps! Feel free to ask if you have any other questions.

 

[AmpOverload]

I forgot about something... In case this issue (computers with USB3 hubs that are not USB2-compatible) applies to your hardware, you might want to read this thread on the FORScan forums: Recall of vLinker FS USB from the list of recommended adapters

 

[JSilo]

For sheer simplicity, convenience, and minimum expense a Bluetooth dongle and an Android device with a serial terminal app are hard to beat. Even if only to get your feet wet in becoming familiar with the J1850VPW traffic.

Less that $20 and you can easily monitor and record all or selected serial data traffic. I use devices from Veepeak and can attest to their reliability. For a free serial data app look no further than "Serial Bluetooth Terminal" by Kai Morich.

I have no experience with wired store bought OBD devices. I built an Arduino device for my own use with J1850VPW for the purpose of adding sensors and piggybacking the data on the vehicle data bus. The additional data can be displayed on an Android OBD2 app.






All GM J1850VPW will be the 3 byte variant.


Here is a sample from a test bench with a PCM, BCM and TCCM.

View attachment 116599









No. A Tech 2 cannot show you the serial data traffic.

I'm trying to take a cut at decoding the sample above. 1- If the first byte is the first byte of the 3 bit line is the header, Are all of the messages/Frames using "functional addressing"? If I'm reading it correctly, I don't see a single one with its addressing mode "Y" bit set to 1? Could you then help me out on a simple one like 08 FF 10 03 58? I'm thinking FF is a "Network control Status" report, I'm not sure how to intrepret the 10 03 58. can you decode this one for me? With it, I'll take a cut at the others. Thanks, john

 

[TJBaker57]

Could you then help me out on a simple one like 08 FF 10 03 58? I'm thinking FF is a "Network control Status" report, I'm not sure how to intrepret the 10 03 58. can you decode this one for me?

08 FF 10 03 58 as follows....

$08: Priority 0, message type 8

$FF: functional target address "Network Control" (status ID),

$10: source address (physical) $10 (PCM),

$03: secondary ID, "Node Alive",

$58: CRC

Breaking down a little further.... the "W bit" is 1, the "Q" and "C" bits are 0.

This message is called by a few terms depending on where you see it referenced. Some call it the SOH (state of Health) message. Also seen as a "heartbeat" message. All modules on the bus are required to transmit such a message not less than every 2 seconds.

Here are several such messages displayed in a truly hideous spreadsheet I use to display logfiles. Some of the pertinent bits are broken out.

 

[TJBaker57]

trying to take a cut at decoding the sample above. 1- If the first byte is the first byte of the 3 bit line is the header,

I laugh at myself when reading things like this!

I am at a disadvantage in that my mind cannot parse these sorts of things. It's somewhat like looking at a command prompt that throws "syntax error" when all is not exactly correct.

If I come upon a word that doesn't seem to fit my brain just stops right there. It's like hitting a question in a diagnostic flowchart where I don't have the answer so I cannot continue.

For this example I come upon "3 bit line" and the anchor drops. "3 bit line,,,, 3 bit line,,,, hmmmm". What is that I ask myself. Maybe it should read " 3 byte line?" "No, that doesn't make any more sense".

"Let's move on" I think. " 3 bit line is the header, ". Hmmm,,,, Maybe "3 bit line 'IN' the header??" ....... Maybe he means the 3 'priority' bits in the first byte of the 3 byte header??? Maybe. That could be it.

It's a handicap of mine that makes both written and verbal communications difficult.

 

[JSilo]

08 FF 10 03 58 as follows....

$08: Priority 0, message type 8

$FF: functional target address "Network Control" (status ID),

$10: source address (physical) $10 (PCM),

$03: secondary ID, "Node Alive",

$58: CRC

Breaking down a little further.... the "W bit" is 1, the "Q" and "C" bits are 0.

This message is called by a few terms depending on where you see it referenced. Some call it the SOH (state of Health) message. Also seen as a "heartbeat" message. All modules on the bus are required to transmit such a message not less than every 2 seconds.

Here are several such messages displayed in a truly hideous spreadsheet I use to display logfiles. Some of the pertinent bits are broken out.



View attachment 116612

Do you mind a couple more questions? 1- I couldn't find the $03 secondary ID in any of the J2187 documents. Where would I find it documented? It seems like it should be part of the standard? 2-Seeing that the CRC is an attribute that is being displayed, are some of the other attributes like the CRC if it had a in frame response and the EOD also going to be displayed are are they filtered out? Lastly do you mind decoding 6a EA 40 20 9E 00 E0 I got message type 10, its using functional extended addressing, Target ID is "displays, what ever that is" Extended address is aft of A piller or is the 20 mean something else?, 9E and 00 got me stumped.

 

[JSilo]

I laugh at myself when reading things like this!

I am at a disadvantage in that my mind cannot parse these sorts of things. It's somewhat like looking at a command prompt that throws "syntax error" when all is not exactly correct.

If I come upon a word that doesn't seem to fit my brain just stops right there. It's like hitting a question in a diagnostic flowchart where I don't have the answer so I cannot continue.

For this example I come upon "3 bit line" and the anchor drops. "3 bit line,,,, 3 bit line,,,, hmmmm". What is that I ask myself. Maybe it should read " 3 byte line?" "No, that doesn't make any more sense".

"Let's move on" I think. " 3 bit line is the header, ". Hmmm,,,, Maybe "3 bit line 'IN' the header??" ....... Maybe he means the 3 'priority' bits in the first byte of the 3 byte header??? Maybe. That could be it.

It's a handicap of mine that makes both written and verbal communications difficult.

sorry about that, I'm bad at english and that is why I became an engineer. I know precision means everything especially when it comes to this stuff.

 

[TJBaker57]

couldn't find the $03 secondary ID in any of the J2187 documents. Where would I find it documented?

Volume 4,, page 33 in the 1999 revision.

2-Seeing that the CRC is an attribute that is being displayed

The CRC being displayed is a result of the ELM AT command to turn on headers. Turn the headers on with "AT H1" and you get both the headers and the CRC. Turn headers off with "AT H0" and both headers and CRC are not displayed.

are some of the other attributes like the CRC if it had a in frame response

The GM implemntation of the spec does not allow an in-frame response.

Lastly do you mind decoding 6a EA 40 20 9E 00 E0 I got message type 10, its using functional extended addressing, Target ID is "displays, what ever that is" Extended address is aft of A piller or is the 20 mean something else?, 9E and 00 got me stumped.

This message is the BCM transmitting a "load command extended" message to functional address of "displays" with a secondary ID of $20 and extended address of $9E. The data to load is $00.

In general terms this messages causes the IPC to turn off the security indicator. This message and others like it are sent even if said indicator is already off. Plus these messages are frequently sent multiple times at key on.

Right after these messages appear an acknowledgement message will be sent by the IPC. It will be AA EB 60 20 9E 00 30.

A quick edit/addition:

Some of these are sent by the BCM ($40), some by the PCM ($10) and the 4WD by the TCCM ($1A).

$9E = security
$91 = High Beam
$8E = Battery
$98 = Brakes
$82 = Change engine oil
$84 = Check oil level
$85 = Check Gauges
$8C = Cruise Control
$95 = ABS
$B7 = Reduced Engine Power
$D1 = Service 4WD

 

[JSilo]

Volume 4,, page 33 in the 1999 revision.

View attachment 116614



The CRC being displayed is a result of the ELM AT command to turn on headers. Turn the headers on with "AT H1" and you get both the headers and the CRC. Turn headers off with "AT H0" and both headers and CRC are not displayed.





The GM implemntation of the spec does not allow an in-frame response.






This message is the BCM transmitting a "load command extended" message to functional address of "displays" with a secondary ID of $20 and extended address of $9E. The data to load is $00.

In general terms this messages causes the IPC to turn off the security indicator. This message and others like it are sent even if said indicator is already off. Plus these messages are frequently sent multiple times at key on.

Right after these messages appear an acknowledgement message will be sent by the IPC. It will be AA EB 60 20 9E 00 30.

A quick edit/addition:

Some of these are sent by the BCM ($40), some by the PCM ($10) and the 4WD by the TCCM ($1A).

$9E = security
$91 = High Beam
$8E = Battery
$98 = Brakes
$82 = Change engine oil
$84 = Check oil level
$85 = Check Gauges
$8C = Cruise Control
$95 = ABS
$B7 = Reduced Engine Power
$D1 = Service 4WD

 

[TJBaker57]

View attachment 116627

Re: "Test Mode (defined by GM????) Much if not all of the specifics for these instructions is proprietary and we are unlikely to get any documented details. If they are out there I have not come across them.

Here is a posting I came across years ago when first I became interested in J1850. It has some useful stuff in it.

VPW Communication Protocol

 

[mrrsm]

Sweet...

 

[JSilo]

Sweet...

Thanks, its nicely organized whereas you have to read 5 separate standards. I appreciate it.,

 

[TJBaker57]

Thanks, its nicely organized whereas you have to read 5 separate standards. I appreciate it.,

A minor note: Near the bottom of this webpage (and the .pdf) there is an addition error...

"To get real trouble codes you should request only
$80+$10+$02=$C2"

The sum is obviously incorrect.

 

[JSilo]

This message is the BCM transmitting a "load command extended" message to functional address of "displays" with a secondary ID of $20 and extended address of $9E. The data to load is $00.

I get that message is Load Command Extended and it using function addressing and Primary Id of $EA for "Display" and a secondary of $20. But when I look in the standards (J2187 for command $EA, the only secondary address in the table is $08 for Metric Desplay. , I don't see a secondary ID entry for $20 and since that entry isn't listed there , I can't see what the Extended address of $9E maps to. So how did you do it? Is there another document that I should read?

 

[TJBaker57]

I get that message is Load Command Extended and it using function addressing and Primary Id of $EA for "Display" and a secondary of $20. But when I look in the standards (J2187 for command $EA, the only secondary address in the table is $08 for Metric Desplay. , I don't see a secondary ID entry for $20 and since that entry isn't listed there , I can't see what the Extended address of $9E maps to. So how did you do it? Is there another document that I should read?

Manufacturers can make and use their own proprietary secondary IDs. The standard allows for this. Thus you will find a great deal of messages for which there is no lookup in the SAE standard(s). All we can do is speculate and try to work out the details by capturing and analyzing large amounts of data and experimentations.


As far as the display secondary IDs ($EA) I have determined many of them by sending the message and see what displays.

I have a growing assortment of used modules at my disposal.

5 Clusters
5 or more PCM
3 or more BCM
8 or 9 TCCM
1 DDM
1 PDM
1 LGM
2 HVAC Modules (CJ2)
2 HVAC Modules (CJ3)
1 EBCM
1 Radio
1 Battery Control Module (added yesterday)

Then there's a bucket or two worth of ignition switches and tumblers, Passlock sensors, headlight switches, 4WD switches, multifunction switches, blower motors, blower motor controllers, fuse boxes, MAP sensors, fuel tank pressure sensors, oil pressure switches and sensors, etc., etc ..

 

[JSilo]

As far as the display secondary IDs ($EA) I have determined many of them by sending the message and see what displays.

Is that a typo? Isn't $EA the primary ID in this message and $20 is the secondary and $9E the extended? .... and the way you tied it to the security indicator is not by the J2187 documents but rather reverse engineering and send it and seeing what changed in your environment and in this instance, you saw that the indicator lamp went off. I think that is what your conveying

 

[TJBaker57]

Sweet...

Nice that you uploaded this pdf of "VPW Communication Protocol" because it appears that the source site FastFieros is no more!

 

[eblade]

Apologies for coming in and resurrecting an old-ish conversation here, but... this is the most in-depth discussion I've been able to locate on older GM bus systems so far with some googling, and it seems like the people in this thread are about as close as I'm going to find to experts that I can talk to about it

I've got some old GM products (97-98 Pontiac GAs), that I'd really like to get access to BCM and any other information that might possibly be floating around in there. I know I'm not necessarily going to come across all the nice stuff I'd find on a modern CAN vehicle, but I'm trying to diagnose absolutely bizarre problems with two different vehicles that i *believe* are related to bad sensor / switch readings most likely, and even if I have to write my own software to read it, it'll take a lot less time than digging out every possible sensor or switch that might cause one vehicle to never turn it's interior lights off, or the other one to suddenly decide to drop cruise control for no obvious reason whatsoever.

I've got a bog standard ELM327 clone that I picked up off Amazon years ago for like $10 or $15, and I've also just got the brand new WiCAN Pro which, my understanding is that it attaches a ELM327 to some other fancy stuff that does data collection and interfaces it to other systems. My initial experiments with the WiCAN seem to indicate that it doesn't do anything for me more special than the basic ELM does right out of the box, because all of it's special functions apparently depend on CAN, although there's not really any good reason for that, other than that their software just isn't developed far enough along to capture all the other busses that the ELM supports. Anyway, I digress.

I need to learn the basics here -- if I want meaningful data from the GM bus, are there any pre-existing apps that interpret that in any useful fashion? or do I *have* to connect to the ELM manually and go and get it myself and figure it all out?
If that's the case, do I just Bluetooth connect to the ELM from a PC, then it's exposed as a serial Bluetooth connection? Then I can just talk to it as if it were a modem?

From there, can I simply snoop all the information on the bus, just as I might on a modern CAN bus, and I "just" have to figure out what it all means?

 

[AmpOverload]

I need to learn the basics here -- if I want meaningful data from the GM bus, are there any pre-existing apps that interpret that in any useful fashion? or do I *have* to connect to the ELM manually and go and get it myself and figure it all out?
If that's the case, do I just Bluetooth connect to the ELM from a PC, then it's exposed as a serial Bluetooth connection? Then I can just talk to it as if it were a modem?

Welcome to the forum!

To get data from the SAE J1850 VPW bus (GM), you have multiple options. There are certainly various software applications to support it, with varying degrees of "completeness" and "usefulness". You can also connect directly to the OBD2 scantool hardware via a serial terminal app (on PC or tablet/phone) and communicate at a "bare bones" level. Doing the latter is really like you asked, i.e. it's exposed as a serial connection (whether USB, Bluetooth, or WiFi) and then you just talk to it as if it were a modem. But then you have to learn both the language of the ELM327 and the appropriate commands to send to the ELM327 to have it send onward to the vehicle. And you have to learn how to interpret the vehicle's (and the ELM327's) replies. This is a bit of a long road, but certainly not impossible. I and many others have mastered the skill. But it's always nicer if you can find an app to do the dirty work for you!

I wasn't familiar with the WiCAN-Pro, so I took a quick look at it. I can't really tell if it's WiFi, Bluetooth, or both. Using an ESP32-S3, it could be any of those cases.

It sounds like your ELM327 clone is Bluetooth capable, or were you referring to the WiCAN-Pro?

Also, what OS and hardware do you use? Windows, Mac, Linux, Android, iPhone? Those answers may help folks to give better advice.

If my sources are correct, '97-'98 Pontiac Grand Ams use the "P04" PCM. I've done a lot of testing on vehicles with P04 PCMs (mostly Buicks).

I have more advice to offer, but I'd like to understand your situation a bit better first, so if you could clarify with answers to those questions, it would help.

 

[TJBaker57]

I'd really like to get access to BCM

I only took a quick look through literature at the Charm.li site so not as exhaustive search.. but do your 97-98 GAs even have a BCM?

Information Bus: Description and Operation — 1997 Pontiac Grand AM V6-3100 3.1L VIN M SFI Service Manual | Operation CHARM

Detailed repair manual for the 1997 Pontiac Grand AM V6-3100 3.1L VIN M SFI.

charm.li

 

[AmpOverload]

These 1997/1998 Pontiac Grand Ams turn out to be rather interesting to me because the oldest (real-world, not simulated) GM OBD2 vehicle I've tested was a 2001. IIUC, it seems that the Grand Ams from the 1997/1998 era have only the PCM on the VPW bus (pin 2 on the OBD2 DLC) but also have another serial data bus (probably much like the older ALDL) that seems to be on pin 9 of the OBD2 DLC on these vehicles. I'd never seen or heard of that before.

As such, most of the Tech2/Tech2Win information, when configured for such a Pontiac and running with a VPW-protocol vehicle simulator, are not as useful without something to supply the traffic from that "side-channel" bus that's used for the PCM/EBCM/IPC/SIR (IIRC) to communicate.

So, unsurprisingly, @TJBaker57 seems to be right on target to suggest the lack of a BCM.

Regardless, I had hoped that the PCM might have some information to at least help diagnose the 'cruise control disconnect' issue. I know for certain that some 2004/2005 Buicks (with the P04 PCM) support a (Mode $22) PID ($112B) that reports the "Cruise Control Inhibit Reason". But, to my surprise, it seems like the Pontiacs of the 1997/1998 era, despite having a 'P04' PCM, do not support that PID!

(I had wondered in the past if a database of GM PCM PIDs could be done by PCM "family" -- e.g. "P01", "P04", "P10", etc. But this seems like strong evidence that it's not practical to do so. It seems that such databases must specify something about the actual software load, ostensibly the PCM's 'OSID').

So, unfortunately, even if the OP @eblade is able to get custom PIDs working, there seems to be limited information available for diagnosing the cruise control issue (let alone the "interior lights" issue).

Here's a screenshot of what I saw in Tech2Win, showing cruise-control-related PIDs for a 1998 Pontiac with 'N' body and 'M' engine:


Neither of the 2 PIDs shown there will be nearly as helpful in diagnosis as the "inhibit reason" PID would have been.

 

[mrrsm]

Seems like a visit to @Mooseman 's Thread might be worth exploring for owners of Tech 2 and some VXDIAG-NANO Devices...

Thread 'Computer and Tis2000 setup for Tech2'

May 30, 2015

A lot of info I found over at SaabCentral but it is just a giant thread to read through although a lot of the info is on the first page. And a lot doesn't apply since it's geared towards Saab (even the 9-7x doesn't apply, it's under GM).

So you have a Tech2 but a lot of the things you would like to do is locked out because you don't have access to the computer software to allow you to do it. Things like updating PCM's and modules and anything security related are locked out. If you bought one of the Tech2 clones, it probably came with a CD with the Tis2000 software. If you...

• Mooseman
• Replies: 127
• Forum: Tech 2

• 

...as sometimes...the Early Model BINS may work -=better=- than the later iterations because Module Support might be discarded over time. To illustrate this... Keith DeFazio from New Level Auto up in Staten Island, NY once performed a 'Face Off' between a contemporary Pro Grade Scan Tool that failed to work and an Autel Maxi-DAS DS-708 with the latter device being the only way to address an arcane issue with a 1990s GM Product... just to make the point about "Why I NEVER Discard Older Scan Tools...for NEWER Ones ...Ever."

Keith is on the Left, Ivan from Pine Hollow Auto Diagnostics is on the Right and the Red Arrows point to the shelves FILLED with Legacy Diagnostic Tools to emphasize and illustrate this idea:

Trained By Techs

TO IMPROVE THE AUTOMOTIVE SERVICE INDUSTRY THROUGH NETWORKING, EDUCATION, AND INDUSTRY AWARENESS.

trainedbytechs.com

 

[AmpOverload]

...as sometimes...the Early Model BINS may work -=better=- than the later iterations because Module Support might be discarded over time.

I've "rolled back" my Tech2Win BIN once in the past, as a test, in response to someone in this thread:

Can anyone help roll back Tech2WIN to V30.004

I don't know if it would change anything with respect to the available PCM Mode $22 PIDs for a 1997/1998 Pontiac, but it might be worth a try, if in fact @eblade pursues this issue and gets custom PIDs working on some hardware/software combo.

 

[eblade]

> To get data from the SAE J1850 VPW bus (GM), you have multiple options. There are certainly various software applications to support it, with varying degrees of "completeness" and "usefulness".

Well, I've messed around with Torque and Car Scanner, with the ELM and the WiCAN. Basically, the WiCAN is going to be, for me, just an ELM with BT and WiFi in a fancy package, because as far as I can tell, I can't take advantage of any of it's onboard data collection features, since I'm lacking CAN. It seems odd it can't collect standard OBD-II from other protocols, but I suspect that's more a software problem than "it can't do it". I can get the OBD-II info, I can read and clear codes with them, but I haven't figured out any software that lets me see anything else. Yeah, having access to the engine stuff is cool and all, and I'll want that, but right now I want to see what ELSE is in there

> But it's always nicer if you can find an app to do the dirty work for you!
I am hoping for something.. :-D

> It sounds like your ELM327 clone is Bluetooth capable, or were you referring to the WiCAN-Pro? Also, what OS and hardware do you use? Windows, Mac, Linux, Android, iPhone?

Basic ELM is BT, WiCAN ELM is BT and WiFi. It's easiest for me to work with WIndows and Android, but I can work with anything necessary

I'm an old hand with serial and modems, and I've done software work with simulated CAN bus systems (that worked well enough that when someone plugged it into a real CAN bus, it actually mostly worked), so it's not super scary or anything

> If my sources are correct, '97-'98 Pontiac Grand Ams use the "P04" PCM.
Absolutely no idea, but if you tell me how to tell, I can possibly find out. I've got a 98 available for parts that I can tear into pieces if necessary, although it's winter right now so i don't want to spend time outside too much

> I only took a quick look through literature at the Charm.li site so not as exhaustive search.. but do your 97-98 GAs even have a BCM?
Well.. there's some kind of module, but don't know if it communicates on the bus, or is readable on the bus, or not. A mechanic removed said module in my 97 because the interior lights were stuck on permanently, and they presumed that the module was broken. It's sitting in the storage area in the armrest, awaiting cracking a replacement out of another car or cracking it open to see what's inside it. *I* think it's sensors gone bad telling it bad information, rather than the module itself. But I can't prove it without tearing the dash out of my parts car. And if that does prove my theory, I still don't know *what* sensor(s).

On that link page (very interesting looking site I'll probably spend entirely too much time there, thank you), it does say something about "Sensing Diagnostic Module", and "PRNDL Control Module", and "EBCM", all of which *potentially* might contain information that would be of interest to the specific problems ... (although the car with the cruise problem is manual so maybe doesn't have a PRNDL module, or maybe there's an equivalent for manual trans?) Of course, I'm kind of interested in just seeing what all is possible to see, as well. There's got to be more going on that what's documented there, I know there's radio commands on that bus, because I know someone has hacked the radio through the bus.

> These 1997/1998 Pontiac Grand Ams turn out to be rather interesting to me
If you happen to be near Detroit, you're welcome to come have a look ;-)

> .... [talk about PIDs and Tech2] ...
That stuff is a bit over my head right now, I have a vague understanding of PID, what is Tech2? What is that software you screenshotted?

> with the latter device being the only way to address an arcane issue with a 1990s GM Product
.. I wonder where they are, once I get a coolant problem fixed, my 98 is ready to be restored to like new status, so i am going to go through some things with it lol

Anyway, I'm ready to learn. I can reach the WiCAN from my living room via WiFi, if I park close enough in the driveway, so if I can read from it with the power On but Engine Off, I've got plenty of time to mess around. If I find something really interesting, i suppose i can run the engine for a while if need be

Thanks all for any help, I really appreciate the help you've given already, I've already learned a fair amount from this thread.

 

[AmpOverload]

Well, I've messed around with Torque and Car Scanner, with the ELM and the WiCAN.
.
.
.
I'm an old hand with serial and modems, and I've done software work with simulated CAN bus systems (that worked well enough that when someone plugged it into a real CAN bus, it actually mostly worked), so it's not super scary or anything

Excellent! If you're semi-comfortable with Torque and Android, that seems like a good place to start. As you've probably seen, there are a lot of threads on this forum (and elsewhere) talking about that app and even one (long!) thread here dedicated to Torque Pro PIDs.

"Tech2" is an old device that communicates with GM vehicles, covering OBD2 vehicles from roughly 1996 to about 2008 (IIRC). There's also a software app running on Windows called 'Tech2Win' which emulates the hardware Tech2 device, in both screen presentation and firmware behavior. But it requires a compatible device (like a VXDIAG VCX Nano). That's what my screenshot shows.

Identifying a P04 PCM is probably easiest by seeing if the 2 80-pin connectors are marked "CLEAR" and "BLUE". I don't think any other PCM families use the same scheme. But it would be even better to get the "Service Number" and "Hardware Number" from the label on the outside of the PCM. Once you can read from the PCM, you can read both the "Hardware Number" (confirming the label's value, hopefully) and "OSID", to further confirm just what sort of PCM you have in each Pontiac.

And the VIN of both vehicles will be useful if I'm going to run Tech2Win again simulating your vehicle(s). Feel free to put zeros in the last several VIN characters for anonymity.

On the 1997/1998 Pontiacs, I don't think you'll be able to (easily) communicate with anything but the PCM over the 16-pin DLC (OBD2 Diagnostic Link Connector), so don't get your hopes up too high.

But you should probably experiment some more with Torque Pro and (initially) your BT-only ELM327 clone device, talking to the PCM. Figure out how to set up a custom PID in Torque Pro then use it to query something on a Grand Am, like Mode $22 PID $1101, bit 0, which is "Brake Pedal Status" on every P04 vehicle I've tested on. That will be an easy PID to test. If that works, I'll try to help figure out the right Torque Pro formula for a couple of cruise-control PIDs shown in that Tech2Win screenshot. (I don't actually use Torque Pro.)

If you get that working, I'll take more screenshots in Tech2Win showing you what PIDs your Pontiacs should be able to support.

And if that all works out and you haven't lost motivation, it would then probably be time to start looking for a Bluetooth serial terminal app for Android, so that you might communicate directly with the vehicle via your ELM327 clone (which is where your modem experience should be a bit helpful). Some folks here use the one by Kai Morich. (I use one that I got years ago from the F-Droid site, simply called "Bluetooth terminal", but I cannot find it there now.) The datasheet for the ELM327 chip (available in many places on the Internet and probably somewhere on this forum too) will be a big help at this point.

Oh, BTW, you can read from the PCM with Key On, Engine Off ("KOEO"), but be sure you don't drain the battery -- it's all too easy!

 

[eblade]

I'm *hoping* that I can get time in the next 7 days to poke at it at least a little bit, because I am off work, and when I'm back in the thick of things, who knows when I'll have the luxury of spending time on a side project that requires learning. My initial impression is that I want to try and get at it with the WiFi elm, since it's probably got longer range than the Bluetooth, and I can sit in my living room and at least poke it. I am not seeing anything in the way of detailed instructions on how to actually connect to a WiFi ELM device, but my gut feel is that a simple "telnet" to it would hopefully connect to the terminal interface on it. Google AI agrees with that, but I can't figure out why it agrees with me on that, so I guess I just try it

I can supply the VINs, how many digits of it are relevant?

> VXDIAG VCX Nano
Not opposed to spending $100 for a device (i just spent 80 or something on this WiCAN, only to find it's primary function won't work for me oops! guess it goes in the one newer car in the family once i'm done messing with it) if I have reason to believe it's utility is worth it.

> As you've probably seen, there are a lot of threads on this forum (and elsewhere) talking about that app and even one (long!) thread here dedicated to Torque Pro PIDs.

I actually hadn't explored this forum too much, I was doing a google search on trying to figure out what information would be available on a J1850 VPW bus, and it dropped me directly onto this thread .. I can poke around, or if you happen to have some links bookmarked, that'd be awesome

Looks to me like I'd probably do something along the lines of ... get connected to the ELM, tell it

- ATD (reset to defaults)
- ATSP00 (set automatic protocol, save)
- maybe futz around with some possible formatting or control character options

then just give it the hex value for the Mode and PID desired? ie

221101

and then just repeat that whenever i want to query it? doesn't seem very difficult at all, much easier than messing with apps, if we already know the shape of the data we're digging at.

I am realizing that this is probably all just academic, though, as I have doubts that I'm going to be able to get at any switch status information .. but I am curious that if there's a way I can *monitor* the bus from one of these adapters, instead of *query*ing it, then I can compare the bus data on a car with good door switches compared to one with suspected bad door switches, and see if there's any difference.

If we could get brake and clutch data, though, that'd be at least a start to determining if one of those sensors is causing it to drop out of cruise. Although a guy at the local former Pontiac dealer told me a few days ago, that it sounds very much likely that the cruise control cable is possibly getting interfered with somewhere physically. My mechanic's current assumption, since replacing the activator switch itself with a brand new one made the problem *worse* instead of *better* is that the cruise module itself is fried, and that's an easy one to disprove.

 

[AmpOverload]

[...] I want to try and get at it with the WiFi elm, since it's probably got longer range than the Bluetooth, and I can sit in my living room and at least poke it. I am not seeing anything in the way of detailed instructions on how to actually connect to a WiFi ELM device, but my gut feel is that a simple "telnet" to it would hopefully connect to the terminal interface on it.

Unfortunately, I've never used a WiFi ELM327 device, so I can't offer anything useful there, especially so if you're using Windows. Don't know that I've ever "telnet"ed directly to a WiFi device, but in theory, that should work.

I can supply the VINs, how many digits of it are relevant?

For Tech2/Tech2Win, one typically needs the body style and engine type. Since these sometimes vary in position within the VIN, depending on the vehicle, it's best to give out the full VIN with, say, the last 5 digits zeroed out to retain anonymity, if you prefer.

> VXDIAG VCX Nano
Not opposed to spending $100 for a device (i just spent 80 or something on this WiCAN, only to find it's primary function won't work for me oops! guess it goes in the one newer car in the family once i'm done messing with it) if I have reason to believe it's utility is worth it.

For me, the VCX Nano has been a blessing and a curse. It opened up a whole new world of PID and formula exploration, for a lot of the older GM vehicles using Tech2Win (software) and for a lot of the newer GM vehicles using GDS2 (software). But it's a curse in that it's very "fragile". Oftentimes, it seems to get confused and hangs up, forcing me to jump through various hoops to get it running properly again. And it has an annoying "expiration date" where you always have to "back date" the clock on the Windows PC on which it runs to keep the driver working, assuming you keep the PC from accessing the Internet, as I do. I simply cannot recommend the VXDIAG VCX Nano, frankly, unless someone is very patient and willing to put up with a lot of frustration.

> As you've probably seen, there are a lot of threads on this forum (and elsewhere) talking about that app and even one (long!) thread here dedicated to Torque Pro PIDs.

I actually hadn't explored this forum too much, I was doing a google search on trying to figure out what information would be available on a J1850 VPW bus, and it dropped me directly onto this thread .. I can poke around, or if you happen to have some links bookmarked, that'd be awesome

There are several good threads in the "Scan Tools" section of this forum. I'd start there. There's a lot to read, but there's a lot to be learned from it. If you have questions about anything there, feel free to ask.

Looks to me like I'd probably do something along the lines of ... get connected to the ELM, tell it

- ATD (reset to defaults)
- ATSP00 (set automatic protocol, save)
- maybe futz around with some possible formatting or control character options

then just give it the hex value for the Mode and PID desired? ie

221101

and then just repeat that whenever i want to query it? doesn't seem very difficult at all, much easier than messing with apps, if we already know the shape of the data we're digging at.

You're right... It's really not that difficult, if one is at all comfortable with the concept of a "chat" session with an OBD2 scantool.

I typically send these commands (with some culled from the list, to avoid needless confusion at this early stage):

1. ATZ
2. ATE0
3. ATL1
4. ATS1
5. ATH1
6. ATTP 2

Then, something like this, to query Mode $22 PIDs $1101, $1102, and $1103:

1. ATSH 6C 10 F1
2. 22110101
3. 22110201
4. 22110301

Some notes about my command list shown above:

• The (excellent, well-written) ELM327 datasheet will have all the information you need about the "AT"-prefixed commands.
• Before communicating with the vehicle, you have to set the OBD2 message headers with the "ATSH" command. $6C includes things like Priority Level, Addressing Mode, and Message Type. $10 is the receiving node address ($10 = PCM on most VPW-protocol vehicles). $F1 is the (typical) address used for the reply (i.e. from the vehicle to your scantool). See the SAE J2178-1 document if you want to "drill down" into the details.
• With GM, you have to suffix a "01" to the end of all Mode $22 commands.

Here are a couple of real-world examples, from a 2004 Buick Century (VPW protocol):

Command: ATSH 6C 10 F1
  Reply: OK

Command: 22110101
  Reply: 6C F1 10 62 11 01 60 D2

I am realizing that this is probably all just academic, though, as I have doubts that I'm going to be able to get at any switch status information .. but I am curious that if there's a way I can *monitor* the bus from one of these adapters, instead of *query*ing it, then I can compare the bus data on a car with good door switches compared to one with suspected bad door switches, and see if there's any difference.

You can monitor the bus with the "ATMA", "ATMR", and "ATMT" commands. Again, the ELM327 datasheet will help. But doing what you suggest will not be easy.

 

[azswiss]

.. but I am curious that if there's a way I can *monitor* the bus from one of these adapters, instead of *query*ing it, then I can compare the bus data on a car with good door switches compared to one with suspected bad door switches, and see if there's any difference.

Using your ELM327 device in conjunction with a serial terminal emulator app, you can monitor (using the ATMA command) the bus traffic and generate a HEX log file.

Cycling lock & unlock with Key On Engine Off will give you a repeating pattern without excessive unrelated data.

You will need to parse the HEX data to get to readable ASCII (I use Excel) and then look for the Open/Close patterns.

Based on the recommendation of @TJBaker57 I installed "Serial Terminal Emulator" by Kai Morich on my Android phone & tablet. It pairs nicely with my garden variety WiFi ELM327. Note: there are both BT & WiFI versions available of the emulator.

I used this technique to quickly find the lock/unlock sequence on my 2003 Suburban.

I have attached the Excel spreadsheet I use for parsing & decoding HEX log files. The module addresses on the Lookup tab are specific to my 2003 Suburban so they are unlikely to match your vehicles but the Header bytes should be largely the same.

Feel free to reach out if you have any questions.