The SPI horizontal offsets at 0x6080 tell the Switch what accelerometer
values to expect when the controller is held in normal gaming position.
The Switch uses this as a gravity reference for its sensor fusion.
Old values (-688, 0, 4038) were from a real Pro Controller's physical
IMU chip. Our bridge sends ~(0, 0, 4096) through the axis reversal
pipeline. The 388-count mismatch on X (0.095G = 5.4° tilt error) caused
the Switch's sensor fusion to continuously fight the gyro data, trying
to correct toward the wrong reference orientation → camera swinging.
New values (0, 0, 4096) match the bridge's output for a still controller
after SDL axis reversal, matching the zeroed calibration origins at 0x6020.
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 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.
- 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)
