Search results for:

Thanks @johan_m_o, do you have another device to calculate the step count? We need logs that are a known step count. I use an Amazfit bip or GTs on the same wrist when making recordings. This allows us to check the simulated counted steps against the step count recorded by the other device. We need logs with 1000s of steps, its not really practical to manually count steps.

Looks like the test harnesses are in agreement in that the results we get from the Bangle harness are the exactly the same counts as your harness.

Brilliant to see these comparisons.

Looks like it has better accuracy than the Oxford one, especially in absence of movement. Well >done!

Thank you. Its good to see the confirmation of the approach and also the approach to testing.

$ ./banglejs-algos-tester |grep -v dummy|grep uncontrolled
steps-uncontrolled, oxford, 0_HughB-drive-29min-0.csv, 469, 0
steps-uncontrolled, espruino, 0_HughB-drive-29min-0.csv, 192, 0
steps-uncontrolled, oxford, 0_HughB-drive-36min-0.csv, 512, 0
steps-uncontrolled, espruino, 0_HughB-drive-36min-0.csv, 160, 0
steps-uncontrolled, oxford, 0_HughB-drive-a3-b136.csv, 321, 0
steps-uncontrolled, espruino, 0_HughB-drive-a3-b136.csv, 124, 0
steps-uncontrolled, oxford, 0_HughB-static.csv, 0, 0
steps-uncontrolled, espruino, 0_HughB-static.csv, 0, 0
steps-uncontrolled, oxford, 0_HughB-work-0.csv, 259, 0
steps-uncontrolled, espruino, 0_HughB-work-0.csv, 20, 0
steps-uncontrolled, oxford, 0_HughB-work-66.csv, 414, 0
steps-uncontrolled, espruino, 0_HughB-work-66.csv, 97, 0
steps-uncontrolled, oxford, 10134.csv, 14824, 10134
steps-uncontrolled, espruino, 10134.csv, 10253, 10134
steps-uncontrolled, oxford, 3058.csv, 3135, 3058
steps-uncontrolled, espruino, 3058.csv, 3013, 3058

The more data we have the better.

Totally agree. I was attemoting to collect up to 4 10K+ step logs when I ran into a problem with the logger. I will get back to collecting logs again soon. Need some 1 hour logs for sleep, driving, working, sitting watching TV - all ZERO step logs.

Got the same build error again. Did you resolve the time_t definition clash ?

I recloned the repository and started from scratch. Still get the build error.

Scanning dependencies of target banglejs-algos-tester
[  7%] Building C object CMakeFiles/banglejs-algos-tester.dir/src/main.c.o
In file included from /home/hughbarney/src/banglejs-algos-tester/src/stepcounters/stepcounters.h:4,
                 from /home/hughbarney/src/banglejs-algos-tester/src/main.c:6:
/home/hughbarney/src/banglejs-algos-tester/src/stepcounters/../types.h:11:18: error: conflicting types for ‘time_t’
 typedef uint32_t time_t;
                  ^~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:129,
                 from /usr/include/stdlib.h:394,
                 from /home/hughbarney/src/banglejs-algos-tester/src/main.c:4:
/usr/include/x86_64-linux-gnu/bits/types/time_t.h:7:18: note: previous declaration of ‘time_t’ was here
 typedef __time_t time_t;
                  ^~~~~~
make[2]: *** [CMakeFiles/banglejs-algos-tester.dir/build.make:63: CMakeFiles/banglejs-algos-tester.dir/src/main.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/banglejs-algos-tester.dir/all] Error 2
make: *** [Makefile:106: all] Error 2

The easiest way to fix this is to comment out the time_t definition in types.h and add include at the top of types.h

@user107850 - I managed to get it to compile with this hack:

I dont think you need to worry about rolling over time_t in 1 year of milli seconds for a test harness where the logs are a few hours at most.

