319: Module to Module Communication Faults

Welcome to the Automotive Diagnostic Podcast.

We're going to explore ways to sharpen our diagnostic skills, find learning resources, and hear from

experts in the automotive field.

This episode is brought to you by L1 Automotive Training and Keith Perkins.

If you're looking for education on module programming, J2534, eProm work, key and immobilizer,

electrical diagnostics, or drivability diagnostics, Keith has a website L1Training.com that's

got over 60 hours of training videos on all those subjects and more.

When I first started out doing mobile, I utilized Keith's videos on module programming and J2534

in order to get my head wrapped around what I would need for the tooling, the computers,

the software setups, what kind of obstacles I would be up against when I'm out there

programming modules on cars, and it was a huge benefit to me.

And I continue to use the training videos that he has on his website.

So I strongly recommend checking out L1Training.com.

The link is in the show notes.

Hey, what's going on?

Automotive World, welcome to another episode of the Automotive Diagnostic Podcast.

My name is Sean Tipping and I'll be your host once again for this week's episode.

Don't mind my voice today if it's a little off just recovering from a cold, but we're

going to do this anyways.

Today I'm going to talk about something that we have been dealing with recently, which of

course a lot of the time is what I talk about on the podcast.

It's like, what are we getting calls on right now?

What are shops challenged with?

What are maybe we challenged with and how do we deal with it?

That's what I want to talk about here and that's what this episode is.

So what I'm going to go with today is module to module communication.

And of course I talk a ton about networks and communication on the podcast.

It is a recurring theme obviously.

Maybe you're tired of hearing about it, but again, I'm basing the content that I put on

the show off of what I'm seeing in the field and again, what is most challenging.

And today, like I mentioned, module to module communication.

Not so much specifically network communication in general, although it is involved.

And not so much scan tool to module communication, although it is involved.

This is two modules on the car that need to share data in some way on some network, but

there's an issue.

So I'm going to give you a few different examples because it does depend on the car, the network

setup, the information that's being transferred, all of that.

Obviously there's different situations.

If there wasn't, this would be really easy if there was just one setup and we knew

exactly what to do.

But therein lies the problem is there's a ton of different configurations and setups

and modules and brands and scan tools and network architecture.

All that is going to change from car to car to car.

And we've got to deal with all of it if you want to work in the independent all makes

and models.

Maybe you don't.

Maybe you're like, hey, I only work on Europeans or I only do domestic and Asian.

Or maybe I work in a dealer and I only work on one brand.

Even within that, I think you've got a lot to deal with and you're going to see

some variation.

I'm going to cover a few different ones here.

And again, this is two modules on a car that share information and one or both of

them is presenting some sort of issue or code that is either causing a warning

light, disabling part of the car, maybe the entire car due to either no

communication, a lack of communication between the two modules, maybe data

that it's expecting, but it's not getting, right?

Maybe there's communication, but it's an invalid data or a missing message

between these two modules on the car, but we can talk to those two modules.

And actually, I'll give you another example of a situation where we can't

talk to one of the modules.

But the one that we've dealt with on a couple of different cars recently

is two modules on the car.

You can talk to them with the scan tool, but they are saying or at least

one of them is saying that they can't talk to each other and that's creating

some sort of negative effect on the vehicle.

Maybe it doesn't start, maybe a certain function doesn't work.

Maybe there's a warning light on the dash, whatever it is, right?

That's the end goals to fix that.

But we've gotten to the point, you know, with the initial scan and

assessment of the vehicle is that, hey, one of these modules isn't getting

what it needs from the other module, if anything at all.

Maybe it's just saying, I got no calm with this module.

But you can talk to both of them with the scan tool.

Okay.

Now the other situation is a sub module that isn't meant to talk to your scan tool.

Okay.

So that would be something that is maybe on a Lynn bus.

There's proprietary can networks as well.

We see these pretty commonly on GM stuff on modern vehicles where they'll

have an independent can network to like a fuel pump driver module.

And you don't talk to that module on the scan tool.

Maybe you can get data, PIDs and information from it, but that's being transferred

