Help to decode CAN data pls - Page 1
Forum section: electronics / projects

author: Chriss
author_rank: Frequent Contributor
timestamp: September 27, 2017, 02:53:53 pm
content: 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 0CI 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 27, 2017, 05:23:08 pm
content: 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

author: Chriss
author_rank: Frequent Contributor
timestamp: September 27, 2017, 05:34:19 pm
content: 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 toenter the service lets say where are the live data and a PID to get the data for lets say acoolant 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 27, 2017, 05:57:27 pm
content: Did you research CAN before asking this question?

author: ale500
author_rank: Frequent Contributor
timestamp: September 27, 2017, 06:08:14 pm
content: 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.

author: cat87
author_rank: Regular Contributor
timestamp: September 27, 2017, 06:24:35 pm
content: 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 thinkI 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 27, 2017, 06:36:44 pm
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 27, 2017, 07:48:55 pm
content: 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.

author: max_torque
author_rank: Super Contributor
timestamp: September 27, 2017, 07:53:27 pm
content: 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!

author: Chriss
author_rank: Frequent Contributor
timestamp: September 27, 2017, 08:26:31 pm
content: 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 farfrom 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 Wikipediahttps://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_1_PID_00and 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 strangethinks 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 isreally 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 differentcars 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 samecar 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 arereally 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.

author: crisr
author_rank: Contributor
timestamp: September 28, 2017, 03:34:44 am
content: 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.

author: max_torque
author_rank: Super Contributor
timestamp: September 28, 2017, 02:51:30 pm
content: 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.

author: Chriss
author_rank: Frequent Contributor
timestamp: September 28, 2017, 03:00:53 pm
content: Reflashing the ecu and tuning etc is not a matter for me now, the question is how to be sure after repairing theflasher 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 theflashing 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.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 05:35:11 pm
content: Quote from: AndyC_772 on September 27, 2017, 07:48:55 pm200hex ID is "reserved" in CANopen.

author: Janne
author_rank: Contributor
timestamp: September 28, 2017, 06:01:44 pm
content: 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=1I'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

author: PIC18F2550
author_rank: Newbie
timestamp: April 16, 2021, 02:38:28 am
content: Quote from: Chriss on September 27, 2017, 02:53:53 pmThe 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 unit0xc0 = Setup requestthis is TP2.0 protocol (KWP2000) ISO1423-3