We need some other testers to join in.

This looks really promising! Thanks for the log as well - that really helps.

Sorry for the lack of replies. I've been a bit busy lately and I'm on holiday for 2 weeks starting next week, so there's a lot of preparation/finishing stuff off.

lib/misc/stepcount.c only goes as far back as April 2021. It must have been somewhere else before that ?

Yes, it was in lib/banglejs/jswrap_banglejs.c alongside everything else before that. It's literally just : https://github.com/espruino/Espruino/blob/bb99dd861bfbf9765edcdc60f7bfe93d8984563e/libs/banglejs/jswrap_bangle.c#L648-L655

Threshold beforehand was 0.99g -> 1.01g so the acceleration had to dip below 0.99 then rise above 1.01 for it to be counted - but that's way less that in the paper you found

Anymore thoughts on this @Gordon. I have tried a couple of other iterations but the payoff is between accuracy and not recording steps when not walking. The only major thing I could suggest would be a simpler filter that has much less ring. After that you would have to go to more complex approaches like the muti-threaded oxford counter - but that will use up more precious RAM etc. I think I have gone as far as I can with this.

Thanks - I've been a bit busy lately I'm afraid.

I feel a bit uneasy about the need for things like active_sample_count (gating the filter) - it just seems like it's a bit of a workaround that'll probably end up biting us later.

The only major thing I could suggest would be a simpler filter that has much less ring

Yes, I've been wondering about this. I was thinking a simple low pass filter might do what we need (producing a nice, smooth signal) without introducing anywhere near as much ringing.

Did you find anything out about the best frequency cut-off to use? I know I used 2.5Hz, and I could just do that as a low-pass filter (without trying to cut off anything below 1hz).

3Hz was quoted a lot in the papers I read. I constructed the table below when thinking about this. 2.5 steps / s is fast marching pace where its easier to run that walk. 3Hz would allow for some slow running to have a chance of working. Suggest trying a simple cut off at 3Hz.

The 'windowing' concept in the oxford step counter is effectievely the state machine approach which ensures step events arrive within the expected time range for every step.

1 Attachment

Hey, it looks to have some interesting work here :)

Is there some implementation available on which I can do test? I see there was a js app in the thread should I use it or is there a firmware which already implements what does the js app?

Thank you

I dont think there is anything new to test yet. But it would be good to gear up for testing something new as real world tests take up a lot of time and require focus to record the results and repeat the same test again etc.

The steps_mc35.js on page 3 of this thread is my attempt to improve on the current firmware, on the basis that experimenting in Javascript is a lot easier than compiling the C and flashing a new version of firmware onto your watch. The key issue with the current step counting algorithm is that it counts steps when you are not walking eg when sat at a desk typing, when driving, when sleeping. Its no good waking up with 1200 steps on your step counter when all you have been doing is sleeping in bed for 8 hours. This is due to a couple of problems. 1) the low pass filters keeps oscillating for 5-7 'rings' after the movement has stopped 2) the firmware only enforces 6 steps in 6 seconds but does not enforce the period between each and every step. So example sssss_s (where s is a step and _ is a longish gap) is accepted as long as it took 6 seconds. What is needs is that the gap between each step is checked against the timestamp of the last so that it falls within 0.3s to 1s.

steps_mc35.js adds a gating meachanism to shut output of the filter off if the movement has stopped and secondly adds a state machine to check the gap berween each step. You would be more than welcome to test that so that you get a feel for how I was experimenting. Just load the file onto the watch through the IDE and execute it through the FileManager.

When testing I normally wear the bangle and another smartwatch like a FitBit or AmizFit Bip on the same wrist. I record step counts at start and end of the test period and the type of activity and compare results. As well as walking 1,2 or 3 miles I check counts when sat at a desk working for a few hours, when driving, when sleeping.

The conclusion at the moment is that we need to try a different low pass filter that has less ring. If we can get close to 1 ring when the movement stop that can be compensated for in the state machine.

I've just pushed some new code to the Espruino, so the cutting edge travis builds will have a new step counter: https://www.espruino.com/binaries/travis/master/

Basically it's a much simpler ~3Hz low-pass filter with virtually no ringing, with the previous counter which handles 4 steps in ~8 seconds. I'd be really interested to see how it performs.