from the engine control module to your scan tool off of this proprietary network

that you, you never touch it directly with your scan tool is where I'm going

with that.

And that could be a Lynn bus again, can be a can bus.

There can be these sub networks that don't touch the scan tool.

And I mean, if you look at a vehicle with a gateway setup, which

many manufacturers use, that's true of a ton of the modules on the car, right?

You're talking to the gateway and it's transferring information to your scan

tool.

You're not directly talking to any of those modules on that particular vehicle,

but I'm not so much going with the gateway thing here.

I'm talking about you can talk to this module and it's upset about another

module and maybe you can talk to that secondary one if it's on a network

where that's possible, or maybe it's just on its own independent network

that the scan tool will never have communication with it because it's not

meant to write.

So different setups on different cars, but what you end up having is again,

one or more of these modules doing the, you know, the spider man thing at

each other, the meme, if you haven't seen it, there's multiple spider

mans that are pointing at each other, looking up if you haven't seen it.

I'm sure everybody has and they're saying, well, he's the problem.

No, he's the problem.

And I can talk to both of them.

And that's where this becomes really challenging.

Now, the first thing that you want to consider that might help you determine

what's going on is looking at the network configuration on the particular

vehicle that you're working on and ask yourself, OK, well, how does my scan

tool talk to these modules?

And is that the same method or same network that these two modules

talk to each other on?

OK, and a perfect example of this was the other day on an 07 Nissan Titan.

It was a it was immobilized.

It wouldn't start and you could talk with everything on that vehicle.

All all modules that were capable of talking to the scan tool did.

However, it's in no start.

It's immobilized.

And if we scan it, we see a ton of you 1000 codes.

That's Nissan's thing.

If there's a can network error, they just say, yep, you 1000.

We got a problem here, not going to tell you what it is.

You can do a little bit more with consult digging into the details of those codes.

But if you're just using an aftermarket scan tool,

you know, actually, now that I say that, I think some of them

do have an option to do like a can diagnostic.

I haven't played around with it much on an aftermarket tool.

So that's a separate discussion.

But anyways, where I'm going with this is I can talk to everything.

But just about everything on that car that lives on the can network

is setting a can communication code.

And clearly this vehicle is disabled for one reason or another.

So how is that possible?

How can I talk to everything but everything can't talk to each other?

What's going on there?

This thing has two different networks.

There is a K line and now, granted, this is an 07.

So this is like right at the beginning of can networks.

Yes, they used them in vehicles much earlier than 2008.

But 2008 was the like, hey, everybody's got to do this for,

you know, powertrain communication six and 14.

You got to have info there for, you know, generic OBD two standards.

But 07 was right before that and some vehicles were already using can.

This is one of them.

So if you look at six and 14, you've got your can network

and it's just your traditional like bus style can.

And there's also a K line on that OBD two connector.

And I forget which pin that is off top of my head.

Maybe one or seven. Don't quote me on that.

Anyways, it's a single wire network that goes to a number of the modules on the vehicle.

And so I'm able to talk to those modules with the scan tool

because of the K line, not because of the can bus.

I ended up scoping the can bus.

It was clearly open.

And by the way, if you see a, you know, traditional bus style like this

and what I mean by that is there's like a main branch of the can network.

And then it has legs that go off to the module.

This is not the Daisy chain style that GM and others use.

But this is your traditional bus style can.

And if you look at the waveform of a can network

and you see your two and a half volt bias

or you don't even need to see it, put whatever measuring bar indicator

you have on your scope at two point five volts.

And then look, and this is on one side of the network, right?

You're grounded, you're grounding your scope on the body of the vehicle

and you're looking at one side. I don't care which side.

If you look at it, you see two point five volts.

And then it goes above and below on the same side of the network.

You have an open. That's it.

I've talked about this before on the show.

That one hundred percent is an open for it to go up and down.

No, it's not shorted together because then you would have nothing.

They would cancel each other out, right?

Now, here's the other important thing.

When when you have this and this is generally going to be

there's an open on one side of the network.

If it's both sides, you'll get a different waveform.

