Two root causes of camera 'wild jumping':
1. FIFO latency (bridge): Popped from the FRONT of the 32-sample FIFO,
sending 145ms-stale data while fresh samples sat at the back. Movement
played back on delay, making the camera feel disconnected from input.
Fix: pop from the END (newest samples) and clear the entire FIFO.
2. Zero-accel startup (firmware): At boot, imuData was all zeros until the
first UART frame with IMU arrived (~3-4 seconds later). The Switch
interpreted zero accel as free-fall, corrupting its sensor fusion state.
Fix: default imuData to a 'rest' sample (1G on accel_z, zero gyro)
so the Switch always sees a valid gravity reference.
Reverts the 0x10/0x21 routing to handle_feature_report() — those reports
during handshake are rumble-only keep-alives where buffer[10] is coincidental
data (always 0x01), not a real subcommand. Routing them caused every report
to trigger BLUETOOTH_PAIR_REQUEST.
The real subcommands (TOGGLE_IMU, SPI_READ, SET_MODE, etc.) are sent via
0x80 config reports and 0x01 feature reports, which were already routed
correctly. UART0 debug log now confirms is_imu_enabled=1 after handshake.
Added LOG_PRINTF to handle_feature_report() showing the report ID,
command ID, and is_imu_enabled state for each processed subcommand.
The Switch sends subcommands (IMU enable, SPI reads, vibration enable,
player lights, etc.) inside 0x10 and 0x21 output reports at byte 10.
The firmware extracted rumble data from these reports but never routed
the subcommand to handle_feature_report() — it fell through the
if-else chain silently.
This caused the handshake to stall: the Switch kept retrying early
subcommands (0x00-0x0f cycling) because it never received ACK replies.
It never progressed to sending 0x40 (Toggle IMU), 0x10 (SPI Read),
0x48 (Enable Vibration), or 0x30 (Set Player Lights).
The IMU was technically sending data, but the Switch never enabled it
via subcommand 0x40, so the Switch's IMU processing was undefined.
Fix: after extracting rumble from 0x10/0x21 reports, also pass them
to handle_feature_report() so the subcommand at buffer[10] gets
processed and ACK'd. Same fix applied to both tud_hid_set_report_cb
and tud_hid_report_received_cb.
The motion threshold (0.5 rad/s) caused two bugs:
1. Normal hand tremor could exceed the threshold, so bias_samples never
reached 200, bias never locked, and IMU never activated.
2. Violent shaking produced occasional near-zero samples at direction
reversals that contaminated the accumulator with wrong values, locking
a completely wrong bias and causing immediate fast spinning.
New approach:
- 1.5s warmup phase: discard all samples while the user is still interacting
with the keyboard/terminal after launch. Print a message so the user knows
to hold still.
- Unconditional collection of 100 samples (~0.5s at 200Hz) after warmup.
- 10s force-lock timeout: if 100 still samples haven't accumulated after
10s total, lock anyway with whatever we have (> 10 samples required).
- Print bias quality report: magnitude > 0.05 rad/s warns the user that
the controller was moving during calibration and they should restart.
The Switch applies its stored SPI calibration when interpreting IMU data:
gyro_dps = (raw - spi_origin) * 936 / coeff
The firmware had real hardware offsets as calibration origins:
gyro_origin = (9, -22, -95) accel_origin = (-29, -199, 493)
A real Pro Controller sensor reads those values at rest, so the Switch
subtracts them to get zero. But our bridge already removes hardware bias
via gyro bias calibration and sends near-zero counts when still.
The Switch was then applying a second origin correction:
gyro_z=2 → (2 - (-95)) * 0.070 = 6.79 dps constant yaw rotation
This caused the character to spin horizontally even when holding the
controller perfectly still.
Fix: zero all calibration origins. The bridge handles bias correction;
the Switch must not apply a second offset on top.
Two bugs causing constant camera drift and jarring first-frame behaviour:
1. Bias calibration was immediately collecting samples at launch, while the
user is still typing / setting down the controller. This polluted the bias
estimate (observed: by=-0.073 rad/s vs true ~-0.009 rad/s), causing a
permanent ~4 deg/s camera drift even when the controller is held still.
Fix: reject samples with gyro magnitude >= 0.5 rad/s (motion threshold)
during the calibration window so only truly still samples count. Also add
a return-early so no IMU is sent to the Pico until bias is locked.
2. last_accel initialised to (0,0,0), but the first gyro event fires before
the first accel event. The Pico received accel=(0,0,0) on the first sample
instead of the expected ~4096 counts on the gravity axis.
Fix: default last_accel to (0.0, 9.80665, 0.0) — gravity on SDL Y axis,
which is correct for a Pro Controller held in normal gaming position.
- Migrate all SDL2 GameController API calls to SDL3 Gamepad equivalents
- Fix PermissionError on controller reconnect by closing UART handle before
releasing port back to pool (Windows holds COM ports exclusively)
- Add DisplayIndexAllocator so controllers get stable display indices (0, 0, 0)
instead of incrementing SDL instance IDs (1, 2, 3) on each reconnect
- Button mapping now uses SDL3 positional constants (SOUTH/EAST/WEST/NORTH)
which works correctly for all controller types without USE_BUTTON_LABELS hint
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
SDL3 includes a dedicated 8BitDo HIDAPI driver with native gyro/accel sensor support, which SDL2 lacked.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
SDL's hidapi_switch.c SendSensorUpdate() remaps Nintendo's raw sensor axes
to match PlayStation convention before emitting SDL sensor events:
SDL_X = -Nintendo_Y, SDL_Y = +Nintendo_Z, SDL_Z = -Nintendo_X
This commit reverses that transform so the values sent to the Pico are in
Nintendo's native coordinate frame:
Nintendo_X_raw = -SDL_Z
Nintendo_Y_raw = -SDL_X
Nintendo_Z_raw = +SDL_Y
Same mapping for gyro (bias subtraction happens before axis reversal).
Confirmed from SDL3 hidapi_switch.c source (SDL2 uses same SDL3 backend).
- Add SwitchImuSample struct and IMU fields to SwitchInputState
- Add fill_imu_report_data() to pack samples into imuData[36]
- Rewrite switch_pro_apply_uart_packet() for v2 with checksum validation
- Enlarge poll_uart_frames() buffer to 64 bytes for variable-length frames
- Clear imu_sample_count after each USB report send (prevent stale IMU)
