Better Pedometer - HELP NEEDED!

but again, this is why it's really good to be able to run the code in a test harness

Totally agree. Once we have all the necessary logs and agreed algorithm, identified parameters that we tune against the data - this will be the only practical way to run the 100+ tests that might be required to optimise the 2-4 tuning parameters. I have installed Node.js / npm but I have no Node.js experience - so its going to take a while for me to convert my code to a test harness. Going to focus on getting good recordings for a bit longer. Plus track the firmware updates you are doing.

SLEEP TEST RESULTS
Amiz GTS 2 - 10
2.10.13 - 191 ** this is the extra steps coming in due to noise on the input
3.10 App - 169

As is, when gate_open becomes true, accFiltered is now suddely>0 and all it takes is
for the next sample after that to be lower and you've now got a step recorded.

No this is not the case.
The raw threshold works like this.

Count up to 3 consecutive ABS(raw) values that are over threshold - then open the gate
Now we have readings that are not noise and represent actual movement
The gate only turns off if active_sample_count-- counts down to 0 and it will take 3 consecutive out of threshold values for it to count down. This avoids the potential for counting steps when at rest.

The gate opens up quickly when there is real movement, stays open and closes down quickly when the movement stops.

The M of the accelerometer when the watch is at rest/stationary is biased in the 3-8 range.
As per the screenshot above. The noise is not balanced across the zero line which is what I
would have expected. I have thought of building that into the threshold code. Too early to tell.

personally I feel like it would be a lot cleaner to do the threshold after the filter.

Ideally I would agree but the amplication of the filter is not linear and very dependant on what gets through. With the 2.9.90 filter any input got heavily amplified. Also with a 12.5Hz sampling frequency we can only have a filter that works up to 6.25Hz - this introduces distortations and
errors etc.

The only way we could prove lineararity would be through mass tests and to try and get a set of real world recordings that had a range of increasing raw values in the output. The driving recordings are the most interesting for this. Using the theoretical response is not going to help when in the real world the signal has got low level noise and bumps in the round etc.