CAN Bus Communications Decoded: Determining Parameter Scaling
Watch This Course
$199 USD $99.50 USD
-OR-
Or
8 easy payments of only $12.44
Instant access. Easy checkout. No fees.
Determining Parameter Scaling
07.43
| 00:00 | - In the previous module, working with a simple CAN message, we determined the location of the engine speed parameter within the CAN data stream on the bus in our Audi Q7. |
| 00:10 | We now need to determine how the transmitted data relates to the real world parameter value. |
| 00:15 | Key to this process is having a known value for that parameter to compare our recorded data to. |
| 00:22 | This is where having a common automotive scan tool is invaluable. |
| 00:25 | Like we discussed earlier in the course, the data on the diagnostic busses within a vehicle are often not transmitted at a high enough frequency to be useful for our logging or display purposes but they can be very helpful when determining our raw data to parameter relationship. |
| 00:41 | There are a couple of things we need to keep in mind when we're doing this, first of these is the byte endianness of a multi byte parameter. |
| 00:49 | Multi byte parameters will almost always be transmitted as consecutive bytes within a data frame. |
| 00:55 | So we'll be looking at 2 or more bytes directly next to one another within that single frame. |
| 01:01 | We can determine the endianness by changing the parameter in question and watching the data on the bus. |
| 01:06 | Small changes to the parameter should cause the least significant byte of data only to change. |
| 01:13 | If any changes made to the parameter cause multiple consecutive bytes to change, they will be changing at different frequencies. |
| 01:21 | The bytes with the highest frequency will be the least significant, working back to the most significant byte having the lowest frequency. |
| 01:29 | With the endianness of a multiple byte piece of data determined or just with a single data byte by itself, we have what is called the raw data value. |
| 01:39 | To convert this to a real world parameter value, we need to determine the scaling and offset that have been applied to arrive at this raw value. |
| 01:48 | So in the previous module, we determined the parameter location or at least what we think the parameter location is for the engine speed signal on the data stream in our Audi Q7. |
| 01:59 | Now what I've done is I've plugged in a standard OBD automotive scan tool and I've got that to give me a readout of the RPM. |
| 02:08 | In a lot of cars you could probably take this information from the tachometer as well, but sometimes the tachometer in cars is actually a little bit, they're not particularly accurate, so best to plug in a scan tool to get this real world parameter RPM reading here. |
| 02:27 | I've then revved the engine to different points and held it there and have recorded the corresponding data bytes in our assumed location as well. |
| 02:40 | So now we're going to go through the procedure of decoding this data to see how it relates to our engine RPM and if our assumption that those 2 are related is in fact correct. |
| 02:51 | So the first part of that, as we have previously discussed is we need to determine our byte endianness. |
| 02:57 | Now in this example here, it is reasonably obvious that this data is being transmitted in little endian format. |
| 03:05 | So our least significant byte here is in byte position 1 and our most significant byte, the high byte is in byte position 2. |
| 03:14 | I know that because we can see that our byte 1 is actually changing quite a lot with our engine RPM and every time it overflows, see this EE here would have had to overflow from FF back to 0 and that's been recorded by an increase in our high byte here. |
| 03:34 | So we need to combine those 2 bytes to get them in 1 format. |
| 03:39 | Now luckily most spreadsheet programs, particularly Google Sheets I'm using here, I know Excel does the same thing, have a concatenate command. |
| 03:48 | So I'm going to concatenate which simply means I'm going to join these 2 together. |
| 03:57 | So concatenate and I want to choose my high byte first and then followed by my low byte. |
| 04:06 | We'll run that through and you see that's given us 0D3 which is 0D3. |
| 04:11 | So I'm simply going to propagate that down, that's going to do the same for all of our bytes of data here. |
| 04:19 | So it's combined them together. |
| 04:22 | So now we've got this data sitting here in hexadecimal format and that's not going to be particularly useful for us to just look at as it is because I don't know about you but I'm not particularly great at inferring relationships from hexadecimal data. |
| 04:36 | So I want to get this into a decimal form. we're going to have to do the conversion. |
| 04:41 | Now we could go through and do this by hand, we could use our Windows calculator, but once again our spreadsheet program here actually gives us a really good functionality for doing that. |
| 04:50 | So it is simply, in Google Sheets, the =hex2dec and then just choosing that byte there. |
| 05:02 | You can see this equals 211 in decimal and I'm just going to propagate that down. |
| 05:07 | So now that we've got our complete 16 bit value shown correctly and then converted into decimal, we need to work out the relationship between these values and our real world parameter values of RPM. |
| 05:22 | So in this instance I'm going to look for I think a simple division. |
| 05:29 | So to test that theory, I'm simply going to divide our RPM by our data shown in decimal there. |
| 05:40 | So we're going to equals, this cell divided by this cell. |
| 05:46 | And that's very very close to 3. |
| 05:50 | So if I propagate this down, and we can see that all of these are very very close to being 3 so that is a really good sign, it means we've got one factor involved for the conversion of our raw data shown in decimal here to our real world parameter value and that one factor is working for every different point that we've taken our data from here. |
| 06:16 | So just to really prove that to ourselves I'm going to go the other way, I'm going to call our multiplication factor 3, so I'm just going to look at what all of our raw values here, multiplied by 3 actually are. |
| 06:29 | And we'll just propagate that down and you can see here within a pretty tight margin of error, our recorded raw data converted back with our assumed scaling factor of 3 is actually really closely matching our engine RPM that we've recorded from our OBD2 scan tool. |
| 06:54 | Now when I was recording this, it was actually a little bit tricky to hold the engine at a totally stable RPM. |
| 07:00 | So there will be a wee bit of variance here, I would be absolutely confident that we have definitely found the parameter location and the scaling factor for the engine RPM on our Q7 here. |
| 07:14 | Almost universally, scalers and offsets are applied in this order, where we take our real world value, we scale it by a factor first and then the offset is applied. |
| 07:25 | It is possible the person that has designed that CAN data stream though, might have gone about it a different way so this isn't a catch all but it is going to be the best place you can start for taking the raw data and getting the real world parameter value from it. |
