You are reading a single comment by @HughB and its replies. Click here to read the full conversation.
  • summary of results so far.

    I attempted to build a javascript version (3.91) using the new filter. But this failed. I noticed steps were not being detected as the 1000 threshold was not being crossed. This is a difference in the way the filter amplifies the input. Rather than tweak threholds I decided to try PEAK detection. This has the advantage of being self adjusting. However it does need a simple gating mechanism otherwise you start finding peeks in the noise signal when the bangle is at rest. When combined with the state machine it works really well. I have tested against the oxford filter but will go back and repeat against the bangle v2.10.9 filter taps and see which one looks best.

    The C code of the oxford step counter has a much smalled set of filter taps and implements two filter ranges. See code.

    https://github.com/Oxford-step-counter/C­-Step-Counter/blob/master/src/filterStag­e.c

    This has:

    static magnitude_t filter_taps[FILTER_TAP_NUM] = {
        -2696,
        -3734,
        11354,
        17457,
        11354,
        -3734,
        -2696};
    
    

    I figured I could scale the vales down so divided by 256 and tried this as a filter as well.

    // a scalled down oxford LPF
    var filter_taps = new Int8Array([-11, -15, 44, 68, 44, -15, -11]);
    

    My latest javascript code is at:
    https://github.com/hughbarney/bangle_bit­s/blob/master/step_counters/steps_310.js­

    Next step for me is to retest another version (3.11) of 3.10 with the same filter taps in the 2.10.9 Bangle Firmware.

    The key problem is when driving. Even Fitbit had a lot of trouble with driving counting steps for a while. There is a support thread on the Fitbit site with users complaining about counting 1000s of steps which driving. I think it depends on the device and formware as I suspect different devices had different teams write the firmware. My original Charge HR seemed to do ok when driving. AmazFit have the driving problem cracked - so it is doable.

    I'm happy to try the 4/8 hour recordings but think it would be better just to record actual activities like WALKING, WORKING at a DESK, SLEEPING. My worry would be if you just adjust thresholds to fit an end of day value that you will loose accuracy when counting walking steps.

    The key problem to be solved I think is screening out counting steps while driving. I did some recordings of my own today, just printed the raw/filtered output to a file in the IDE when I was driving for a few minutes. I could clearly see the impact of going over speed bumps and little bumps in the road. I am wondreing if it will be possible to get an RMS value for driving vs walking etc.


    1 Attachment

    • test-results-22-aug-2021.png
About

Avatar for HughB @HughB started