I am wondering about widpedom though and the step event.

Have now flashed my bangle 1 and 2 with 2v10.27 so should be able to do some real world tests against the actual firmware now rather than the javascript version.

Does Widpedom get 6 step events when the firmware passes through the state machine to reach 6 steps ?

  Bangle.on('step', (up) => {
    let date = new Date();
    if (lastUpdate.getDate() == date.getDate()){
      stp_today ++;     // only gets one step when 6 would be returned by the state machine
    } else {
      // TODO: could save this to PEDOMFILE for lastUpdate's day?
      stp_today = 1;
    }
    ....

During the day there can be 200 passes through the state machine that would result in 6x200 steps. 1200 steps. If the firmware only returns 1 step for these events then at the end of the day widpedom will be 1000 steps short.

Have just verified experimentally that widpedom is only counting one step for the first 6 steps of the state machine. I think either a) Bangle.on('step') needs to provide a step size value of 1 or 6. OR b) the firmware will need to send 6 step events when it moves from S_STEP_22N to S_STEPPING state OR c) need a Bangle.getSteps() which will return the number of steps since the last reboot or something like that.

Results of testing javascript version 3.13 will test the Firmware v2.10.27 once its clear how widpedom is handling the passes through the state machine.

1 Attachment

Ahh - right. So a.mag is what you'd found above - it's sqrt(accMagSquared)/8192

It should be 1/8192 accMag value in stepcount.c: https://github.com/espruino/Espruino/blo­b/fc2d816c57bd36da89972aa39775ba03c3d591­a5/libs/misc/stepcount.c#L248

stepcount uses an integer square root but otherwise the value should be basically identical

Does Widpedom get 6 step events when the firmware passes through the state machine to reach 6 steps ?

Ahh - yes, you're spot on there. The step event actually contains the Bangle's step count as an argument, but it is ignored in that widget. I've just updated the widget!

. I've just updated the widget!

Fantastic. Will update tonight.

Still puzzling over why the test harness results seem different to what I measure in reality but will investigate with the latest widget first as its the only way I can get the step count out of the firmware.

Accellog v0.2 appears to be broken on both b1 and b2 ?

What I see is a quick flash of the overwrite YES/NO dialogue then it returns to the accellog menu. Nothing on the console when connected via the IDE.
Apologies have not tried to fix as I have not got my head around the new Layout module yet.

Just tried and It works fine here for me... Maybe you can run the IDE at the same time and see if any errors are reported?

I know you had issues with the IDE not uploading that font module for you (was that ever fixed?), and I'm wondering whether you're getting the same thing with the App Loader now where it can't find the Layout module. Please could you take a look at the Chrome Dev Console after you upload accellog and see if it reports any errors?

On B2 - Deleted through the AppLoader.
Checked no remanents of files left through the IDE.
Installed through the App Loader
Started accelog App, pressed start
App flashes for a second and returns to menu.
Am using FW 2.10.27.

Checked console log in Chrome Browser, no obvious errros.
Console log of install attached.

1 Attachment

• comms js 2.txt

Getting early test results now against the 2.10.27 firmware that has the full implementation of the step counter in it. Also using the upated widpedom.

SLEEP Amiz 8, 2.10.27 89

• DRIVE Amiz 3, 2.10.27 136
  
• WALK Amiz 3070, 2.10.27 3046 (99.1%) accurate on the walk
  
  

Added logs for the the DRIVE and WALK and into the test harness.
The results validate the test harness and point to the differences with the javascript version.

X_STEPS = 6, RAW_THRESHOLD = 14
File, Expected, Simulated, Diff, (Orignal)
HughB-walk-a3070-b3046.csv, 3070, 3013, -57, (1909)
HughB-drive-a3-b136.csv, 3, 124, 121, (535)

If you look at the walk results, the simulated value of 3013 its actually only 33 steps off the value
measured on the physical device. This gives a lot more confidence in the test harness, and suggests caution with the javascript version in future.

Going to leave everyone in peace for a bit as on holiday next week :)

