@Amy Smith yeah this is a real thing and your diagnosis is pretty much spot on — self-heating from sustained IMU polling is a well-known issue on combo sensor chips, and a 3-5°C offset under heavy load is honestly within the range I'd expect when you're hammering the accel/gyro continuously.
The good news is that decoupling the environmental sensor polling rate from the motion sensor polling rate does help in practice, even if they share a common power rail. The thermal contribution isn't just about the clock cycle — it's cumulative heat from sustained current draw, so if you can drop the temp/humidity/pressure sample rate way down (like once every few seconds is usually plenty for environmental data anyway) while keeping your IMU fast, you'll reduce the average power dissipation on the die and the offset will shrink. Whether you can fully separate the duty cycles in firmware depends on how the module is configured, but it's worth trying before going down the software correction path.
For a software correction approach in the meantime, the simplest thing that actually works is characterizing the offset empirically at a few different polling rates — run a steady-state test, let thermals stabilize, note the delta versus your reference, and build a lookup table keyed on your IMU ODR or approximate current draw. It's not elegant but it's reliable and takes maybe an hour to generate the data. On published calibration coefficients from RFOXiA specifically — I'm not aware of anything formal being out there yet, but honestly tagging Moamen directly in this thread or posting in the Dev Hub resources section would be the right move, because if there's demand for an offset table it's the kind of thing that could end up in the documentation.
Physically isolating the module is a last resort in my opinion — it works but adds mechanical complexity and most people solve it sufficiently in firmware first.
