You are reading a single comment by @HughB and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@HughB
Agree - looked up ringing on wikipedia and the upshot is that ringing is enevitable and complex to get rid of.
https://en.wikipedia.org/wiki/Ringing_arÂtifacts
BUT - Eureka - I think I have worked out a way to deal with this - but will need to do the experiments.
1) the filter rings. But it is fairly consistant and does a good job in ampliying the walking cadence.
2) Using STEPO (one of my apps in the repo) with trip counter I can see that rolling over or moving my arm over to the bedside table and back to switch the light on will cause on averge between 6-9 steps. This suggests to me that making the threshold for starting step counting should be 10 steps in 10 seconds. Your X in Y algorithm works. The only difference with the state machine is that after we get to step counting (STEPPING) state - that the criteria is removed and only a gap of 2 seconds will put you back into STEP1 state (waiting for X steps in Y seconds). With your C code 5 stepHistory[] approach (much simpler and very elegant) - the constraint continues for all steps and if not met will drop the odd step. In reality the difference may not be significant or matter. Will have to measure it. Your 5 line approach just took a lot longer to understand - but it is a lot less code, which is usually a good thing.
3) I have observed after stopping walking on average I see 2-3 extra steps due to the ringing. So the solution is that when you come out of 10 steps in 10 seconds you count 7 steps to start with knowing that the ringing will provide the other 3 steps at the end of the STEPPING period. This may sound a bit hacky at first but the more I think about it the more I like it.
Will build an App tonight and test it.