CAN Bus Communications Decoded: Determining Simple Message Parameter Location
Watch This Course
$199 USD
-OR-
Or
8 easy payments of only $24.88
Instant access. Easy checkout. No fees.
Determining Simple Message Parameter Location
06.11
| 00:00 | - So far, we've talked about how to interface with an OEM CAN system and how to get a display of the bytes of data being transmitted on our laptop. |
| 00:08 | This isn't all that useful until we can then decipher what those raw bytes of data actually mean and how they relate to the real world parameters that we're looking for. |
| 00:17 | In the earlier simple CAN message module, we looked at the creation of a single CAN message containing some vital engine operating parameters to be transmitted by the ECU. |
| 00:28 | When we're dealing with an unknown OEM data stream though, we need to do essentially the opposite of this procedure. |
| 00:34 | Instead of making decisions as to how we get the data we want out there on the bus, we need to decipher the decisions that someone else has made about how that information is being transmitted. |
| 00:45 | There are 2 main parts to this process, determining the location of the parameter we're looking for within the data stream, followed by the scaling of that data and how we convert it back to a real world value. |
| 00:57 | To determine the parameter location, the basic idea is to cause that parameter to change in the real world and look for a corresponding change in the data stream. |
| 01:06 | Let's have a look at an example of doing this now, looking for the engine speed parameter on our Audi Q7. |
| 01:12 | With all of our CAN data packets up in our PCAN view here, we can see we've got a lot of traffic going on in this vehicle. |
| 01:20 | We've got all these PIDs coming in down this column here and all these data bytes. |
| 01:27 | What we're looking for in this particular instance is going to be engine speed in this vehicle. |
| 01:33 | We're looking for that parameter amongst all this data. |
| 01:35 | Now that's really key to keep in your mind. |
| 01:37 | It's really easy to get distracted by all this data but if you keep aiming for one specific piece, you're going to find it much easier. |
| 01:45 | Now engine speed is a piece of data that is reasonably easy to directly influence in the vehicle. |
| 01:51 | I can simply do that with the throttle. |
| 01:53 | So I'm going to start the vehicle up, we're going to have a look at our data and see if we see anything that immediately looks like vehicle speed to us. |
| 02:08 | So with our vehicle running here, you can see it's actually really hard to pick out the piece of data that we're looking for. |
| 02:16 | So we need to go through in a reasonably methodical way and look at each of these data bytes in turn and see if anything changes as we rev the engine up and down. |
| 02:26 | So I'm simpy applying a little bit of throttle now, adjusting the engine rev and I'm looking at these data bytes here and you can see that none of them are changing whatsoever so we can be pretty certain that our engine speed parameter is not going to be contained within that part of our CAN data stream. |
| 02:48 | Now the rest of the procedure is simply a rinse and repeat of this. |
| 02:52 | I'm going to go down our list of CAN traffic here, through all these PIDs, having a look at them one by one to see if I could spot a correlation between the changes I'm making to the engine speed with the throttle and the data that I'm seeing in that CAN data stream. |
| 03:09 | So I'm going to go ahead and do that now. |
| 03:47 | Now I think I found something that looks reasonably promising here. |
| 03:50 | If we have a look at PID 48A, in hex, that's what the h means there. |
| 03:57 | And bytes, this will be byte 0 so bytes 1 and 2 of this. |
| 04:05 | And if we watch those as I increase the engine speed, we can see byte 1 changing there and then byte 2 is changing as well. |
| 04:15 | And as byte 1 rolls over, so gets to FF and then rolls back over to 00, the second byte is increasing as well. |
| 04:28 | So that's looking an awful lot to me like that is going to be our engine speed signal parameter and it's going to be a 16 bit value and it's going to be transmitted in little endian there. |
| 04:42 | Now there is definitely a little bit of experience that comes in with this and I absolutely encourage you to get your can analyser hooked up to a vehicle and set yourself a target, engine speed would probably be the first one that I would be trying as it is the easiest to directly influence in the car. |
| 04:58 | As you do this more and more, you're going to start spotting patterns and every time you do it, you're going to find deciphering the next CAN bus to be that much easier. |
| 05:06 | In the next module of the course, we're going to go through how we convert these raw data bytes, which I'm going to take some recordings of, into the actual real world engine speed parameter. |
| 05:19 | It's important that when we're doing this, we approach it in a methodical way. |
| 05:22 | There will be parameters in the data stream that change seemingly at random and it's very easy to confuse these with the parameters that are changing in relation to the changes we're making to the vehicle in the real world. |
| 05:34 | Try to only change 1 physical thing at a time and narrow down that parameter's location before moving onto the next. |
| 05:41 | It's important to also remember that it's completely possible the parameter you're looking for might not be present on the data stream at all so do keep that in mind. |
| 05:51 | The nature of reverse engineering systems like this is that we're working from imperfect data and assumptions so don't get bogged down trying to determine what every byte of data on the bus means. |
| 06:01 | Instead, only search for the specific items you need and think should be present on that data stream. |
