What is Ultrawipf/OpenFFBoard?

OpenFFBoard is C firmware for a USB HID force feedback interface, targeting direct drive steering wheels and joysticks, with a class based main system, swappable motor driver and encoder back ends, and a separate configurator GUI. It suits builders who want to own the whole force feedback stack, and it does not suit people who want a working wheel without soldering.

Can I use Ultrawipf/OpenFFBoard commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is Ultrawipf/OpenFFBoard still maintained?

Yes. The repository last received commits 3 days ago.

What programming language is Ultrawipf/OpenFFBoard written in?

Mainly C, according to GitHub's language statistics.

OpenFFBoard: open source force feedback firmware

At a glance

What is it?: OpenFFBoard is C firmware for a USB HID force feedback interface, targeting direct drive steering wheels and joysticks, with a class based main system, swappable motor driver and encoder back ends, and a separate configurator GUI. It suits builders who want to own the whole force feedback stack, and it does not suit people who want a working wheel without soldering.
Who is it for?: Adopt OpenFFBoard if you are building a direct drive wheel or joystick and want the force feedback firmware, the hardware designs and the configuration tool to be open and modifiable. Do not adopt it if you need a finished, supported product, since the project states the software is experimental, is intended for advanced users, and that features may contain errors and can change at any time.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 3 days ago.
What is it written in?: Mainly C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Maintained by the Hysen Labs editorial team. Last updated October 20, 2026. 8 min read

One firmware, several device personalities selected at runtime

OpenFFBoard is an open source force feedback interface with the goal of creating a platform for highly compatible FFB simulation devices like steering wheels and joysticks. It is firmware, not hardware, and the hardware designs live in a separate OpenFFBoard-hardware repository, while the configuration GUI lives in OpenFFBoard-configurator.

The interesting architectural point is that the device type is not fixed in the firmware. The main modes cover a FFB Wheel, which is a USB one axis force feedback device with HID FFB support plus multiple analog axis inputs and digital buttons, and a FFB Joystick, which is a USB two axis force feedback device. There is an EXT FFB Gamepad mode, a USB two axis gamepad device without HID FFB, which is for simple non FFB devices or for sending custom FFB data through commands. And there are two CAN modes: one that sends all supported digital and analog inputs as CAN packets to a main FFBoard, and a GVRET compatible CAN interface for bus debugging.

That list describes a firmware that can present itself to a game as a wheel, a joystick, a gamepad or a CAN debugging interface, from the same board. The FFB wheel and joystick modes are what the project is mainly designed for, and the documentation is explicit that it is optimized for the OpenFFBoard board and mainly designed for use with DD steering wheels.

The audience is therefore makers. The homepage for the project is a Hackaday.io project page, and the README says plainly that the software is experimental and intended for advanced users, with features that may contain errors and can change at any time.

The class based main system lets you replace the whole device behaviour

The extension mechanism is the strongest argument for building on this firmware rather than writing your own USB stack.

The firmware is class based in a way that the whole main class can be changed at runtime, and with it even the USB device and the complete behaviour of the firmware. For FFB, the motor drivers, button sources and encoders also have their own interfaces, so a new wheel axis can be added without touching the rest of the stack.

The modular structure means you are free to implement your own main classes, and the project points at the FFBoardMain and ExampleMain class files in the UserExtensions folder as the place to start. Helper functions for parsing CDC commands and for accessing the flash are included, so a custom main class inherits the runtime parameter channel and the storage access rather than reimplementing them.

That runtime configuration channel is a unified command system supporting different interfaces, and the project recommends it for setting parameters at runtime. The relevant file is CommandHandler.h and the example main class. For a device that sits under a desk and is tuned by feel, runtime parameters matter, since a driver gain or an encoder offset is exactly the value you want to adjust while the wheel is mounted rather than while it is on a bench.

The practical consequence is that the same binary can be a wheel today and a joystick after a configuration change, and a third-party device can be added by writing one class rather than by forking the firmware.

Six motor driver back ends, and the TMC4671 is the one with the caveat

The supported motor driver table is the part of the documentation to read most carefully, because the support levels differ sharply between options.

The OpenFFBoard TMC4671 is the integrated solution, on SPI, and it supports three phase servo (BLDC) motors, two phase stepper motors with an encoder, and DC motors. It is the only entry with yes for one channel wheel support and limited for two channel joystick support, it supports absolute encoders, it supports encoder forwarding, and it is the only entry with yes for the dual interface encoder column.

External drivers are supported over CAN. ODrive and VESC both give yes for one channel wheel support and yes for two channel joystick support, and both list three phase servo motors. ODrive accepts ABZ, SPI and internal encoders, while VESC is listed with ABZ. Neither supports encoder forwarding, and MyActuator, which integrates the servo itself and uses an internal encoder, is in the same category.

The PWM option is the widest in motor terms, accepting any external driver with PWM plus Dir, Centered, RC PPM or 2x PWM outputs, and any FFBoard encoder, but it has no for two channel joystick support and no encoder forwarding.

Simplemotion is the odd one out, since it needs an RS232 interface with an adapter, and is marked limited for one channel wheel support and no for two channel joystick support.

The practical read is that the TMC4671 board is the smoothest path for a one axis wheel, while the two axis joystick story is better served by an external ODrive or VESC over CAN.

Encoder support is narrow, and only some of it is absolute

The encoder table is shorter and has a sharper limitation than the driver table, and the limitation is about whether the firmware knows the absolute position of the shaft.

