Fix sampling rate miscalibration problem #30

New Issue

MrUnknownDE · 2026-04-05T17:51:40+02:00

MrUnknownDE commented

2026-04-05 17:51:40 +02:00

Originally created by @gorbit99 on 11/19/2025

In previous firmware versions, there is an issue, where the tracker miscalculates the sampling rate of the IMU, which causes sensitivity issues. This is caused by sudden spikes in calculation overhead, for example saving the configuration, wifi activity, or things like that. This creates a sudden burst of unread IMU samples. Since we read at a given max rate, but the calibration is real-time based, this can create a false representation of how many samples we receive each second.

To mitigate this issue, several steps were taken:

Now the sampling rate calibration doesn't get saved by itself. Since this is redone each time the tracker is turned on, this isn't a huge issue, and as a side effect, this also reduces the number of EEPROM writes, albeit by a trivial amount.
Now the IMU reading code can signal when the MCU is seemingly "overwhelmed", meaning it has more readings than it can handle in a single step. This is then used by the sampling rate calibration code to restart the step completely.

With these two solutions, the calibration is back to being functional. Other steps are unlikely to be affected by the same issue, since they are average based, not time based.

*Originally created by @gorbit99 on 11/19/2025* In previous firmware versions, there is an issue, where the tracker miscalculates the sampling rate of the IMU, which causes sensitivity issues. This is caused by sudden spikes in calculation overhead, for example saving the configuration, wifi activity, or things like that. This creates a sudden burst of unread IMU samples. Since we read at a given max rate, but the calibration is real-time based, this can create a false representation of how many samples we receive each second. To mitigate this issue, several steps were taken: - Now the sampling rate calibration doesn't get saved by itself. Since this is redone each time the tracker is turned on, this isn't a huge issue, and as a side effect, this also reduces the number of EEPROM writes, albeit by a trivial amount. - Now the IMU reading code can signal when the MCU is seemingly "overwhelmed", meaning it has more readings than it can handle in a single step. This is then used by the sampling rate calibration code to restart the step completely. With these two solutions, the calibration is back to being functional. Other steps are unlikely to be affected by the same issue, since they are average based, not time based.

MrUnknownDE closed this issue

2026-04-05 17:51:40 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/SlimeVR-Tracker-ESP#30