Low-Speed GMLAN

I realized today that I used a few different AESwave tools to diagnose an interesting vehicle, especially if you haven't seen a failure like this before.

The patient was a 2015 Chevrolet Impala with a 3.6L engine. The complaints were that the patient presented with a multitude of issues ranging from poor running and a lack of power to the instrument cluster gauges and light swinging and blinking erratically and sometimes going dead altogether. The same could be said of the HVAC blower motor. The client was convinced that the vehicle "was possessed by a demon".

I'm fairly certain she was not speaking of the Chrysler version...

I connected a scan tool, and maybe I should get the screenshot but, hopefully, you will take my word for it, it was riddled with "U" codes. I printed those out and cleared codes from all modules, not really paying all that much attention to what was coding and what wasn't. Many codes successfully cleared, but I still had a great deal of "U" codes that re-set.

I printed out a network schematic, which may have been a bit of wasted paper as I had 8 pages of them, and started marking modules that had codes associated with them. A pattern started to emerge. All the codes were associated with, of course, the first page of schematics I printed out: The Low-Speed GMLAN bus.

The next thing was to try to communicate with any of the modules on said bus. I could not. I then used my LineSpi HC (Harvey Chan version) connected to the DLC and then connected to my scan tool to allow easy access to Pin 1 of the DLC.

Using my PicoScope I connected to Pin 1 and saw this pattern.

Now, I won't lie, I've scoped these before so I knew immediately that this was incorrect. But, if you haven't scoped one before and don't have immediate access to another vehicle with Low-Speed GMLAN you would find that service information gives you a bit of a hint.

So, I'm reasonably certain, one way or another, that this signal is not as it should be. The path I chose was to access connector JX300 (Figure 5,6), which is really a splice-pack. Basically it does exactly as it implies, it splices together many wires, and in this case a bunch of Low-Speed GMLAN wires. This will effectively help me "divide" the problem. I could have gone with JX200, but I can't kid you around...experience was at play.

I removed the "comb" and saw this in my waveform.

So, I shipped the car.

Okay, just kidding.

I've now done myself a great service in drilling down the issue. I now KNOW that it can only be from that connector "back".

I decided to use yet another "toy" I picked up from AES, the uIsolate Network Isolator. These were a product suggestion by long-time AESwave friend Scott Shotton

I chose the set with the proper terminal sizes and used them very much like jumper wires. I started with Pin A because that is where Low-Speed GMLAN comes in from JX200. A watched my waveform closely as I added connections down the line. B, C, D, E, etc...until I reached K; and this is what happened to my signal.

So, now you can see from Figure 1 where I need to target, and for those of you that have seen this you can wonder why I just didn't go right to it but...what kind of war story would that make?

The Side Object Sensor Modules. The Low-Speed GMLAN bus passes through the Left module to get to the Right side.

So I disconnected the Right side first. No change to my waveform, but I had a lot of green corrosion (actually fairly normal in MN...).

Disconnecting the left side module restored my signal to normal.

I'm recommending both modules and a harness.

Thanks to AESwave products, both that they sell and a couple they design and build, I narrowed this issue down well within an hour and fairly easily.

If you look it over and look at the process, would much experience really be required to track down a similar issue even faster than me (which really isn't saying all that much as I'm pretty darn slow)?