Heartrate measurements in background

[patricgruber]

This implements heart rate measurements when the screen is turned off. The ticket I found for this is: https://github.com/InfiniTimeOrg/InfiniTime/issues/183

When starting the heart rate measurements through the HeartRate screen and turning off the screen, the heart rate task doesn't stop but keeps running in the background until the heart rate measurement is stopped through the screen again. The task wait delay is set to ~10 seconds (10k ticks) so the task doesn't run all the time and drains the battery too much.

Already tested it on my PineTime and works great. Right now it was more a proof of concept, therefore the interval between background measurements is hard-coded to ~5 minutes. But I'd be happy to implement a settings screen to configure the interval or other features that are wanted.

[github-actions[bot]]

Build checks have not completed. Possible reasons for this are:

1. The checks need to be approved by a maintainer
2. The branch has conflicts
3. The firmware build has failed

[eliedrian]

Was about to implement the same thing!

Another idea that I was thinking of was to measure heart rate after a number of steps taken. Perhaps taking measurements after a certain number of steps in a time window.

[lman0]

Another idea that I was thinking of was to measure heart rate after a number of steps taken.

This idea should be a setting and not a default, Because there is people with leg disability that could use the pine time with the heart rate. And this people wouldn't be have the heart rate function. But for fitness related event, without leg disability it could be .

[patricgruber]

Another idea that I was thinking of was to measure heart rate after a number of steps taken.

This idea should be a setting and not a default, Because there is people with leg disability that could use the pine time with the heart rate. And this people wouldn't be have the heart rate function. But for fitness related event, without leg disability it could be .

It could maybe be an additional trigger for measuring, but not the only one.

[btdogan]

I use hr monitor for my sleep. this shouldn't prevent that.

[patricgruber]

I use hr monitor for my sleep. this shouldn't prevent that.

The code just runs measurements every 5 minutes when the heart rate task is started (through the heart rate screen) and the watch is locked/the screen is off.

All the other functionality is exactly as before. The new changes don't interfere with monitoring the heart rate while staying in the heart rate screen.

[patricgruber]

I noticed during testing that notifications interrupt the background measurement delay and make it reset, so I removed the reset for the GoToSleep message. Now the behavior is slightly different as the background measurement will every 5 minutes from the last background measurement or as soon as the watch is going to sleep. Instead of measuring every 5 minutes starting from the time it goes to sleep.

Notifications and "just checking the time quickly" won't reset the delay now and the measurements will run more consistently over time.

[LinuxinaBit]

This idea should be a setting and not a default, Because there is people with leg disability that could use the pine time with the heart rate. And this people wouldn't be have the heart rate function. But for fitness related event, without leg disability it could be .

And the heart rate sensor likes to use a lot of battery power, so for those feeling battery conscious it would need to be a setting somewhere. Maybe in the HR app?

[patricgruber]

Maybe in the HR app?

The background measurements are only running, if the user activates the heart rate measurement in the HR app. If the user doesn't activate the HR measurements in the HR app or if they are disabled again, no background measurement will be taken.

So there is no new default that HR measurements are taken in the background all the time, just when activating them through the HR app.

The behavior when activating the measurement and leaving the HR app is that when the screen is on the HR is measured all the time. If the screen is off, HR is not measured. If the HR measurement is not activated in the app no measurement is taken ever.

My code does not change the case when measurements are activated and the screen is on (stays at "measure as often as possible"). Also when the measurement is not activated in the HR app nothing changes (stays at "never measure"). Only for the case when the measurement is activated in the app AND the screen is off, then the new mode "measure every 5 minutes" is activated.

So the the user still always has the option to just don't activate HR measurements at all, but if they are activated, then additionally to measuring when the screen is on there are also occasional measurements when the screen is off.

I'm not sure if it makes sense to have another setting that switches between the current mode and the new "measure additionally in the background" mode. I think that would be a bit confusing if you have to activate two things in separate places to activate the background measurements. But if that is needed and wanted I'll of course add it.

