4 ms·

Isn't CAN very limited in terms of bandwidth? Seems like this wouldn't be appropriate for most applications of interest? When I worked at an equipment manufactu

Isn't CAN very limited in terms of bandwidth? Seems like this wouldn't be appropriate for most applications of interest? When I worked at an equipment manufacturer, everyone was very concerned about accidentally saturating the bus, and we even had a very compact data representation.

sokoloff 9y ago
500kbps is typical. That's not super-slow, IMO.
- spatulon 9y ago
  It can also operate at 1Mbps. There's a relatively recent extension called CAN FD that can go faster, as can the FlexRay protocol, which is sometimes used instead of CAN.
spotman 9y ago
Some systems do up to 1mbps. MIDI for example is nowhere near this. It's not the right protocol for media or bandwidth intensive applications but for control systems or reading sensors its often enough.
- AceJohnny2 9y ago
  > but for control systems or reading sensors its often enough. But not for the self-driving car generation, where the sensors are higher-bandwidth. As I recall, Mobileye worked around this by just putting the detection intelligence with the camera and sending back synthetic data.
diydsp 9y ago
Next stop after can/flexray is EtherCat!
Mtntk 9y ago
It varies with length of the connection, if it's short fire it up to 1 mbps or higher. Your speed gets lower as distance gets further
delfinom 9y ago
CAN-FD raised the baud rate to 12mbit. Honestly, in my applications where I have idiotic ascii logs transmitted over CAN due to management idiots, I've only managed to saturate reception buffers rather than the bus.
childintime 9y ago
Noone ever talks about the very significant downsides of CAN: - CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps. - a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it. - CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents. - CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates. So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications. It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.

sokoloff 9y ago

500kbps is typical. That's not super-slow, IMO.

spatulon 9y ago
It can also operate at 1Mbps. There's a relatively recent extension called CAN FD that can go faster, as can the FlexRay protocol, which is sometimes used instead of CAN.

spotman 9y ago

Some systems do up to 1mbps. MIDI for example is nowhere near this. It's not the right protocol for media or bandwidth intensive applications but for control systems or reading sensors its often enough.

AceJohnny2 9y ago
> but for control systems or reading sensors its often enough. But not for the self-driving car generation, where the sensors are higher-bandwidth. As I recall, Mobileye worked around this by just putting the detection intelligence with the camera and sending back synthetic data.

diydsp 9y ago

Next stop after can/flexray is EtherCat!

Mtntk 9y ago

It varies with length of the connection, if it's short fire it up to 1 mbps or higher. Your speed gets lower as distance gets further

delfinom 9y ago

CAN-FD raised the baud rate to 12mbit. Honestly, in my applications where I have idiotic ascii logs transmitted over CAN due to management idiots, I've only managed to saturate reception buffers rather than the bus.

childintime 9y ago

Noone ever talks about the very significant downsides of CAN: - CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps. - a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it. - CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents. - CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates. So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications. It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.