I just realised something about accellog - maybe try now? I hadn't updated the minified Layout library so the old one was getting used.

Thanks for your work on this! I'm on holiday next week too - but this is all looking really promising now!

Just tried accelog. Problem solved.

It is just about usable on a B2 through the touch screen.

The problem is that the font for the list menu's is so small you need pin point precision with your finger poking to invoke the right option. I think we need at least double the font height for the list menu's. The problem will then be the horizontal space to get the TEXT in. So maybe the list needs to be spread out a bit so that the available touch area to select the option is a bit larger. I guess these will all be discussed over the coming weeks as we gather experience of the B2.

but this is all looking really promising now!

I think we have reached the point now where we have a credible - but not perfect step counter.
Its 98-100 accurate for walking. Not so great in other non stepping scenarios.
But its acceptable when sleeping, not counting at all when sitting typing, watching TV etc.

Improving it further would require a much more complex algorithm, but we now have a good baseline if someone facies taking it to the next level. Be really interesting to see what others think when 2v11 gets released - assume that is sometime away as you have only just released 2v10 ?

That's great! I don't have a timeline for 2v11 yet, but I don't plan on leaving it so long this time. I may attempt to get some built-in handling of HRM and pedometer logging done, in which case I'd do a 2v11 release after that.

The problem is that the font for the list menu's is so small

I've had other complaints about that too, but that is why you don't actually have to tap on the menu item. You just drag your finger up and down to scroll the selected item, and tap to select.

I felt that as you point out, if you had to actually tap the item itself, realistically you'd only be able to have maybe 3 menu items on a screen at once, which would make most of the menus very hard to navigate.

Maybe E.showMenu should have an option to show a big, scrollable, tappable menu - but I think for most cases that would be less user friendly than the current solution

You just drag your finger up and down to scroll the selected item, and tap to select.

Yes, done the scrolling bit but assumed that the tap had to be on the actual menu item. Its pretty nerve racking when you want to select VIEW and the option below it is ERASE or DELETE though.

realistically you'd only be able to have maybe 3 menu items on a screen

Currently there are 8 lines of menu items but they are hard to see and select.
Could the thickness be configurable ? And the text adjust to the thickness ?
EG select 6,5,4 menu items per scoll window ?
The TEXT is so small that you need a magnifying glass to read the text sometimes.
I would not mind scrolling a bit to get to the option I wanted and the list was easier to READ.
It feels very awkward at the moment.
I think this is general problem with Smart UI design.
The AmizFit watches tend to go for 4 lines in a list , scrollable / readable.

I guess this discussion belongs in a seperate thread.

It's configurable in that you can install an app the specifies its own E.showMenu function - there's a post on this in the forum from maybe 2 weeks ago. I guess it could be made even more configurable via an item in Settings.

I had added a new, larger font for Bangle.js 2 (the one used in the menus), but I guess that could be even larger and maybe more bold?

Currently there are 8 lines of menu items but they are hard to see and select.

The thing is they're not hard to select though? You only think they're hard to select because you think you have to press your finger directly on the menu item, but you don't. I've just tried here and even with my large thumb pressed flat on the screen I can easily and repeatably select menu items.

I get your point about the text though. Personally I find it ok and I made the new font to ensure it was the same physical size as the Bangle.js 1 menu font which I felt everyone had come to terms with, but a bump in size wouldn't hurt.

But yes, this should definitely be in a new discussion. It's actually really hard to get a clear idea of what most people want. Many will find it absolutely fine as-is and would find having less than half the number of menu items on the screen frustrating, so it's just getting a good balance.

Thanks - I can confirm I can use the TAP mechanism and it works well.
My only issue is reading the text, even with reading glasses the contrast and size is hard to read.
I have started a new thread for a separate discussion.

Here's the baseline set of test results for the step counter in the current firmware (2.10.27 and beyond).

1 Attachment

Great! Looks pretty promising. Shame about the housework one though.

Shame about the housework one though.