[LinuxinaBit]

That sounds pretty reasonable.

One other concern is just that it takes so long to take a HR measurement, and the first reading is often wildly inaccurate especially during movement. Maybe wait for 3 measurements and average the last two, as well as checking for excess movement from the accelerometer before measurement.

Another idea is to pause readings when absolutely zero accelerometer movement is detected for the past few readings, i.e. when the watch has not been on one's wrist for a while (of course the accelerometer would still be checked every 5-ish minutes even when off one's wrist and would also resume periodic readings when the watch is woken up).

These would both help the battery life and improve accuracy immensely.

[Itai-Nelken]

One other concern is just that it takes so long to take a HR measurement, and the first reading is often wildly inaccurate especially during movement.

After #1486 is merged, measurements will be almost instantaneous and much more accurate.

[LinuxinaBit]

Alright, though I still think excessive and no movement detection should be added to preserve some amount of battery life...

[pankk]

I've been testing https://github.com/InfiniTimeOrg/InfiniTime/pull/1486 for a couple of days now and while the updates are almost instantaneous the first reading usually takes up to 10 seconds for me. I can't say much about the accuracy, but it's similar to the miband 3. I found that for best results, wearing the watch higher up the forearm (about 1/3 of the way) and having it face the inside of the arm works. I was not able to get a measurement restart when I wore it like that (i.e. the reading did not reset to 000, like it does when moving around while having it on the wrist). PSA: It also might be worth checking if the protective film has been removed from the sensor "window". (I assume mentioning the PPG PR here is enough and that I don't have to add this feedback to that PR as well.)

[khimaros]

i'm also testing the new PPG algorithm and sometimes it takes upward of 15-20 seconds to get a fix on the heart rate. i've checked out @patricgruber PR and built it. i'll take it for a spin.

also, @pankk thank you for the tip with the film, i'd totally forgotten to remove mine! that might explain the 15-20s delay :)

[khimaros]

i'm testing this PR on my device and i'm happy to say it is working quite well. (removing the sensor film reduced the fix time considerably).

to start, i tested heart rate characteristic notifications in bluetoothctl:

$ bluetoothctl
[bluetoothctl]# devices
Device C9:2D:E5:XX:XX:XX InfiniTime
[bluetoothctl]# pair C9:2D:E5:XX:XX:XX
[bluetoothctl]# connect C9:2D:E5:XX:XX:XX
[InfiniTime]# menu gatt
[InfiniTime]# select-attribute 00002a37-0000-1000-8000-00805f9b34fb
[InfiniTime:/service005b/char005c]# notify on

i received notifications almost exactly every five minutes with the screen off:

[CHG] Attribute /org/bluez/hci0/dev_C9_2D_E5_XX_XX_XX/service005b/char005c Value:
  00 53                                            .N              
  00 53                                            .N    

