I’m excited to announce a significant usability improvement for all moteus controllers, command line tools and the python library! If your moteus controllers are on firmware version 2025-09-20 or newer and your moteus client tools are at 0.3.91 or newer, (and if you are using a pi3hat, it is on firmware 2025-09-20 or newer) there are some big improvements that you transparently get:

1. You no longer need to assign unique CAN IDs before daisy chaining controllers
2. The python transport lets client programs transparently operate across multiple CAN-FD interfaces simultaneously
3. tview will automatically open all controllers attached to all CAN-FD interfaces on the computer

Let’s dig into what this looks like from the command line, tview and what the practical constraints are.

It has been a minute since there has been a pi3hat firmware release, but we have a new one out now, that fixes a longtime usability issue with the pi3hat as well as improves its ability to drive busses with many devices. The release, 2025-09-20 can be found on github with the source and firmware elf. If you’re not running into problems, there is no real need to upgrade, but read on to see if it is something you might be interested in.

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:

Recently I announced an updated version of the moteus performance analysis tool. It’s development was unique in that I used the Claude Code agent to do basically the entire project, modulo copying the simulation logic from the original mpat tool. It was my first attempt at using any of the LLM based coding agents and I have a few takeaways:

Using the newly data from the newly released moteus performance analysis tool, we’ve gone and updated the rated output currents for each moteus controller. The conventions for such ratings are measured at 24V supply voltage with the default PWM frequency selected.

In addition, each value has a link to the mpat page which shows that value in context, so you can see for instance that the 62A current with maximum cooling for the moteus-x1 requires even more cooling than just a 12V fan alone provides.

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.

Here’s a short and easy to report new feature for moteus. Thanks to Eli Rutan, as of firmware release 2025-07-21, the same sky AMT22 SPI 14/12 bit absolute encoder (formerly CUI Devices), is now supported in moteus firmware. It requires a 5V supply, so can be used with the moteus-c1, moteus-n1 and moteus-x1 in all the ways other external SPI encoders can be used.

Both 12 and 14 bit single turn encoders are supported. Multi-turn variants can be used, although moteus does not use or need the multi-turn functionality.

There are many configurable values and internal firmware limits in the moteus brushless motor controller that result in the output current being less that would exist in an ideal system or less than what was commanded. To date, the only way to know if any of these factors was resulting in limiting behavior was to know all of the possible limiting factors, and look at factor specific diagnostic values one by one to see which was the culprit. Now, as of firmware release 2025-07-21, moteus will report exactly which feature is limiting the output at any given point in time, making that diagnostic process much simpler.

Read on for more details.

moteus first added support for hall effect encoders way back in 2022, when many new encoder types were added. At that time, hall effect sensors were treated basically like any other encoder. However, because of their inherent low resolution, this resulted in them performing much worse than other encoder options, especially at low speed. In practice, very careful tuning of the encoder low pass filter was required to achieve useful performance and that performance would often only be valid in a narrow range of speeds.

Now, as of release 2025-07-21, moteus has a suite of new heuristics which drastically improve the performance of hall effect encoders at all speeds, and make them relatively insensitive to filter bandwidth selection. If you don’t care about the details, just upgrade your firmware following the instructions in the reference manual and be on your way! If you do care about the details, read on for more.

Way back in 2021, I described the approach moteus uses for filtering encoder values and its derivation from the “all-digital phase locked loop”. What I did not realize until now was that the formulas used in that derivation operated based on the “natural frequency” of the filter, not the 3dB cutoff frequency as I had intended. They are related by a constant, but this resulted in the bandwidth of the encoder being higher than expected. Here, I’ll set the record straight, and document how that effects moteus going forward.

TLDR: Now moteus has slightly less audible noise for the same effective control performance. Read on for the details.