Supercon 2024: Yes, You Can Use The Controller Area Network Outside Of Cars

Mention the Controller Area Network at a party and two things usually happen: the automotive engineers perk up, and everyone else assumes you are about to explain why their check-engine light has trust issues. But at Supercon 2024, Randy Glenn’s talk, “Yes, You CAN: Use The Controller Area Network Outside Of Cars,” made a very useful point: CAN bus is not married to the automobile. It merely had a long, successful first career there.

The real story is bigger. CAN bus is a rugged, low-cost, message-based communication network for embedded devices. It was designed so small controllers, sensors, displays, motors, and actuators could talk to one another without a central computer bossing everyone around. That same idea works beautifully in machines, boats, robots, elevators, test benches, farm equipment, art installations, Halloween props, and probably at least one over-engineered coffee maker with firmware opinions.

What Is CAN Bus, Really?

CAN stands for Controller Area Network. At its core, it is a shared communication bus that allows multiple electronic nodes to send and receive short messages over a two-wire differential pair: CAN High and CAN Low. Instead of wiring every sensor directly to every controller, you connect devices to a common network. Each device listens, broadcasts what it needs to broadcast, and ignores messages it does not care about.

That may sound simple, but the elegance is in the details. CAN is multi-master, meaning any node can start a transmission when the bus is free. It uses message identifiers instead of traditional device addresses, so the network cares more about “what is this data?” than “which box sent it?” A motor controller might broadcast speed, a temperature node might report heat, and a display might choose to show only the values it needs.

Why Supercon 2024 Made CAN Feel Fresh Again

Hackaday Supercon is famous for turning “obscure embedded protocol” into “wait, I could use that this weekend.” Glenn’s talk did exactly that. Rather than treating CAN as something locked behind an OBD-II port, the talk framed it as a practical tool for distributed embedded systems. The takeaway was refreshingly direct: if you have several microcontrollers or modules that need reliable local communication, CAN belongs on your shortlist.

This matters because many maker and engineering projects begin with familiar buses such as I2C, SPI, or UART. Those are excellent in the right place, but they have limits. I2C is wonderful on one circuit board but gets grumpy over distance. SPI is fast but usually wants more wires and a clearer master-slave relationship. UART is simple but often becomes messy when several devices need to share a line. CAN sits in a different category: it is built for noisy environments, multi-node networks, arbitration, error handling, and practical wiring.

CAN’s Origin Story: Born in Cars, Raised by Machines

CAN was developed by Bosch in the 1980s to solve a growing automotive problem. Cars were gaining more electronic systems, and point-to-point wiring was becoming heavy, expensive, and complicated. A networked approach reduced wiring complexity and allowed electronic control units to share information more intelligently.

But the qualities that made CAN attractive for cars also made it useful elsewhere. A factory machine has vibration, electrical noise, sensors, actuators, timing needs, and maintenance headaches. A boat has distributed electronics, engines, navigation equipment, environmental sensors, and a strong dislike of wiring chaos. A robot has motor controllers, encoders, battery monitors, safety devices, and a talent for making wires fail at the worst possible time. In other words, the world outside the car looks suspiciously CAN-shaped.

Why CAN Works So Well Outside Automotive Projects

1. It Handles Electrical Noise Like a Champ

CAN uses differential signaling. Instead of relying on one signal wire referenced to ground, CAN transmits information as the voltage difference between CAN High and CAN Low. Electrical noise that affects both wires similarly tends to cancel out, which is extremely useful near motors, relays, pumps, solenoids, switching power supplies, and other tiny chaos machines.

2. It Does Not Need a Central Master

CAN is not a “one boss, many minions” network. Multiple devices can communicate, and the bus uses priority-based arbitration when two nodes try to speak at the same time. Higher-priority messages win without destroying the lower-priority message. That is not just clever; it is civilized. Imagine a meeting where people interrupt each other, but the system automatically lets the fire alarm speak before the snack committee.

3. Error Detection Is Built In

