PicoScope 7 Automotive
Available for Windows, Mac, and Linux, the next evolution of our diagnostic scope software is now available.
CAN bus
CAN bus
hi there i am wondering is there something wrong with the signals in the attached files. Its from one vehicle first time with key on and second with key off.
- Attachments
-
- Renault_Kangoo_Petrol_20181213-0002.psdata
- (29.8 MiB) Downloaded 447 times
-
- Renault_Kangoo_Petrol_20181213-0001.psdata
- (25.83 MiB) Downloaded 398 times
-
Technician
- TwoWaves
- Posts: 707
- Joined: Thu Apr 24, 2014 8:32 pm
Re: CAN bus
Somebody more experienced than I may arrive soon, but to my viewing the CAN H and L look OK, OK there is a little noise present but is there at fault on a component system?
-
ben.martins
- Pico Staff Member
- Posts: 543
- Joined: Tue May 16, 2017 1:02 pm
Re: CAN bus
Hello MartinA,
Thank you for your post and there a number of things we can do to help understand your capture namely with maths channels.
Before looking into this further, does the vehicle have a specific fault? Or is the vehicle running as normal? Where did you access the CAN network to make the capture, eg at the OBD connector? Finally, where did you place the ground for your test leads?
The first thing that stands out from your 0001 capture is when the data is being transmitted the signal appears to jump up on channel B which in this instance I believe to be CAN H. What we notice is that the voltage is pulled from 1.8V up to 3.5V which for CAN is a little odd. Typically CAN will have an idle voltage of 2.5V, idle being where no data is being transmitted. When data begins to transmit CAN H is pulled up to 3.5V and CAN L pulled down to 1.5V. There is further reading on CAN in the following topics : -
topic12871.html#p53581
topic14691-10.html#p89151
You'll notice throughout these topics we talk a lot about Math channels. These can help us to reveal more about the signals by applying certain formulae to the signals we have captured. As CAN is a differential signal, whatever happens in one should happen in the other. This provides CAN with it's fault tolerant capabilities as the ECU can subtract CAN H from CAN L and be left with the physical layer. Here we can apply the serial decode tool within PicoScope with greater success as any interference is cancelled out.
Also with Math we can add the two channels together. The idle voltage being 2.5V for both CAN H and CAN L when added together gives us 5V. When data is active then the voltage moves between 2.5V on both to either 3.5V on H or 1.5V on L, 3.5 + 1.5 is also equal to 5V. This should give us a fairly fixed line throughout the entire capture meaning we can quickly see if there is any major problems with the network without having to worry about the structure or the data within the packet. I have applied both these math channels to your 0001 file along with the decoded data for CAN H - CAN L
Quickly we can see that the CAN H + CAN L is not a give us the expected flat 5V line and it jumps around from 3.6V to around 5V when data is active. What you will also see is that despite the odd idle voltage the data decodes perfectly fine which is why I ask if you have a fault.
I have seen this occur before where there is an ECU with a fault that causes the CAN idle voltage to be pulled down from it's idle voltage. In that instance a component carrying a voltage was providing a dead short back to ground through the ECU. Removing this ECU in the first place saw the idle voltage return to the expected 5V and after further removal of components to the ECU we did find the fault.
Ideally if you have ECU's reporting one is missing, then I would be taking this 'missing' ECU out of the network to start with and seeing if the idle voltage returns to the expected 2.5V. If it does return ensure you continue with your diagnosing as with the vehicle I saw, fitting a new ECU would not have cured the fault. If possible try to remove the inputs and outputs from the ECU leaving powers, grounds and CAN wiring. This way you will have a better idea if it is the ECU or a component.
I hope this helps and there is further reading with a case study and CAN problems and using the maths channels to help isolate the problem.
https://www.picoauto.com/library/case-s ... ions-fault
Let us know how you get on with this and if you need further assistance please get in touch.
Kind regards
Ben
Thank you for your post and there a number of things we can do to help understand your capture namely with maths channels.
Before looking into this further, does the vehicle have a specific fault? Or is the vehicle running as normal? Where did you access the CAN network to make the capture, eg at the OBD connector? Finally, where did you place the ground for your test leads?
The first thing that stands out from your 0001 capture is when the data is being transmitted the signal appears to jump up on channel B which in this instance I believe to be CAN H. What we notice is that the voltage is pulled from 1.8V up to 3.5V which for CAN is a little odd. Typically CAN will have an idle voltage of 2.5V, idle being where no data is being transmitted. When data begins to transmit CAN H is pulled up to 3.5V and CAN L pulled down to 1.5V. There is further reading on CAN in the following topics : -
topic12871.html#p53581
topic14691-10.html#p89151
You'll notice throughout these topics we talk a lot about Math channels. These can help us to reveal more about the signals by applying certain formulae to the signals we have captured. As CAN is a differential signal, whatever happens in one should happen in the other. This provides CAN with it's fault tolerant capabilities as the ECU can subtract CAN H from CAN L and be left with the physical layer. Here we can apply the serial decode tool within PicoScope with greater success as any interference is cancelled out.
Also with Math we can add the two channels together. The idle voltage being 2.5V for both CAN H and CAN L when added together gives us 5V. When data is active then the voltage moves between 2.5V on both to either 3.5V on H or 1.5V on L, 3.5 + 1.5 is also equal to 5V. This should give us a fairly fixed line throughout the entire capture meaning we can quickly see if there is any major problems with the network without having to worry about the structure or the data within the packet. I have applied both these math channels to your 0001 file along with the decoded data for CAN H - CAN L
I have seen this occur before where there is an ECU with a fault that causes the CAN idle voltage to be pulled down from it's idle voltage. In that instance a component carrying a voltage was providing a dead short back to ground through the ECU. Removing this ECU in the first place saw the idle voltage return to the expected 5V and after further removal of components to the ECU we did find the fault.
Ideally if you have ECU's reporting one is missing, then I would be taking this 'missing' ECU out of the network to start with and seeing if the idle voltage returns to the expected 2.5V. If it does return ensure you continue with your diagnosing as with the vehicle I saw, fitting a new ECU would not have cured the fault. If possible try to remove the inputs and outputs from the ECU leaving powers, grounds and CAN wiring. This way you will have a better idea if it is the ECU or a component.
I hope this helps and there is further reading with a case study and CAN problems and using the maths channels to help isolate the problem.
https://www.picoauto.com/library/case-s ... ions-fault
Let us know how you get on with this and if you need further assistance please get in touch.
Kind regards
Ben
- Attachments
-
- Renault_Kangoo_Petrol_20181213-0001 with Math and Decode.psdata
- (25.92 MiB) Downloaded 372 times