Now I don't have a fitbit, but wearing this and a totally standard Q3 watch on my wrist has the Q3 reporting almost exactly half the number of steps. If I actually count what I consider to be a step (one foot hitting the ground) then Bangle.js is now seems pretty much spot on so I can only assume that the Q3 is actually reporting a step as 'one,two'.

I've been typing for several minutes now and it's yet to report a single step, so I think that's a good sign too.

@HughB how would you feel about running the 'acceleration recorder' over the course of a whole day, and taking some step count figures from other devices over that time period? I feel like that'd give a really good baseline that we could try these algorithms against, as obviously the odd little sections of walking data aren't really cutting it.

I'll flash the 2v10.9 firmware. I'll do 4 basic tests.

WALKING - 1m, 2m walks - looking for around 2000 steps counted per mile. I suspect this will work. Counting steps when actually walking is a lot easier than not counting them when doing othre things. The previous version of the firmware with the old filter was quite good at this.

SLEEP - how many steps recorded while sleeping - needs to be less than 100.
DRIVING - needs to be low as possible.
WORKING - needs to be minimal while sat at a Desk for 3-4 hours typing.

That will give an initial set of results that can be compared with the other results I published to this thread. We can then look at doing the recordings. Will there be enough space on the bangle to record 8 hours of accelerometer data ?