after that, i installed nrfConnect (unfortunately, a proprietary app and there doesn't seem to be an open source equivalent) and logged all of the notifications overnight.

inspecting the logs, the heart rate accuracy and success rate of notifications seemed very reliable and consistent. awesome!

i estimate that total battery drain overnight was less than 10%, but i did not look at the exact percentage before sleep. i will take more accurate battery measurement tonight.

[lman0]

@khimaros could you share the firmware ? I would like to test it too

[khimaros]

@lman0 -- i'm open to sending this privately if you provide an email address. unfortunately, the build artifact contains private information (usernames and unabridged filesystem paths, possibly more). alternatively, i've written up detailed reproducible build instructions in the comments on this PR: https://github.com/InfiniTimeOrg/InfiniTime/pull/1761

[mark9064]

So I've been testing this PR along with the related gadgetbridge PR. Super cool to have the HR measurements showing up. A few thoughts on it

• Previous HR values are changed to no longer be cleared upon screen wake with this PR, or upon the PPG algorithm losing fix on the HR
  • I think this is confusing as it is difficult to tell when the HR value on screen is fresh and when it is the last reading.
  • It's also difficult to tell when it goes from a live reading to holding the last value when the PPG algorithm can't find a value
• The running time is unlimited when doing a background measurement
  • In the extreme case, if there is no sensor contact, the PPG will run continuously

Suggestions

• I think the UI needs to convey that a HR measurement is stale, or it should not show it at all
  • Not sure how this applies to all watchfaces
• Limit runtime to 15-20s
  • Can be done by checking the running duration using the tick count inside HandleSensorData

Regarding the measurement interval: I was thinking about what it works best as. There are a few options I see regarding when to trigger a measurement

• Measurement begins every 5 minutes, ignoring whether the device has been woken or not (close to what is currently implemented)
  • In this case it needs to be wary of a possible BackgroundMeasuring -> (screen on) Measuring (total time < limit) -> (screen off) BackgroundWaiting
    • A measurement is then skipped
  • Also possible to have Measuring -> background timer expires -> (screen off) BackgroundWaiting -> BackgroundMeasuring
    • i.e the PPG stops and then immediately gets started after, discarding all state and forcing a refix
• Measurement runs at least every 5 minutes, taking into account measurements from being awake
  • In other words, every time a HR fix is achieved, the measurement timer is set to expire in 5 minutes
  • The other condition is that the expiry timer must be reset when a background measurement is attempted but fails due to the time limit
  • This way solves the second problem above by design and also seems more sensible to me intuitively
    • I think solving the first problem might require another state?

Not sure if I made any sense so interested to hear any thoughts :)

[khimaros]

@mark9064 i think these are great suggestions. i'll just mention that, even though the data is stale, it is sometimes useful to be able to quickly turn the watch on to see what the most recent HRM measurement was. maybe it can be displayed in another color to indicate staleness?

[khimaros]

FYI, slightly off topic here, but possibly useful for testers of this PR. phyphox also works as a tool for graphing and exporting heart rate data from InfiniTime on android: https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2383#issuecomment-915776

[patricgruber]

Thanks for all the suggestions.

Regarding the timeout reset for background measurements: Before I implemented the checks so that whenever a measurement started, the timer reset. Which was a problem since just checking the time reset the timer. I then changed it to the current implementation that only resets the timer when specifically a background measurement is done. This way having the screen up doesn't effect the background measurement at all and so if the watch goes to sleep, the code pretends as if nothing happened and will immediately measure the heart rate if the screen was on for longer than the interval. A nice change would be to change it so whenever a measurement is done, either in the foreground or background, the interval is reset.

Regarding the reset to 0 when the screen wakes up when ambient light is detected: I personally rather have a slightly older/stale value then no value at all. If I want a fresh value I can just wait, but at least I can just check the screen and see in which region I am, if I had some more or less constant state for at least 10 minutes or so. But if the heart rate is reset to 0, then I don't have that. I have the background measurements that are either sent to companion app or go no where, but I won't ever see them on the watch. I think a good compromise is having a different color for stale values so I know that the values are old, but I also see the last measurement.

Regarding the ambient light sensor and running forever: I think implementing a timer to stop the sensor if there is ambient light for more than 10-20 seconds and then just try again for the next "scheduled" measurement seems reasonable.

[mark9064]

Sounds sensible overall :+1: One thing to note re running time limits: if it is dark but the PPG has no contact it will still run forever if it just checks ambient light. If the PPG has been running for say 30s with no success the chance it's going to succeed is probably pretty low so I think giving up makes more sense? I guess it depends on how power hungry running the PPG is relatively. I'm planning on making a continuous measurement patch for testing so I should have some ideas on that soonish

[patricgruber]

@mark9064 I would just implement it to always stop trying to measure after 30s, no matter if it is because of ambient light or other reasons.

Also as side note: my first test was to just let it run continuously in the background and I think it drained around 50% battery or more over night. Also the watch got warm. I think letting it run for that long without breaks is probably not the best idea. But maybe with the updated PPG code made it possible. I have only tested with the old code.

