Search results for:

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
80=P
111=o
108=l
etc

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

Here's the quick answer with too much information: https://github.com/espruino/BangleApps/pull/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.

Fantastic, thanks @Mi!

@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) {
   console.log(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.

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

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?

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

master

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.

RELEASE_2V12

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.

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?

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

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

@Fteacher I've found three bugs and fixed two of them. I hope to have it all submitted in a PR this evening.

I know where to look to fix that. I'll take a look today and get back to you.

@Fteacher, I am the one who added the notifications and it's really cool to hear that someone else likes them! I'm curious if you find them currently strong enough; after a few runs I'm finding that I miss some of the notifications.

I totally agree with the HR alarm idea, but have had issues with my watch reliably showing my HR at all, even when I am motionless. After I get that sorted I plan on adding that feature.