Recent improvements to the mjcanfd-usb-1x and the pi3hat were stepping stones to improved reliability for long daisy chains of moteus controllers. Another step in that process is the feature I’ll describe here, hardware CAN ID filtering in the moteus firmware. Let’s talk about how things used to work, what the problems were and how this new feature helps.
It seems that development of the mjcanfd-usb-1x and fdcanusb comes in spurts! After more than a year of silence, but shortly after announcing a new firmware with support for customizable sample points, we have a new firmware release with some exciting improvements, 2025-09-19 on github! The short is that the mjcanfd-usb-1x is now faster and able to successfully drive longer chains of controllers in a high performance pipelined mode. Read on for more details:
CAN-FD communication has a number of configurable parameters in order to specify how long each bit period lasts, what amount of clock skew is permissible, and when to sample the physical layer to clock in each bit. For many CAN 2.0 applications, only the bitrate is configured and the sample point and skew parameters are left to a default. Optimizing them may be necessary if you want to control timing margins over a CAN bus with many hosts. Doing so is often not necessary though, as for CAN 2.0 different hosts can have different sample points and largely still interoperate.
While it may not be technically spring outside, it is spring for product announcements here at mjbots, and I’m excited to announce the next evolution of CAN-FD adapter hardware we’re offering, the mjcanfd-usb-1x:
The major changes from the fdcanusb:
USB-C instead of USB micro
Smaller form factor - 30x18mm
PH3 CAN-FD connector instead of DB9
Less expensive, only $39
This makes the mjcanfd-usb-1x better suited for in-application deployments and just all around better as a development tool. It can be mounted down more easily, uses the same connector and pinout as moteus, and is compatible with our existing PH3 cables.
This is a quick post to highlight two new nice to haves at mjbots.com that have been long requested.
First, is a pre-built JST PH3 CAN-FD cable, initially available in 30cm lengths. It can be used to daisy chain between controllers, or connect up a pi3hat. Use it as is, or cut it and strip the wires to easily build a JST PH3 to pigtail cable.
Second, is a pre-built CAN-FD termination resistor that can be directly plugged into a JST PH3 receptacle on the moteus controller. This uses split termination to achieve 5Mbps bandwidth over longer daisy chains than can be achieved with a simple one-resistor terminator.
The moteus controller, communicates exclusively over CAN-FD for command, telemetry, and diagnostics. It will accept either standard or extended frames, and until now, the ID format in terms of bits looked like the following:
33333222222221111111100000000
43210765432107654321076543210
XXXXXXXXXXXXXQSSSSSSSDDDDDDDD
Where:
If the lower 8 bits matched the configured ID, all the X bits would be completely ignored and moteus would accept the CAN message as if it were destined for itself. This may not be super desirable, as it consumes nearly all of the available CAN-FD addressing space.
On the mjbots discord, people are often looking for the cheapest possible way to command and monitor a moteus controller. One possible solution that comes up over and over again is the CANBed-FD board, as sold by Seeed Studio (and others). I decided to get one of these in house to see if I could make it work:
The first thing I figured out was that the DB-9 connector used a non-standard pinout for CAN_L and CAN_H. I just switched to the terminal block connections instead of the DB-9 to get around that. For the software, I decided to use the acan2517FD Arduino library, as it was quite a bit more robust and featureful than the one provided by Longan Labs.
To date, the pi3hat CAN channels only supported CAN properties suitable for use with moteus controllers. Given that’s what most people are using them for, that’s fine. However, there was no real constraint behind that, just laziness.
Thus, I’ve released new firmware for the pi3hat that supports configuring the bitrate, FD-ness, and other properties of all 5 CAN channels.
Currently only the C++ library exposes the configuration functionality, but it will be easy enough to add to python when someone needs it.
It seems like all the posts I’m writing these days are for new products! Here’s the pi3hat r4.4:
There are two changes from the previous r4.2. First, it now supports voltage inputs up to 44V. Second, in support of future upgrades, the 5th CAN-FD port has been upgraded to support 8Mbps, but downgraded to no longer have a wide common mode voltage range.
THUS, IT IS NOT SAFE TO CONNECT THE CAN-FD PORT ON THE pi3hat r4.4 TO A power_dist r3.X BOARD.
After receiving many requests via youtube, discord, and email, I’ve finally gone ahead, bitten the bullet, and updated all of the moteus tools to be pure python and work in a cross platform manner. Now, the only thing you need to do to install pre-compiled versions of tview and moteus tool on most* platforms is:
pip3 install moteus_gui
python3 -m moteus_gui.tview # (or maybe just tview)
python3 -m moteus.moteus_tool # (or maybe just moteus_tool)
I’ve personally tested these on Linux, Windows, and Raspberry Pi, and others have at least verified basic operation on Macs. Python 3.7 or greater is required.