ABZ quadrature is supported directly by the firmware and the main board, and it is the only entry marked as not absolute. BISS-C is supported over SPI with an adapter and is absolute. MagnTek encoders, specifically the MT6825 and MT6835, are supported over SPI plus ABZ and are absolute. SSI is supported over SPI and is absolute.

The reason this matters is the encoder forwarding column in the driver table. The TMC4671 can take its encoder input from an external source, which means the encoder does not have to sit on the motor driver board. A wheel with an SSI or MagnTek absolute encoder on the steering axis can drive a TMC4671 over the forwarding path. ODrive, VESC, MyActuator, PWM and Simplemotion all carry no for encoder forwarding, so their encoders have to reach the driver by their own supported route.

The second thing to notice is what is absent. There is no incremental encoder other than ABZ, no magnetic encoders in the hall sense, and no resolver support in the list. For a builder choosing a sensor, the table is the specification, and the practical trap is buying a BISS-C sensor and then finding it needs the adapter that the table flags with a warning marker.

Building the software: submodules, matching GUI versions and the release channel

The repository is a firmware project with sibling projects for hardware and for the configuration tool, and the submodules are pulled with two commands.

bash

git submodule init
git submodule update

The repository also carries a Configurator directory, a Firmware directory, a Hardware directory and a doc directory, alongside the CHANGELOG.md and the GitHub wiki. The README notes that the LICENSE file applies to all other parts in the Firmware/FFBoard folder, and that some parts of the software may contain third party libraries and source code licenced under different terms, with the applicable licence found in the header of the file. That is the normal arrangement for embedded code that vendors driver libraries, and it is worth reading the headers of the files you copy into your own project.

The versioning rule is the one thing to internalise: updates often require matching firmware and GUI versions. The configuration GUI is a separate repository, so a firmware upgrade is not self-contained. If you upgrade the board without upgrading the configurator, you may find settings that no longer line up, and the diagnosis is not obvious from the symptom.

For binaries, the GitHub release section is the place to go, and the recent tags show an active line: v1.17.0-dev on 2026-03-18, v1.17.0 on 2026-04-17, and v1.17.1 on 2026-07-24. A separate dev tag alongside the stable one is a sign that users are expected to test a pre-release build.

The wiki is the documentation. There is a commands page listing the available commands, a games setup page with a compatibility list, and the Doxygen site for the code summary of the latest stable version.

Where OpenFFBoard is the wrong choice

There are clear cases where this project is the wrong tool, and the project itself is candid about the first one.

The software is experimental and intended for advanced users, features may contain errors and can change at any time, and the compatibility story is documented through a wiki page rather than a guarantee. If you want a force feedback wheel that works out of the box with a warranty behind it, this is the wrong shape of project, and the fact that the design work lives on a Hackaday page tells you where the effort is going.

Second, the cost of entry is not only software. You need the board, and while the hardware designs are published under OpenFFBoard-hardware, building the board is a soldering exercise. A USB HID device that also drives a brushless motor over SPI, reads an absolute encoder and speaks CAN is not a weekend project if you have not done embedded work before.

Third, the feature matrix constrains designs. If you want a two axis joystick, the integrated TMC4671 path is marked limited, so you are pushed towards an external ODrive or VESC over CAN, which adds cost and a second device to configure. If your encoder is not ABZ, BISS-C, MagnTek or SSI, the table does not support it, and there is no indication of a generic incremental input.

Fourth, there is no compatibility guarantee for games in the code itself. The project points to a compatibility list on the wiki, which is community-maintained knowledge rather than a tested matrix, so a title that behaves oddly on a commercial product may behave oddly here too, and you will be the one reading the source.

Editorial conclusion

Adopt OpenFFBoard if you are building a direct drive wheel or joystick and want the force feedback firmware, the hardware designs and the configuration tool to be open and modifiable. Do not adopt it if you need a finished, supported product, since the project states the software is experimental, is intended for advanced users, and that features may contain errors and can change at any time. Before you start, confirm the firmware and configurator versions match, because updates often require it, and check that your motor driver and encoder are in the supported tables, in particular the TMC4671 for two axis joystick use, which is marked as limited.

Frequently asked questions

What device types can OpenFFBoard present itself as?

The firmware offers an FFB Wheel mode, a USB one axis HID force feedback device, an FFB Joystick mode with two axes, an EXT FFB Gamepad mode without HID FFB, a CAN remote mode for analog and digital inputs, and a GVRET compatible CAN interface for bus debugging.

Which motor drivers does OpenFFBoard support?

The documented list is the OpenFFBoard TMC4671 on SPI, ODrive and VESC over CAN, MyActuator over CAN, PWM for external drivers, and Simplemotion over RS232 with an adapter. The TMC4671 is the only one marked as limited for two channel joystick support.

Which encoders can OpenFFBoard read directly?

ABZ quadrature, which is not absolute, BISS-C over SPI with an adapter, the MagnTek MT6825 and MT6835 over SPI plus ABZ, and SSI over SPI. Only the TMC4671 entry supports forwarding an external encoder to the motor driver.

How do I build the OpenFFBoard firmware from source?

Pull the submodules with git submodule init and git submodule update, then use the configurator GUI to set the parameters. The README stresses that updates often require matching firmware and GUI versions, since the configuration tool lives in the separate OpenFFBoard-configurator repository.

Can I add my own device behaviour to OpenFFBoard?

Yes. The firmware is class based so the whole main class can be changed at runtime, along with the USB device and the complete behaviour, and you can implement your own main classes by starting from the FFBoardMain and ExampleMain files in the UserExtensions folder, using the unified command system in CommandHandler.h for runtime parameters.

Official sources

Was this useful?