PiDog V2, Raspberry Pi 5, Robot HAT v5, Raspberry Pi OS Bookworm 64-bit (Trixie). imu_sh3001 and rgb_strip both fail on init. \

General
1

PiDog V2, Raspberry Pi 5, Robot HAT v5, Raspberry Pi OS Bookworm 64-bit (Trixie). imu_sh3001 and rgb_strip both fail on init. i2cdetect -y 1 is empty — all devices appear on buses 13 and 14. Servos are stiff/powered but not responding to PWM commands. All cables appear correctly seated.

Please let me know if you have any help or suggestions- best regards.

2

We will reply you through email.

3

I have a similar problem with the AI Fusion Kit - did you get any help that worked?

Here is what my AI found:
**System:**

  • Raspberry Pi 5
  • OS: Debian GNU/Linux 13 (trixie), 64-bit
  • Kernel: `6.18.50+rpt-rpi-2712` (after a full `apt full-upgrade`; the fault persisted across the update from 6.18.34)
  • Firmware: version `086b83e3` (2026/05/26)
  • Python 3.13.5; SunFounder `sh3001` lib v0.0.1; `fusion_hat` library installed
  • I2C bus: `/dev/i2c-1` (RP1 `i2c_designware`, `1f00074000.i2c`)

**Symptom:**

  • **QMC6310 magnetometer (0x1c):** detected, returns valid magnetic-field vectors. ✅
  • **SPL06-001 barometer (0x76):** detected (product-ID `0x10`); pressure reads a plausible ~982 hPa, but its **temperature output is far too low** — about **−0.6 °C against a 23.4 °C ambient** (checked with a desk thermometer). Using the chip’s own calibration coefficients and the datasheet compensation, the scaled temperature is identical at 1× and 16× oversampling and independent of the temperature-source bit, so the chip’s coefficients and its raw temperature cannot be reconciled. This looks like a second defect on the same module.
  • **SH3001 accel/gyro (0x36, and alt 0x37):** **no response** — every read returns `OSError errno 121 (Remote I/O error)`. It never returns its chip-ID (register `0x0F`, which should read `0x61`).
  • Other unrelated I2C peripherals on the same bus (a light sensor at 0x23, an OLED at 0x3c) are detected and working normally, which confirms the bus, cable, power, and pull-ups are healthy.
  • The kernel log shows, **only when the bus is scanned across 0x36** (the bus is clean at idle):
    ```
    i2c_designware 1f00074000.i2c: i2c_dw_handle_tx_abort: lost arbitration
    i2c_designware 1f00074000.i2c: i2c_dw_handle_tx_abort: SDA stuck at low
    ```
    So the SH3001 appears to be *present but malfunctioning* — actively holding SDA low — rather than simply absent (an absent device would only NAK).

**What I have already tried (no change):**

  1. Fresh boot with the module seated.
  2. Full power-down, then a careful reseat of the 4-pin cable (no forcing).
  3. Visual inspection — the SH3001 chip looks properly seated and soldered; nothing visibly loose.
  4. Lowered the I2C bus speed to 50 kHz (`dtparam=i2c_arm_baudrate=50000`) and rebooted.
  5. Checked both possible SH3001 addresses (0x36 and 0x37).
  6. Installed all pending OS updates (`apt full-upgrade`, kernel 6.18.34 → 6.18.50) and rebooted — no change.