It will be it does depend on the network and where and how it's broken

and terminating resistor locations.

But if you have like both sides of the network completely disconnected,

this will change.

But one side of the network open.

On the broken side, right, the side that has the open,

you'll see voltages or data packets go up and they'll go down, right?

Up to three and a half down the one and a half on the same side of the network.

OK, that's your indicator like, hey, you know, pin 14, this white wire.

I know when I find my open, it'll be on this side of the network.

And that's been very true for the can network diagnostics that I've done.

OK, so we saw that on this one.

You look at the other side, it looks like a relatively normal data transmission.

You can own check it, OK, I got 120.

So not only do I know that there's an open on this network,

but I know it's somewhere between the DLC and one of the terminating

resistors, ECM and IPDM on this Nissan have the terminating resistors,

which is not an easy thing to find, by the way.

So if you want to jot that down for an 07 Titan,

it might save you a little bit of digging and service information.

But ECM and IPDM have terminating resistors.

OK, let's go to those.

And I ended up finding a pin fitment issue at the ECM.

That case study is not really what I want to go in depth in on this episode.

Right. But it was an open can network.

But I was able to talk to everything else,

even though there was a major communication issue.

Now, the other module or the modules on that vehicle,

importantly, like the body control module,

the IPDM, the ECM, those involved with immobilizer functions

communicated important information over the can network.

They were not able to do that because it was open at the ECM connector.

But I was able to talk to all of them using the scan tool.

Now, if you didn't understand network construction,

you didn't look at the diagram, you don't have a reference

for how this stuff is working.

You would be very confused about all of these communication codes

that all these modules have, but I can talk to everything.

Very strange. OK, but it has to do with how does the scan tool

interact with these modules on this vehicle?

OK, and that's just one example that might not be true of a 2008

Nissan Titan because then is, you know, that can't protocol

defining that that you have to talk to the ECM.

TCM through the pins six and 14, I don't know.

I didn't have an O8 sitting there to compare.

But I know for sure I could talk to all the modules on this network.

And I know for sure I didn't open on the can at the ECM.

So there's no way I was talking to that ECM,

even though there was one side connected.

The high speed can that this one uses is not the fault tolerant version

that I think some of the slower speeds can use, where you can still talk

on just one side is not the case on this one.

I was talking to it through the K line, the single wire network.

OK, so where I'm going with that is you need to understand

how does my scandal actually talk to the module I'm talking to.

And then in addition to that, how do those modules talk to each other?

Is it the same in this case?

It wasn't. And you might find that on some other vehicles,

is they have their own independent network

that is separate from the way that your scan tool communicates with them.

And for vehicles that have multiple networks, this is very possible, right?

You could have a body controller or any sort of gateway module, really,

but a BCM is the one that comes to mind in a lot of cases

that is connected to every network on the vehicle.

And there's three or four different networks.

OK, now you might be able to talk to it with your scan tool,

but one of the networks it's connected to might be down,

might be affected in some way, so you'll have communication codes in there.

But again, it's how does your scan tool reach out to it?

Another real quick example is if you look at a lot of Ford vehicles

that use the gateway module that is the OBD2 connector.

And if you look at the diagram, you'll have a couple buses,

right, these vehicles will have like four different buses.

They'll have three high speed and a medium speed.

And a couple of the high speed will be directly connected to the pins,

the female pins on the OBD2 connector.

So you are hardwired in.

You could scope those right at the DLC and get usable information.

But then there's two other networks that go into the backside of this module.

That's what it is.

It's a gateway and you're not directly connected to them with the scan tool.

And you would have to go to the backside of that module to scope those networks.

So again, what I'm going with this is you got to understand network,

architecture, construction on the vehicle you're working on,

where those modules are in reference to those networks.

And then how does that all play together in the situation that you're dealing with?

And it's not always the easiest thing to answer

because they might just not come out and tell you

that these two modules talk on this network for sure.

And your scan tool talks to this module on this network for sure.

I actually find that to be the case a lot of the time is

it doesn't come out and tell you which network

your scan tool is using to communicate to a specific module

if there's multiple paths for that to happen.

