Better Pedometer - HELP NEEDED!

What this shows is that maybe the threshold should be 15, 16 or 17 as 18 is making it too insensitive.

After my own very unscientific testing I had the same thought. Wanted to do some more testing before making any conclusions though... Nice to see that your small test showed something similar.

Thanks for looking into this further...

the threshold should be 15, 16 or 17 as 18 is making it too insensitive.

All I can really go by is the test data, and with that data, 18 clearly came out on top in a number of scenarios. I'll change it back to 17 though and you can see.

My big concern here is the reason for the change wasn't because I thought I could do better than @HughB's testing - it was that others users have had issues with the step counter counting phantom steps when their accelerometer had a slight (totally within spec) DC offset.

The DC offset could be significantly higher than it was in @Mr_Ploppy's case and still be within spec, so I wanted to be on the high side to make it far less likely anyone encountered the phantom steps.

As noted above though the step count really is just a proxy to see how much exercise you've done over the day. My personal feeling is if you're using the step count to see how much activity you've had during the day (which I think most people are) then for many people, walking makes up only a small proportion of the day and it's much more important that the other 80% of the day is more accurate.

@HughB Your work with Gordon on the Pedometer is very much appreciated. I thought you might be interested in the results I have been getting using it with a different accelerometer the sc7a20 which is found in a lot of watches such as the P8, ROCK, Magic3 and SN80. The sc7a20 is a very cheap device which sells for pennies and many examples have readings that are well off centre. As a result, I have had to introduce calibration which Gordon has noted is not that simple. You have to gently move the watch into six different positions to get full calibration data - face- up/down, edge - up/down and end - up/down. However, I have only needed to calibate once. I have been comparing the step count during dog walks with that of my iPhone. The results for walking are quite impressive - here are two recent walks which are typical of the results I have been getting:

iPhone: 5121 SN80: 5124
iPhone: 5209 SN80: 5169

I have measured this walk at 2.6 miles with the Bangle GPS recorder. Personally, I am interested in measuring steps as a proxy for distance during walks - enabling step counting at the start of a walk and disabling at the end. I am very impressed with the bangle algorithm.
BTW: I have been using the old threshold of 14.

I just had a thought about this...

Right now, we use the absolute magnitude of the acceleration value. If you were to gently rock the Bangle around its axis, that would not give you any change in the value at all.

What if we use the difference in accelerometer values? That is by its very definition going to be centered, and any rotational movement would add to the value you saw.

Obviously it needs work and testing, but could be an interesting way forward anyway.

Yes, some of my experiments used the difference and it showed promise.

The problem is that if the readings for an axis are off centre you do get a change in the magnitude as you rotate with respect to gravity. So rotating your wrist will give a false acceleration that may look like swinging your arm while walking. It is why the continuous steps were detected by some people in only some orientations. The current algorithm is trying to detect accelerations that are independent with respect to your orientation to the downward force of gravity which is why the iPhone in my pocket agrees with the watch on my wrist.

I am very impressed with the bangle algorithm.

Just to be clear are you saying you are using the B2 algorithm on a SN80 and getting these results ? If so that is really encouraging.

Personally, I am interested in measuring steps as a proxy for distance during walks

Its an ok approximation method providing you work out the stride distance or have a setting for stride distance. You will know it will be different for each person depending on height. I know for me that 2000 steps (on a pavement) is 1 mile. But walking on tracks, grass, mud etc etc, stride length changes a lot.

I have not tested how accurate the Recorder calculation of distance is using the GPS trace. It may suffer from the bug I just fixed in the RUN app where the distance between two lat/lon's was not an accurate calculation. The 0.03 of RUN app should be good now.

I would definitely recommend you take a look at the RUN App. You can use it with GPS on / off. One option would be to add a stride length and when the GPS is off to estimate PACE and distance based on steps*stride length. Would save a lot of battery.

it was that others users have had issues with the step counter counting phantom steps
when their accelerometer had a slight (totally within spec) DC offset.

@Gordon - totally get it. We want these users to have a decent step counter if their accelerometer is in spec. The test harness showed that 15 would have been enough - so jumping to 18 felt a bit too quick. I think 16 would have been as high as I would have gone at the moment. But 17 will probably good too.