Here's the baseline results through the test harness.
we can see 102% (+2%) accuracy on the 10K step log.
But 277.97 % (+177% over) on the housework log.

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)
TOTAL DIFFERENCE 4013

Now it is possible to improve the housework log to +32% over by increasing the thresholds.
BUT this is at huge cost to the overall accuracy when actually walking.
I would not be happy with only 85% accuracy over a 10,000 step walk. Needs to be 98-102%.

X_STEPS = 8, RAW_THRESHOLD = 17
File, Expected, Simulated, Diff, %, (Orignal)
HughB-walk-6605.csv, 6605, 6012, -593, 91.02 %, (3223)
HughB-walk-2350.csv, 2350, 2198, -152, 93.53 %, (1042)
HughB-walk-a3070-b3046.csv, 3070, 2891, -179, 94.17 %, (1909)
HughB-walk-a10021-b10248.csv, 10021, 8542, -1479, 85.24 %, (12222)
HughB-drive-36min-0.csv, 0, 13, 13, 0.00 %, (1199)
HughB-drive-29min-0.csv, 0, 46, 46, 0.00 %, (1153)
HughB-drive-a3-b136.csv, 3, 52, 49, 1733.33 %, (535)
HughB-work-66.csv, 66, 56, -10, 84.85 %, (980)
HughB-work-66.csv, 66, 56, -10, 84.85 %, (980)
HughB-mixed-390.csv, 390, 356, -34, 91.28 %, (1871)
HughB-general-a260-b573.csv, 260, 226, -34, 86.92 %, (3854)
HughB-housework-a958-b2658.csv, 958, 1266, 308, 132.15 %, (5762)
TOTAL DIFFERENCE 3671

So I think without a radical rethink this is the limit of what can be acheived with this algorithm.

Yes, seems sensible. There's also nothing to say that the watch you're using for a baseline is actually logging the steps for housework correctly either...

Hi all, excited to see how things are progressing here. I was curious to know how much of the original windowed peak detection is left in the current implementation?

The last version of the Oxford step counter in C was optimised for Bangle actually, and I even added a detection stage to filter out non-movement based on a minimum amplitude. I collected some data myself, 17 files with manually counted reference, and the accuracy was >90%.

Gordon, maybe having some sort of competition would be indeed a good idea, but we need to set it up well, which means good data and a simple way to run the code. I could also propose it to students here at the Uni.

A bit unrelated, but we could do the same for heart rate.

@user107850 - were you involved with the Oxford Step counter project.

I dont think @Gordon's attempt to follow the Oxford approach got off the ground.
I think he introduced a low pass filter which had a lot of ringing.
My main contribution has been testing. I have done litterally 100s of tests.
I built prototypes in Javascript and finally checked in some C code changes.
I identified the Oxford LPF filter as a better filter which is now used.
I introduced a state machine which made things significantly more accuate.

The actual C code for the Bangle step counter is at:
https://github.com/hughbarney/Espruino/b­lob/master/libs/misc/stepcount.c

If you were involved in the implementing the Oxford step counter I would be really interested to undertsand how the code works as I found it hard to follow after spending many hours looking at it. The event / queue driven structure of the code had me totally confused.

I am also interested in what testing the Oxfrod team did to test non stepping activities like driving.
150 steps (about 10 minutes of activity) is not enough to have confidence in a step counter. I could not find any test results for activities like driving, sleeping, sitting at a desk, typing etc etc. All of which should log very few steps per hour.

but we need to set it up well, which means good data and a simple way to run the code.

I have collected accelerometer logs for various activties. We have about 20 measured logs and these were calibrated against an AmizFit Bip which appears to be pretty accurate from the various tests I have done. When collecting the logs I wore the Amizfit Bip on the same wrist as the Bangle and recorded the steps recorded by both devices. The output in my above posts are from the test harness and the results are a good match for what gets measured in reality - so as a good simulation against algorithm changes.

I would be really interested in talking with you if you know more about the Oxford approach.

Hi, yes I was involved, I proposed the idea as a BsC project and I supervised students both at Oxford and at Malmo who worked on that.