Right. And when I say multiple paths, like conceivably,

this body controller on this Cadillac, I could be talking to it

on the low speed GM LAN pin one,

or I could be talking to it on the high speed can six and fourteen

because they're both connected to the DLC and they're both connected

to the body control module.

Well, which one is it when I'm reading scan tool information

out of that body controller?

Which one am I using?

I don't know for sure, you know, right?

Sometimes you might have to take a guess in certain circumstances

if they don't just come out and tell you, maybe they do, right?

Looking for this information and sometimes you can deduce

which one is the network based on network architecture,

but not always.

But back to vehicles where we have

module module communication issues,

but we can talk to everything properly with the scan tool.

We dealt with a few of these recently, so I'm going to go through these.

First one is a 2012 Porsche 911.

This one was setting codes in the airbag control module

for the passengers seat presence module, if you will, or sensor.

I forget the terminology they use specifically, but it is a module

that goes underneath the passenger seat and it's connected

to the actual math sensor to detect if somebody's sitting there or not.

And this module, the passenger presence module

does not talk to the scan tool directly.

It is a lint bus that goes from that module

to the airbag control module under the center console.

OK, and we had communication codes with that airbag module

and with the pass and we had communication codes

in the airbag module saying, hey, I can't talk to

the passenger presence module under the seat.

All right, so we looked at this and we ended up, you know,

it's a very simple circuit at the passenger presence module.

It's got power, it's got ground, it's got lin,

and then it's connected to some sensor wires.

OK, easy enough, check power, check ground, check lin.

It all seems to be good, right?

We're using a scope to check the lin.

Everything seems to be present there.

We tell the customer to get a passenger presence module.

They do. We put it in there. Same thing.

OK, so a little bit more investigating here.

What we didn't do when we checked that lint bus the first time

was check it while it was plugged into the module.

We did that and what we ended up finding

was the lint bus looked OK on the scope.

I was using a Uscope when I looked at this

until you plugged it in the module, then it dropped down to nothing.

There was no communication.

And so at first, I was thinking some sort of short in the module.

Does this have something to do with the sensor?

It didn't. I ended up finding if I was touching

the metal part of the probe that was connected to the lint bus

and I unplugged that passenger presence module

and I took my other hand and I touched it to a metal surface

on the vehicle, like the frame for the seat.

I could actually pull that waveform down right there.

This show is brought to you by Auto Rescue Tools and Isaac Rotel.

If you've been looking for a programming laptop,

you're not sure which one to buy or how to set it up,

especially if you want to program multiple brands.

You know, you've got some domestic vehicles.

You've got European vehicles.

Can the same software go on the same laptop?

What size hard drive do I need?

All those questions. Isaac's your guy.

He can custom set up programming laptops

that are ready to tackle any make or model.

I've got one of these laptops myself and I can say that it is

outstanding and it really streamlines the process

by having everything you need in one device.

So if you're looking for something like that,

I highly recommend checking out AutoRescueTools.com.

You'll also find scan tools, diagnostic equipment,

key cutting equipment and much more.

Check out the link in the show notes.

I highly recommend it.

Just me through my body, a million ohms of resistance.

And that was enough to pull that LinBus down to almost nothing.

So what's happening there is we've got some sort of

issue going on with either the circuit or maybe the circuit

inside of the airbag module, but we had to get to the airbag module,

remove the center console.

It ended up being a pin fitment issue at the airbag control module

for that LinBus.

And so it was pretty easy to miss because again, the LinBus looked OK.

Just looking at it open circuit, but connected to the module that pulled it down.

Again, you could pull it down pretty easily just by touching the circuit

with your body and correcting the pin fitment at the airbag module.

We're just barely touching, right?

That pin fitment was creating some unwanted resistance, if you will.

And open circuit.

OK, yeah, we can still read the voltage, any sort of load,

which a LinBus shouldn't really have a ton of load.

But any amount of load was enough to pull this down

and make that circuit unusable, causing my communication code.

OK, now this is one where the airbag control module,

we have to rely on that to give us information of like,

hey, I can't talk to this module.