[patricgruber]

I implemented a timeout of 30s for the background measurement. If there is no data within these 30s, then the measurement is stopped and retried after 10 mins.

[mark9064]

So I tried implementing functionality (https://github.com/mark9064/InfiniTime/commit/225be818b14637092e09e2ce3587e25c71a91bce and https://github.com/mark9064/InfiniTime/commit/97d894edc4a2787ada38f6c3057d49aa4326e934) that allows the user to choose between no background measurements, periodic background measurements and continuous measurement. It seems to work as expected but as you noted battery life with continuous measuring is poor (~24h). I don't know where the majority of the power is consumed but it makes sense that it would be the PPG LED as it's on about 50% of the time and has a high drive current. The data is interesting though, sleep zones are clearly visible, but the UI for switching between modes sucks. Not sure if this is a feature users would want or if we should just keep it simple

[khimaros]

@mark9064 i'm using your testing branch now on my Pinetime device and it is working quite well. thank you for putting this together and sharing it! i especially like the new raise to wake/lower to sleep functionality. it's very reliable and accurate and i haven't seen any unintended wakes yet.

battery life is, expectedly, worse with the continuous mode on. apart from the battery used to power the LED/hardware, i suspect continuous mode is also preventing the main CPU from going to sleep, since it is always busy with the measurement task? this is just a guess, i don't know any of the inside details of InfiniTime/FreeRTOS power management.

i agree with you the UI for choosing the HRM mode could be a bit clearer, but as a power user it was intuitive enough. maybe it's just a matter of choosing more descriptive names for the toggle? alternative descriptions: "Always", "Periodic", "Foreground". another option is to make the "background delay" configurable, but then we'd likely need two controls; one for the delay and one to toggle background mode on/off.

overall, however, i think this is a great feature and would love to see it land in a release version! it's really incredible to be able to raise my wrist, look at the screen, and see instantaneous heart rate information! i suspect i'm not the only person who would think so.

[mark9064]

Finally got time to do some proper power testing using the patchset in my last message With low brightness, raise wake and lower to sleep (latest PR versions), sleep mode ~8h/day, wearing watch ~97% of the time: 8 days battery from a full charge. So it would probably be feasible to enable unconditionally if we wanted to, though I think having controls is still nicer

[khimaros]

@mark9064 is this using the testing branch at https://github.com/mark9064/InfiniTime/tree/testing ? which measurement mode were you using? periodic? continuous?

[mark9064]

@mark9064 is this using the testing branch at https://github.com/mark9064/InfiniTime/tree/testing ? which measurement mode were you using? periodic? continuous?

Using periodic mode, though I've rebased the branch on 1.13 locally

[mark9064]

@patricgruber What's your opinion on the proposal that the user can choose whether they want background measurements or not? I think we should choose what we want to do here so we can get closer to having this merged.

Personally I think it's useful as it allows users to have better idle battery life if they don't care for periodic measurements, and it also allows users to enable continuous monitoring which is useful for exercise or detailed sleep tracking where constant updates without having the screen on are desirable

[patricgruber]

@mark9064 I personally feel like measuring continuously in the background is not a good idea. It nearly drained the battery over night and the device got quite warm in my tests, which probably leads to degradation of the hardware especially of the battery, which is not really what anyone wants.

I also personally didn't feel like a second user action to activate the background measurement seems necessary, since there is already the user action of activating the heart rate measurement. But I think a feature that would be nice and which gives users more control is settings for the interval length of background measurements. Something like Never, Every 30s, Every 1 min, Every 5 min, Every 10 min, Every 30 min. This way the users can deactivate the feature completely or customize the duration for their specific needs and goals.

[Idcrafter]

i own my pinetime since 2020 and it's battery seems to not have degraded that much because i still get almost over a week of battery life and making it possible for a user to choose when it measures like in every hour or every second hour and that inside like from 6am to 9pm or similar would make it a great compromise of battery life and function

[patricgruber]

I added a new screens in the settings with options to choose between Off, 30 seconds, 1 minute, 5 minutes, 10 minutes, and 30 minutes as options for the background measurements.

But there is a bug, which causes the settings files (I guess) to be destroyed or not handled correctly somehow and that crashes the watch. I advise against testing the last commit on a real device. I think the issue is fixed with rolling back to version 1.13 from the releases page, but I wouldn't risk it, since I don't know how to wipe the settings file and create a new one and what the actual problem is right now. I will investigate further, but if someone finds the bug in the code until then, please let me know.

[mark9064]

@mark9064 I personally feel like measuring continuously in the background is not a good idea. It nearly drained the battery over night and the device got quite warm in my tests, which probably leads to degradation of the hardware especially of the battery, which is not really what anyone wants.

I also personally didn't feel like a second user action to activate the background measurement seems necessary, since there is already the user action of activating the heart rate measurement. But I think a feature that would be nice and which gives users more control is settings for the interval length of background measurements. Something like Never, Every 30s, Every 1 min, Every 5 min, Every 10 min, Every 30 min. This way the users can deactivate the feature completely or customize the duration for their specific needs and goals.

Having those different background modes is a good idea, if we're going to have multiple settings we may as well give the user choice :+1: The device can't get hot when background measuring, the power draw is not large enough for this to be possible. The battery is 180mAh (according to pinetime wiki), and let's suppose continuous measuring drains it in one day. This gives an average current of 7.5mA, and an average power of 30mW (assuming constant 4V battery). 30mW is not enough to create noticeable heat or overheat the battery. Continuous measuring isn't something the user would want to enable all the time, but I find it useful during exercise. All other smartwatches I am aware of measure heart rate continuously when they are set for exercise. I therefore think it's still worth including as one of the modes.

I added a new screens in the settings with options to choose between Off, 30 seconds, 1 minute, 5 minutes, 10 minutes, and 30 minutes as options for the background measurements.

But there is a bug, which causes the settings files (I guess) to be destroyed or not handled correctly somehow and that crashes the watch. I advise against testing the last commit on a real device. I think the issue is fixed with rolling back to version 1.13 from the releases page, but I wouldn't risk it, since I don't know how to wipe the settings file and create a new one and what the actual problem is right now. I will investigate further, but if someone finds the bug in the code until then, please let me know.

I'll see if I can spot anything. You can wipe the settings file using itd or any other companion that allows you to access the external flash/resources filesystem

[patricgruber]

Continuous measuring isn't something the user would want to enable all the time, but I find it useful during exercise. All other smartwatches I am aware of measure heart rate continuously when they are set for exercise. I therefore think it's still worth including as one of the modes.

An "exercise mode" is already kind of implemented. If you have the heart rate app open the screen stays on (the display timeout is disabled in the heart rate app) and you have continuous measurements.

[mark9064]

This is true, but having the screen on drains the battery really fast especially at higher brightnesses, and it's quite easy to have your sleeve touch the screen and turn off the HRS (which is easy to miss if you're busy exercising, and annoying to stop exercising to turn it back on)