I'd like to understand the DC offset a bit better. I have a suspcicion that the DC offset may always be positive. In which case maybe thresholds of +17 and -10 might be better. There's more tests that could be done using the test harness to establish that. Plus we need more acceleromert recordings and samples from the phatom step users. We dont just want a step counter that's fine tuned for @HughB's Bangle 2. We need some stats on the variance of these accelerometers and the batches we have. I dont know the hardware stuff well enough to comment. But there were 2 cases complaining about phantom steps out of 2000 watches sent out ? Were they freak accelerometers or are there a lot more that never looked at step counts or didn't report any issues because they were more interested in clocks or GPS or games etc.

I'm heartenned by the fact that no one complained about the step counter for so long. I've been expecting a lot more people to complain saying they drove 1 hour to work and count so many hundred steps etc.

I'd like to see if we could collectively come up with a better approach for the THRESHOLD / GATE concept that can work out this DC offset and compensate accordingly. Either some sort of dynamic approach or a calibration approach. There are some really smart and experienced people in this forum who can knock things together in an hour that would take me 2 evenings, whilst I'm still playing catch up as I don't really have prior experience with Javascript.

Today's testing on 2v11.31, threshold 17.

Took a walk to the store and back, 1.4 km one way. Going there:
Fitbit - 1487
Bangle - 1388

Walking around the store (about 15 minutes):
Fitbit - 380
Bangle - 387

Walking home:
Fitbit - 1617
Bangle - 1559

5 hours spending time at home, playing with the little one, doing housework, etc:
Fitbit - 2229
Bangle - 2591

Looking pretty good. Sounds like there are some good ideas being thrown around so looking forward to see how things will progress.

Yes, it’s the B2 algorithm on a SN80. I programmed the first version of plot track for B1 that Gordon then added to the gps recorder app and it used exactly the equirectangular approximation you have suggested for the Run app. I have just checked and the current version still uses it so the distance should be accurate as I did check its accuracy at the time.

Hi @johan_m_o - good tests.

The first one concerns me. If you scale the FitBit result up to 10000 steps - you get a scale factor of 6.72 . Multiply the 1388*6.72 gives 9334. Which indicates 93.34% of the Fitbit result. This to me isn't accurate enough, 98% was my target, over 10K steps. I used a FitBit Charge HR for several years and know they are really accurate, so I trust them for comparisons.

@HughB is the difference between the positive and negative noise just gravity? I am not at the computer but I can't remember where in the current algorithm it is accounted for.

I had a go with using a DC filter to remove the bias and here are the results. First. here is the simulated performance of the current Pedometer with RAW_THRESHOLD = 17:

X_STEPS = 6, RAW_THRESHOLD = 17
File, Expected, Simulated, Diff, %, (Original)
HughB-walk-6605.csv, 6605, 6215, -390, 94.10 %, (3223)
HughB-walk-2350.csv, 2350, 2204, -146, 93.79 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 2936, -134, 95.64 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 9107, -914, 90.88 %, (12222)
HughB-drive-36min-0.csv, 0, 52, 52, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 109, 109, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 82, 79, 2733.33 %, (535)
HughB-work-66.csv, 66, 68, 2, 103.03 %, (980)
HughB-work-66.csv, 66, 68, 2, 103.03 %, (980)
HughB-mixed-390.csv, 390, 408, 18, 104.62 %, (1871)
HughB-general-a260-b573.csv, 260, 361, 101, 138.85 %, (3854)
HughB-housework-a958-b2658.csv, 958, 1728, 770, 180.38 %, (5762)
MrPloppy-stationary-0.csv, 0, 0, 0, 0.00 %, (1)
TOTAL DIFFERENCE 1508

Now here are the results with using a DC Filter and reducing the threshold to 15:

NSAMPLE = 12
X_STEPS = 6, RAW_THRESHOLD = 15
File, Expected, Simulated, Diff, %, (Original)
HughB-walk-6605.csv, 6605, 6054, -551, 91.66 %, (3223)
HughB-walk-2350.csv, 2350, 2164, -186, 92.09 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 2858, -212, 93.09 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 9903, -118, 98.82 %, (12222)
HughB-drive-36min-0.csv, 0, 45, 45, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 58, 58, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 67, 64, 2233.33 %, (535)
HughB-work-66.csv, 66, 65, -1, 98.48 %, (980)
HughB-work-66.csv, 66, 65, -1, 98.48 %, (980)
HughB-mixed-390.csv, 390, 407, 17, 104.36 %, (1871)
HughB-general-a260-b573.csv, 260, 400, 140, 153.85 %, (3854)
HughB-housework-a958-b2658.csv, 958, 1825, 867, 190.50 %, (5762)
MrPloppy-stationary-0.csv, 0, 0, 0, 0.00 %, (1)
TOTAL DIFFERENCE 1399

