Better Pedometer - HELP NEEDED!

Posted on
of 6
First Prev
/ 6
  • 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

    • Screenshot 2021-08-31 22.23.44.png
  • 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:­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

  • 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.

    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.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Better Pedometer - HELP NEEDED!

Posted by Avatar for Gordon @Gordon