An help for study and decode the line CAN bus.

Ask for and share advice on using the PicoScope kit to fix vehicles here.

An help for study and decode the line CAN bus.

Postby tode » Tue Apr 25, 2017 8:56 pm

Hi men i start this topic for ask you an help for better understand the decoding and diagnose the signals of the CAN bus.
First question:
Someone knows what are those bits not decoded by pico software?
EX:
decode can bus.jpg
Yellow are bits decoding by software red is bits undecoding.


Second question:
Does anyone know the method to use decoded IDs from the software?
The Can protocol does not use addresses to identify a receiver, but should only give a "name" to the message. I think that I could understand who sends the message might be useful to figure out who generates a mistake.

EX:
decode ID.jpg
Example of IDs.


Regards.
tode
OneWave
OneWave
 
Posts: 48
Joined: Fri Jun 20, 2014 8:59 pm

Re: An help for study and decode the line CAN bus.

Postby steevegt » Tue Apr 25, 2017 10:53 pm

tode wrote:Hi men i start this topic for ask you an help for better understand the decoding and diagnose the signals of the CAN bus.
First question:
Someone knows what are those bits not decoded by pico software?
...


I guess that could be from a number of things, like noise...
Sometimes changing the threshold values in the CAN decoding settings helps.

tode wrote:Second question:
Does anyone know the method to use decoded IDs from the software?
The Can protocol does not use addresses to identify a receiver, but should only give a "name" to the message. I think that I could understand who sends the message might be useful to figure out who generates a mistake.


If I understand your question right, you are correct. The ID's identify only the nature of the message, and that doesn't say anything of the sender or the possible receivers.

The receivers, as far as I know, are impossible to isolate. Anyone connected to the bus could be a valid receiver.

The sender of the messages, is something that you can isolate easily.
I use for that a low current clamp (AEMC K110) clamped around one of the bus wires, at the sender that we want to test. If that module is the sender, there will be some current flowing in the bus wire, at the same time the messages originating from that module are written.
The current will be very low, that is why you need the low current clamp to see it.
steevegt
TwoWaves
TwoWaves
 
Posts: 66
Joined: Wed May 13, 2015 12:05 am

Re: An help for study and decode the line CAN bus.

Postby tode » Tue Apr 25, 2017 11:48 pm

Many thanks, very interesting the use of a very sensitive amperometric clamp near the possible transmitter. :D
tode
OneWave
OneWave
 
Posts: 48
Joined: Fri Jun 20, 2014 8:59 pm

Re: An help for study and decode the line CAN bus.

Postby STC » Wed Apr 26, 2017 12:05 am

Tode

Someone knows what are those bits not decoded by pico software?


those bits you can decode yourself, it will be 0's & 1's. That binary you can convert to HEX.

The ID's identify only the nature of the message, and that doesn't say anything of the sender or the possible receivers.

Once you have decoded the packet you will know where it came from. For example Wheel Speeds will be from ABS if the speed sensors are wired into that module.
There is no Single "Receivers" in a Can Network. Each message is a transmission onto the network and every node will see it.

Does anyone know the method to use decoded IDs from the software?

The manufacturer wont give you that information, so you would have to spend months working it out. For diagnosis purposes you do not need that information - indeed it would be helpful.

The Can protocol does not use addresses to identify a receiver, but should only give a "name" to the message. I think that I could understand who sends the message might be useful to figure out who generates a mistake.


Again you are asking for something that is very difficult to achieve, the effort involved will be massive and the reward tiny by comparison.
I see many technicians being daunted by CAN and overcomplicating the diagnosis of it. I found that the trick was to get an understanding of it (training courses) and it is generally an easy diagnosis and fix.
Can is robust and the majority of faults are related to wiring and connectors or water damaged nodes. possible but rare for a control unit to just go down for fun.

Steeve

I use for that a low current clamp (AEMC K110) clamped around one of the bus wires, at the sender that we want to test. If that module is the sender, there will be some current flowing in the bus wire, at the same time the messages originating from that module are written.


How would you know if that activity highlighted by your Amp Clamp is a message being received or transmitted? I am trying to think about both "Ring" and "Tree" Topology.

If that module is the sender, there will be some current flowing in the bus wire

There will be current flowing if that module is the "Sender" or "Receiver". In fact there will be equal current flow in the entire circuit, even at nodes on the network that choose to ignore that message at that time.

You would have to be looking at Current Direction with the Clamp ? Have I got that half right ?

Again, I can see how that would use up time and resource but I'm not so sure how that would help you fix a car with a Can fault.
User avatar
STC
Banned
 
Posts: 790
Joined: Sun Sep 13, 2015 4:10 am

Re: An help for study and decode the line CAN bus.