We can't go to the airbag or the passenger presence module

and check for it.

Does it communicate because the scan tool doesn't have means to talk to it.

It was never set up to talk to a scan tool, right?

This little passenger presence module was only set up to talk to the airbag module

and vice versa between the two on the LinBus.

So we have to actually analyze what's going on on that network using a scope.

And that's kind of where I'm going with this is when you get into these situations,

one of your only weapons here in order to make the right call

is analysis of the network between these two.

Right. Once you have identified, OK, well, how does data transmission

happen between these two modules in question?

OK, well, how do they transfer information between them and on what network?

And then once I know what network, well, what is that network supposed to do?

Right. And it's a LinBus.

And so, you know, we would expect to see a LinBus up towards

battery voltage of the vehicle and then be pulled down for data transmission.

And the other interesting thing about this after the fact is a little hindsight.

I didn't pick this out in the moment, but that the resting voltage

for that LinBus when there was still an issue was lower than battery voltage.

So again, resistance at that pin fitment.

And I'm sure just connecting my scope was somewhat of a load on that circuit.

Right. And if you've been doing this long enough before,

you've seen that where your measuring device can act as a load

in an instance where there is high enough resistance in a circuit, usually unwanted.

But right, you've got high enough unwanted resistance.

So even though your scope or measuring device is not meant to take much load

or take much current from the circuit, it does a little bit, a very small amount.

That's how it performs the measurement.

And in those situations, the tool alone can be enough to affect the circuit.

And I think it was a little bit in this one didn't pull it all the way down.

But anyways, being able to assess that network was what allowed us to get to the fix on that one.

All right, the next two that I want to talk about, and these are strangely similar

as far as the result of the vehicle and the modules that we're dealing with.

And both, in my opinion, very difficult to make an accurate call on.

We basically got down to 50 50 on these.

Now, I say that and I don't mean that it's impossible to be able to pick it out.

But I think without a known good in front of you, it would be very, very challenging,

especially in the moment to make an accurate call.

You're going to get it down to the two modules and you can do your due diligence

for like, you know, powers and grounds checks to these modules.

And we did and I'm kind of excluding that from this conversation, right?

Let's just assume that we've checked all the powers and all the grounds

and all the necessary connections to a given module.

But we still have these communication issues between the two of them.

We eventually got down to a point where it's like, yeah,

it's data shared between these two that is the issue.

But we don't know which module is at fault, right?

Again, they're doing the Spider-Man thing pointing at each other.

And what's we got?

We got to call one of them.

What is the most likely?

Unfortunately, in both of these vehicles, we made the wrong call.

And that's kind of why I'm talking about it, right?

I don't I don't talk about the easy ones on the podcast that would be really boring.

Like, oh, yeah, we found a missing fuse or, oh, yeah, that that corroded wire

was, you know, causing an open.

We you guys get really bored listening to that really fast.

I want to talk about the stuff that is challenging and difficult.

And it is really tough to make an accurate call.

And unfortunately, that 50 50 call went the wrong way on both of these.

And we're going to fix them and we'll eat whatever cost is involved.

And we will take this is sidebar.

But in those situations, you have to collect data.

So that doesn't happen to you again, that in the off chance,

you run into this same scenario again, or maybe you know

somebody else who runs into this situation.

You have the data to say, yep, this is what good looks like.

This is when it was bad.

Here's what you check for.

And you can make more of an informed decision.

Well, going into it really didn't have it available to us.

So let me set the scenario here.

The first cars, no seven Subaru legacy.

It is immobilized.

There seems to be an issue of communication between the body integrated unit,

which handles the immobilizer data like it actually reads the chip and the key

and the engine control module.

And we have a code in the engine control module

saying I don't have any communication with the body integrated unit.

And eventually, if you try starting this thing enough,

you also get the same code in the body integrated unit

as I don't have any communication with the PCM.

Now, these particular codes aren't can codes.

They refer specifically to two circuits

that go between the two modules just for immobilizer data.

Now, interestingly enough, on these data lines

that look very much like a Linn bus,

although they're not defined that way in super service information,

