Help to decode CAN data pls

[Chriss]

Hi!
I'm working on a CAN bus logger project.
Actually it is working...

I need some help about to decode one CAN message pls.

Through the car CAN network i saw a data which is in this format:
200 01 0C

I assume it is a message whit the msg ID of 200 which is searching for the ECU mode 01 and the data (command) is 0C.

If I'm right, it could be some sort of wake up command?

Or I'm wrong?

I have no clue...


Thanks in advance.

[Leo Bodnar]

There is no "format" for CAN bus messages.  They can mean absolutely anything, just like random byte from a random RS232 wire.

From your message it is not even clear if 01 is the DLC or part of the data packet.

Leo

[Chriss]

I know there is nothing like "format" but there is a PID, a request and or a result maybe.

Actually, to request a parameter from a service on a car CAN bus I must to
enter the service lets say where are the live data and a PID to get the data for lets say a
coolant temp.

which could be service 01 PID 05 and the result would be read out and show in the putty or whatever..

So I will got something like 01 05 XX where xx is the coolant temp in hex format.

I assume this 200 01 0C could also be something that...

This is coming from the CAN bus from an obd diag tool when I try to connect to an ecu.
The logger shows this data.

I tried the logger on the car and it works nice, I can recognize some of data infos, key press etc.

Thanks.

[Jeroen3]

Did you research CAN before asking this question?

[ale500]

As you may know CAN is a transport protocol. The packet itself has a payload area, a length and an ID. The ECUs talk to each other and send themselves packets with specific coding. Each bit means something and if you do not know how the fields in a specific packet are lay out you are out of luck. This protocol is agreed between both parties and there are mostly no standards, afaik.
You must also understand that the signals, as they are called are most of the time sent with some kind of compression, say each bit is 4 °C or each bit is 0.25 °C and some offset is used too. That is done because messages are small and have to arrive at a certain time. Maybe some knob, switch is sent with 1 bit for on/off, but something like temperature ? it is probably like 8 bits with offset, say 0 means -40 °C and the max value is like 140 or 160, who knows.
There is a bit of information but mostly is kept kind of secret. If you do not have the format of the packets you are mostly guessing.
Try to find some information for your specific model, seeing the bits is something but without knowing their meaning... not that useful.

[cat87]

Ok, so  forst thing's first: What is it exactly that yo are trying to do here? Are you just trying to see some PID data or are you actually planning to snoop in on an actual CAN bus? Because these two are different things.

The PIDs have a somewhat vague format and are not actually CAN data per se. These are somewhat more subject to the manufacturer's whyms. Some OEMs tend to do their own stiff like PID address and encoding. If this is the case, it's kind of simple, because most of the info is out there, just search for PIDs for you specific car model.

Actual CAN data has a very standardized format. In cars at least. There is also the industrial  kind, that sometmes may or may not respect the standards.

For cars, the CAN message usually is comprised of a Start of Frame, an identifier which is 11 or 21 bytes (11 bits for most stuff is the norm), the DLC (Data length), and the Address (to whom you are broadcasting to) then the actual data itself.  After this, there's some CRC and an ACK signal.

ECUs use this to talk to each other and also to whoever is connected to the diagnose port.

The protocol itself also uses bit stuffing; more than 4 bits that are the same and a stuffing bit is introduced so that the ECUs' clocks can sync back up with the main  ECU in the car. So if sometimes you see some packets having more transitions, it might be due to this.

A CAN network in a car also uses some form of flow control for the communications. I.e. any information that has to  be put in  more than 8 bytes will have to follow the flow control protocol. You can spot this whenever you see conseccutive messages starting with "21", "22", "23", up to 29... I think

I myself am not that familiar with PIDs so I can't really help out with decoding the data you posted, but the assumption you made is somewhat OK, though there must be some more to that message than just those bytes.

[JPortici]

How do you know it's working if you can't interpret the data?

do you have a good/reliable can interface to use to check against what you see?

for example, at work i use a kvaser interface and depending on what i have to do either canking (their software) or busmaster (a free alternative software compatible with a number of interfaces. very useful)

you should really tell us what you want to accomplish so we can tell you what document you need to study.

As other said CAN is a transport protocol.. the protocols built on it are a whole different thing.
OBD for example uses can but it has absolutely nothing to do with the rest of the CAN network inside your car.

[AndyC_772]

CAN data packets all carry a CRC, and typically all the serialisation, bit stuffing, collision detection and so on is done by dedicated hardware in the CPU. This makes it quite easy to tell when a packet has been received correctly; either you get a signal from the CAN decoder that a valid packet was received, or you don't.

There are defined protocols that may be used over CAN, such as CANopen. If your device uses one of these, then you might be able to determine the likely meaning of a given message.

It probably doesn't, though. In that case, "200 01 0C" means nothing more than "200 01 0C", until you know the protocol.

[max_torque]

CAN, as mentioned is the communication network, in all it's layers: http://www.warwickcontrol.com/how-is-can-architecture-layered/