NSAMPLE is a parameter of the filter:

//Exponential Moving Average DC removal filter alpha = 1/NSAMPLE

int DCFilter_sample_avg_total = 8192*NSAMPLE;

int DCFilter(int sample) {
    DCFilter_sample_avg_total += (sample - DCFilter_sample_avg_total/NSAMPLE);
    return sample - DCFilter_sample_avg_total/NSAMPLE;
}

@HughB It appears that the accuracy gets worse on your shorter walks and better on your longer walk with this approach.
The main advantage is that it deals with the Mr Ploppy problem even if you set the threshold as low as 10.

Interesting. Whats the results at 14 and 10.

14 was the original baseline. Note we need more logs from @Mr_Ploppy as 60s of holding the Bangle is not enough. I'd really like 15mins driving and 1 mile walking.

Can NSAMPLES be 6? What is the impact of that?

At threshold 14, the results are still pretty good:

NSAMPLE = 12
X_STEPS = 6, RAW_THRESHOLD = 14
File, Expected, Simulated, Diff, %, (Original)
HughB-walk-6605.csv, 6605, 6135, -470, 92.88 %, (3223)
HughB-walk-2350.csv, 2350, 2188, -162, 93.11 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 2913, -157, 94.89 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 10220, 199, 101.99 %, (12222)
HughB-drive-36min-0.csv, 0, 53, 53, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 60, 60, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 75, 72, 2500.00 %, (535)
HughB-work-66.csv, 66, 81, 15, 122.73 %, (980)
HughB-work-66.csv, 66, 81, 15, 122.73 %, (980)
HughB-mixed-390.csv, 390, 465, 75, 119.23 %, (1871)
HughB-general-a260-b573.csv, 260, 444, 184, 170.77 %, (3854)
HughB-housework-a958-b2658.csv, 958, 2078, 1120, 216.91 %, (5762)
MrPloppy-stationary-0.csv, 0, 0, 0, 0.00 %, (1)
TOTAL DIFFERENCE 1709

10 still solves Mr Ploppy but I think it's too sensitive.

NSAMPLE = 12
X_STEPS = 6, RAW_THRESHOLD = 10
File, Expected, Simulated, Diff, %, (Original)
HughB-walk-6605.csv, 6605, 6548, -57, 99.14 %, (3223)
HughB-walk-2350.csv, 2350, 2268, -82, 96.51 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 3082, 12, 100.39 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 11388, 1367, 113.64 %, (12222)
HughB-drive-36min-0.csv, 0, 120, 120, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 164, 164, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 195, 192, 6500.00 %, (535)
HughB-work-66.csv, 66, 154, 88, 233.33 %, (980)
HughB-work-66.csv, 66, 154, 88, 233.33 %, (980)
HughB-mixed-390.csv, 390, 663, 273, 170.00 %, (1871)
HughB-general-a260-b573.csv, 260, 790, 530, 303.85 %, (3854)
HughB-housework-a958-b2658.csv, 958, 3601, 2643, 375.89 %, (5762)
MrPloppy-stationary-0.csv, 0, 0, 0, 0.00 %, (1)
TOTAL DIFFERENCE 4092

With NSAMPLE=6 you lose too much low frequency I think and step counting suffers:

NSAMPLE = 6
X_STEPS = 6, RAW_THRESHOLD = 15
File, Expected, Simulated, Diff, %, (Original)
HughB-walk-6605.csv, 6605, 5977, -628, 90.49 %, (3223)
HughB-walk-2350.csv, 2350, 2091, -259, 88.98 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 2775, -295, 90.39 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 9506, -515, 94.86 %, (12222)
HughB-drive-36min-0.csv, 0, 12, 12, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 53, 53, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 26, 23, 866.67 %, (535)
HughB-work-66.csv, 66, 54, -12, 81.82 %, (980)
HughB-work-66.csv, 66, 54, -12, 81.82 %, (980)
HughB-mixed-390.csv, 390, 356, -34, 91.28 %, (1871)
HughB-general-a260-b573.csv, 260, 339, 79, 130.38 %, (3854)
HughB-housework-a958-b2658.csv, 958, 1476, 518, 154.07 %, (5762)
MrPloppy-stationary-0.csv, 0, 0, 0, 0.00 %, (1)
TOTAL DIFFERENCE 1171

So 15 with NSAMPLE=12 worked best, however, I agree more data would be desirable.

Hi there is some extra log files. The 2 train ones should come to very low step counts. The 2 walking ones my pebble had at 600 and 500 steps.