there's two circuits, but they are redundant or one is redundant.

And it lists that in the diagram.

It says there's a main communication and a backup communication.

So without a whole lot more explanation from Subaru,

I can surmise from that is they have one circuit is like, hey, here,

let's transfer immobilizer data and then we'll give it a backup

just in case something happens to that main circuit. OK.

So right there, if that's true, it's very unlikely it's a wiring issue,

but maybe still could be two wires open or maybe a connector

right that's affecting both circuits if they're close to each other,

which they were. But let me get in here and see what's going on.

Now, I see communication on both lines between the ECM and the body unit.

And it looks the same on both sides.

Now, what I did see here, and I'll put a picture of this

in the Facebook group, if I remember, sometimes I forget to put those up.

But in the data transmission, it does not appear

that the data packets are being pulled all the way down to zero all the time.

And that stood out to me immediately of like, OK, this is a problem.

And I checked the wiring first because I'm already at both of these modules.

I went to the ECM first, then I went to the body unit

and I checked the wiring between the two of them and it's good.

There are no issues.

Both wires can handle a load from one end to another.

There's not a pin fitment issue. OK.

So then it's got to be one of these modules

that does not seem to be able to pull this all the way down to zero.

OK. Now, in that case, you definitely want to check grounds

for the module in question because, you know, what's a module going to use

to pull a data line down to zero, a ground, right, right?

It's going to need that. So, OK, we'll check the grounds.

We did that. Well, now it's basically down to, OK, well,

which module is the problem?

So what I did was I separated the network on each end, right?

So I'll plug it from the BCM, look at the data line.

I unplugged it from the PCM and I looked at the data line.

Here's what I found on the PCM side,

like the PCM still plugged in and I have the BCM unplugged.

I get that same data packet where you see it's not pulling it down to ground.

It's like a distorted wave at the bottom.

And that's coming from the PCM for sure.

There's nothing else on this network.

I'm like, OK, well, the PCM is definitely having trouble

pulling this down to ground.

And so then I unplugged the engine control module

and then I plug in the body integrated unit

and I cycled the key and I look at it.

And there's actually no traffic on this one with the ECM unplugged.

I'm like, OK, well, maybe it needs maybe the ECM is the master,

maybe the ECM needs to talk.

And so I based based on what I saw,

I was convinced the waveform that I saw was the issue.

And I told him to get an engine control module.

I said, this is the one that looks like it's just having issues

not being able to pull these lines down to ground.

It was the same on both lines.

I'm going to say get one of these and again, check powers and grounds.

All that stuff is good.

He gets one.

We put it in as the same problem.

So we're actually waiting on a body integrated unit

right now to see if that takes care of it.

I don't know if there's something between the two of them

that needs to happen inside the body integrated unit

in order for that waveform to look OK.

Maybe the waveform I'm looking at is normal for that circuit.

I can't say I've ever scoped the immobilization

circuit on one of these seven legacies before.

I kind of doubt that's how it's supposed to look like.

But again, maybe there's something in the BCM

that is, you know, open, not connected,

and it's affecting the way that that looks. That's possible.

I made my best judgment call in the moment

and it ended up being wrong.

Luckily, those used ECMs on these things aren't very expensive.

So it's not a terribly expensive gas, but it is a waste of time.

And, you know, we don't like doing that.

But it's one of those scenarios where, you know, it's 50 50.

I'm going to use my best judgment here. OK.

So I'm still waiting for that one to get fixed.

I will report back and let you know what fixes that vehicle.

Next one, we're still waiting on getting fixed,

is a 2001 Jeep Grand Cherokee.

Like these are not new vehicles either.

And so you might be like, why are we talking about all these old vehicles?

Well, these sort of problems exist on modern vehicles, too.

I've got a 23 BMW where I don't even have enough information

to talk about on the podcast.

But that that's another one.

I've got data transfer between two modules that isn't adding up.

But again, I'm not going into that one

because I don't have enough info just yet to even talk about it.

So this is relevant, even though I'm telling you about an 01 Jeep Grand Cherokee

