PicoScope 7 Automotive
Available for Windows, Mac, and Linux, the next evolution of our diagnostic scope software is now available.
J1939 CAN bus Loading
J1939 CAN bus Loading
Hello,
I am trying to measure the CANbus loading of a J1939 CAN network with a baud rate of 250kbs, I have first noticed when I use the serial decoding tool the figures are always in red. I have also noticed the CAN trace I have uploaded the messaging on the right hand side looks to move out of line from the expected parameters. Has anyone seen this before, any advise would be appreciated.
I am trying to measure the CANbus loading of a J1939 CAN network with a baud rate of 250kbs, I have first noticed when I use the serial decoding tool the figures are always in red. I have also noticed the CAN trace I have uploaded the messaging on the right hand side looks to move out of line from the expected parameters. Has anyone seen this before, any advise would be appreciated.
Re: J1939 CAN bus Loading
Hi, it is due to short time capture per one screen. The frames will be red in decoding table simply because part of the frame is missing (continue beyond the screen)
Set the time to at least 50ms/division and sample rate 5Ms/second. Then use zoom to see details.
If you want, I will post here captured example that you can use.
Regards,
Roman
Set the time to at least 50ms/division and sample rate 5Ms/second. Then use zoom to see details.
If you want, I will post here captured example that you can use.
Regards,
Roman
Re: J1939 CAN bus Loading
Evening,
Thank you for your reply @rfmotors1, I will give this a try next week once am back in the workshop. Makes perfect sense now.
Thank You.
Thank you for your reply @rfmotors1, I will give this a try next week once am back in the workshop. Makes perfect sense now.
Thank You.
-
ben.martins
- Pico Staff Member
- Posts: 545
- Joined: Tue May 16, 2017 1:02 pm
Re: J1939 CAN bus Loading
Hello,
Thanks Roman for the advice.
To add further if you have the latest stable or early access version of PicoScope 7 Automotive take a look at the new heavy duty and off highway guided tests. There is a built in J1939 serial decoding test which will preload the settings required to make the capture.
There are further resources for J1939 CAN bus analysis which I will post links tomorrow.
Kind regards
Ben
Thanks Roman for the advice.
To add further if you have the latest stable or early access version of PicoScope 7 Automotive take a look at the new heavy duty and off highway guided tests. There is a built in J1939 serial decoding test which will preload the settings required to make the capture.
There are further resources for J1939 CAN bus analysis which I will post links tomorrow.
Kind regards
Ben
Re: J1939 CAN bus Loading
Hi gbgunn-st,
I have attached some examples of CAN 500 capture with decoding, it is not J1939 as I do not come across commercial vehicles, however the scoping and decoding is not much different.
(This was captured with x10 300Mhz probes, but ordinary leads will be just fine)
I think it is good example to see and compare the good and bad one.
First waveform is captured at the state of vehicle fault (no communication to instrument cluster was the DTC present in most other nodes) It is VW car, between Gateway and instrument cluster is a 500Mhz CAN, no other node is connected to this bus.
Pico is backpinned to this bus.
You can see there is only one frame ID 727 which does not have acknowledgement bit at the end (ACK 1), which means the other CM did not confirm receiving the frame.
Second waveform is captured when all works well (It was intermittent problem), we can see the ID 727 and many other IDs in the decoding table. Notice the voltage range of the ID 727 and other IDs, you can visually see there are two voltage levels as each node has own characteristic, noise, voltage range etc. The frames have acknowledgement bit OK, as other node confirm receiving the frame ACK 0. Zero means acknowledgement OK. The question was what CM, Gateway or Instrument cluster ID was OFF the bus when the car had problem?
Simple simulation by pulling out fuse for gateway (easier to reach) has proven all ID has disappeared except ID 727, hence it has to belong to Instrument cluster.
So, the advantage of using scope and decoding in this simple example is not to replacing instrument cluster where all the DTC were pointing but gateway which is intermittently faulty.
I hope it helps with scope setting and also brings some ideas for bus troubleshooting.
Hi Ben,
Thank you for helping us with the J1939 and I must admit that I need to educate myself in the J1939 as well.
In the meanwhile, I share some info that may inspire others as well.
Regards,
Roman
I have attached some examples of CAN 500 capture with decoding, it is not J1939 as I do not come across commercial vehicles, however the scoping and decoding is not much different.
(This was captured with x10 300Mhz probes, but ordinary leads will be just fine)
I think it is good example to see and compare the good and bad one.
First waveform is captured at the state of vehicle fault (no communication to instrument cluster was the DTC present in most other nodes) It is VW car, between Gateway and instrument cluster is a 500Mhz CAN, no other node is connected to this bus.
You can see there is only one frame ID 727 which does not have acknowledgement bit at the end (ACK 1), which means the other CM did not confirm receiving the frame.
Second waveform is captured when all works well (It was intermittent problem), we can see the ID 727 and many other IDs in the decoding table. Notice the voltage range of the ID 727 and other IDs, you can visually see there are two voltage levels as each node has own characteristic, noise, voltage range etc. The frames have acknowledgement bit OK, as other node confirm receiving the frame ACK 0. Zero means acknowledgement OK. The question was what CM, Gateway or Instrument cluster ID was OFF the bus when the car had problem?
Simple simulation by pulling out fuse for gateway (easier to reach) has proven all ID has disappeared except ID 727, hence it has to belong to Instrument cluster.
So, the advantage of using scope and decoding in this simple example is not to replacing instrument cluster where all the DTC were pointing but gateway which is intermittently faulty.
I hope it helps with scope setting and also brings some ideas for bus troubleshooting.
Hi Ben,
Thank you for helping us with the J1939 and I must admit that I need to educate myself in the J1939 as well.
In the meanwhile, I share some info that may inspire others as well.
Regards,
Roman
Last edited by Rfmotors1 on Wed Dec 06, 2023 10:05 am, edited 1 time in total.
-
Steve Smith
- Pico Staff Member
- Posts: 1594
- Joined: Sun Aug 25, 2013 7:22 am
Re: J1939 CAN bus Loading
Hello and thank you for the posts
Just following on from the original post “trying to measure the CAN bus loading of a J1939 CAN network with a baud rate of 250kbs”
The following link may help looking at 11-bit CAN bus loading viewtopic.php?p=101204#p101204
Taking this onto to 29-bit CAN for J1939, I am going on the assumption that if a typical 11-bit CAN packet consists of 125 bits, then a typical 29 bit CAN packet equates to:
125 – 11 (11 bit) + 29 (29 bit) = 143 bits
Using the Guided Test from Ben’s J1939 decoder:
Guided Tests > Heavy-Duty/Off-Highway > J1939 serial decoding I have modified the decoder settings to decode the data between the time rulers at 0.2 & 1.2 seconds (1 second delta)
Below we can see 810 packets of CAN data in our 1 second decoded interval
Given a typical 29-bit CAN packet contains approx. 143 bits and our baud rate is 250 kbs
(1/250,000 bits per second = 0.000004 seconds (4 µs) for a baud rate of 250 kbs)
We now know each bit is 4 µs long, therefore 4 µs/bit x 143 = 572 µs per packet
The time taken to transmit 1 x packet on the CAN bus = approx. 572 µs
Based on these values, how many packets can we transmit in 1 second at a baud rate of 250 kbs?
1/0.000572 seconds (transfer rate of 1 packet in seconds) = 1,748 packets per second
1,748 packets per second = 100 % bus loading
This is the maximum number of packets transferable on the CAN bus
Returning to our decode table, we have 810 packets transmitted in 1 second.
To determine the percentage of bus loading at 810 packets per second:
810/1,748 = 0.463 x 100 = 46.3 % bus load.
Once again, the above is an approximation returning an indication of Bus loading
I hope this helps, take care……Steve
Just following on from the original post “trying to measure the CAN bus loading of a J1939 CAN network with a baud rate of 250kbs”
The following link may help looking at 11-bit CAN bus loading viewtopic.php?p=101204#p101204
Taking this onto to 29-bit CAN for J1939, I am going on the assumption that if a typical 11-bit CAN packet consists of 125 bits, then a typical 29 bit CAN packet equates to:
125 – 11 (11 bit) + 29 (29 bit) = 143 bits
Using the Guided Test from Ben’s J1939 decoder:
Guided Tests > Heavy-Duty/Off-Highway > J1939 serial decoding I have modified the decoder settings to decode the data between the time rulers at 0.2 & 1.2 seconds (1 second delta)
Below we can see 810 packets of CAN data in our 1 second decoded interval
- 1
(1/250,000 bits per second = 0.000004 seconds (4 µs) for a baud rate of 250 kbs)
We now know each bit is 4 µs long, therefore 4 µs/bit x 143 = 572 µs per packet
The time taken to transmit 1 x packet on the CAN bus = approx. 572 µs
Based on these values, how many packets can we transmit in 1 second at a baud rate of 250 kbs?
1/0.000572 seconds (transfer rate of 1 packet in seconds) = 1,748 packets per second
1,748 packets per second = 100 % bus loading
This is the maximum number of packets transferable on the CAN bus
Returning to our decode table, we have 810 packets transmitted in 1 second.
To determine the percentage of bus loading at 810 packets per second:
810/1,748 = 0.463 x 100 = 46.3 % bus load.
Once again, the above is an approximation returning an indication of Bus loading
I hope this helps, take care……Steve
-
ben.martins
- Pico Staff Member
- Posts: 545
- Joined: Tue May 16, 2017 1:02 pm
Re: J1939 CAN bus Loading
Hi all,
Firstly thank you Steve for posting the additional information on BUS loading calculations. Shame there isn't a maths channel for it!
Going back to original image we need to see how the decoder is being set up. I think the reasons for the decoder not working is it's not setup correctly. Typically we usually have CAN H on channel A and CAN L on channel B. This will then allow the built in math channel A-B to show the differential. Where CAN L is on channel A and CAN L is on channel B, we now have the inverted waveform.
Looking at the decoder we can see that it is setup to decoder on the math channel A-B and so is trying to decode on an inverted signal. Can you try creating a new math channel but B-A. This will then show the correct differential signal. Click the decoder and then change the source to B-A and setup accordingly.
The following link takes you to the section on our YouTube channel which looks at J1939 decoding - https://youtu.be/AJT1hXxhW54?si=cZEUocIjOsMC8rk0&t=748. Please also take a look at the J1939 guided test in the latest stable version of PicoScope 7 Automotive.
Further resources for J1939 can be seen below -
A-Z J1939 entry - https://www.picoauto.com/library/picosc ... l-decoding
J1939 training - https://www.picoauto.com/library/training/j1939-decoder
Loss of communication case study - https://www.picoauto.com/library/case-s ... munication
Loss of communication forum post - topic23073.html
I hope this helps
Kind regards
Ben
Firstly thank you Steve for posting the additional information on BUS loading calculations. Shame there isn't a maths channel for it!
Going back to original image we need to see how the decoder is being set up. I think the reasons for the decoder not working is it's not setup correctly. Typically we usually have CAN H on channel A and CAN L on channel B. This will then allow the built in math channel A-B to show the differential. Where CAN L is on channel A and CAN L is on channel B, we now have the inverted waveform.
Looking at the decoder we can see that it is setup to decoder on the math channel A-B and so is trying to decode on an inverted signal. Can you try creating a new math channel but B-A. This will then show the correct differential signal. Click the decoder and then change the source to B-A and setup accordingly.
The following link takes you to the section on our YouTube channel which looks at J1939 decoding - https://youtu.be/AJT1hXxhW54?si=cZEUocIjOsMC8rk0&t=748. Please also take a look at the J1939 guided test in the latest stable version of PicoScope 7 Automotive.
Further resources for J1939 can be seen below -
A-Z J1939 entry - https://www.picoauto.com/library/picosc ... l-decoding
J1939 training - https://www.picoauto.com/library/training/j1939-decoder
Loss of communication case study - https://www.picoauto.com/library/case-s ... munication
Loss of communication forum post - topic23073.html
I hope this helps
Kind regards
Ben