- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 447
- Reaction score
- 7
Anyone currently digging into the KMBox B Pro internals has probably hit that wall where the NG screen just won't go away. If you try to call boot.py normally or trigger km.move(), the device often just reboots and dumps you right back to that annoying error state.
I've been messing with a workaround that involves bypassing the standard boot cycle and feeding commands directly through the serial interface to simulate the initialization logic. This keeps the device stable and ready for input without the constant crash-reboot cycle.
The Logic
Essentially, you're opening a serial connection and sending the initialization string manually. This includes setting the frequency, baud rate, and curve types before the hardware has a chance to freak out. I also noticed that km.trace_enable() triggers a preload state—useful to know if you're trying to optimize your curve correction.
Python Simulation Script
Here is a basic implementation using pyserial. I've included the VID/PID spoofing section because, let's be honest, running stock IDs is just asking for a manual ban if you're using this for any serious DMA setup.
Technical Notes & Troubleshooting
It’s not a perfect fix yet, but it’s a solid way to get the device responsive when the internal scripts are failing.
Anyone else found a more permanent way to nuke the NG screen on these builds?
I've been messing with a workaround that involves bypassing the standard boot cycle and feeding commands directly through the serial interface to simulate the initialization logic. This keeps the device stable and ready for input without the constant crash-reboot cycle.
The Logic
Essentially, you're opening a serial connection and sending the initialization string manually. This includes setting the frequency, baud rate, and curve types before the hardware has a chance to freak out. I also noticed that km.trace_enable() triggers a preload state—useful to know if you're trying to optimize your curve correction.
Python Simulation Script
Here is a basic implementation using pyserial. I've included the VID/PID spoofing section because, let's be honest, running stock IDs is just asking for a manual ban if you're using this for any serious DMA setup.
Code:
import serial
import time
# Adjust COM port to match your device manager
s = serial.Serial('COM28', 115200, timeout=1)
def send_command(command):
s.write((command + '\r\n').encode('utf-8'))
time.sleep(0.1)
# Tech Specs
mcu = 500
rate = 115200
trace_type = 0 # 0: Bezier, 1: Missile tracking
send_command(f'km.freq({mcu})')
send_command(f'km.baud({rate})')
send_command(f'km.trace_type({trace_type})')
# Mode Configuration
# 0: Universal, 1: USB, 6: USB+BT
mode1 = 1
bt1 = 0
send_command(f'bt.enable({bt1})')
send_command(f'km.mode({mode1})')
# VID/PID Spoofing - Crucial for AC avoidance
send_command('device.VID("04d9")')
send_command('device.PID("a09f")')
send_command('device.enable(1)')
send_command('km.delay(100)')
# Drawing to the TFT Screen
send_command('tft.fill(TFT.BLACK)')
send_command('tft.text((2, 15), "Kmbox B Pro", TFT.RED, sysfont, 2, nowrap=True)')
send_command('tft.text((22, 80), "OK", TFT.GREEN, sysfont, 8, nowrap=True)')
# Test movement
send_command("km.move(10,0)")
s.close()
Technical Notes & Troubleshooting
- Serial Port: Make sure your COM port is correct in the script. Check Device Manager if you aren't seeing the device.
- Baud Rate: 115200 is standard, but some custom firmware builds might require different rates for stability.
- Hardware Curve: Enabling km.trace_enable can be hit or miss depending on your firmware version. If it causes a hang, keep it commented out.
- VID/PID: If you're targeting Vanguard or EAC, change the hex values to match a legitimate mouse (Logitech/Razer) to reduce your detection surface.
It’s not a perfect fix yet, but it’s a solid way to get the device responsive when the internal scripts are failing.
Anyone else found a more permanent way to nuke the NG screen on these builds?