Avatar for HughB

HughB

Member since Dec 2020 • Last active Jan 2022
  • 90 conversations
  • 740 comments

Been in IT for 40 years. Love interprative programming languages. Wrote my own small Emacs in 2000 lines of C (see Atto on Github). Best way to contact me regarding Bangle stuff is through this forum or the private Message service in the forum.

Most recent activity

    • 40 comments
    • 1,039 views
  • in Bangle.js
    Avatar for HughB

    Did you try a factory reset, in Settings/ Utility.

  • in Bangle.js
    Avatar for HughB

    Yes, I am sure something like that will emerge from the planned Android app.

  • in Bangle.js
    Avatar for HughB

    To test 0.03 you will need to refresh your local repository after Gordon has merged my pull request. I only submitted on Saturday, so hope Gordon is enjoying his weekend.

    Aha - but in the meantime it is available on my loader at:
    https://hughbarney.github.io/BangleApps/­#run

  • in Bangle.js
    Avatar for HughB

    Real world Test results v2.11.30 Step Implementation - INDICATIVE only.

    I have only two two tests so these are indicative.
    @Gordon I was wrong about the threshold - combine it wit X_STEPS = 8 and THRESHOLD = 17 and you start to drop 1000s of steps. Its in the checkin comments of stepcount.c back in september.

    Method: I wore 3 watches on my left wrist. AmizFit BIP, Bangle 2 with 2.11.27 and Bangle 2 with 2.11.30. I used the RUN app with GPS and HEART turned off but it makes it much easier to count steps for a test.

    AMIZ: 5438 10k (scalled up to 10K = 1.84 factor)
    2.11.27 5455 10037 (scalled up by 1.84)
    2.11.30 5166 9505 (scalled up by 1.84)

    I have scalled these to 10k to compare what the step count might be at 10K steps. I have used the scaling factor of the AMIZ - this is just for comparison purposes. Really I would always like to test a 10K step stretch but it is not always possible.

    This shows that 2.11.27 is 100.37% of the AMIZ which is a great result.
    2.11.30 would be 95% of the AMIZ which is the trade off you get. Target is really 98%

    HOUSEWORK - I did a test doing 1h44 housework BUT the 2.11.27 watch got poked somehow and rebooted so I lost the result as the steps got reset. This is the hazard you get when you try and wear 3 watches on the same wrist :)

    AMIZ 524
    2.11.30 482
    The 2.11.27 was always higher.
    What this shows is that maybe the threshold should be 15, 16 or 17 as 18 is making it too insensitive.

    More tests to do.

  • in Bangle.js
    Avatar for HughB

    Just done a pull request for Run v0.03 - which fixes the distance calculation. I have tested against a Garmin Etrex and an AmazFit GTS 2.

  • in Bangle.js
    Avatar for HughB

    I'd really like to find time to properly write this up and but I've already spent a huge amount of time on it already and kind of need to pull back a bit.

  • in Bangle.js
    Avatar for HughB

    Its a bit of a compromise with running and a question of how far you go. If you go less that 300ms for a step then its possble that a rythmic vibration will look like you are stepping.

    For running I think we should rely on the RUN app / GPS for accuracy. I am about to checkin a fix for the RUN app that corrects the distance calculation from the GPS.

    I think if we improve the more common 'walking' and non walking cases first we can then explore the limits (eg moderate to faster running) and see how it performs.

  • in Bangle.js
    Avatar for HughB

    I thought I would explain how the current step counter works, where it is weak and where it could be improved.

    I refer to the diagram below to the various stages.

    TH: - the raw signal is taken scaled and a gating signal derived from the input.
    I will describe why the gating process is needed shortly.
    This has a lot of weaknesses and assumptions but I was unable to come up with
    some simple code to do what was needed. Others may be able to help in this area.

    F : The raw signal is passed onto the LOW PASS FILTER with a cut off frequency of 3hz if I remember. This is to take out high frequencies that will not be walking. Steps take beween 300-1300ms. I did a spreadsheet of ranges that is published in this thread. However the sampling frequency is only 12.5Hz and this in itself results in a filter that could be improved and is unable to
    detect a signal greater than 6.25hz (Nyquest Sampling rule). The current filter is a version of the Oxford step counter filter.

    The filter has an amplification effect on any signal. A small amount of noise will come out of the filter amplified with peaks and troughs that could look like steps - this has been observed with 2 people who have watches that phantomly count steps.

    P : Peak detection. The undulating signal its checked for a Peak. The primary reason for this is that the input to the filter can not be guaranteed to be a blanced zero average signal. In many cases it is offset in the positive direction. This means that some low points will be above the zero line and will not cross a negative threshold value. Using peak detection avoids this issue. The peak detection is crude BUT it works. It was well tested with recordings and I sometimes walked around with a debug version of the step counter connected to the IDE running on my phone. It maybe does not look elegant or good code but it works in practice. I would not say this is the weakest link.

    The primary weakness is the implementation of the Threshold Gating signal - I will cover the reasons for saying after describing the G: and S: phases.

    G: The gate. The gate_open boolen value set by the TH code is used to decide do we send the detected PEAK onto the statemachine or send throw the PEAK away. The idea is that we are not just sending amplified noise to the state machine. It is also necessary because I swapped to PEAK detection shortly after switching to the Oxford filter. The previous filter would result in a more balanced sinewave like signal that would cross the zero line. However the previous BAND-PASS filter also head a 'Ringing' issue that mean't when you stopped moving the signal would echo a further 5 or more cycles that would be counted as steps. Having swapped to PEAK detection it was important to ensure we were not just sending a peak in the noise signal onto the state machine.

    So returning to the TH Threshold detection.
    The idea was to say 'are we generating a strong enough signal to warrant checking if we are walking.
    There are various problems.

    1. There is not a lot of differentiation between gentle walking and noise.
      The changes in acceleration are actually quite small unless you are a STOMPER of a walker like the incredible hulk.

    2. The raw signal can be unbalanced. In that you would expect the sine wave to cross the zero line but it is often offset by a positive value.

    The code assumes that the raw signal will not be offset and only checks that the raw signal is greater that +TH or less that -TH where TH is the threshold value.

    What is really needed is a way to detect the average and to offset the raw signal so that its undulations rise and fall around a zero line. Then what is being fed into the LOW PASS filter will be balanced and just be amplified.

    OR there needs to be two thresolds one for the position range and one for the negative range. EG 14-18 positive but -5 for negative.

    The gate needs to open and close quickly, we allow 3 samples in a row that are above or below the threshold to set the gate and for this to be reset after 3 samples below the threshold. If we extend the time take to decide if the signal is some movement or noise is too long then we could start miss counting more steps during that period. 3 samples is less than 1 second at a 12.5hz sample frequency.

     if (v > RAW_THRESHOLD || v < -1*RAW_THRESHOLD) {
        if (active_sample_count < N_ACTIVE_SAMPLES)
          active_sample_count++;
        if (active_sample_count == N_ACTIVE_SAMPLES)
          gate_open = true;
      } else {
        if (active_sample_count > 0)
          active_sample_count--;
        if (active_sample_count == 0)
          gate_open = false;
      }
    

    One approach to improving this would be have a POS_THRESHOLD and NEG_THRESHOLD and to run tests against the test harness to establish the best pair of values for both.

    But we also need a lot more controlled samples from different people and different watches.
    @johan_m_o - would be good if you could record some samples of different distinct activies against your fitbit. 1 mile walking. driving etc.

  • in Bangle.js
    Avatar for HughB

    @johan_m_o

    Appreciate this is just a first round of testing, a just a rought feedback and more is needed.

    Mixed activities are not great, they dont make good comparisons. We have to be quite rigid in the testing regime and a range of activties measured seperately AND the activity set needs to be as close a possible the same as the last test.

    I came up with this list of tests:

    1) Walking a 1 mile circuit
    2) Sleeping overnight.
    3) Driving 15 minutes or 30 minutes
    4) Sitting at a Desk for 4 hours typing
    5) General housework.

    Even if you walk exactly the same walk, same route, same distance 10 times it will comes out different each time with the same device because your path will always be slighly different, unless you had painted footprints in the path and walked exactly the same footprints etc.
    You have to do the same tests multiple times and take the average, one result is not enough.

    Whats is already known:

    on Threshold 14 Bangle will over count on none stepping acctivties like driving, housework but be within 98% of a control device like a fitbit or Amazfit Bip.

    On Threshold 18 - I would expect the Bangle to under count by maybe 2000 steps over a 10K steps walk. I did the tests and have the result somewhere.

    When I set the threhold at 14 it was because over 10K steps of actual walking I got the most accurate results. I dont want to go on a 10 mile walk and the step counter tell me I have only walked 14000 steps instead of the 20,0000+ it should be saying- as its a pretty worthless step counter in that situation.

    On the days I am not walking I am less bothered about accuracy. If I know I have been in the house all day apart from taking the dog round the block, done a bit of housework - I dont really care if the counter reads 1000 steps or 1500 steps - I know I simply did not get enough exercise that day and I'm not going to fool myself just because a step counter says I did 200-300 steps more than I actually did.

Actions