Teensy 4.1 as a DMA input device
The full Teensy 4.1 build: soldering the host pads, flashing with the Teensy Loader, wiring order, serial or network control, report rates, descriptor work and common failures.
Short answer
Solder a 5-pin header to the host pads of the 600 MHz Teensy 4.1, then flash passthrough firmware with the Teensy Loader. Plug the mouse into the host port and the device port into the game PC, then drive the board over serial.
On this page12
- What the Teensy 4.1 is
- Why choose a Teensy over a ready-made device?
- How to solder the USB host port
- What software you need and where the files are
- How to flash the firmware and test the host port
- In what order to connect the cables
- Choosing the control link and setting up the cheat
- Does a higher report rate help?
- How to change the USB descriptor
- Common Teensy problems and fixes
- Common Teensy questions
- Sources
What the Teensy 4.1 is
The Teensy 4.1 is a general-purpose microcontroller board from PJRC that was never designed for this job. That is why it is cheap, and also why it becomes the most capable of these input devices once you have done the work.
- Microcontroller
- NXP i.MX RT1062, ARM Cortex-M7 with a hardware floating-point unit
- Clock
- 600 MHz stock, selectable in the IDE. Do not overclock it for this job
- Flash
- Around 8 MB (7936 K), far more than any passthrough firmware needs
- RAM
- 1024 K total, 512 K of it tightly coupled to the core
- Device port
- The micro-USB socket. USB 2.0 high speed, 480 Mbit/s. This is the end that faces the game PC
- Host port
- Five through-hole pads on the board, unpopulated from the factory. Runs at 480, 12 or 1.5 Mbit/s depending on what you plug in. This is the end your mouse goes into
- Host 5V
- Switched by the chip through a current-limit switch. The pads carry no power until the firmware calls the host library's begin function
- Hardware serial
- Eight UARTs, if you want a serial link that is not the USB device port
- Ethernet
- 10/100 capable, but the magjack is a separate kit you solder on. Not required for a serial build
- Programming
- Teensy Loader, driven automatically by the Arduino IDE once Teensyduino is installed. A physical Program button forces the bootloader
Why choose a Teensy over a ready-made device?
There are three reasons, listed in order of how often each one is the real reason. First, you compile the firmware yourself, so you decide which USB descriptor the game PC sees and how often reports are sent, which no ready-made device lets you do. Second, the host and device controllers are fully independent, so passthrough does not compete with injection for bandwidth. Third, it is cheap. The cost is that you become the vendor: when it misbehaves there is no support channel, only your own wiring and your own code.
Warning
How to solder the USB host port
This is the only soldering you must do, and it decides whether the rest of the build works. The host pads are five plated through-holes, unpopulated from the factory, and they carry host 5V, the D-minus and D-plus pair, and ground. Follow the silkscreen and the official pinout card for the order, and do not guess or trust a diagram from a forum post.
- Identify the five host pads on your board and confirm their order against PJRC's own pinout card for the Teensy 4.1
- Fit a 5-pin male header into the holes, or prepare the matching USB host cable that PJRC sells for the Teensy 3.6 and 4.1
- Solder with a fine tip and a low-temperature alloy, because these are small pads on a dense board and a fat tip will bridge them
- Inspect every joint under good light. A dull, grainy or balled-up joint is a cold joint, and it is the most common reason a host port enumerates nothing
- Before you power anything, use a multimeter on continuity to check for bridges between D-minus and D-plus
- If you use bare wires instead of the cable, keep the D-minus and D-plus pair short and equal in length, because it is a differential pair carrying up to 480 Mbit/s
- Do not casually connect host 5V to an external supply, because the board switches that rail itself and the switch is current-limited for a reason
What software you need and where the files are
You need the Arduino IDE plus Teensyduino, the add-on from PJRC. Teensyduino bundles the host library and the Teensy Loader, so nothing else has to be installed.
# After installing Teensyduino, set these three in the Arduino IDE:
Tools > Board > Teensy 4.1
Tools > USB Type > Serial + Keyboard + Mouse + Joystick
Tools > CPU Speed > 600 MHz
# The host-side library ships with Teensyduino. Prove the hardware with its own example:
File > Examples > USBHost_t36 > Mouse
# USB identity is defined in the core, not in your sketch:
<arduino>/hardware/teensy/avr/cores/teensy4/usb_desc.h
<arduino>/hardware/teensy/avr/cores/teensy4/usb_names.hWarning
How to flash the firmware and test the host port
Flash the stock USBHost_t36 mouse example first. It prints every movement and click from the attached mouse to the serial monitor, so it proves your soldering in about thirty seconds. Before you test, keep in mind that the 5V rail on the host pads is switched by the chip rather than hard-wired. If the board runs firmware that never starts the host library, a mouse in the host port will not even light up. A dead-looking host port on such a board tells you nothing. Flash first, then test, and only then flash the firmware your cheat expects.
- Connect the Teensy's micro-USB device port to the PC you are compiling on
- Open the USBHost_t36 Mouse example, set Board and USB Type as in the toolchain settings, and click Upload
- Teensyduino hands the compiled image to the Teensy Loader, which reboots the board and writes the image. On a stock board this happens automatically
- If the upload hangs, press the Program button on the Teensy once. This forces the bootloader, and the Loader will then find the board
- Plug a wired mouse into the newly soldered host port and open the serial monitor
- Move the mouse. If movement and button events appear, the host port works and the hardware part of the build is finished
- Now compile and flash the passthrough firmware your cheat documents, keeping the same Board and USB Type settings
- Power-cycle the board once after the final flash instead of relying on a soft reset
In what order to connect the cables
If you get this sequence wrong, you can easily spend an hour debugging a cable. The device port faces the game PC because that is the end that claims to be a mouse, while the host port faces your hand.
- Plug the physical mouse, or your wireless mouse's dongle, into the Teensy's soldered USB host port
- Connect the Teensy's micro-USB device port directly to a rear USB port on the GAME PC, with no hub and no front-panel header
- Add the control link from the SECOND PC. It cannot share the device port, because that port's USB serial interface enumerates on the game PC, where the cable is plugged in
- Use one of the eight hardware UARTs for the control link instead. Put a USB-to-serial adapter at the second PC's end so the two machines never share a cable
- Boot the game PC and confirm that Windows shows a mouse device and that your hand moves the cursor
- Only then start the software on the second PC and open the link
Tip
Choosing the control link and setting up the cheat
A composite USB type gives you a mouse interface and a serial interface on the same cable. That serial interface appears on the game PC, where the device port is plugged in, so the second PC cannot open it. It also means the machine you are cheating on has a serial device from the same composite gadget as your mouse, with both interfaces under one descriptor. So take the control link from a hardware UART instead, and put a plain USB-to-serial adapter at the second PC's end. The game PC then sees a device that is only a mouse, which gives you a cleaner build for one more cable and one more part. Whichever link you use, the firmware defines the protocol and the cheat has to match it. In the cheat's input menu you set three things: the device type, the COM port and the baud rate. The device type is often listed as Teensy or as a generic serial device. The COM port is the one the second PC assigned, and the baud rate is the one the firmware was compiled with. All three must agree. A mismatched baud rate does not produce a clear error, because the connection opens and then does nothing, which looks exactly like a dead device. So check Device Manager for the port number and force it below 10 if the cheat reads only single digits, and write the baud rate down when you flash instead of guessing later.
Does a higher report rate help?
The device port is USB high speed, so the descriptor can request intervals shorter than the 1 ms floor that limits a full-speed mouse. In practice this means sub-millisecond reporting, which is the reason people like this board, but it is also where enthusiasm gets ahead of usefulness. A report rate far above what the game's own input loop consumes gives you no measurable benefit. A report stream that is perfectly regular at an unusual rate is also a pattern, and patterns are what behavioural analysis looks for. Set a rate that a real mouse of that class would plausibly use. There is no honest benchmark showing that a higher number is safer, and anyone who quotes one to you in milliseconds is making it up.
Tip
How to change the USB descriptor
Because you compile the firmware, you control the vendor ID, product ID, manufacturer and product strings, serial number and HID report descriptor. Left alone, a Teensy presents PJRC's own identity, which is a development board's identity on a machine that has no other reason to have one. The strings and IDs live in the core's usb_desc.h and usb_names.h rather than in your sketch. The 4.x core offers a cleaner approach: define the string descriptors in a small separate C file in your sketch folder. Once you change the vendor and product IDs, Teensyduino can no longer find and reboot the board automatically, so every upload after that needs the Program button pressed. That is expected behaviour, not a brick. Read the descriptor guide before you change anything, because copying a real mouse's identity badly is worse than leaving it stock.
Common Teensy problems and fixes
Work from top to bottom. The first four rows cover most of what goes wrong on a first build, and three of those four come down to soldering.
| Symptom | Likely cause | Fix |
|---|---|---|
| Mouse plugged into the host port does nothing, no LED on the mouse | Either a cold joint on the host pads, or firmware that never starts the host library so the 5V rail stays off | Flash the USBHost_t36 Mouse example first. If the mouse still shows no sign of life, reflow all five pads and check continuity |
| Host port enumerates intermittently, or only slow devices work | The D-minus and D-plus pair is too long or mismatched in length, or there is solder residue between the pads | Shorten the pair and match the lengths, or switch to the proper USB host cable. Clean the pads with isopropyl alcohol and inspect them under light |
| Game PC shows no mouse device at all | USB Type in the IDE does not include Mouse, so the device port never presents a HID mouse interface | Set Tools > USB Type to an option containing Mouse, recompile, reflash, then power-cycle the board |
| Upload fails or hangs at Waiting for Teensy device | The running firmware is not responding to the reboot request, or you have changed the vendor and product IDs | Press the Program button on the board once. After a VID or PID change you need to do this on every upload |
| Cursor moves from the cheat but your own mouse does nothing | Passthrough is not running: the host side is dead while the device side works | Test the host port with the Mouse example, because the cause is almost always the soldering |
| Your mouse works but the cheat cannot open the link | Wrong COM port, or a baud rate that does not match the compiled firmware | Find the port in Device Manager, set it below 10, and set the baud rate to the value the firmware was built with |
| Movement is coarse or stepped rather than smooth | The report descriptor uses 8-bit movement fields, so large deltas clip and get sent as several steps | Use firmware whose descriptor declares 16-bit relative axes, and let the cheat split large movements instead of leaving it to the descriptor |
| Board gets warm and the host device drops under load | The attached device is drawing more current than the host rail's limit allows | Use a plain wired mouse instead of an RGB-heavy one or a powered hub, and never attach a hub full of devices to the host port |
Common Teensy questions
Can I use a Teensy 4.0 instead of a 4.1?
Not comfortably. The 4.0 exposes the host signals as two surface pads rather than five through-holes with power management, so you have to hand-wire D-minus and D-plus and supply 5V yourself. It can be done, but every guide and every piece of firmware assumes the 4.1.
Do I need the official PJRC USB host cable?
No, but it is the easiest correct option, because it mates with the 5-pin header and gets the differential pair right without extra effort. Hand-wiring also works if the pair is short and matched.
Is a Teensy less detectable than a KMBox?
Not automatically. What a Teensy gives you is control: you decide the descriptor, the strings and the report rate, so you can present a plausible identity instead of a stock one. Left on defaults it presents a development board's identity, which is worse than a device designed for the job, so the control is only an advantage if you use it.
Can the Teensy run the cheat itself?
No, because it has no way to read the game PC's memory. It moves the cursor when told to, while the DMA card and the second PC decide where.
Will a wireless mouse's dongle work in the host port?
Usually yes, because the host treats the dongle as a USB HID device. Some dongles present extra interfaces or a proprietary configuration protocol that passthrough firmware ignores, so onboard button remaps and some software features may stop working.
Do I need to solder the Ethernet magjack kit?
Only if you want an IP control link instead of serial. When the second PC sits beside the game PC, serial is simpler and saves you one soldering job.
What happens if I flash the wrong firmware?
Nothing permanent. The bootloader lives on a separate chip, and the Program button always returns the board to a state where the Teensy Loader can write a new image. That makes a Teensy very hard to brick by flashing.
Sources
Nothing in our checked source list covers the Teensy itself, so the board specs, soldering, flashing and failure table come from bench work.
- 01Microsoft Learn, USB device descriptors
the vendor id, product id, string and serial number fields you set when you compile your own descriptor
learn.microsoft.com
Read next
- KMBox Net, KMBox B+, MAKCU, Teensy or Arduino: which input device to buy
- USB descriptors, VID/PID and what descriptor cloning means
- The full signal chain, from your hand to the game
- The cursor will not move: how to fix the input layer
- MAKCU and MAKCM setup, start to finish
- How to set up a second PC for DMA
Still stuck? Open a ticket on Discord
All guides