$ git diff
diff --git a/src/types.h b/src/types.h
index 6e74ab1..39a972e 100644
--- a/src/types.h
+++ b/src/types.h
@@ -1,11 +1,12 @@
 [#include](https://forum.espruino.com/search/?q=%23include) <inttypes.h>
+#include <time.h>
 
 // type for the accelerometer samples, this depends on your hardware
 typedef int16_t accel_t;
 
 // type used for time: warning the algorithm is not robust to roll-over of this variable
 // example: a year worth of ms needs 35 bits, 32 bits allows you to store about 50 days of ms
-typedef uint32_t time_t;
+//typedef uint32_t time_t;
 
 // steps count type
 // the size of this depends on what is the maximum number of steps you are willing to show and store
$ 

But when I ran it I didn't match the results you showed in the README file.

$ ./banglejs-algos-tester |grep oxf
steps-controlled, oxford, 0.csv, 0, 0
steps-controlled, oxford, 0_1.csv, 0, 0
steps-controlled, oxford, 0_2.csv, 0, 0
steps-controlled, oxford, 0_3.csv, 0, 0
steps-controlled, oxford, 100.csv, 77, 100
steps-controlled, oxford, 100_1.csv, 79, 100
steps-controlled, oxford, 100_2.csv, 80, 100
steps-controlled, oxford, 100_3.csv, 170, 100
steps-controlled, oxford, 100_4.csv, 268, 100
steps-controlled, oxford, 100_5.csv, 270, 100
steps-controlled, oxford, 100_6.csv, 270, 100
steps-controlled, oxford, 100_7.csv, 270, 100
steps-controlled, oxford, 150.csv, 326, 150
steps-controlled, oxford, 150_1.csv, 345, 150
steps-controlled, oxford, 150_2.csv, 564, 150
steps-controlled, oxford, 150_3.csv, 727, 150
steps-controlled, oxford, 150_4.csv, 914, 150
steps-uncontrolled, oxford, 0_HughB-static.csv, 0, 0
steps-uncontrolled, oxford, 10134.csv, 17314, 10134
steps-uncontrolled, oxford, 3058.csv, 20694, 3058
steps-uncontrolled, oxford, 0_HughB-work-0.csv, 22287, 0
steps-uncontrolled, oxford, 0_HughB-work-66.csv, 24182, 0
steps-uncontrolled, oxford, 0_HughB-drive-29min-0.csv, 26783, 0
steps-uncontrolled, oxford, 0_HughB-drive-36min-0.csv, 29674, 0
steps-uncontrolled, oxford, 0_HughB-drive-a3-b136.csv, 29678, 0
$ 

I noticed that the step count was just incrementing file on file.
So I looked at the reset code and put a reset in after printing the results from a single test.
See diff below.

diff --git a/src/main.c b/src/main.c
index 0dc2d1d..a4838cb 100644
--- a/src/main.c
+++ b/src/main.c
@@ -69,6 +69,7 @@ void becnhmarkFolder(char *prefix, char *dirname)
 
                 fclose(pFile);
             }
+           resetStepCounters(); // reset after every run
         }
     }
     closedir(folder);
@@ -89,4 +90,4 @@ int main()
     resetStepCounters();
 
     return 0;
-}
\ No newline at end of file
+}

Now the results look more realistic and the 3058.csv result for the Oxford of 3301 steps EXACTLY matches your results.

$ ./banglejs-algos-tester |grep oxf
steps-controlled, oxford, 0.csv, 0, 0
steps-controlled, oxford, 0_1.csv, 0, 0
steps-controlled, oxford, 0_2.csv, 0, 0
steps-controlled, oxford, 0_3.csv, 0, 0
steps-controlled, oxford, 100.csv, 113, 100
steps-controlled, oxford, 100_1.csv, 101, 100
steps-controlled, oxford, 100_2.csv, 102, 100
steps-controlled, oxford, 100_3.csv, 91, 100
steps-controlled, oxford, 100_4.csv, 77, 100
steps-controlled, oxford, 100_5.csv, 84, 100
steps-controlled, oxford, 100_6.csv, 80, 100
steps-controlled, oxford, 100_7.csv, 80, 100
steps-controlled, oxford, 150.csv, 138, 150
steps-controlled, oxford, 150_1.csv, 150, 150
steps-controlled, oxford, 150_2.csv, 192, 150
steps-controlled, oxford, 150_3.csv, 131, 150
steps-controlled, oxford, 150_4.csv, 151, 150
steps-uncontrolled, oxford, 0_HughB-static.csv, 0, 0
steps-uncontrolled, oxford, 10134.csv, 17314, 10134
steps-uncontrolled, oxford, 3058.csv, 3301, 3058
steps-uncontrolled, oxford, 0_HughB-work-0.csv, 1347, 0
steps-uncontrolled, oxford, 0_HughB-work-66.csv, 1639, 0
steps-uncontrolled, oxford, 0_HughB-drive-29min-0.csv, 2372, 0
steps-uncontrolled, oxford, 0_HughB-drive-36min-0.csv, 2651, 0
steps-uncontrolled, oxford, 0_HughB-drive-a3-b136.csv, 1093, 0

Can you check the 2 changes I have made to the test framework code are correct.

I will do a pull request for the test files.

@user107850 - I ran into build issues. I had to create the build directory, but there is also a clash with time_t.

I am on a Linux Debian environment

