I'm having some issues with my Tracker One not firing on obvious high-g drop events and could use some help. I'm doing some testing with e-bikes and looking for some fall detection capabilities, which should be right in the wheelhouse of the Tracker One, as far as I understand.
For the basics, we're talking about a Particle Tracker One (ONE404MEA) running stock Tracker Edge firmware configured in the console.
And here's the situation, in as much detail as I can muster:
High-G detection is confirmed enabled at the device level (get_cfg returns "high_g":"enable"), and I've run several deliberate hard-impact tests with no events showing in the event stream. No imu_g trigger has fired under any test condition, including a direct hard drop onto a rigid, uncushioned floor, which I'd have to imagine would clear the documented 4g/2.5ms threshold.
However, I did get one imu_g event during an actual test ride (a hard braking moment), so the mechanism clearly can work but it's just not reproducing on the bench or on simulated falls on the bike that were significantly higher-g than whatever sharp braking event it caught.
As for theories, I noticed that enabling High-G detection calls into the BMI160 driver's wakeup() function, which puts the accelerometer into "low power" mode with "undersampling" enabled, rather than continuous/Normal mode. I assume that's a conscious battery-saving strategy, but it raises the question of whether a brief (sub-3ms) shock event could fall entirely within a duty-cycle sleep gap and simply never reach the sensor, regardless of impact severity.
So I guess the question is whether or not that is expected behavior for high-g detection in the low power mode and whether there is a combination of configuration settings to force continuous accelerometer monitoring without getting into custom firmware. I'm also of course open to the possibility that I'm totally missing something simple and this low power mode thing is a red herring.
Thanks in advance!