WinOLS Mastery: Map Identification & Editing: 8bit 16bit 32bit and Floating Point Values
Watch This Course
$299 USD $149.50 USD
-OR-
Or
8 easy payments of only $18.69
Instant access. Easy checkout. No fees.
8bit 16bit 32bit and Floating Point Values
11.18
| 00:00 | - Bits and bytes are the terms we use when we're talking about how electronic devices read and store data. |
| 00:06 | You'll need to have a good grasp on what these terms mean as we're going to be using them frequently throughout the rest of the course. |
| 00:12 | Although they will seem initially a little abstract and possibly confusing, once you start dealing with them in the practical sections of the course, the concepts will fall into place and become second nature. |
| 00:22 | A bit is simply the smallest individual piece of information an electronic device can interpret and store. |
| 00:29 | It's a single binary digit which we've already learned has a maximum value of one and a minimum value of zero and these are the only two values it can ever have. |
| 00:37 | Sometimes these values are referred to as on and off or high and low. |
| 00:42 | Binary is the language of computers and electronics and although we naturally think of data contained in a particular map in decimal terms, it all needs to be converted to binary at some stage so that the ECU can work with it. |
| 00:55 | A byte on the other hand is simply a group of eight bits and as each bit is a single binary digit, this means a byte is an eight digit long binary number. |
| 01:06 | The maximum value a byte can have is 255 and the minimum value is 0. |
| 01:12 | To verify this, we'll open up the calculator app and enter the largest possible eight digit binary number which is simply eight 1s and see what this translates to in decimal and hexadecimal. |
| 01:23 | You can see that this is 255 in decimal and is FF in hex. |
| 01:30 | So if we naturally think of data in decimal terms and our electronics need to use binary terms, why in the previous section of the course did we also introduce the hexadecimal system? Well if you look at our largest possible eight digit binary value in the calculator, you can see that this is the same as the hexadecimal value FF. |
| 01:51 | This is the largest possible value we can represent with two hexadecimal digits so now our eight digit binary number and our two digit hexadecimal number have the same maximum and minimum values. |
| 02:04 | This gives us a great shortcut when we're wanting to represent a byte of data as a byte is just an eight digit binary number, we can convert it to hex and write it down using only two digits which is much faster and simpler. |
| 02:18 | When we're viewing raw map values within WinOLS, we have the option of displaying this data in decimal, hexadecimal or binary. |
| 02:26 | The maximum value we can represent with one byte is important. |
| 02:29 | We just found out that this is 255 in decimal so let's try and understand the relevance of this. |
| 02:34 | Let's assume we want it to represent the accelerator pedal position which is obviously a value of 0 to 100%. |
| 02:41 | In this case we could easily represent this using eight bits or one byte. |
| 02:46 | In this case a value of 0 would represent closed throttle or 0% and 255 would be wide open throttle or 100%. |
| 02:55 | To convert the raw value of 255 into a throttle position, we recognise that we can divide the raw value by a factor of 2.55 For example, 255 divided by 2.55 equals 100 or 100% throttle. |
| 03:10 | The other important part of this is not just the maximum value we can represent but also the resolution. |
| 03:17 | What I mean here is that if we represent the throttle position with an eight bit number then each step will be one divided by 2.55 or about 0.4% of throttle movement. |
| 03:29 | That's probably just fine for throttle position resolution but let's consider what happens if we wanted to represent engine speed. |
| 03:36 | Let's assume we have an engine that will rev to 8000 RPM. |
| 03:40 | 255 obviously is not a great way of representing a value of 8000 but we could do it. |
| 03:45 | If we divide 8000 by 255 we get a value of 31.37. |
| 03:51 | In this way, if we use a factor of 31.37 to multiply our raw value, we can span the required RPM. |
| 03:59 | 255 multiplied by 31.37 simply equals 8000. |
| 04:04 | All good so far however this leaves us with terrible resolution which is likely to be unacceptable for almost any ECU operations. |
| 04:14 | What we're saying here is that each time we increment our eight bit binary value by a factor of one, the RPM jumps by 31. |
| 04:22 | Not exactly what we want for fine control of the engine. |
| 04:25 | So how can we improve this situation? Well simply by using a 16 bit number instead of an eight bit one. |
| 04:32 | Since we already learned that there are eight bits in a byte, it's no surprise that 16 bits are simply two bytes. |
| 04:40 | Using 16 bits massively increases the maximum value we can display and we can now represent numbers between 0 and 65,535 in decimal. |
| 04:51 | If you wanted to represent this is hexadecimal, it would of course be FFFF given that we already learned the maximum hex value for a single byte was FF. |
| 05:01 | Now we're just adding a second byte to the first. |
| 05:04 | So let's look at what we've learned. |
| 05:07 | An eight bit value is limited to 255, while a 16 bit value is limited to 65,535. |
| 05:14 | Let's go back to our engine speed example and if we divide 8000 by 65,535, we get 0.1 which means we now have a resolution of 0.1 RPM when we use 16 bits or two bytes. |
| 05:30 | More than sufficient for our purposes so this would be a great way of representing the engine speed. |
| 05:36 | While 65,535 is a big number, there may be instances there we still want to be able to represent large decimal values with very high precision where 16 bit just isn't sufficient. |
| 05:49 | Of course we can step up to 32 bit which is four bytes together. |
| 05:54 | This would then allow us to represent decimal values between 0 and 2,147,483,647 if you want to be precise. |
| 06:05 | There's a limited number of applications where we would need this kind of precision when it comes to ECU tuning so 32 bit values are relatively uncommon but they do exist. |
| 06:15 | Lastly we also have floating point numbers which is a little trickier to explain. |
| 06:21 | Up to this point we've covered eight, 16 and 32 bit numbers which are all integers or whole numbers. |
| 06:27 | This means that do decimal point needs to be dealt with and as far as the ECU is concerned, any map involving integers is really simple. |
| 06:35 | When it comes to floating point values, we're now considering a number that includes a decimal point and that decimal point could be located anywhere within the number. |
| 06:44 | In other words, there can be an indeterminate number of digits or bits before and after the decimal point. |
| 06:51 | Without getting too deep down in the weeds here, this has a significant effect on the way the ECU performs math on floating point values. |
| 07:00 | The way it does this is by storing the value in scientific notation. |
| 07:05 | This means it will code the bits required to represent the integer portion of the number and then code the bits required to represent the fraction part or the part after the decimal point. |
| 07:15 | Then the ECU adds the exponent required to get from scientific notation to the original number. |
| 07:21 | This means that any time the ECU needs to perform math on a floating point number, it needs to split out the parts and normalise the exponent portion, then it performs the math on each part before putting them back together to form the result. |
| 07:34 | If that last paragraph may as well have been in a different language then don't worry as fortunately for us, we don't need to have an in depth understanding of this process but rather just know that floating point values do exist. |
| 07:47 | It's also important to understand the implications of the various ways the ECU can represent a value. |
| 07:53 | To be efficient with processor use and hence improve processing speed, there's an advantage in using the smallest number of bits that we can get away with while providing sufficient precision. |
| 08:04 | For this reason, floating point values are the most processor intensive, followed by 32 bit, 16 bit and finally eight bit. |
| 08:12 | For this reason, floating point and 32 bit values are seldom necessary and predominantly we'll be dealing with eight bit and 16 bit values. |
| 08:21 | Of course as processors become more complex, we can expect this to change but for now, floating point and 32 bit values would be the exception rather than the norm. |
| 08:30 | Hopefully you haven't drifted off to sleep by now because the most important takeaway from this module is some very specific values that we need to understand and recognise. |
| 08:40 | These values are related to the way the ECU represents the decimal values that we want to see in our maps and these become the key to the factors we'll use to convert from raw values to recognisable data like RPM, injection quantity, torque, throttle position and more. |
| 08:57 | We've included these values as an attachment to this module and I'd recommend you print this out and use it as a reference card when you're finding maps. |
| 09:04 | For example, if we're considering the binary system, we have values on this card that continue to double. |
| 09:10 | Two, four, eight, all the way through to 8192, 16,834, 32,768 and finally, 65,536. |
| 09:23 | Hopefully some of these numbers might start sounding familiar. |
| 09:27 | 65,536 for example being the maximum number of values in a 16 bit number. |
| 09:33 | Why this is important is that we'll start to recognise these raw values in maps we're looking for and use these to decide on a suitable conversion or scaling factor. |
| 09:43 | Earlier in our introduction to OLS, I gave an example of throttle position which used the raw value 65,535. |
| 09:52 | This of course is now immediately recognisable as the maximum value for a 16 bit number and we see the same number on our cheat sheet. |
| 10:00 | Now to be specific, there is a small difference of one number and this is simply because when we start counting, we begin from zero. |
| 10:07 | Hence the maximum value is 65,535. |
| 10:11 | However, this actually represents 65,536 discrete values, a subtle but important distinction. |
| 10:19 | Anyway, once we recognise this as an important number, we can use it as our diviser for our conversion factor. |
| 10:26 | Some care with the location of the decimal point is needed so that our end result spans 0-100% and there we go, throttle position in a range of numbers that makes sense. |
| 10:37 | This module did get deep pretty quickly so let's just cover off the key points before we move on. |
| 10:42 | Remember that there are 8 bits in a single byte, and this can be represented by two hexadecimal values which is a great short cut rather than using the binary or decimal systems. |
| 10:53 | Since one byte has a maximum value of 255 in decimal, this does have an impact on the resolution of the value we want to represent and while it's more than adequate for something like throttle position, we need better resolution for a channel like RPM. |
| 11:07 | The easy solution here is to use two bytes instead which then has a maximum value of 65,535 in decimal. |
