Pebble Vs Bangle

Thanks @Mr_Ploppy, that's great!

I've just looked at the datasheet and it says there's a maxiumum zero-g offset for the accelerometers of 90mg (or 25 typical) - so that's 8192*90/1000 = 737 maximum, or 205 normally!!

So it's hardly surprising that some people are finding the step count going crazy - @Mr_Ploppy's accelerometer isn't broken or defective, it's actually well within spec.

The datasheet (https://kionixfs.kionix.com/en/datasheet­/KX023-1025%20Specifications%20Rev%2012.­0.pdf) does hint that the offsets can be due to things like stress (so the PCB expanding/contracting slightly and squashing the accelerometer) so it may not even be something we can calibrate for as it may change depending on temperature.

So...

• what happens if we increase the threshold? It seems like it may be a benefit looking at those stats you posted. Sure, it has a 0.5% change during a walk, but for driving/housework/etc which were always an issue it's 50%+ better!
  
• Maybe instead of accMag-8192 we have a long-term average of accMag that we subtract? that way it effectively auto-calibrates.
  
  

I think I'd mentioned this at the time with this updated peak detector, but the old one required that the acceleration be below a threshold, then above in order to trigger - and I don't think it would have suffered as much with this. We could always look at doing a slightly different method of peak detection.

1 Attachment

The problem of removing the static accelerometer magnitude would seem to be the same as DC removal in Digital Signal Processing. The problem with a simple moving average is that it may obscure the signal at some orientations if as seems likely the magnitude at rest varies due to rotation. There is a great article here on a low cost very simple digital filter to deal with this - it even lists a 3-line Javascript implementation.

but the old one required that the acceleration be below a threshold, then above in order to trigger
and I don't think it would have suffered as much with this.

The old approach was way off though, it was not a practical, beleivable step counter in any shape or form.

I think for now increase RAW_THRESHOLD to 15. But around 16, 17 you start to have a step counter that wont count steps properly.

I think a calibration process would be the best way to go. Having the Bangle lie flat on a table for 1 minute and work out where the noise offset is. Then offset the raw signal. Either that or another approach. But to be honest at 12.5 sampling frequency filter design is severely constrained - as high frequency would be classed as up to 6.5Hz. After that all bets are off due to the Nyquest sampling rule.

@myownself - you will be interested in this thread if you have not already spotted.

I dont think I can take this any further, it needs fresh eyes. It was a lot of experimentation. We have a good test harness and good reference accellogs so any hypothesis can be tested to see if it improves matters.

I've spotted it, thanks.
I haven't had chance to try with that sample yet, but I'm hoping at least one of my experiments will cope with it.

But to be honest at 12.5 sampling frequency filter design is severely constrained - as high frequency would be classed as up to 6.5Hz. After that all bets are off due to the Nyquest sampling rule.
Yes, I've so far found that filters haven't been that helpful because of the sampling frequency.

Ok, thanks... I'll bump the threshold up to 15 for now, which should help as you say.

I'm not convinced with a calibration step. I'm not sure it's as easy as placing it on a table, and I'm not aware of any other device that asks for the accelerometer to be calibrated. I doubt many people would be happy doing that.

The old approach was way off though

As a complete system, yes. However there are plenty of different ways of doing peak detection and the current way is definitely not the most robust.

Hopefully someone can jump in and try some more options out though. @jeffmer that link looks really neat - took me a while to see I had to click on the graphs though :)

It's possible that something like that code would work fine for us. We originally had a bandpass filter which cut out the DC element completely, but that meant there was ringing, which caused other issues :)

That blog's got some other great-looking articles too:

http://sam-koblenski.blogspot.com/2015/1­0/everyday-dsp-for-programmers-frequency­.html
http://sam-koblenski.blogspot.com/2015/1­1/everyday-dsp-for-programmers-spectral.­html

I spent a significant part of my evening reading through that website. Thanks @jeffmer.

Ok, I'm just pushing changes to change the step count threshold from 14-> 18.

My reasoning:

In the step-count repo, we were applying an equal relevance to the steps from all files. IMO if there's a long walk with 10000 steps and you detect 1% less steps, that's less of a big deal than detecting 100 steps over a period where you shouldn't be detecting any steps at all.

When I readjusted things a little to give more weight to @HughB's work/housework/driving and
@MrPloppy's code, the best threshold went from 14->18. It means:

• Normal walking activities, 97% accurate -> 93%
  
• Driving: roughly 30% of the amount of steps recorded
  
• Working: roughly 50% of the amount of steps recorded
  
• Housework/general: roughly 50% of the amount of steps recorded
  
  

So there is a difference in step counting during walking (relative to other step counting devices), but I think as far as day to day wearing of the device goes, this should be a massive improvement to accuracy.

@Gordon 17 kills the step counter dead in reality. This is very finely balanced. I think you will find everyone will start complaining it is undercutting by 2000 or more steps in 10k steps or worse.

You will have to trust me on this, I did the tests, doing actual walking as the test harness is not perfect.

@Gordon I wanted to jump in and test the new threshold, but it seems like the cutting edge firmware isn't being built as it should. Still stuck on 2v11.24 from 13 january.

Argh, ok - thanks - it seems I've run out of credits for Travis again. I'll try and get it topped up.

... might end up ditching it and just build on my server. Won't be as fast but at least it won't keep breaking or running out of credit :)

@HughB thanks - I'll give it a good try here and make sure it still works on a real walk with the new settings.

Any idea why the test harness wouldn't be perfect though? It should be exactly the same code running with the exact same data.