As part of our ongoing development at obd2global.com, we’re diving deep into the world of high-speed vehicle networks. Following our recent success with Holley EFI to N2k gateways for performance boats, our focus has shifted to developing firmware for HS GMLAN to J1939 and N2k protocol gauge output. To kickstart this project, I needed to get hands-on with a GMLAN system. Fortunately, a customer generously lent us their 2008 Duramax, providing the perfect testbed for capturing high-speed data packets directly from a functioning vehicle.
My initial approach involved tapping into the engine harness bus at the body control module (BCM) interface. After starting the Duramax, I isolated the ECM/TCM data stream by disconnecting the BCM. My initial assumption was that General Motors continuously streams gauge information from the ECM, with the BCM acting as a translator to the low-speed LAN used by the instrument cluster. However, my initial tests suggest this might not be the case. It appears the BCM actively requests data from the ECM multiple times per second, rather than passively receiving a continuous stream.
During data capture, I also connected Torque and EFIlive scanners to observe OBD-II data availability. Even without the BCM in the loop, I successfully requested standard OBD-II PIDs such as oil pressure, temperatures, MAP, and TPS. While OBD-II provides access to essential parameters, the inherent latency in OBD request-response communication becomes a bottleneck when aiming for high-frequency data acquisition. This leads to a crucial question for the automotive expert community: has anyone extensively reverse-engineered the high-speed GMLAN packet structure?
Before committing significant resources to reverse engineering from scratch, I’m reaching out to see what prior work exists in this area. If relying solely on OBD-II PIDs is the only viable path, we will adapt. However, the goal is to achieve significantly faster data rates – ideally 10Hz or more – for critical parameters like boost and tachometer readings. This high-speed data is essential for our gateway to process and output industry-standard protocols with minimal delay, ensuring real-time performance monitoring and integration capabilities. Any insights or pointers towards existing GMLAN reverse engineering efforts would be greatly appreciated as we move forward with this project.
