CAN Part 1 - Hardware

The CAN bus.  Where do I begin.  I've said before that there are people who spend their entire career working on the CAN bus, and its true.  I'm not one of them but I do work with CAN often, and the more I learn, the more I realize I don't know enough.  So this series of posts is intended to help demystify some of the CAN bus that we use for various communications.  First lets focus narrowly on the hardware, and more specifically we will first focus on the most common CAN setup which is dual wire high speed CAN.  This first entry is going to try to cover the basics, and you won't hear much about how to actually do anything in software.  But this is an important step none the less to understand the differences, wiring techniques, and features of various CAN buses.


Before we get started on the discussions of various CAN software and communication protocols.  Lets first talk about what CAN is physically.  This is not CAN:

This is a USB to serial converter.  The 9 pin connector known as DB9 is a common way to connect hardware that communicates over RS-232 and RS-485.  This same DB9 connector is the most common interface you'll find for CAN hardware as well.  But just because they share the same connector, does not mean they communicate with the same protocol.  If you have a DB9 on your computer, it does not mean you have CAN.  If you can manage to shove a USB cable into your ethernet port, don't expect it to work just because it fits.  

There do exist USB to CAN converters like this ValueCAN from Intrepid, with other common competitors like Vector, NI, and Kvaser having similar low cost products.
These look similar to USB to serial converters, but talk very different protocols.  The first major difference between serial and CAN is that with a two wire serial interface you typically only talk to one device at a time.  With the transmit wire on one end, getting wired to the receive on the other. 

With CAN you can connect potentially hundreds of devices together.  This is because each CAN device that is two wire has a CAN-High and a CAN-Low wire.  But instead of swapping wires like serial does, you wire up all the CAN-Highs together, and all the CAN-Lows together.  In a typical two wire high speed CAN setup, you will also have two 120 ohm resistors between high and low on each end of the bus.  

These resistors are optional in some cases and depending on the length and number of nodes, can be replaced by a single 60 ohm resistor, or some other configuration.  With long CAN lines you may get signal reflection, causing corrupt messages.  CAN is pretty robust and even dropped messages will be resent.  So even if you have no resistor in place there is a chance it will work fine.  But if you are getting lots of lost messages or communication issues check that you have the appropriate wiring.  One analogy I've come up is to state that the resistors are like wave breakers in a pool, and the best placement of these would be at each end of a pool, so that the wave won't come back after hitting a wall.

Serial and CAN also vary quite a bit when it comes to their features.  Lets compare RS-232 serial to a dual wire high speed CAN bus.

Serial and CAN Comparison
RS-232 Serial Dual Wire High Speed CAN
Dual wire system with TX and RX usually seen as a DB-9. Dual wire system with CAN High and CAN Low usually seen as a DB-9
Only two nodes can ever be on the bus at once. Potentially 100s of nodes.
Things like priority, ACK, checksum, retransmit, end of message, and message length can be done through software. The hardware transceiver supports priority, ACK, CRC, retransmit, end of message, and message length.
Standard baud rates up to 115.2 Kbit, with some support for higher. Standard baud rates up to 1 Mbit, with CAN-FD up to 8 Mbit.
Usually request / response. Usually periodic transmission
Much cheaper to implement, and most industrial PC come with it built in. More expensive to implement.

Requires two termination resistors

Just like how there isn't just one serial protocol, there also isn't just one CAN protocol.  As mentioned earlier the typical CAN setup is with two wires, and the most common baud rate is 500K.  This would be considered High Speed CAN.  There is also Low-Speed, Medium-Speed, CAN-FD, and a few other variants.  There are also CAN setups that are dual wire, and some that are single wire, with the devices on the bus sharing the same ground.

Dual Wire Configurations

In a dual wire configuration, only CAN_H and CAN_L need to be wired unless the specific hardware requires power.  Common shielding and ground are also usually not necessary for testing purposes but maybe desired in long buses or buses when there are many nodes.  Ideally this is with twisted shielded pairs of wires going from one node to the next.  A star-like wiring pattern should not be used, but instead a single long chain of nodes.  The distance from a bus node and the bus should be kept to a minimum.  This sometimes means using 4 wires, CAN_H In, CAN_L In, CAN_H Out, and CAN_L Out.

The highest expected voltage potential between the CAN_H and CAN_L is 5V.

High Speed CAN (Automotive SAE Class C)