$ uname -a
Linux penguin 5.4.131-16049-gc688e114d34e #1 SMP PREEMPT Sun Sep 19 21:16:20 PDT 2021 x86_64 GNU/Linux

$ 
$ mkdir build
$ pwd
/home/hughbarney/src/banglejs-algos-tester
$ 
$ ll
total 12
drwxr-xr-x 1 hughbarney hughbarney    0 Oct  4 21:13 build
-rw-r--r-- 1 hughbarney hughbarney  608 Oct  4 21:04 CMakeLists.txt
drwxr-xr-x 1 hughbarney hughbarney   10 Oct  4 21:04 data
-rw-r--r-- 1 hughbarney hughbarney 1068 Oct  4 21:04 LICENSE
-rw-r--r-- 1 hughbarney hughbarney 1703 Oct  4 21:04 README.md
drwxr-xr-x 1 hughbarney hughbarney   50 Oct  4 21:04 src
$ 
$ 
$ cd build
$ cmake ../
-- The C compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/hughbarney/src/banglejs-algos-tester/build
$ 
$ cmake --build .
Scanning dependencies of target banglejs-algos-tester
[  8%] Building C object CMakeFiles/banglejs-algos-tester.dir/src/main.c.o
In file included from /home/hughbarney/src/banglejs-algos-tester/src/stepcounters/stepcounters.h:4,
                 from /home/hughbarney/src/banglejs-algos-tester/src/main.c:6:
/home/hughbarney/src/banglejs-algos-tester/src/stepcounters/../types.h:8:18: error: conflicting types for ‘time_t’
 typedef uint32_t time_t;
                  ^~~~~~
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:129,
                 from /usr/include/stdlib.h:394,
                 from /home/hughbarney/src/banglejs-algos-tester/src/main.c:4:
/usr/include/x86_64-linux-gnu/bits/types/time_t.h:7:18: note: previous declaration of ‘time_t’ was here
 typedef __time_t time_t;
                  ^~~~~~
make[2]: *** [CMakeFiles/banglejs-algos-tester.dir/build.make:63: CMakeFiles/banglejs-algos-tester.dir/src/main.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/banglejs-algos-tester.dir/all] Error 2
make: *** [Makefile:106: all] Error 2
$ 
$ pwd
/home/hughbarney/src/banglejs-algos-tester/build

I will have a look at how easy it is to attach the current step counting algorithm into your framework.

Note its already in the current firmware at:
https://github.com/espruino/Espruino/blob/master/libs/misc/stepcount.c

I'm concerned that the test harness does not have enough non-stepping data and long enough logs.

We must have good tests cases for when not walking - otherwise we are just prone to the same mistakes and errors as before. We can easily be fooled in thinking a code tweak has improved things when it fact it has not. A bad selection of test data will waste our time. Any step counter must be measured against stepping and non-stepping scenarios in equal measures.

The Accelerometer logs below are all ZERO steps and should be part of the controlled test data in my view. I was not walking when they were logged, I was sitting or driving or typing at a Desk. These and similar logs must form at least 50% of the test data in any test harness.

HughB-drive-36min-0.csv
HughB-drive-29min-0.csv
HughB-drive-a3-b136.csv
HughB-work-66.csv

It would be useful to keep the same file names so that provenance of the logs can be tracked. Or we should keep a proper register of every log detailed where it came from and and any other measurements that were done against it at the time.

I am also concerned that the current 0 step samples (0.csv 1.csv, 2,csv) are only 30 seconds long. This is not long enough to flush out problems. For example the drive-a3-b136 log was a 15 minute log and the AmizFit Bip registered 3 steps where as the Bangle registered 136. I suspect it would be possible to select many different 30 second segments from that log and have a target step counter register 0 steps - thus fooling ourselves.

I'm glad you have included HughB-walk-a10021-b10248.csv as 10134.csv as its a really good log. It was recorded recently. I wore both watches on my left wrist whilst walking across the yorkshire dales :)

I feel like it's actually working pretty well now

Its pretty good, but not perfect. I'd like to get the housework log down a bit.

When I have a day at home sat at a desk I expect to see about 600-800 steps for the day, and often see 1500-2000. But where as before it was really obvious where the inaccuracies were I think it might be a while before users start raising issues. Once the new daily logging is in place then I thnk it will be more obvious for people to spot the over counting.

filtering on X/Y/Z separately and then getting magnitude would help with false steps.

We'd have to do the experiments. Maybe an experiment for the future using the javascript version.
I think looking at plots of the x,y,z when of the driving accelerometer logs would be intereseting to do.

I am using Gadgetbridge 0.59.3 from F-Droid. Same problem with incomimg call notifications.

Regarding ringing, yes we switched to a low pass filter. Its the same one you use in the c code with the coefficients scaled down.

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.

