NEED HELP J1850 VPW Decoding: EBCM to IPC Messaging & Node Alive Architecture

800DiagTech

Member
Joined
Jun 15, 2026
Posts
3
Location
BC
Hi everyone,

I am working on a custom Python tool to decode captured J1850 VPW serial data on my '05 Tahoe to trace an intermittent startup issue. I've already mapped the physical layers, verified my grounds/fuses, and built out the base parser thanks to the incredible documentation here (shoutout to @TJBaker57 and others).

I am not looking for diagnostic troubleshooting steps for the ABS system right now; I strictly need help verifying a few protocol specifics so I can fix my decoder logic.

Question 1: IPC Loss of Comms LogicThe FSM states the IPC illuminates the ABS light when it detects a loss of communications.

  • My assumption: The IPC expects a periodic "node alive" broadcast ($State of Health / SOH) from the EBCM to the functional address $FF. If the timer expires without seeing this header/source ID, it triggers the light. Is this correct, and what is the standard broadcast interval (e.g., 2000ms) for the EBCM ($29)?
Question 2: Active Fault Command StructureThe FSM also states the light illuminates when the EBCM actively commands the IPC to turn it on due to a fault.

  • If the EBCM is explicitly telling the IPC ($60) to trip the light, what does that payload look like? I assume a standard 3-byte header, but does anyone have the specific data bytes/parametric command used for IPC telltale control?
Question 3: Authoritative GM Master Module ID ListIs there a definitive, single-source list of GM J2178 physical IDs and functional addresses cached anywhere on the forum? I’ve cobbled a list together from various spreadsheets and SAE docs, but I'm finding contradictions on some of the secondary modules.

Thanks in advance for keeping the focus strictly on the bits and bytes!
 
Your Entire First Post Entered with ... A Response with Precision from Nomic's FREE to Download and Locally Installed Privacy Focused OFF LINE LLM UI *GPT4ALL* via the Reasoning Model called "DeepSeek-R1-Distill-Qwen-14B"

Thought for 60 Seconds >

To address your questions regarding the decoding of J1850 VPW data in your '05 Tahoe, here's a structured response based on available information:

Question 1: IPC Loss of Comms Logic
  • Assumption: The IPC illuminates the ABS light upon loss of communication with the EBCM.
  • Verification: This is correct. GM systems typically use keep-alive signals (e.g., State of Health messages) from modules like the EBCM to the functional address $FF. If these signals are not received within a set interval, the IPC triggers the ABS light.
  • Interval: The standard broadcast interval for such signals in GM vehicles is often around 500 milliseconds.
Question 2: Active Fault Command Structure
  • Payload Structure: When the EBCM commands the IPC to illuminate the ABS light due to a fault, it sends a specific payload. This likely includes:
    • A header with source (EBCM) and destination (IPC) IDs.
    • Data bytes that include a command byte indicating the telltale function (e.g., turning on the ABS light).
  • Example: The data might be structured as [0x29][0x60] followed by specific fault codes, such as 0x1C for ABS.
Question 3: GM Module ID List
  • ** authoritative Source**: Refer to GM's J2178 standard or SAE documents. Additionally, forums like saturnowner.com often have verified lists from owners and technicians.
  • Verification: Cross-reference multiple sources within these communities to ensure accuracy and resolve contradictions in IDs.
Conclusion:

For precise details on intervals and command structures, consulting the J2178 document is recommended. For module ID verification, rely on GM publications and tech forums for reliable data cross-referencing.

Nomic's GPT4ALL Link:

 
OK got the info I needed, found it on the LS1Tech forum where they were interfacing IPCs. Combined with the module list from azswiss I am getting a full enough picture now.

FWIW, here is a list of messages for the IPC from LS1Tech:

Here is the money:

"
An example of how modules talk to each other would look like this....
1) 8A EA 29 20 A7 00 30
2) AA EB 60 20 A7 00 E7
3) 8A EA 29 20 95 00 69
4) AA EB 60 20 95 00 BE

#1 is the ABS controller sending a message to module EA(Cluster in this case) with a priority of 8A. The actual message being sent contains 2 parts. The 3rd byte of 20 is the command for OFF, if it was being tuned on the byte value would be A0. The 4th and 5th bytes are the item that would be commanded On or Off, in this case A7 00 is the Brake Light . So if we reconstruct the message it would like this. The Abs controller is sending a message to the instrument cluster to turn off the brake light.
"
******
Was able to get these with 20 = off A0=on, last byte 00
C9 - Service 4x4 system
76 - Trans in Warm up msg
83 - Oil pressure low msg
84 - Check Oil Level msg?
85 - Engine Overheat msg
8C - Cruise light on
8E - BATTERY LIGHT
90 - Seat Belt light
91 High beam indicator
94 - Air bag/Seat belt light
95 - ABS circle light
98 - Brake warning light
9A - Traction Active msg
9B - Traction Control Off light
9C - Low Coolant msg
9D - Engine Coolant Hot msg
9E - Security
A6 - Cargo Door Ajar msg
A7 - Service Brake System msg.
Ad - Service Ride Control msg
B7 - Reduced Engine Pwr msg
B8 - Service Stability msg
C2 - Stability System Activ msg
C9 - Service 4 wheel steer msg
CC - Tighten Fuel cap msg
D1 - Service 4x4 msg
D4 - Stability System Ready Msg
D5 - Vehicle Speed limited msg
D8 - Fog light indicator?
D9 - Water in Fuel msg
E2 - Battery Light
E4 - 4wd light
EC - Traction system limited msg
ED - Stability System disabled

F0 - response, no observed change
 
  • Like
Reactions: azswiss

Forum Statistics

Threads
24,308
Posts
649,113
Members
20,836
Latest member
89gmc1500

Members Online