Again this is the most common type of CAN bus seen, and is wired using the example from earlier.  Once wired, every node on the bus must be set to the same baud rate which can range from 125K to 1M.

Low Speed Fault-Tolerant (Automotive SAE Class B)

Manufacturers may call this Low Speed, Fault-Tolerant, or LSFT.  This is still a dual wire configuration but each node on the bus has an internal termination.  The baud rate of this type of configuration can vary from 10K up to 125K.


CAN-FD is relatively new and stands for Flexible Data Rates.  As automotive manufacturers pushed CAN to its limits they realized they wanted ways to send and receive more data and faster.  Several software protocols were made to help with this but at the end of the day the baud rate, and payload size was what was limiting the throughput.  The new CAN-FD still uses the same High Speed CAN wiring scheme and can use the same existing buses.  The only thing that is needed is to have upgraded CAN transceivers on each node on the bus.  With this the baud rates can be increased to 8M, and the payload size can increase up to 64 bytes, while all other CAN interfaces are limited to 8.  

Most CAN hardware is not CAN-FD compatible, but several of NI's hardware is. For more information on CAN-FD checkout Part 14 of the CAN Blog.

Single Wire Configurations

Single wire CAN is as the name implies, needs only a single wire connected between all nodes on the bus.  The only other requirement is that all the nodes be powered from the same ground.  Wiring is simplified because all that is required is the single CAN_H in the diagram below is wired to all the devices, and then all device need the same ground, which is easy to do if all devices get their power from the same source like a battery.  Twisted shielded pairs are not necessary but as a result the stable baud rates are decreased.

Single wire CAN can operate in a slow speed which is 33.3K or a high speed which is 83.8K.

High Voltage Wake Up

A unique feature of the single wire interface is the high voltage wake up.  High voltage in this case is quite relative and just means that the voltage will be at the voltage of the battery which in automotive is typically 13.8 volts but most hardware can range from 9V to 24V.  As mentioned in the dual wire configuration the highest expected voltage between CAN_H and CAN_L is 5V.  In the single wire configuration this is true for the voltage between CAN_H and Ground, except when high voltage is enabled, and then the differential will be VBat.  This allows for some devices on the bus to go into a low power sleep mode and draw very little power.  When the voltage above 5V is seen on CAN_H the device can wake up and start operating again.  When using the high voltage wake up feature it is usually only used for a short time, and then the bus goes back to operating like normal.  This feature is software selectable in both NI and Intrepid hardware.

PC Hardware Options

Now once you know what type of bus you are using, the next thing to be considered is what hardware is needed to connect a bus up to my PC for reading and writing data.

CAN-FD Hardware

If you need a CAN-FD bus then you have only a couple of options with my recommendation being the NI XNet line of hardware, which is in the PCI, PXI, cDAQ, and USB form factors.  There are a few other vendors that have some support like AVT, and Vector, but since their driver support for external interfaces isn't as mature as NI's API I'd stick with them for now.

CAN-FD Hardware
Hardware Cost Notes
USB-8502/1 - USB-8502/2 $550-$750 USB single or dual port high speed, and FD
PCI-8512 $1,201 Single port, high speed, FD
PCI-8513 $1,568 Single port, high speed, FD, low speed, and single wire, software selectable
PCI -8512/2 $1,806 Dual port high speed, and FD
PCI-8513/2 $2,285 Dual port, high speed, FD, low speed, and single wire, software selectable
PXI-8512 $1,167 Single port high speed, and FD
PXI-8513 $1,524 Single port, high speed, FD, low speed, and single wire, software selectable
PXI-8512/2 $1,754 Dual port high speed, and FD
PXI-8513/2 $2,220 Dual port, high speed, FD, low speed, and single wire, software selectable transceiver
PXIe-8510 $1,987-$4,122 1 to 6 ports, high speed, and FD
NI-9862 $746 cDAQ/cRIO single port high speed, and FD
NI-9860 $937-$1,324 cDAQ/cRIO single or dual port high speed, and FD

Single Wire Hardware

