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