Avatar for GrandVizierOlaf


Member since Mar 2022 • Last active May 2022
  • 0 conversations

Most recent activity

  • in Bangle.js
    Avatar for GrandVizierOlaf

    Wonderful, thanks! To add to what @Mi said, the manufacturerData is your actual health data. Without looking up the spec I would assume that a large part of it is the PPG data and it ends with your HR, the 59. For the curious, you can also pick out how the name is encoded in the data section;

    19=read 19 bytes with the next byte explaining the section
    9=what follows in the other 18 bytes name of the device

    @Mi, the id scheme is up to the manufacturer, but follows a spec. This is the summary that made the most sense to me. Given that the H10 rerandomizes after pulling the battery I was a little concerned that the OH1 might do the same after a power cycle or be of a type that expects bonding (given that BTHRM was connecting by name before and that wouldn't be changing), but that is not the case given @Fteacher's data. It might have a method to factory reset the device which would cause it to rerandomize, but that is fortunately not our concern.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    Here's the quick answer with too much information: https://github.com/espruino/BangleApps/pĀ­ull/1655

    Basically, trying to make connection improvements to the BTHRM app without breaking backwards compatibility.

    I'm happy to talk more about it after getting the kids off to school.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    Fantastic, thanks @Mi!

  • in Bangle.js
    Avatar for GrandVizierOlaf

    @Fteacher, I haven't forgotten about this but have been working through some quirks with the Polar H10 and BTHRM app. Do you mind doing a test with your OH1 if you get a chance? We're trying to determine if the Bluetooth address is changing on a common device that is powered on and off.

    @Gordon will you make sure I'm not crazy here based on our BTHRM discussions?

    1. Open the web IDE and connect to your watch
    2. With the HRM off, execute this command:

      NRF.findDevices(function(d) {
      }, { timeout: 4000, active: true, filters: [{ services: [0x180D], }] });
    3. Turn the HRM on

    4. Make sure your HRM is set to be discoverable, likely from the Polar app

    5. Run the same command as above (you might need to give it a minute to start broadcasting)

    6. Power off the HRM, wait a few minutes, and run the same command as above

    7. Turn the HRM back on and run the same command as above

    8. Paste the results of the test here or at least let us know if the discovered BluetoothDevice had a different id after power cycling

    I'm also curious what Espruino firmware you're on and if the BluetoothDevice has a name, but that is more a curiosity around the original issue I had with my H10 which has since been fixed.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    @Fteacher FYI, Gordon got the the box settings problem is fixed in 0.13.

    Also, I have a Polar H10 arriving today and after getting used to it for a couple of runs I can start looking at the HRM alarm configuration we discussed the other day.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    I totally agree!

    Similarly, with the en_US locale I don't get much benefit from the distances before 1 mile being shown in yards and would rather it be in tenths of miles. Does anyone else have an opinion of that?

  • in Bangle.js
    Avatar for GrandVizierOlaf

    @Gordon this is because the if check is happening in onchange, which is triggering even when the value isn't submitted.

    Edit: I was looking at master and not the RELEASE_2V12 tag for this analysis, which might still be true for master, but does not apply to this discussion. RELEASE_2V12 analysis appears below.


    If I'm reading it correctly it looks like there is a discrepency in E_showMenu_Q3.js where if the list is short it will use Bangle.setUI directly with updown and it will only call item.onchange when an item in the list is selected (dir is not set in the Bangle.setUI cb), but E.showScroller fires select (and therefore E.showMenu's item.onchange) every time the scroll position is updated.


    E_showMenu_Q3.js will trigger onchange every time the menu calls move.

    If that analysis is correct it would be nice to rectify it and have two functions, one for as the item scrolls and one for as the item is saved. For RELEASE_2V12 it would be straightforward to leave onchange where it is called within E_showMenu_Q3's move and add something like onsave to the else where the selection is made, but for the code in master it's not as straightforward.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    Thanks @Fteacher, I was able to duplicate the issue and have opened a PR.

    I am very interested in the HR alarm and think it would be relatively straightforward to turn the hralarm widget (by @halemmerich) on and off much as the recorder widget is today. I do not yet have a external HRM to test with, do y'all have any recommendations or know what to stay away from?

    @Gordon you mentioned in the original run notifications PR that you didn't want to add too much to exstats, but I was thinking it would be nice to be able to add calories burned using one of the estimates available. There are a few mentioned in the answers to this stackexchange question and we have access to speed and even grade with a little math, but could also take in the user's weight and combine it with METs or their weight and age and combine it with their HR. Do you have thoughts about that?

  • in Bangle.js
    Avatar for GrandVizierOlaf

    @Fteacher I ended up going for a drive and testing this more thoroughly so I was confident enough to open a PR.

  • in Bangle.js
    Avatar for GrandVizierOlaf

    @Fteacher Do you mind loading run and recorder from my fork's app loader and testing it out? I think I've solved the issues you ran into and a couple of others, though my testing was done by adding a 5m notification option to debug and I have not gone on a real distance run yet. I hope to do that later today.

    The only problem I ran into was that as the GPS got a fix it jumped quickly past 5m and I got a ton of notifications serially. I don't think this will be an issue with longer notification distances, but if it is I have a plan to remediate it.