that uses a PCI bus, which is a single wire data transmission.

It pulls up instead of down, otherwise very similar to what you would see

on a Linn bus, but PCI bus has its own standards

as far as data transmission and voltages and all that stuff.

I think it goes up to about eight and a half, seven and a half, eight and a half

volts when it's pulled high for data transmission.

Well, this one's also immobilized.

This one also has codes in the PCM saying it can't talk to the skim module.

And there were other communication codes with this one as well.

There was also issues with the scan tools, talking to specific modules at times.

And we ended up calling the skim module.

So I was working with one of my employees.

They were going through it.

We really try to be as thorough as possible.

We got to it like, yeah, I think I think it's between

the skim and the PCM, that's where we got to it.

And we decided to call the skim module because I think at one point

it had set a code for the skim module.

It said like internal fault or something to that effect.

I apologize.

I wasn't at the cars working with my technician over the phone on this one.

But we decided, hey, let's let's put a skim module in this and see what happens.

We do the skim module and it was a bear to get this thing initialized

and set up for the vehicle because there was still a problem and didn't fix it.

And now we're going for a PCM, but we have a little bit more ammunition here

because, you know, we're getting more invested in this.

We're really looking at all the details like, OK, well, what can we prove to say?

Like, hey, this is this module is the issue.

And again, this is where this data is huge.

Had I seen this or had this knowledge or been able to compare it to this

ahead of time, maybe we could have picked it out.

But there was a waveform on the PCI bus when you'd unplug the PCM

and then plug the PCM back in and you can see the data corruption.

It is it is very subtle.

But if you look at it, it's there.

And what the PCM is doing on this PCI bus is it's outputting a single

pulse, if you will, right?

It's pulling up the network for just a brief period of time.

And that happens every five milliseconds as long as the PCM is plugged in.

Now, here's the problem.

It does that consistently as long as it's plugged in,

including when other modules are trying to talk on the bus.

You can see it interrupt these data packets every five milliseconds,

which is the reason we were having scandal communication issues.

The reason we were having programming issues for the skim.

And most likely, the reason that this thing is not starting

is that even though we can talk to the PCM, right?

Yes, there's glitches in the data.

If you watch the data stream, it'll come in and out, but we can talk to it.

It's not offline and it's setting code saying it can't talk to the skim module.

But the PCM appears to be polluting the PCI bus on this one.

So this one's not fixed either.

We got a PCM coming.

I think we're going to do that Monday or Tuesday to get that one fixed.

But these are the types of situations that I'm talking about

when there's module to module communication about some particular information.

And we've got to make a determination of like, who is at fault, right?

And we see this even just within valid data.

Maybe it's not a no-com, but it's like, I don't like the information

that that module is giving me.

Well, I don't like the information that module is giving me.

Like, who is at fault here, right?

You give a wrong module installed or wrong calibration installed

and you would get one of those.

You could have a configuration issue between two modules

and get that where it's like, hey, I'm not getting the right data from this module.

He is the problem.

But really it's that, you know, module B is the problem.

I don't like the data he's giving me, but it's because module A

didn't have the right configuration or wasn't the right part, right?

Another scenario where we see that module module communication being an issue.

So these are not easy problems to work through.

This can be very challenging, as I've described here,

kind of kicking our butts lately.

But again, why I wanted to talk about it and put it out there.

Maybe you're dealing with some similar issues.

So if you are, let me know.

I'd be curious to know your thoughts or experiences with stuff like this.

How do you get through it?

Do you just get to a point where it's a 50-50 and you got to make a call?

Or like, how deep do you go into it to try to make that determination?

It's tough, especially when you're doing it mobile.

Very difficult sometimes to make an informed decision on stuff like this.

But we're going to keep trying.

We're going to keep documenting, build up that database of information that we can use.

So anyways, hopefully you enjoyed that, found that interesting.

Maybe you learned something.

Maybe you can share something based off of that.

But with that all out of the way, let's get out there.

Start fixing the world on car at a time.

319: Module to Module Communication Faults

Nissan Titan

Porsche 911

Jeep Grand

About this episode

Original notes