If you need a single wire CAN interface your options are again limited.  NI has a couple of software selectable transceivers in the PCI or PXI platform only.  Outside of NI I've had success with using the Intripid line of hardware and used the single wire bus on a NeoVI Fire.  The outdated LabVIEW drivers function fine, and the documentation explains how to use the high voltage wake up feature, despite it not being in the LabVIEW driver.  This is a very cost competitive device if multiple buses are needed since it includes 3 dual wire high speed CAN buses, one dual wire medium speed CAN bus, one single wire CAN, and 4 LIN buses, and a few simple analog inputs, for $2,000 in a single USB form factor.  The drivers are done through a Windows compiled DLL so using it on embedded hardware or other operating systems will be quite difficult.  Where the NI solutions clearly work well with any NI platform like cRIO, embedded cDAQ, RT Linux, and others.  Another option might be AVT and their AVT-852 or AVT-853 USB or Ethernet based devices.  I've never used the single wire option on this hardware but looks promising with multiple protocols and interfaces for the lowest price of them all.

Single Wire CAN Hardware
Hardware Cost Notes
PCI-8513 $1,568 Single port, high speed, FD, low speed, and single wire, software selectable
PCI-8513/2 $2,285 Dual port, high speed, FD, low speed, and single wire, software selectable 
PXI-8513 $1,524 Single port, high speed, FD, low speed, and single wire, software selectable
PXI-8513/2 $2,220 Dual port, high speed, FD, low speed, and single wire, software selectable
neoVI FIRE $1,995 USB 3 high speed, 1 medium speed, 1 single wire, 1 low speed, 4 LIN
AVT-853 ~$400 Ethernet interface, 1 high speed, 1 high speed or single wire, multiple built in protocols like ISO 15765, J1939 and others

Low Speed Hardware

The options here are again basically just NI's offerings, and Intrepid's neoVI FIRE.  I'm not going to list all the options here, but NI has offerings in PCI, PXI, cDAQ, cRIO, and USB platforms.

High Speed Hardware

If your needs are for the more common dual wire high speed bus, then you are in luck.  Not only do all of the CAN-FD options mentioned earlier work, but there are several other options from NI, and other manufacturers like Kvasar, Vector, and more.  NI has two basic CAN platforms, NI-CAN which is older and NI-Xnet which is newer.  Along with each hardware type is a different API.  The newer XNet hardware can have compatibility drivers installed so that they can use the older NI-CAN API but honestly the XNet API is much easier to work with when you are doing anything other than basic frame reading and writing.  The APIs for other manufactures are basically like the older NI-CAN API with support for reading and writing raw frames and not much else.  The options here and plentiful so I won't list them all, but I will add some of the hardware I've used outside of NI that I've had success with.

Single Wire CAN Hardware
Hardware Cost Notes
neoVI FIRE $1,995 USB 3 high speed, 1 medium speed, 1 single wire, 1 low speed, 4 LIN
Vector CANcase XL ~$1,000 USB dual port, high speed
Vector VN1630 ~$2,000 USB 2 or 4 port, high speed and CAN-FD
Kvaser USBCAN Professional $1,100 USB dual port, high speed
AVT ~$400 USB or TCP, multiple built in protocols, and multiple interfaces including analog LIN and CAN
Lawicel CAN232 $120 USB or RS232, single high speed.
Teensy 3.1/3.2 Microcontroller ~$30 Custom C++ code needed but the library is available

So with such a large range in price what's the difference?  Are all CAN hardware the same?  Not quite but most might share some of the low level hardware.  The CAN transceiver, which is the actual chip doing the heavy lifting, is likely the same between several manufacturers.  The most common high speed transceiver I've seen is the MCP2551, which is often paired with the MCP2515.  The result is high speed CAN on one side, and SPI on the other.  But if your microcontroller interfaces with the CAN bus like the Teensy line then all that is needed is an MCP2551.

Which to Choose?

So if these two chips are in several of the manufacturers devices why the price difference?  Well NI's offerings generally do CAN-FD and not just high speed, so it is using a different transceiver.  But the main benefit is support, and software tools.  NI wants you to buy NI hardware so you can use it with LabVIEW, Vector wants you to buy Vector hardware so you can use it with their software.  Intrepid is the same way, and Kvaser to some extent.  So while a Vector CANCase may work great with CANAlyzer, expect to pay thousands of dollars, for their software packages.  But we aren't interested in that, what we want is to use our hardware, with our software.  And for that we are at the mercy of whatever drivers are provided.  All the devices I've listed can work with LabVIEW and have some drivers, but the clear winner when it comes to software and support is the NI XNet line of hardware.

Part 2...

So in the next part of this series I'm going to start with the best option, and talk about the NI XNet API along with NI's older NI-CAN API.  We'll also discuss what hardware works with what, and some examples on how to use it.  Then later we'll talk about the other hardware options, and why they are a bit harder to work with.