Merging modern software development with electrons and metal
Random header image... Refresh for more!

The Reality of Serial Bus Speeds

Serial buses and networks such as Ethernet, CAN, USB, and Firewire are popular.   But you can’t just say “I need to transfer 1Mbps, therefore I can use CAN.”  You need to understand a bit about the physical layer and your chosen software layers before you can pick a bus that will work.

All serial buses have some protocol overhead, and software layers add even more.

I’ll take a quick look at CAN:

  • CAN messages can carry between 8 and 64 bits of data.
  • At 1Mbps, the maximum actual throughput is roughly 17543 messages/sec (1 byte data) to 8771 messages/sec (8 byte data) or 140,344 to 561344 bits per second of actual data.
  • CAN does have many good features, like extremely fast arbitration (much faster and more predictable than CMSA/CD Ethernet), and producer/consumer messaging.
  • So CAN is a good choice for a real time network that isn’t transferring a lot of data.  It’s even better if many nodes need to consumer data produced by one node (so the data is only sent once, unlike in a master/slave network where the master has to receive the data and then send it out again to each slave node).
  • On the other hand, it’s not a good fit for a 1M sample/sec 16-bit ADC; high speed USB 2.0 or 100Mbps/1000Mbps Ethernet would be better choices.
  • There’s also a cable length / speed trade off; as the bit rate increases, the maximum cable length (and branch length) decreases.
  • The maximum number of messages gives an idea of what kind of update rates you can realistically see.  For example, a 100 node CAN network could handle a maximum of roughly 175 1-bytes messages or 88 8-byte messages per node per second.  So a 1 msec update rate for all nodes is impossible, but a 10 msec rate might be achievable.

Ethernet has its own set of considerations.  Just a few:

  • Ethernet has significant protocol overhead, especially for small data sizes.  (Summation frame systems such as EtherCAT reduce this, but require non-standard hardware).
  • If you’re using hubs, you have to take collisions into account.
  • If you’re using switches, you have to consider the time the switches add.
  • Ethernet and its typical protocols require a lot of resources; if your product uses an underpowered controller, even if it’s physically on 100BaseT, it might only be able to manage 1Mbps or less.
  • For long distances, the time traveling between nodes can be significant.
  • Higher level protocols such as TCP, ftp, NTFS, etc can add substantial delays and additional overhead along with their added features.

I’m not a USB expert, but I know USB 2.0 can’t deliver actual data at its advertised speed.


There are no comments yet...

Kick things off by filling out the form below.

Leave a Comment