CAN Bus Communications Decoded: Bus Load
Watch This Course
$199 USD
-OR-
Or
8 easy payments of only $24.88
Instant access. Easy checkout. No fees.
Learn more
Bus Load
04.39
| 00:00 | - In the last module, we discussed CAN message frequency but why was that so important? It all comes down to bus load which is the term we use to describe the amount of traffic that is on the bus. |
| 00:11 | In a perfect world, we'd just transmit all of our desired parameters on the bus as fast as we possibly could as there really isn't a downside to transmitting more data than we need. |
| 00:21 | However, in the real world there is a hard limit to the amount of data that we can transmit on the bus and we need to stay substantially below this limit to ensure our data frames are sent and received in a timely manner. |
| 00:34 | Then amount of traffic we can transmit on the bus is determined by the bus speed setting. |
| 00:39 | If we had this set at 1 Mb per second, this means a maximum of 1 million bits can be transmitted on the bus within 1 second. |
| 00:46 | If we're trying to transmit data frames that add up to more than 1 million bits within a second, the bus is going to get choked with all that traffic and the system will fail. |
| 00:57 | Even if we get close to 1 million bits per second on the bus, our system is still likely to fail or at least give us some unexpected results. |
| 01:05 | Many messages will have to spend quite a bit of time waiting in queues for space to become avialable on the bus and they won't be transmitted at the expected times. |
| 01:14 | For this reason, the general rule is to stick below a maximum bus load of 80%. |
| 01:19 | This means that with our bus speed set to 1 Mb per second, we would need to make sure our traffic on the bus is configured to be below 800,000 bits per second. |
| 01:29 | To calculate the bus load, all we need to do is add up the bit length of all our data frames to be transmitted within a second and ensure that that's below 80% of our bus load limit. |
| 01:42 | With that said, calculating the exact bit length of our data frames is not actually particularly straightfoward thanks to a transmission strategy the CAN protocol uses called bit stuffing. |
| 01:53 | We don't really need to get into the details of how bit stuffing works as any tool you're using to see data on a bus will deal with this for you but it means that the data frames might actually take more bits on the bus than we would initially anticipate. |
| 02:06 | To get around this, a common approach is to assume that each CAN data frame we want to transmit will take 130 bits. |
| 02:14 | This is a worst case assumption and is a pretty safe value to use. |
| 02:18 | This assumption is for a full data frame containing 8 bytes. |
| 02:22 | If you have a frame with less than 8 bytes, you can subtract 8 from this value for each byte that is missing. |
| 02:28 | With this assumption, we can pretty easily calculate our bus load. |
| 02:32 | As an example, we'll think back to that Link generic dash compound message profile that we had a look at earlier. |
| 02:39 | This was a compliment of 14 full 8 byte data frames. |
| 02:44 | Using our 130 bit per data frame assumption, this means that each compound message is 14 times 130 or 1820 bits long. |
| 02:55 | If we choose to transmit this compound message at a message frequency of 100 Hz, this would mean that we multiply our 1820 bits by 100, giving us 182,000 bits per second on the bus. |
| 03:13 | Knowing this and the speed that we've set our bus at, we can work out the percentage of the available bus bandwidth that this will use up. |
| 03:19 | Assuming our bus speed is set to 1 Mb per second, we can take our message bit rate of 182,000 bits per second and divide it by the bus speed, 1 million bits per second, giving us a bus load of 0.182 or 18.2%. |
| 03:37 | This is well below our 80% upper bus load limit so we can be sure that all our frames are going to be sent and received as expected. |
| 03:45 | The compound message we're sending out contains a lot of data and transmitting it at 100 Hz is considered a relatively high message rate. |
| 03:52 | So you can see it's possible to send out quite a bit of data very quickly on a 1 Mb bus. |
| 03:59 | It's not uncommon to rub up against the bus load limits on intense data logging applications like damper position and multiple position tyre temperature readings for example. |
| 04:10 | These require really high message frequency and large message structures. |
| 04:14 | Often a little head room can be gained by looking at the message frequency of other data frames on the bus and reducing them as much as possible. |
| 04:23 | However, in these higher end applications, often the electronic modules will have multiple CAN bus interfaces, meaning a second or even third bus can be used to extend the overall network bandwidth. |