[khimaros]

I agree with @mark9064 here. leaving the display on is not a viable alternative to his branch. the user experience even as currently implemented in his branch is excellent and turns the PineTime into a first class health/exercise app. pair this with the recent addition of HRM recording in GadgetBridge and it starts to become competitive with devices like Fitbit costing 5x the price.

[patricgruber]

I agree with both of you @mark9064 @khimaros . Having an exercise mode which continuously measures the heartrate, steps and possibly more would be awesome and would really make the PineTime comparable to other watches. I just don't think that it fits in the scope of this pull requests as this PR is about getting heartrate measurements also running in the background. An exercise mode would probably need its own screen/app where you can start and stop an exercise session, during which the HR, steps, ... are measured continuously. Right now when an user wants to "start an exercise" they would have to go to the settings, set the interval to "Continuous", go back to the heartrate app, start the tracking, make the watch go to sleep. After the exercise session they would again have to go to the heartrate app and stop the tracking or go to the settings and change the interval to another interval if they want to have background measurements that are not continuously.

So I totally agree that having this feature would be awesome, I still think it would make more sense in another PR which focuses on making the UX of this better.

[patricgruber]

I changed the UI slightly and fixed the crashes, but there still exists a weird bug. The heartrate is stored in the settings file just fine, but when having intervals that take up 4 bytes in the settings file, e.g. 0x5802 which is 0x0258 with correct order and 600 in decimal, then the 2 most significant bytes are ignored and the the result is just 0x58, which is 88.