The approach is described in two papers: here (behind paywall) and here. The basic idea is that the signal is converted to magnitude, then peaks are somewhat amplified, identified and selected.

You can split the algorithm into a pipeline of stages, with buffers between each stage. Not all stages are mandatory, for example I observed that interpolation and linear filtering do not bring any significative improvement and can be skipped.

As far as I remember, Gordon embedded the algorithm into the Espruino firmware at some point, but he complained about the fact that it took too much memory. After that I spent some time trying to remove redundancies and optimising memory a little bit, but I don't know if Gordon included those changes or if he decided to adopt another approach in the end.

Re. non-walking activities: the algorithm was meant to be used during walk and was not optimised to distinguish between genuine walk and other activities. To address this, I later added a basic movement detection step which improved things a bit on my short tests, but I have never tested it "in the wild" for a long time.

As for the competition, we could separate the algorithm from the Espruino code, prepare the testing dataset and add some wrapping code that runs the algorithm and compares it with the reference. I have something similar already I used myself to test my algorithm: I would happily polish it a little and share it if there's interest.

The last version of the Oxford step counter in C was optimised for Bangle

Yes - I looked at this code. I took the filter taps from its and scaled them down to work with the Bangle. A lot of the code is around the pipeline and buffers. It would be interesting to see what it looked like without the buffering and pipeline and was just sequential.

The approach the Bangle currently takes is very similar

1) The magnitude value is taken. 2) There is a small threshold that must be crossed for 3 samples before we pass the output to the low pass filter - otherwise we dont pass to the next stages. 3) The filtered output is passed through a simple peak detection 4) the peak event is passed through a state machine that checks that the current peak event is within the expected step time 0.3-1 second from the previous peak event. I think this is the same as your sliding window, though I dont understand the terminology - could do with a diagram 5) The state machine also counts up to 6 steps before starting to return step events to the clients in the Bangle. The first event once 6 steps are reached returns 6 steps. The state machine screens out a lot of non stepping activity.

We have some good accelerometer data at:
https://github.com/gfwilliams/step-count­/tree/master/data

I would be really interested to see how the oxford step counter performs using the logs below:

HughB-drive-a3-b136.csv
HughB-general-a260-b573.csv
HughB-housework-a958-b2658.csv

HughB-walk-a10021-b10248.csv - is a 10K step log which can be used to test walking

The a value is the steps recorded by the AmizFit Bip.
The b value is the steps recorded by the 2.10.27 step counter.

These 4 test cases are enough to assess the accuracy when walking and not walking.

not optimised to distinguish between genuine walk and other activities.

This where all the difficulty lies. I am pretty certain any student can make a step counter that is reasonably accurate when walking. I have seen all sorts of code / papers that claim good accuracy but they never discuss a real world test methodology around not counting steps for non step activities. This is the bit that no one seems to do. As you say some of the other parts of the algorithm are not really contributing much when the problem is just counting steps. It is the screening out of the non step activities that is the important thing otherwise you count 2000+ steps just typing at a computer sitting at a desk for 4 hours.

As for the competition,...prepare the testing dataset and add some wrapping code that runs >the algorithm and compares it with the reference.

If you could build a framework around those test cases above then I think we would have what we need. I'd really like to see what the oxford results are for the 3 non stepping cases, if it does this well then we might not need a competition.

Hello,
one note about your "ringing": it is maybe because of the pass-band filter. Have you tried with a low pass instead? Or can you just remove the filter altogether?

It would be interesting to see what it looked like without the buffering and pipeline and was just sequential.

Yes, I asked students to do that but they didn't have enough time. I agree that the buffers are not needed.

The approach the Bangle currently takes is very similar

Peak detectors are somewhat similar. The main issue is adapting to a signal where amplitude can change quickly. There are also other approaches than peak detection, like analysis in frequency, wavelets, or even machine learning, but I don't think they are suitable for an embedded device like a smartwatch.

If you could build a framework around those test cases above then I think we would have what we need.

Yes, I'll set it up and post the link here. I'll try to do it next week.