CAN controllers handle much of the boring but essential work: error detection, acknowledgments, retransmission, and fault confinement. This reduces the amount of custom reliability code you need to write. For embedded developers, that is a gift. Nobody wakes up excited to reinvent error handling at 2 a.m. unless the coffee machine also runs on CAN.

4. Hardware Is Everywhere

Because CAN is so widely used, hardware support is easy to find. Many microcontrollers include a CAN controller. Some still need an external transceiver to connect to the physical bus, while boards without native CAN can use SPI-based controllers such as the popular MCP2515 family. USB-to-CAN adapters make development on Linux, Windows, or macOS manageable. In Linux, SocketCAN turns CAN interfaces into network-like devices, making it surprisingly pleasant to send, receive, log, and inspect frames.

Real Non-Automotive Uses for CAN Bus

Industrial Automation

Industrial systems were among the earliest and most enthusiastic CAN adopters outside passenger vehicles. Protocols such as CANopen and DeviceNet build higher-level structure on top of CAN, defining device profiles, object dictionaries, diagnostics, and communication behavior. This is useful in drives, conveyors, packaging machines, cranes, forklifts, and other equipment where a controller must coordinate many devices reliably.

Marine Electronics

NMEA 2000, widely used in marine electronics, is based on CAN. It allows devices such as engines, GPS receivers, depth sensors, wind instruments, displays, battery monitors, and autopilot systems to share data over a vessel network. Boats are perfect candidates for bus wiring: long runs, distributed equipment, moisture, vibration, and enough accessories to make a wiring diagram look like spaghetti after a storm.

Robotics

Robots love CAN because robots are basically moving bundles of sensors, motors, and bad timing decisions. A mobile robot might use CAN to connect wheel motor controllers, an inertial measurement unit, a battery management system, a safety stop module, and a central computer. CAN keeps lower-level control traffic local and deterministic enough for many practical designs, while higher-level planning can remain on Ethernet, Wi-Fi, or another network.

Interactive Installations and Props

One of the most fun examples from the Supercon discussion was a Halloween-style build using CAN to trigger lighting and sound effects when a doorbell was pressed. That kind of project shows CAN’s maker appeal. You can spread small nodes around a yard, haunted hallway, stage, or art installation, then let them coordinate events without running separate wires for every button, LED, relay, speaker, and sensor.

Elevators, Pinball Machines, and Weird Beautiful Hardware

Once you start looking, CAN appears in places that are not cars at all. Elevators need dependable communication among buttons, doors, controllers, sensors, and displays. Pinball machines and arcade systems can benefit from distributed boards that simplify wiring. Test equipment and medical devices use networked embedded control where reliability matters. CAN is not glamorous, but it is exactly the sort of technology that quietly keeps the blinking lights blinking in the correct order.

CAN Frames: Small Messages, Big Discipline

Classic CAN frames carry up to 8 bytes of data. That sounds tiny in an era when people send 4K video of lunch, but small frames are part of CAN’s design discipline. CAN is not meant to move large files. It is meant to move compact control and status messages quickly and reliably. A few bytes are enough for a temperature reading, a motor command, a battery voltage, a switch state, or a heartbeat.

CAN FD, short for CAN Flexible Data-Rate, expands the payload size and allows faster data phases, making it useful where classic CAN feels cramped. However, classic CAN remains extremely relevant because it is simple, available, and supported by a massive ecosystem. For many maker projects, classic CAN is not the old bicycle in the garage; it is the dependable pickup truck that starts every morning.

Design Rules You Should Not Ignore

CAN is forgiving, but it is not magic. A proper bus needs termination, usually 120-ohm resistors at both physical ends of the main trunk. Stubs should be kept short. Bit rate and cable length are connected: higher speeds require shorter networks, while lower speeds allow longer runs. You also need a common reference ground in many practical systems, proper transceivers, and wiring that respects the physical layer.

The most common beginner mistake is treating CAN like “just two random wires.” It is not. Use twisted pair when possible, terminate the ends, keep topology clean, and do not create a star-shaped monster unless you enjoy debugging reflections with the emotional range of a toaster. A neat CAN bus rewards you with reliability. A sloppy one rewards you with character development.