Thanks! And yes, good point about the storage. I reckon it could be around 7MB of data, so too much for 8 hours, but 4 would be ok :(

I guess if we stored data in binary it'd be ok, but right now with the acceleration logger it's not enough...

Early results on 2v10.9 Pedometer

.................................... Amiz GTS2 ............ Bangle
DRIVING (15mins) .......................9...................549 Bad
WALKING (1.7mile)................3617................. 3570 Expected good accuracy ~98.7%
DRIVING (15mins) .....................19....................653 Bad

I will do a SLEEP test tonight.

Looks like the filter is much smaller AND massively improved - no ringing that I can see.
I copied the filter taps from the code - so I could investigate the filter in javascript.
Hopefully not mis-copied.

// (3) Low Pass filter 
var filter_taps = new Int8Array([5, 6, -4, -17, -15, 4, 11, -10, -27, 8, 80, 118, 80, 8, -27, -10, 11, 4, -15, -17, -4, 6, 5]);

Here is the ringing on the V2.09.90 filter in response to a single arm sideways open and close.

1 Attachment

Same again but for the new low pass filter.

A general observation is that I can definitely observe fast movements of the hand and arm are not resulting in any amplication or much of a filtered output. This is loads more effective than the previous filter.

1 Attachment

I am happy to record a 4 hour segment of mywork day with a bit of walking around the house etc.

SLEEP test on v2.10.9 firmware - 149 steps.

This is a really good result. v2.09.90 was about 1200 steps.
AmizFit would be around 20.

100 steps is 1% of a 10,000 step goal so anything over 100 steps needs to be looked at.

The accuracy goal for me is 97% accuracy - thats 300 steps off in a 10K step day.

For a step counter to be considered good it needs to be 98% of a calibrated mechanical step counter. That was quoted in one of the papers I looked at.

Doing an overall test for today, which will be housework, going to the tip, walking the dog, buzzing about etc. Will update at the end of the day.

3Hrs GENERAL Activities

AmizFit GTS2 .... 1984 steps Bangle (2.10.9)....... 6323 steps, massively over.

This was 3hrs of washing up, clearing the garage, driving to a chartity shop, unloading, driving to the local tip, unloading, driving home.

4 steps in ~8 seconds. I would argue this is too long a period for a single step. It would allow steps at the rate of 2 seconds for a single step. Which in reality is not walking. Its slow motion.

1 step per second is about as low as we want to go.
So I would suggest 4 steps in 4 seconds or 5 steps in 5 seconds would be better.
This might improve the driving inaccuracy, and reject non stepping activity.

@valvin - new cutting edge firmware out. V2.10.9 . New Pedometer. Worth testing.

Edit: solved but i still have low mem on startup when it displays 'gps time' but disappear after.

Thank you, unfortunately i'm unable to upload any firmware on my bangle.
On startup I had a low memory error before uploading. And now even old firmware can't be uploaded 😟 ( invalid object).

summary of results so far.

I attempted to build a javascript version (3.91) using the new filter. But this failed. I noticed steps were not being detected as the 1000 threshold was not being crossed. This is a difference in the way the filter amplifies the input. Rather than tweak threholds I decided to try PEAK detection. This has the advantage of being self adjusting. However it does need a simple gating mechanism otherwise you start finding peeks in the noise signal when the bangle is at rest. When combined with the state machine it works really well. I have tested against the oxford filter but will go back and repeat against the bangle v2.10.9 filter taps and see which one looks best.

The C code of the oxford step counter has a much smalled set of filter taps and implements two filter ranges. See code.

https://github.com/Oxford-step-counter/C-Step-Counter/blob/master/src/filterStage.c

This has:

static magnitude_t filter_taps[FILTER_TAP_NUM] = {
    -2696,
    -3734,
    11354,
    17457,
    11354,
    -3734,
    -2696};

I figured I could scale the vales down so divided by 256 and tried this as a filter as well.

// a scalled down oxford LPF
var filter_taps = new Int8Array([-11, -15, 44, 68, 44, -15, -11]);

My latest javascript code is at:
https://github.com/hughbarney/bangle_bits/blob/master/step_counters/steps_310.js

Next step for me is to retest another version (3.11) of 3.10 with the same filter taps in the 2.10.9 Bangle Firmware.

The key problem is when driving. Even Fitbit had a lot of trouble with driving counting steps for a while. There is a support thread on the Fitbit site with users complaining about counting 1000s of steps which driving. I think it depends on the device and formware as I suspect different devices had different teams write the firmware. My original Charge HR seemed to do ok when driving. AmazFit have the driving problem cracked - so it is doable.

I'm happy to try the 4/8 hour recordings but think it would be better just to record actual activities like WALKING, WORKING at a DESK, SLEEPING. My worry would be if you just adjust thresholds to fit an end of day value that you will loose accuracy when counting walking steps.

The key problem to be solved I think is screening out counting steps while driving. I did some recordings of my own today, just printed the raw/filtered output to a file in the IDE when I was driving for a few minutes. I could clearly see the impact of going over speed bumps and little bumps in the road. I am wondreing if it will be possible to get an RMS value for driving vs walking etc.

1 Attachment

Thanks for all the research! So I guess right now the firmware is a decent improvement over what it was at least.

I'd have thought that actually recording specific activities would be absolutely fine - I think the real thing would be to ensure that we have a balanced set of data - so when running tests on the PC I'm not placing too much emphasis on eg, walking, and not enough on sleep or driving.

I was surprised about the 4 steps in 8 seconds too - it's just that running through the data I had, that's what appeared to give the best result. Although as we know, the data I have doesn't seem particularly great.

With the adjustable threshold - I have tried a variety of ways of doing a threshold, and at least from my experience it seemed that it wasn't worth it. Obviously you may find it's different, but especially now the filter is reasonably flat (eg the amplitude doesn't depend on step frequency) it seemed to me that a flat threshold might work better.

New firmware is better but still way out for none walking activities.

With regards to threshold - I will post some charts I did that compare the filter outputs when walking. The old filter had more pronounced amploification and also tended to centre the output wave around zero better. The new filter can have a full since wave above the zero line. This is why I have now coded a PEAK detection method. To do that I store the last 3 consecutive filter readings (Left Middle, Right), If the middle one is greater than the left and right reading then a PEAK has been reached. This seems to be much more adapatable, self tuning and reliable. You can see my code in the github link above.

What did you think about using the simpler oxford filter ? I'm testing the firmware one and the oxford one at the moment. Looks like the oxford one is even better.

Ahh, thanks for the explanation - yes, peak detection sounds good - I guess with the low pass filter we're smoothing the waveform out enough that it makes a lot of sense.

The new filter is low-pass, so it's passing the low frequency including any offset - hence it being above zero I think.

I'm not against using the Oxford filter either, if it ends up better. I guess ideally I'd like to be able to run it over some data and say for sure that yes, it does do a better job.

Working on 2 sets of test results. 3.10 and 3.11 as same code except 3.10 uses the oxford filter. I'm leaning towards that one as it is looking better.

Here is an accellog for 1834 steps walk (as per AmizFit GTS2).

1 Attachment

• accellog_walk_1834.csv

last record in above log is: 938968,-1468,217,-8059

here's why we need PEAK detection not threshold crossing. Look at the steps after 6000ms. They are not crossing the orange threshold line. This was why when I took the filter taps into my App the state machine was not being called.

1 Attachment