I think that there is a problem with padding or somehow a problem when writing the file and reading it back, because the bug is triggered after you change the heart rate to something that uses 4 bytes and close the settings screen (e.g. close the settings list and the quick settings screen) . When just changing the interval time, closing the heart rate settings screen and opening it again (without leaving the quick settings screen), the interval is read correctly.

I will look into it further, but again if someone knows what the issue could be or sees a problem in the code, please let me know!

[mark9064]

Totally agree that an exercise app would be a great inclusion, especially once the HRS works under motion. And I also agree that having the controls on a settings page is better UX and makes a lot more sense.

But also I think that the user should have the choice for global background measurements if they want. For example, I've been using it for sleep tracking recently. I wouldn't want to record that as an exercise. There are people who will want the HRS to run 24/7 and are fine with 1-2 day battery life (me!).

The 10s period measurements make the HRS run 40-60% of the time (7-15s run, 10s break). Why not allow 100% of the time?

[patricgruber]

@mark9064 You are right. Right now it would be nice to at least have the possibility to let it continuously run in the background until proper sleep and exercise tracking are implemented.

For anyone interested: I fixed the issue with the settings file by using an enum for the interval (1 byte) instead of storing the seconds directly (4 bytes), which circumvents the issue with ignored bytes completely. I still don't know what exactly caused the issue in the first place.

The feature should now work as intended and the PR can be tested. But keep in mind that since the settings file format and content changed, the settings of the watch will be reset to the default settings when using the new firmware.

[khimaros]

edit: this is probably more relevant for exercise tracking, which as mentioned previously is out of scope for this PR.

i wonder if the new circularbuffer utility structs would be useful longer term, to allow storing heart rate data on the watch for some period in case of BLE disconnects.

[mark9064]

https://github.com/InfiniTimeOrg/InfiniTime/pull/1718#issuecomment-1732599601

Yeah out of scope for here, but I think what you'd want to do is write the HR values to the external flash. There's plenty of free space there so 1s resolution measurements would be fine

[patricgruber]

@FintasticMan thank you for the code review! I fixed the issues you mentioned. If these issues still need improvement or if other parts in the code need fixing. Please let me know!

[khimaros]

@FintasticMan is there anything else blocking this from being merged?

[tcld]

Thank you very, very much for working on this! I'm not sure it is of interest, but I have been running this branch for an entire day now. No issues so far.

I'm running the branch on top of the latest release (1.14.0); compiled yesterday (2024-03-16). (Very rough steps for reproduction: 1. check out the repository, 2. build the docker image, 3. add the remote repository containing this branch, 4. rebase the desired branch, 5. docker run ..., 6. write the firmware to the device)

The watch used up about 35% of battery within 24 hours, my heartrate is being measured every 30 seconds. I have now switched to continuous measurement to see how quickly the battery will drain then. I have the watch connected to Gadgetbridge on my phone, which saves the incoming heartrate-values. That combination of watch and software might be interesting for others as well, since you can use the watch for longterm tracking that way, even if the watch itself doesn't store values (yet).

Love it, thanks again for the work!

[tituscmd]

I've noticed that whenever I change either the brightness or the notification mode, the background interval automatically switches to continuous. I've tried going through the code but can't figure out why this is happening, can you take a look and see if you can figure out what's going on?

