GrandVizierOlaf
Member since Mar 2022 • Last active May 2022- 0 conversations
- 13 comments
Most recent activity
-
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?
- Open the web IDE and connect to your watch
With the HRM off, execute this command:
NRF.findDevices(function(d) { console.log(d); }, { timeout: 4000, active: true, filters: [{ services: [0x180D], }] });
Turn the HRM on
Make sure your HRM is set to be discoverable, likely from the Polar app
Run the same command as above (you might need to give it a minute to start broadcasting)
Power off the HRM, wait a few minutes, and run the same command as above
Turn the HRM back on and run the same command as above
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.
- Open the web IDE and connect to your watch
-
@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.
-
-
@Gordon this is because the
if
check is happening inonchange
, which is triggering even when the value isn't submitted.Edit: I was looking at
master
and not theRELEASE_2V12
tag for this analysis, which might still be true formaster
, 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 callitem.onchange
when an item in the list is selected (dir
is not set in theBangle.setUI
cb
), butE.showScroller
fires select (and thereforeE.showMenu
's item.onchange) every time the scroll position is updated.RELEASE_2V12
E_showMenu_Q3.js
will triggeronchange
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 leaveonchange
where it is called withinE_showMenu_Q3
'smove
and add something likeonsave
to the else where the selection is made, but for the code inmaster
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 therecorder
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 Do you mind loading
run
andrecorder
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.
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.