Blog
Recent Posts
CAN Bus Troubleshooting with the PiCAN HATs: Why the Board Is Probably Not the Problem
Posted by on
The PiCAN product line has become the go-to CAN Bus interface solution for Raspberry Pi developers, system integrators, educators, and industrial engineers worldwide. From entry-level CAN Bus connectivity to advanced dual-channel CAN, CAN FD, GPS/GNSS integration, RS232, RS485, and real-time industrial networking, PiCAN boards combine robust hardware design with seamless Raspberry Pi integration. Whether you are developing automotive diagnostics, industrial control systems, marine electronics, fleet management solutions, or embedded IoT applications, the PiCAN family provides reliable, field-proven connectivity backed by extensive software support and a large global user community. Designed for professional applications yet accessible to hobbyists and researchers, PiCAN products deliver the flexibility, performance, and dependability needed to bring CAN Bus projects from concept to deployment.
One of the most common support requests we receive begins with the assumption that the PiCAN board is defective. In reality, after many years of supporting CAN bus applications, we have learned that almost every communication issue originates outside the PiCAN board itself. Incorrect termination, wiring mistakes, missing grounds, bit-rate mismatches, and connector problems account for the overwhelming majority of CAN bus failures. Before suspecting the hardware, it pays to understand how a CAN network actually works.
Step 1: Verify the CAN Interface Is Running
The first step is to make sure the CAN controller has been configured correctly.
For SocketCAN systems, you can verify operation using:
ifconfig can0
or
ip -details link show can0
A properly configured interface should show:
can0: UP
If the interface is down, no CAN communication can occur regardless of the wiring.
Step 2: Check the CAN Bus Bit Rate
One of the most common mistakes is a bit-rate mismatch.
CAN is not like Ethernet where devices automatically negotiate speeds.
Every node on the network must use exactly the same bit rate.
Common bit rates include:
|
Bit Rate |
Typical Application |
|---|---|
|
125 kbps |
Industrial automation |
|
250 kbps |
SAE J1939 |
|
500 kbps |
Industrial and automotive |
|
1 Mbps |
High-speed CAN |
If one node is operating at 250 kbps and another at 500 kbps, communication is impossible.
The CAN controller will see activity on the bus but will interpret it as errors.
Always verify the bit rate of every device connected to the network.
Step 3: Understand CAN Bus Termination
If CAN troubleshooting had a Hall of Fame, missing termination resistors would be the undisputed champion.
A CAN network requires two termination resistors.
Each resistor has a value of:
120 Ohms
One resistor is installed at each physical end of the network.
The result is a measured resistance between CAN_H and CAN_L of approximately:
60 Ohms
when power is removed from the network.
The CAN bus should look like this:
120Ω 120Ω
| |
Node ---- Node ---- Node ---- Node
Not this:
120Ω
|
Node ---- Node ---- Node ---- Node
And definitely not this:
Node ---- Node ---- Node ---- Node
Without proper termination, signal reflections occur, causing corrupted messages, intermittent communication failures, and endless frustration.
Step 4: Using the PiCAN J1 Termination Jumper
Most PiCAN boards include jumper J1.
This jumper enables the onboard 120-Ohm termination resistor.
The purpose of J1 is to simplify development and testing.
When J1 is installed:
Termination Enabled
When J1 is removed:
Termination Disabled
Whether J1 should be installed depends entirely on the physical location of the PiCAN board within the CAN network.
PiCAN at the End of the Network
If the Raspberry Pi with the PiCAN board is physically located at one end of the bus:
PiCAN ---- Node ---- Node ---- 120Ω
^
J1 Enabled
J1 should be installed.
PiCAN in the Middle of the Network
If the PiCAN board is somewhere in the middle:
120Ω ---- Node ---- PiCAN ---- Node ---- 120Ω
^
J1 Disabled
J1 must be removed.
Installing extra termination resistors is just as problematic as having too few.
Step 5: Measure the Bus Resistance
A simple multimeter can solve many CAN mysteries.
Turn off power to the network.
Measure resistance between:
CAN_H and CAN_L
Expected readings:
|
Resistance |
Meaning |
|---|---|
|
~60 Ohms |
Correct termination |
|
~120 Ohms |
Missing one terminator |
|
Infinite |
No termination or broken wiring |
|
~40 Ohms |
Too many terminators |
|
Very low resistance |
Wiring fault or short circuit |
This single measurement can often identify the problem in less than 30 seconds.
Step 6: Verify CAN_H and CAN_L Wiring
It sounds obvious, but it happens more often than you might think.
Check that:
CAN_H → CAN_H
CAN_L → CAN_L
and not:
CAN_H → CAN_L
CAN_L → CAN_H
Crossed wires will prevent communication entirely.
Some devices label the signals differently:
CANH
CAN-H
H
CANL
CAN-L
L
Always verify the documentation.
Step 7: Check Ground Connections
A CAN bus is designed for differential signaling and is relatively tolerant of noise.
However, devices still need a common reference.
Many CAN communication problems disappear after connecting grounds properly.
A typical connection includes:
CAN_H
CAN_L
GND
Neglecting the ground connection may lead to intermittent operation, especially with longer cable runs.
Step 8: Look for Error Frames
The CAN protocol is exceptionally good at detecting communication problems.
When something is wrong, nodes generate error frames and increment their error counters.
Common causes include:
- Incorrect bit rate
- Missing termination
- Excessive bus length
- Faulty wiring
- Ground problems
The CAN controller is usually trying to tell you something.
Listen to it.
Step 9: Test with a Simple Setup
When troubleshooting becomes complicated, simplify.
Disconnect everything except:
- Raspberry Pi with PiCAN
- One known-good CAN node
- Proper termination at both ends
A two-node network eliminates many variables and often reveals the issue quickly.
The Reality: The PiCAN Board Is Usually Innocent
Engineers often spend hours investigating software settings, drivers, and hardware before discovering:
- A loose connector
- Missing termination
- Incorrect bit rate
- Reversed CAN wires
- Missing ground
The PiCAN series has proven itself in countless applications ranging from industrial automation to vehicle diagnostics and marine systems.
Like any electronic device, hardware failures are theoretically possible.
However, in practice they are exceedingly rare.
When CAN communication fails, the odds overwhelmingly favor an external wiring issue rather than a defective PiCAN board.
In other words:
Before blaming the PiCAN board, grab a multimeter.
The bus is usually trying to tell you exactly what’s wrong.
You just need to listen.
Practical Python Programming for IoT: Build advanced IoT projects using a Raspberry Pi 4, MQTT, RESTful APIs, WebSockets, and Python 3
The Internet of Things (IoT) is transforming the way devices interact, communicate, and automate everyday tasks. Combining the versatility of Python with the power of Raspberry Pi, this practical guide teaches you how to design and build connected systems that bridge the gap between software and hardware. Through hands-on projects and real-world examples, you will learn how sensors, actuators, and cloud services work together to create intelligent IoT applications.
Starting with IoT networking fundamentals, including REST APIs, WebSockets, and MQTT, the book then introduces electronics, GPIO interfacing, and circuit design before moving on to practical projects involving sensors, motors, motion detection, temperature monitoring, and automation. Along the way, you will integrate popular IoT platforms such as ThingSpeak and IFTTT, explore modern Python programming techniques, and develop complete end-to-end IoT solutions. By the end of the book, you will have the skills and confidence to build sophisticated IoT systems using Python and Raspberry Pi. More information...
ESP32 Processor: Adding CAN/CAN-FD Controllers per SPI Port
This post is an excerpt from our application note Controller Area Network (CAN) Development with ESP32. The internal CAN controller SJA1000 does not support CAN-FD and is not CAN-FD tolerant. To use CAN-FD with the ESP32, you need to employ CAN-FD breakout boards that are accessible per the ESP32’s SPI ports. Note: The SPI ports are not [...]
ESP32: CAN Bus Programming with MCP2515 and MCP2517FD
For good reasons, the ESP32 processor is a prevalent choice for embedded hardware development. Besides considerable memory resources, it provides various hardware features for many applications, most prominently the Internet of Things (IoT). All that comes with more than reasonable price tags, specifically when you use one of the multiple ESP32 development modules. And since [...]
ESP32 Triple CAN Bus Application Through Adding Two MCP2515 Ports
The first question that may arise when talking about accessing the MCP2515 CAN Bus controller per ESP32 may be, "Why would you need an MCP2515 controller when the ESP32 comes with an internal CAN port?" Yes, I found this question in one of the online forums while researching this particular topic. The answer is easy: [...]
Four Channel CAN Bus to USB Gateway Using The Arduino Due
In the past, I frequently received inquiries regarding the availability of a four-channel CAN Bus gateway. Such devices exist in the marketplace; however, they are usually costly, and they don't support easy customization or programming. While we at Copperhill Technologies have the ability to create such a gateway, this is primarily a matter of market [...]
MCP2515 CAN Bus Monitor Demo Board Kit Forms A Simple Two-Node CAN Bus Network
The MCP2515 is a low pin count stand-alone CAN Bus controller which interfaces to a microcontroller via a standard Serial Peripheral Interface (SPI). The MCP2515 is a second-generation stand-alone CAN Bus controller. It is pin and function compatible with the MCP2510 and also includes upgraded features like faster throughput, data byte filtering, and support for time-triggered protocols.The feature [...]
SAE J1939 Programming with Arduino - The CAN Bus Interface
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. While the code as introduced in the previous chapter was well designed and thus is highly efficient, I inserted yet another software layer between the CAN Bus interface and the ARD1939 protocol stack.I wrote the ARD1939 source code in plain C [...]
SAE J1939 Programming with Arduino - MCP2515 Function Calls
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. There are further functions, among others, for message filtering and settings masks, and they are worth being checked out for more sophisticated functions, but they are not necessary for simple CAN communication tasks.The implementation of the MPC2515 library is fairly easy: Open Arduino, [...]
SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino - The MCP2515 Library
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Microchip Technology’s MCP2515 is a stand-alone Controller Area Network (CAN Bus) controller that implements the CAN 2.0B specification. It is capable of transmitting and receiving both standard (11-bit) and extended (29-bit) data and remote frames. The MCP2515 has two acceptance masks and six acceptance filters [...]
SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino - Microchip MCP2515 CAN Bus Controller
This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino. Microchip Technology’s MCP2515 is a stand-alone Controller Area Network (CAN Bus) controller that implements the CAN specification, version 2.0B. It is capable of transmitting and receiving both standard and extended data and remote frames. The MCP2515 has two acceptance masks and six [...]
Loading... Please wait...