[patricgruber]

@tituscmd Are you running the latest version (as in: local build of the branch including the latest commit 0b4903f)? I had similar problems with the settings, which happened because the settings version wasn't increased. There has been at least one settings version upgrade since this PR was created, so you need the latest version of the branch, otherwise there might be issues with weird settings behavior.

Edit: clarified "latest version"

[tituscmd]

@patricgruber That might be it, I don't think I have the latest version. I'll update it later and see if that fixes the issue.

[Saarsk]

Thanks for not forgetting about those of us who want continuous background HR logging. :)

I'm not an "dedicated exercise guy". I get all my exercise from work, everyday activity and sports. So an "exercise mode" would do nothing for me, I would never use it and especially wouldn't want everything to be flagged as "exercise" since I get my exercise from combining other activities anyway. The watch (by reporting data to the health app) should be able to report activity level.

While an exercise mode wouldn't do anything for me, I see how some people would want it because some people exercise as a dedicated activity (e.g. optimizing their HR while doing so, looking at HR readout as an indicator of whether they should push or not).

I recently tried Pixel Watch 2 for a week (as it was included with the phone) and really found it useful to have the HR readout on the watchface (as well as app/action one-tap shortcuts).

It also gave me notifications about "suspected stress", which was interesting (because I do stress a lot at times). Context: I use ADHD meds which I think does raise the HR somewhat (although I don't feel a thing, I'm part of the group that gets none to minimal side-effects). It could be a combination with poor resting HR, stress, meds and activity with little motion.

Where I'm going with this is, this is why (other than general health insight) I want continuous background HR logging with no delay or pausing. :) It can provide me with useful insight and potentially answer questions about my health and make me able to potentially draw conclusions (or find questions).

---

Slowly fading into OT grey area (I'm going somewhere with this, though):

Really, "exercise" is just activity that you get from spending energy doing work, whether it's running because you need to catch the train, running for fun, walking up stairs, doing work or sports. Excluding all other activities but "dedicated exercise" just creates black spots in the statistics. For some, the entire day and night would be one black void of "no data available".

The statistics is actually telling you a story about your health and life. One can be healthy without "dedicated exercise" when you get it elsewhere. And for your health it's much more useful to count the steps you take, how much you sit without moving around, the calories you consume and how you sleep. Just isolating "exercise sessions" could create an illusion of being more healthy than you think because you don't account for the rest of the hours of a day, in which some people would accumulate lots of exercise over time just in a different way.

---

Arguably pushing into the grey of OT for this PR. However, I think it gives a perspective on the bigger picture of why continuous background sensor data logging is useful. And I don't know about you but I think this stuff is intriguing (I don't know whether it warrants its own thread):

(I'm happy to put all this in a separate thread :) or delete it altogether :( - depending on your preference. I'm just someone without an off button for the brain and who loves to explore ideas.)

If the watch is aware of my movement, the phone could, with this data, extrapolate things like "probably sleeping, resting, writing on keyboard, walking, running, doing an activity" and even assign some sort of "estimated activity level" (which is probably more useful than trying to guess a specific activity). With this sensor data it becomes a foundation for companion apps and their use-case.

