No communication

mbrown1073 · Post by **mbrown1073** » Mon Dec 12, 2022 4:33 am

Looking for some opinions of this J1939 CAN capture. Also would like some help with using the scope in finding the root cause. This unit was in before, with the same issue. It was fixed but now is back. Let me know what you think.

Thank you

Matt B

Post by **ben.martins** » Mon Dec 12, 2022 11:35 am

Hi Matt,

I think the biggest thing here is you haven't quite got enough time on the buffer to capture the whole packet of data. Also I can see that the baud rate is not 500kBaud but actually 250kBaud. If you get the situation where nothing is being decoded look to use 2 time rulers either side of the smallest pulse in the message. The time between the two will also be displayed as a frequency in the ruler overview which can be related to the Baud rate.

By adjusting the decoder to 250kBaud we now get some decoding of the data present on the graph and in the table.

There are some easy options to use here Matt and the first would be to use the guided test for Serial Decoding. This will put more time on the screen, add in a math channel, as well as adjust the sample rate to ensure you can still decode. The only thing is the guided test is looking for CAN H on channel A and CAN L on channel B and you will need to adjust the Baud rate back down to 250 as the guided test assumes 500.

You're other option is to use the dedicated J1939 decoder as seen in the following link - viewtopic.php?p=102564#p102564. This will help you split the header up to focus on PGN and source address. I would then look to include another math channel of A+B or CAN H + CAN L as this can show you voltage fluctuations in the BUS idle voltage as well as during transmission.

The use of shorter test leads or even the x10 scope probes will also help with reduce the amount of ringing you see in the square wave of the bit. It's still fine to decode with but if you're looking for the extra detail it will help clean the signal as Steve shows here - viewtopic.php?p=97872#p97872

I hope this helps Matt and please let us know how you get on.

Kind regards

Ben

mbrown1073 · Post by **mbrown1073** » Tue Dec 13, 2022 2:48 am

Thank you for your replay and suggestions. These trucks have 2 VCAN's, VCAN-1(250K) and VCAN-2(500K). Pins F(high) and G(low) of the 9-pin DLC is VCAN-1 and VCAN-2 is pins C(high) and D(low). I took a capture of both networks; I have ECU source address for Kenworth modules. Was hoping that you could help me decode which module is causing the disruption with the networks. Here is the 250K capture, the 500K is too large to add.

Thank you for your time,

Matt Brown

mbrown1073 · Post by **mbrown1073** » Tue Dec 13, 2022 3:11 am

Was able to create a smaller file size for upload of the 500K network.

Post by **ben.martins** » Tue Dec 13, 2022 4:11 pm

Hi Matt,

If we take the 500K capture we can see there is something really not right with it. You can still afford to give yourself more time on the screen, maybe something around 20ms/div. You can also remove the trigger as that's not really going to help with an capture such as this.

Looking at the data then and decoding using the J1939 decoder rather than the standard CAN decoder. The reason being I'm interested in the source address section of the ID which is easier to see with the J1939 decoder as it split out.

One thing we notice very quickly is how much traffic is present and being transmitted. This would certainly cause a BUS overload and whilst not present itself to the operator the network is clearly being pushed. If we break down the message further we have errors surround the Acknowledgement bit and the bit stuffing. Joe Bell has done a fabulous video on YouTube for this which can be seen here - https://youtu.be/xIIiDKrx6sU. I would suggest watching the whole series if you are working with J1939.

As mentioned in Joe's video the acknowledgement is sent by all the ECU's to say the message has been received and accepted. We don't have this which the message is interrupted and the ECU in question forces the bit stuffing to be invalid causing the rest of the message to fail. The message is then attempted again till
it either goes through successfully or a higher priority message is attempted. These attempts can be seen in the above capture and subsequent buffers.

Whilst we cannot tell which ECU is sending the issue out we can at least say who isn't the problem by looking at the ECU's which are online and comparing those to how many ECU's you should have.

By using the isobus.net website I can see we have the engine (0), transmission (3), management ECU (39) ( this could be body control ECU) and the cab controller (49). Terminology could be different of course but a totally of 4 ECU's which are attempting to put messages on the bus.

The wiring diagram or a topology of the network will be your friend here. If you don't have the topology then I would recommend drawing out where the ECU's should be in the network. If this is the total number on this bus then I would look to remove the ECU's which don't contain a termination resistor to see how the bus changes. Not easy I know but start with the most accessible. You should see that once the problem ECU is removed the bus should calm down and the data will start to be acknowledged correctly.

I hope this helps but please let me know if you need any further information.

Kind regards

Ben

mbrown1073 · Post by **mbrown1073** » Thu Dec 15, 2022 12:01 am

The module that wasn't communicating was the Bendix brake module. After disconnecting the module from the network, communication resumed, and I was able to communicate with the other modules. Thank you for help with this. I have learned a lot and with the information that I have received.

Thank you,

Matt Brown

Post by **ben.martins** » Thu Dec 15, 2022 12:05 pm

Hi Matt,

Great news and thanks for letting us know. This would also tie in with the fact there was no source address for a brake system, 11.

Nice to see the acknowledgement back to what it should look like and the bit stuffing being correct so the message is confirmed OK. If you get the module replaced hopefully you'll have a chance to capture some data with the new unit to see if that brake module source address appears on the network. I do appreciate though that someone will just want the truck out of the workshop and back on the road!

We're here to help and hopefully the information can be used going forward to aid with future diagnosis.

Kind regards

Ben

campbell.kwtech · Post by **campbell.kwtech** » Sat Dec 17, 2022 4:13 pm

Hello Matt, I just saw your post and I know you've already resolved the problem.

Did you read my post below titled: PACCAR KW, PB T/S VCAN, VCAN1, VCAN2?
topic22956.html

And my post for PACCAR Kenworth Dealerships?
topic22269.html

I have 2 presets for (VCAN / VCAN1); and one for (VCAN2) on the above post. Below are links to the downloads.

VCAN/VCAN1 Preset setting for 250 kb CAN:
download/file.php?id=33039

VCAN2 Preset setting for 500 kb CAN:
download/file.php?id=33040

or download these presets below; the above links are the same as these attachments below. They have 100 ms Time Divisions.

Hopefully this information is helpful. Feel free to private message me,

David

PicoScopes
& kits

For vehicle manufacturers

EV kits and
accessories

Noise, Vibration and Balancing

Milliohm tester

Pressure sensors

Current clamps

Breakout
leads/boxes

Accessories

Automotive Forum