1
\$\begingroup\$

I am trying to develop a robotic system that has a distributed DAQ system with one main computer that has the high level control loop. I have a question about the data that has to be transmitted every second to the processing computer. I did a 'quick' calculation about the how much data we want to sent to the main computer and then an estimation about how fast we can send it through the can bus. The baudrate of the CAN bus is: 1Mb/s (bit) The amount of bits we have to transfer is: IMU: 4 (mag,accel, gyro,euler) * 4 (x,y,z, time) * 16 bit (resolution) = 256 bits Analog: 5 *​ 12 bit (resolution) = 60 bits Encoders: 3 * 17 bit (resolution) = 51 bits With a total of 367 bits. This means with the CAN bus, we have a 1.000.000/ 367 = +- 3k Hz sample frequency on the main computer

Could you guys check if this is a correct way to acquire a ballpark figure for the updaterate.

\$\endgroup\$
  • \$\begingroup\$ Every one second? No problem at all. \$\endgroup\$ – Eugene Sh. Oct 22 '15 at 16:46
  • \$\begingroup\$ Where is the CAN bus frame overhead in all of this? Separate the calculation into data bits and CAN bus overhead bits. What the data is for, is irrelevant to the question. You need to decide if you'll use 11 or 29 bit identifiers, as they add different amounts of overhead. \$\endgroup\$ – Lundin Oct 23 '15 at 7:50
1
\$\begingroup\$

Your bit calculations is correct, but it is important to remember overhead and bus usage.

If you use CAN basic frames, then each message can carry up to 64 bits and has 44 bits of header overhead. This means in the most optimal case, you will need extra ~70% of bandwidth for the overhead. In reality, it may be even higher if your senders are not co-located -- for example, if encoders are separate devices on the bus, each one will only send 17 bits per frame -- for 258% protocol overhead.

Also, you should not use full bus bandwidth to leave space for imprecise clocks, error messages, etc... I have heard that you can run up to 80% bus utilization without major problems.

Overall, you are not going to get 3KHz sample rate. Consider multiple CAN busses or ethernet if you need this rate.

\$\endgroup\$
  • \$\begingroup\$ Note that CANBus also does bit stuffing, which will further reduce the available bandwidth. \$\endgroup\$ – WhatRoughBeast Oct 22 '15 at 17:11
0
\$\begingroup\$

In a very very very rough calculation you are entirely correct.

What needs to also be taken into account is how fast can your peripherals actually process what they need. If they can't sustain 3kHz then the calculation is moot. Also some of these devices may work on a call and response type system, then you have to take into account the request message for the data.

Finally CAN has overhead for the message address and packet size and the check sum etc... which will consume more bits that you have not accounted for.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.