CAN vs. I2C, SPI, UART, and Ethernet

Choosing CAN does not mean every other bus is wrong. It means you are matching the tool to the job. I2C is excellent for short board-level sensor connections. SPI is great for fast communication between chips on the same board. UART is simple and useful for point-to-point links. Ethernet is powerful for high bandwidth and IP-based systems.

CAN shines when you need several embedded nodes to communicate over a shared cable in a noisy environment with built-in arbitration and error handling. It is especially attractive when each node only needs to exchange small, meaningful messages. A robot arm joint, a battery pack, a greenhouse controller, a motor driver, and a display panel do not always need Ethernet. Sometimes they need a reliable local nervous system.

How to Start a CAN Project Without Losing Your Weekend

Start small. Use two microcontroller boards and a pair of CAN transceivers, or one board with built-in CAN and another with an SPI CAN controller. Add proper termination at both ends. Pick a conservative bit rate, such as 125 kbit/s or 250 kbit/s, while learning. Send a simple heartbeat frame once per second. Then add a sensor frame, a command frame, and a status frame.

Give your messages clear identifiers. Write down what each ID means, what bytes it carries, what units are used, and how often it should be sent. This informal “mini DBC” habit will save you later. The bus does not care whether byte two represents Celsius, motor current, or the emotional state of a haunted skeleton. Humans care. Future you cares most of all.

Practical Example: A Greenhouse CAN Network

Imagine a backyard greenhouse with distributed nodes. One node reads temperature and humidity. Another controls fans. A third watches soil moisture. A fourth manages lighting. A fifth sits near the door with a small display. Instead of running separate signal wires from every sensor to one controller, each node joins a CAN bus.

The temperature node broadcasts readings every two seconds. The fan node listens and turns on when conditions cross a threshold. The display node listens to everything and shows the current state. A logging node stores data to an SD card. If the lighting controller fails, the temperature system can still talk. If the display is unplugged, the fans do not suddenly forget how air works. This is the beauty of distributed embedded design.

Security and Safety Still Matter

CAN was designed for trusted local networks, not hostile internet traffic. In many classic CAN systems, messages are broadcast and accepted based on identifiers, with no built-in encryption or authentication. That is fine for a small isolated project, but it matters in safety-critical or connected systems. If a CAN network touches gateways, wireless links, public interfaces, or expensive moving machinery, you must think carefully about validation, filtering, access control, and fail-safe behavior.

A good CAN design does not blindly trust every message. Nodes should sanity-check values, watch for timeouts, use heartbeats where appropriate, and enter safe states when communication fails. Reliability is not just about getting frames across the wire. It is about making the whole system behave predictably when something goes wrong.

Why CAN Still Feels Modern

CAN has been around for decades, yet it remains useful because it solves a timeless embedded problem: how do small intelligent devices coordinate in the real world? The real world is noisy, dusty, hot, cold, vibrating, wet, and occasionally operated by someone holding a screwdriver like a magic wand. CAN survives because it was built for exactly that sort of environment.

Supercon 2024’s message is not that CAN should replace every network. It is that CAN deserves a place in the modern maker and engineering toolbox. When your project outgrows jumper wires, when UART becomes a gossip chain, when I2C starts pouting over cable length, and when Ethernet feels like bringing a moving truck to deliver a sandwich, CAN may be the sensible middle ground.

Conclusion

The Controller Area Network may have become famous in cars, but it was never limited to dashboards, brake modules, and diagnostic ports. Its strengthsdifferential signaling, multi-master communication, priority arbitration, error handling, affordable hardware, and broad software supportmake it a powerful option for industrial automation, marine systems, robotics, interactive installations, test equipment, and ambitious weekend builds.

Randy Glenn’s Supercon 2024 talk works because it reframes CAN as approachable. You do not need to be an automotive engineer to use it. You need a few nodes, correct wiring, termination, a sensible message plan, and enough curiosity to let your devices talk to each other without turning the project into a cable octopus. Yes, you CAN use CAN outside cars. The pun is unavoidable, but the engineering is solid.