(I really think there's innovation to be had here, where mainstream watches just put such features behind subscription walls, data mining and proprietary bloatware without any actual ownership of your data or software. Or otherwise is hidden in the noise of their forced eco system or products they want to force on you.)

The health app could look at the motion data and compare it against the HR data and make assertions like "the user is moving upwards in a spiral-like path, so is likely walking up a set of stairs. Just looking at the motion data wouldn't necessarily translate this into a high "activity level". Even though, walking up a set of stairs is quite the exercise and starts looking like strength training (which have its own set of health benefits).

It doesn't even have to know what stairs are but just look at it from a physics standpoint (as well as anatomical and biological one). The stairs could be a hiking trail for all we care. But it should be smart enough not to confuse other movements as something it isn't, by look at other sensor data and make assertions from the additional context.

By knowing a human's range of capabilities (top speed, top speed while gaining elevation) but also be aware of other modes of transports (elevator, elevator stairs, treadmills, airport treadmills, a bike, car, plane, you name it). There are also additional context that reveal potentially insightful facts.

You could be walking up a set of stairs with no extra weight or you could be carrying 50 kg worth of luggage. Would that explain the HR rate? What if you were jogging prior to walking the stairs. Perhaps you had little sleep and nourishment or both. Perhaps you're also stressed or you are in a scary neighbourhood by yourself. Isolating sensor data and timeframes wouldn't reveal such context, so you need to make some logical algebra from the bigger picture and the additional "electronic eyes and ears".

If I'm moving my hand back and forth I could be sitting in a chair, explaining something with hand gestures. Or I could be driving a car. It's hardly an "exercise", but the higher "motion value" could indicate physical exercise. A high HR would confirm or deny that, right? What if you're stressed, having an argument or something happened and you're actually giving information to a police man? And while the watch is experiencing a lot of motion, the phone might not. Which data that reveals the correct situation depends. Another time it could be the HR which leads to the correct assertion.

So ideally, the health app would look at the HR data and motion data from the watch but also various sensor data and states from the phone.

If location access is undesirable, it could simply look at the angle at which the phone sits in space and the velocity (as seen by the sensors). It could easily gather that you are moving through space while sitting (you can't be running so you much be in a vehicle, perhaps that vehicle is a wheelchair). Maybe the traffic stresses you out so the HR goes up, which in isolation could look like physical activity. The orientation data is important since if you follow the human anatomy, you can be sure humans can't move forward at high speed while sitting in a crouched position.

You could even estimate whether the phone is on a table or in your pocket and the distance from the watch (signal strength, which by itself wouldn't be reliable due to all the factors affecting it. Gyro data would be valuable here. The light sensor would also provide context, e.g. it's dark inside a pocket. the phone could also be under a jacket, so that algebra really becomes important. If you're in a car, all objects tend to experience similar forces, so it wouldn't matter.

This would probably require a "logging level setting" on the watch but I can see the smart watch becoming seriously useful for a larger group of people at this point. I can even see myself modding it with a larger battery or having small battery modules (like a rectangular "coin-like" battery that you swap into the watch and put the other one on charging). It would eliminate you having to remove the watch from your hand to charge it. You just swap the battery module (making up a large portion of the total battery capacity which in turn charges a smaller internal battery as it reaches a certain percentage (or just power the watch until the internal battery takes over, whichever is technically preferable).

I personally would also like to see a USB-C port on the watch instead of bringing something proprietary that you might (definitely will) forget. An then you need a charger or port anyway (when you could just use the same charger and cable as you would with your phone and all other USB-C devices). And what if the watchband had additional hardware, making the volumetric real-estate not go to waste (and allowing the watch to house more or be thinner)? Personally I'd like to scan QR-codes, product bar-codes, tickets or log expiration date on food items while putting it in the fridge (reduce food waste). If the watchband could house some parts like RFID receiver antenna, HR sensor, additional battery capacity (could be questionable due to safety (but intriguing with a safe battery chemistry)). Remember Pebble's expandable smart watchbands? I also think it would benefit from hardware buttons, so that you can use it in the shower (controlling music, swiping or replying to notifications etc.).

It got a bit OT at the end, but the point of it all (beyond "oh, interesting ideas") is that the bigger picture explains why expansion of functionality is valuable and actually paves way for advancements. If the watch is able to do more, more people will find a use-case for it and it might even be enough to convince those who otherwise think smart watches aren't useful right now. I also like to think that PineTime paves way for PineTime 2. Both PineTime and Infinitime inspires me to want to modify the watch (and perhaps some day contribute in some way).

If what I just created is a monster made up by letters and you'd like for it to be exterminated - I can make that happen. In that case, is there a place in which ideas like these are welcome? :)