PIDs (Parameter IDs)  are the On Board Diagnostic (OBD) packets of information exchanged between a diagnostic tool (tester) and the control modules on that CAN bus.  These packets are defined by the relevant OBD standards (E-OBD for Europe and OBDII for the USA).  Standardised PIDS are specified for the basic parameters that those OBD standards mandate to be accessible on the Diagnostic Interface (the J1962 socket). Manufacturers then have a raft of hundreds (often thousands) of non-standard PIDs for which they are responsible, which are used for things like dealer diagnostics and reflashing or EOL coding etc.

Google these terms for plenty more info and explanation!

[Chriss]

You are all really brilliant!
Thanks for this nice and kind helping.

So, in my first post I was in doubt how to define my question but not to go too far
from the mayor thinks of my problem.

I studied the CAN protocol many times, and read lot of stuff on the net,
but talking with real peoples are much better for me.

I know does my hardware and software are working because I used the "OBD-II PIDs"
data from Wikipedia https://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_1_PID_00
and I also made the formula calculation of the returned data from the ecu and it was ok.

I use the ELM327 and HyperTerminal to sniff the CAN network for now.
The main reason is for this because I have some flashing tools for ECU's which are make some strange
thinks sometime.
I also repair them too.
So, I got an idea how to test the lets say CAN communication after repairing the flashing tool is,
to hook up to the CAN line a CAN sniffer.
Send some sort of command from the flashing software which is the original software from the flashing tool on the pc.
Let's say some sort of ECU identification.
The sniffer should get the data what was sent from the flashing tool.
Actually, nobody would answer to the request from the flashing tool but some sort of info is captured.
The flashing tool will show up an error like "No ecu" etc...
That's nice and cool.
But, when I started my project to see how stuff is working, I realized does some sort of info is
really captured, that is that 200 01 0C.
That was transmitted on the CAN wire from the flashing tool for one model of car.
When I selected another model of car I got another data what was totally different.
I tried lot of cars and lot of them was different but some of data was the same on different
cars I assume because the ecu was the same, even if the car model was different.

So I got a sort of patterns.

Than I changed to another flashing tool and started to sniff the packets with the exactly same
car models and ecu's like before.
I got the same patterns.
That makes sens.
Than I come to the idea maybe this type of data will show me some sort of info like "ecu wake up" signal or something like that.

I wish to develop a small tool for me what I can use to check if the signals which are traveling through the CAN network are
really CAN signals or just some sort of fake signals.

For that I use my oscilloscope, and that is nice and good for me, but I wish to make some steps more and deeper in the world of CAN.

If it is possible somehow to know if a device like a ecu flasher tool send a regular CAN signal or not, but not to kill some ECU etc..

So, this is my whole story.

If any idea thanks.

My best regards.

[crisr]

Search for the CanHacker software. I was able to reverse engineer most of the data on my Subaru "low-speed" bus using it and a CANbus to RS232 adapter, including info that does not appear on the instrument panel, such as individual door status and coolant temp.

[max_torque]

Google "CCP" and "XCP" and "ASAP-3" for lots of info on the data exchange protocol for automotive control units.

However, reflashing will generally require the target ecu to be unlocked, which is a seed/key exchange process.

[Chriss]

Reflashing the ecu and tuning etc is not a matter for me now, the question is how to be sure after repairing the
flasher too does it's CAN bus is working good.

I'm checking with scope but I wish to go deeper and make a tool for me to simulate some CAN communication between the
flashing tool and my simulator. That conversation would could be something like:

- the flasher sends the comand 200 01 0C (maybe a ecu wakeup comand)
- the simulator sends back some sort of "Ok" or message accepted...

This CanHacker looks very nice.
Could I somehow use the ELM327 tool to sniff the packets through CanHacker?
Or is there any diy can to rs232 converter possibility?

Any ecperience with this?

Thanks in advance.

[Leo Bodnar]

There are defined protocols that may be used over CAN, such as CANopen. If your device uses one of these, then you might be able to determine the likely meaning of a given message.

200hex ID is "reserved" in CANopen.

[Janne]

If you have some budget to spare on the project, maybe get one of these peak CAN modules.. http://www.peak-system.com/PCAN-USB.199.0.html?L=1 I've used few of them in a project and they work nicely as long as you keep the usb leads short, should not be an issue in this case 

[PIC18F2550]

Hi!
I'm working on a CAN bus logger project.
Actually it is working...

I need some help about to decode one CAN message pls.

Through the car CAN network i saw a data which is in this format:
200 01 0C

I assume it is a message whit the msg ID of 200 which is searching for the ECU mode 01 and the data (command) is 0C.

If I'm right, it could be some sort of wake up command?

Or I'm wrong?

I have no clue...


Thanks in advance.

The channel setup request message should be sent from CAN ID 0x200 and the response will sent with CAN ID 0x200 +
the destination modules logical address e.g. for the engine control unit (0x01) the response would be 0x201.

0x01 = address engine control unit
0xc0 = Setup request

this is TP2.0 protocol (KWP2000) ISO1423-3