Postby steevegt » Wed Apr 26, 2017 2:36 am

STC wrote:those bits you can decode yourself, it will be 0's & 1's. That binary you can convert to HEX.


You can, but not a very pleasant thing to do :mrgreen:
At least, you need to be aware of the bit stuffing before converting to binary and then to HEX. Maybe there are more details to take into account, that I don't know or I'm not remembering, before converting the message.

STC wrote:Once you have decoded the packet you will know where it came from. For example Wheel Speeds will be from ABS if the speed sensors are wired into that module.


I think that it is more practical the other way around.
First I want my wheel speed value, and then I will try to find the packet that contains it. For this, it will be a great help if I know what CAN messages are coming from the ABS module.

STC wrote:How would you know if that activity highlighted by your Amp Clamp is a message being received or transmitted?

There will be current flowing if that module is the "Sender" or "Receiver". In fact there will be equal current flow in the entire circuit, even at nodes on the network that choose to ignore that message at that time.

You would have to be looking at Current Direction with the Clamp ? Have I got that half right ?


I guess it depends on the way the bus is connected.
If you have a BUS, 2 wire, CANH and CANL, with only 2 terminating nodes, you will have current flow, on each of that pair of wires, every time a message is sended. The current direction will indicate the node that is lowering, or increasing the wire voltage. The current direction also depends if you are measuring the CANH or CANL, and also which node is producing the "bias voltage" on the wire.

If you have a BUS, 2 wires, CANH and CANL, with multiple nodes, T type connected into the BUS, you will have current flow on the stub wires that goes to node only if the node is "writing" on the bus, or every time someone else is writing if the node is the "bias voltage" producer.

I've only tried the above with a scan tool, as the node to identify. It shouldn't be different on other type of CAN node, right?
The waveform below is from CANL signal, and I'm monitoring the current on the wire that goes to a scan tool. In this car there is no gateway involved, so a lot of messages there that are not for diagnosing purposes.

STC wrote:Again, I can see how that would use up time and resource but I'm not so sure how that would help you fix a car with a Can fault.


I can't share an experience using this technique for diagnostic purpose in a car, but I have managed to identify the right component at fault, in a LIN BUS network, on my mother's faulty Siemens induction hob :D
In LIN you have the master that is always making the questions, and after the master speaks the node that is supposed to answer starts writing.
This Siemens Hob had an intermittent communication fault that bricked the thing. The network was on all the time, so no short or open, the master was making the questions, but when at fault, no answer. So all I needed to do was to identify, when it was working, the node that was answering to that request.
I was able to identify that using the current flow of the LIN wire.
Attachments
can_current.PNG
CANL signal and current flow
steevegt
TwoWaves
TwoWaves
 
Posts: 66
Joined: Wed May 13, 2015 12:05 am

Re: An help for study and decode the line CAN bus.

Postby tode » Mon May 01, 2017 9:47 pm

I think that knowing what the ECUs are exchanging is not important, the important thing is that the message is correct and not damaged. In the first post I was referring to that set of bits not recognized by Pico as a message of the CAN protocol and then not decoded, my curiosity was addressed to it, perhaps a subordinate protocol required by sync or otherwise.

I tried to pick up the current signal on a high-speed CAN line (500KBits), so with 60 ohm resistors present and as indicated by you for each transmitted packet there is current signal so not useful to understand who transmitted.

current 1.jpg

current zoom.jpg
Zoom


I do not have an amperometric clamp suitable for micro currents so I opened the circuit and inserted a 20 winding cable to amplify the current measurement 20 times.

amp clump.jpg


Greetings
tode
OneWave
OneWave
 
Posts: 48
Joined: Fri Jun 20, 2014 8:59 pm

Re: An help for study and decode the line CAN bus.

Postby Mark Dalton » Mon May 15, 2017 5:48 am

This is more a general piece of advice than an answer to the particular question asked in this thread.
But if you are dreaming of diagnosing an issue by decoding BUS Messages, I would suggest that you read chapters 2, 4 & 5 of the Car Hackers Handbook (http://opengarages.org/handbook/ebook/) and watch DEF CON 23 - Charlie Miller & Chris Valasek - Remote Exploitation of an Unaltered Passenger Vehicle (https://youtu.be/OobLb1McxnI). After that you should have a better idea of the mountain you are about to climb.
In all the articles I've read and videos I've watched I have never, never seen anyone hack a CAN Bus with the Pico Scope software
User avatar
Mark Dalton
TwoWaves
TwoWaves
 
Posts: 81
Joined: Mon Dec 01, 2014 11:35 pm
Location: Melbourne


Return to Diagnostic discussion

Who is online

Users browsing this forum: No registered users and 0 guests