Developing some reliable step counting and heart rate measurement is going to be a challenge for us!

@user107850 - totally agree. We have to get these solid if a health / fitness app is going to be of any value on the Bangle watches.

Whilst working on Findphone to make it work with Bangle 2 I have come across a strange issue. I first thought I had broken Findphone but have observed the same problem in Settings. It seems that you have to click on ON twice when using Findphone in the Settings App when Gadgetbridge is installed to get the phone to start ringing. Its as if the very first Bluetooth message is lost.

@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/blob/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.

I guess time will tell - which is the best way to go.
Fullscreen works best for me at the moment.

One to watch out for. Could save a lot of forum time just to ask people to try one of the known clocks first. I'm working on a troubleshooting section for the GB README file.

Got my first SMS notification on my B2 today so definitely up and running now. Thanks for the help.

Did you try just waiting a minute?
I did. It just stuck there was several minutes.

You mean Bangle.factoryReset() at the IDE ? That sounds handy. Clever stuff.

What about the App Loader though - I dont think it is deafulting to Bangle 1 Apps when you use the existing functions on the About section.

because it's always possible the issue is not the app

After stopping the logging - I go into View Logs and the App reports the log length as 2 records. Its not always 2. The first instance was 180+ records. But should have been in the 1000s. The App returns super quick when you select view which indicates that the time to read the file was very short.

I have the same issue. Can get missed call notifcations but not incoming calls.
When logging the GB traffic I see two notifications that are both the same - with a blank cmd: key.

ok - the problem is something todo with the timer and the Bangle.on('lcdPower', function(on).

Not sure why the following code is needed on a B2 when the screen is on all the time.

// Only update when display turns on
if (process.env.BOARD!="SMAQ3") // hack for Q3 which is always-on
Bangle.on('lcdPower', function(on) {
  if (secondInterval)
    clearInterval(secondInterval);
  secondInterval = undefined;
  if (on)
    secondInterval = setInterval(draw, 1000);
  draw();
});

I've made the following changes and pastel clock now works with Full Screen Notifications.

I think in future when users report issues with Gadgetbridge the first question should be to switch to one of the stock clocks.

Can connect through the IDE.
BTN reset just ends up stuck at this state.
Ok - managed to recover through erasing all apps and attempting to install defaults.

However the app loader installs defaults for a Bange 1 not a Bangle 2 - had to manually install the apps by hand.

This raises a few issues:
1) Seems a good way to hang your bangle by clobbering the default clock app.

How I got into this position: - I was some trying some code out on pastel.app.js and made a typo. As it was the default clock it failed to load. Tried a reset but went into DFU start. Tried a reset and got stuck at checking storage.

Maybe the booloader should have a failsafe clock that can kickin in if the default clock fails to load ?

2) Bangle 2 - App loader default Apps loads Bangle 1 Apps.

I'm on 2.10.51 for Bangle 2. See screenshot of About below.
Ok - looks specific to my B2 then.
I just had to erase all apps and re-install from scratch.
I'll try another test tomorrow, maybe the erase all will have cleaned up the Storage (maybe I am clutching at straws).

@Gordon - I tried the debig trick where you replace GB() with a function that writes to a log variable.

I then disconnected from the IDE and connected to GadgetBridge and called my mobile.
No notification.
Then disconnected from GadgetBridge and connected through the IDE.
I can see that log go written to.
But there was no notification on the Bangle 2.

>log
=[
  "{\"t\":\"call\",\"cmd\"" ... "r\":\"0191xxxxxxx\"}",
  "{\"t\":\"call\",\"cmd\"" ... "r\":\"0191xxxxxxx\"}"
 ]
>

I then reset my B2 with a long button press so that the GB() function would be restored.
I then tested the pop up again with:

GB({"t":"notify","id":1575479849,"src":"Hangouts","title":"A Name","body":"message contents"})

This worked and produced a pop up.
I then decided to switch clocks to WaveClock.
And voila - it worked when I rang my mobile.

So the question is - what does a clock have to do, to allow Gadgetbridge to work ?

Hmm - if one overwrites the other I dont see how you could have both installed at the same time. There will only ever be one notify file on the device. But there would be a unique info file on the bangle so the app loader should know which one is installed ? At the moment I delete both just to make sure then install the one I want.

Would it not be possible to have one notify module and have it configurable fullscreen / pop up style notifications ?

Hmm, that's a pain about the pedometer. That's with large font, but no progress display?

Yes - shall we split this off into a seperate thread so as not to confuse B2 notifications.

@Gordon have switched back to thread: 'Anyone had much sucess with Gadgetbridge on Bangle 2'