4 Attachments

• train.1.csv
• train.2.csv
• walk.1.csv
• walk.2.csv

Thanks, here are the results for those files. First the current algorithm with threshold 17:

X_STEPS = 6, RAW_THRESHOLD = 17
File, Expected, Simulated, Diff, %, (Original)
mrploppy_train1.csv, 0, 20, 20, 0.00 %, (61)
mrploppy_train2.csv, 0, 6, 6, 0.00 %, (96)
mrploppy_walk600.csv, 600, 577, -23, 96.17 %, (577)
mrploppy_walk500.csv, 500, 575, 75, 115.00 %, (541)

and next the algorithm with the DCFilter and threshold 15:

NSAMPLE = 12
X_STEPS = 6, RAW_THRESHOLD = 15
File, Expected, Simulated, Diff, %, (Original)
mrploppy_train1.csv, 0, 29, 29, 0.00 %, (61)
mrploppy_train2.csv, 0, 0, 0, 0.00 %, (96)
mrploppy_walk600.csv, 600, 590, -10, 98.33 %, (577)
mrploppy_walk500.csv, 500, 563, 63, 112.60 %, (541)

It's marginal but in my view, the DCFilter helps here.

@jeffmer - could you attach the Espruino/libs/misc/stepcount.c file. I'd like to have a look at RAW vs DCfilter output on a graph. Also just easier to see the full context by looking at the whole code etc.

Here's my baseline result from back in september on Firmware v2.11.27

X_STEPS = 6, RAW_THRESHOLD = 14
File, Expected, Simulated, Diff, %, (Orignal)
HughB-walk-6605.csv, 6605, 6397, -208, 96.85 %, (3223)
HughB-walk-2350.csv, 2350, 2243, -107, 95.45 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 3013, -57, 98.14 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 10253, 232, 102.32 %, (12222)
HughB-drive-36min-0.csv, 0, 160, 160, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 192, 192, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 124, 121, 4133.33 %, (535)
HughB-work-66.csv, 66, 97, 31, 146.97 %, (980)
HughB-work-66.csv, 66, 97, 31, 146.97 %, (980)
HughB-mixed-390.csv, 390, 541, 151, 138.72 %, (1871)
HughB-general-a260-b573.csv, 260, 578, 318, 222.31 %, (3854)
HughB-housework-a958-b2658.csv, 958, 2663, 1705, 277.97 %, (5762)

I'd be interested to see this set against RAW_THRESHOLD = 12 with the DC Filter.

I have forked a copy of the test harness repository and added my copy of stepcount.c with the DCfilter. You can find the repository here.

Today I have tried wearing both my bangles (2v11) on the same arm to compare the step counters. The results were as follows:
2h sitting at my desk: 0(b77) vs. 866(b87)
Lunch and rest of day sitting at my desk: 621(b77) vs. 5221(b87)

b77 seems reasonable, albeit probably some percentage points on the low side.

Surprised by the massive difference I have recorded some accelerometer data and run it through the test program:

X_STEPS = 6, RAW_THRESHOLD = 17
File, Expected, Simulated, Diff, %, (Original)
halemmerich-walking-2-b77.csv, 150, 77, -73, 51.33 %, (156)
halemmerich-walking-2-b87.csv, 150, 78, -72, 52.00 %, (151)
halemmerich-stationary-1-b77.csv, 0, 0, 0, 0.00 %, (1)
halemmerich-stationary-1-b87.csv, 0, 7, 7, 0.00 %, (10)

I have walked a counted 150 steps for the first files. The plots while walking seem ok, but the stationary b87 has a lot of "movement" for being very still and having both watches on the same arm.

I don't know if it is related, but the internal HRM also seems to be a lot better on b77 than on b87. I have not recorded data for this, but during testing the difference was often > 20bpm. Maybe some hardware issue interfering with both sensors (missing filter cap, bad solder joint somewhere)?

Can I collect some other or additional data?

1 Attachment

whats a b77 and a b87 and whats the difference between these.
The 51% accuracy is worthless as a step counter ?

Two Bangle.js 2, 77 and 87 are part of the MAC. If I watch the b77 while walking, close to every step gets counted.

Are we saying that b77 is the new firmware and b87 is 2v11?

It looks like they are both using the original threshold of 14 which is why the simulation with 17 is very different. @halemmerich I would be really interested in seeing these with the DCFilter - b77 has a strong positive bias. Happy to run the test harness if you can provide the files or you run it yourself using my version of the harness from here.