At a previous job I interfaced with hospital beds that used CAN Bus internally. Turns out that Ford had laid off a lot of engineers a few years ago and the firm hired some of them to design the next generation bed. They knew CAN Bus, so they used it to control the hydraulics, pneumatics, lift motors, strain gauges, and so on.

Man, that's really cool. I'm really looking forward to all of this CAN Bus stuff being EOL in 10-25 years so I can get my hands on it at tinker with it.

There are used beds that use the bus available on eBay and other auction sites. Be aware that it's only on their high-end beds, If you're looking to bid on one, know that they weigh over 600 lbs and need wide doorways (ask me how I know..) Current prices are $900 and up, and often don't come with the inflatable mattresses (hospital may not want the potential biohazard liability, so disposes of it first).

Thanks for the tips. I would almost definitely just stash it in my garage while I took it apart.

That actually sounds perfect for a project I've been working on. I think changing your environment really helps with thinking, so I added wheels to my desk/workbench at home. I've been trying to find parts that are inexpensive, reliable, and have enough torque to move an entire workbench, but they are near impossible to find.

My first goal is to add automated raising and lowering of the table surface so I can switch from sitting to standing. Then I want to replace the casters with actual motorized wheels. The plan is to run the whole thing on a bunch of 18650s and use that as my UPS for the electronics on my workbench as well.

Plus I think it would be hilarious to build a desk that you can control from afar, since you have to be at one to use it anyways.

> they weigh over 600 lbs and need wide doorways

Spot the Orderly?

We would occasionally get a new model delivered by truck. The one door between the lab and the elevator was a normal (narrow) door. So we'd have to lift the bed onto it's side and maneuver it through. So that's how I know how much they weigh and that they need wide doors. :)

The bizarre story was we had an employee that was diabetic, and she passed out one day. When the paramedics arrived, they found her already sitting in a hospital bed.

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.

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.

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.

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.

> 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.

Next stop after can/flexray is EtherCat!

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

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

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.