CAN Bus Communications Decoded: Determining Compound Message Parameter Location
Watch This Course
$199 USD
-OR-
Or
8 easy payments of only $24.88
Instant access. Easy checkout. No fees.
Determining Compound Message Parameter Location
05.43
| 00:00 | - In the previous module, we showed how to determine a parameter location in a simple CAN message. |
| 00:05 | But there is an added level of complexity when that parameter is within a compound CAN message. |
| 00:10 | As we discussed in the compound CAN message module, a compound message is a structure where multiple different messages are sent on the same PID. |
| 00:19 | WIth one of the data bytes of the message then being an index to determine which part of the compound message that particular data frame represents. |
| 00:28 | I find it easiest to think about the message as essentially now having a longer PID. |
| 00:33 | Being made up of both the actual PID of the message and the index data byte. |
| 00:39 | Thinking about it like this, the problem of finding and decoding parameter values is no different to working with a simple CAN message. |
| 00:46 | Where the difficulty comes in however is that the tools we use often aren't set up to work with compound messages nicely. |
| 00:53 | We're relying on a persistent view of repeated traffic sorted by the PID to let us see changes in the data. |
| 01:02 | Many tools out there cannot give us this view sorting both by the message PID and an index byte which is where the confusion comes in. |
| 01:11 | However, if the tool you're using does have the ability to work directly with compound CAN messages, then this is something you should make use of and refer to the documentation of your tool to set this up. |
| 01:22 | If the tool you're using doesn't have this ability then there's a technique I use to isolate the specific parts of the compound message that you should be able to apply to any log of CAN traffic that you have. |
| 01:33 | This technique is simply a manual sorting process, using simple freely available spreadsheet tools. |
| 01:39 | So I've got a log here taken with our microchip CAN bus analyser tool of the compound message output from a Link ECU. |
| 01:48 | We're going to have a hunt through this and try and determine the location of the engine coolant temperature parameter. |
| 01:54 | So in order to find that engine coolant temperature parameter, I had to cause it to change in the output data stream. |
| 02:00 | So what I did in our Link ECU is I told it to initially output a value of 0°C, the real world parameter value, and then part way through the log I changed that to 100°C and then little bit later I changed that back to 0°C so we're going to be looking for those step changes in our data. |
| 02:23 | Now the issue we have is outlined here is that we can see our bytes of data here and we've got our frame, our compound message identifiers are in byte locations 0 and 1 here so you can see these increase consecutively and this is going to represent the actual data frame so what we need to do is we need to sort this data by these compound message IDs. |
| 02:53 | And using Google Sheets here, and this is the same procedure for Microsoft Excel as well, is I can simply sort by this column. |
| 03:00 | So I can choose that, right click and sort this sheet. |
| 03:05 | So now that that's sorted I can scroll through our data, you can see all the data we've got at the top here is still consecutively ordered, our timestamps are still in order but it's all compound message with that data ID of 0. |
| 03:21 | So because they're all matching data frames I can simply scroll through and we can look for that step change that we're expecting to see. |
| 03:32 | So just scrolling down and that's the last data frame there with compound message ID 0. |
| 03:39 | We didn't see any step changes in the rest of our data here. |
| 03:43 | So pretty sure it's not going to be in that first compound message. |
| 03:46 | So continuing to scroll down, we're now in data frame ID 01. |
| 03:56 | And I'm still not seeing any step changes in any of the rest of our data bytes here. |
| 04:05 | So we're onto compound message ID 02 now and scrolling down, ah we've just spotted a step change here. |
| 04:16 | So we're still in compound message ID 02 but we're changing from 0x32 to 0x96. |
| 04:23 | Now remembering about the change I talked about introducing into our Link ECU is that I told it to output 0°C then change to 100°C and then back to 0°C. |
| 04:35 | So if we continue to scroll down and we see this change back to 0x32, we can be pretty sure that that is going to be the location of the engine coolant temperature parameter in this data stream. |
| 04:51 | So we're transmitting on PID 0x3E8 which is actually 1000 in decimal. |
| 04:59 | It's a compound message and the compound message ID is 0x02 and it's going to be data bytes 6 and 7 here. |
| 05:10 | One of the key differences to working with a simple CAN message is that it can be very difficult to see the parameter changing in real time in response to our physical input in the vehicle. |
| 05:21 | This is where we need to think carefully about that physical input that we've made to help us locate the matching response in our data log later on. |
| 05:29 | Once the parameter location has been identified within the compound message, the rest of the decoding process is the same as for a simple CAN message and is covered in the next module. |
