Tracking more data in on-watch Health Database

[gfwilliams]

Right now the Bangle.js Health app stores:

• Heartrate
• Amount of movement
• Steps

In 4 bytes every 10 minutes - this uses 18kb of storage per month, which is pretty minimal (Bangle.js could store 30+ years worth of data). I think there's probably scope to store a bit more data. We don't have that much available on the Bangle but we could have:

• Battery level + charge state
• Air pressure/altitude?
• Temperature
• Activity type - we don't currently know this - but at least adding detection of Not Worn/Idle/Walking/Sport should be reasonably easy and we could potentially have some sleep detection

Any other ideas? If I'm changing the format of the health app I'd prefer to only make one change (as the health app will have to support analysing previously written data anyway)

[thyttan]

Hi @joserebelo and @storm64! You took part in espruino/BangleApps#3275 where this was previously talked about. Maybe you'd have something to add here?

[thyttan]

Any other ideas?

This probably doesn't make sense, but tracking how much the processor has been running maybe?

I don't necessarily think it's a good idea - just a thought.

[nravanelli]

Right now the Bangle.js Health app stores:

• Heartrate
• Amount of movement
• Steps

In 4 bytes every 10 minutes - this uses 18kb of storage per month, which is pretty minimal (Bangle.js could store 30+ years worth of data). I think there's probably scope to store a bit more data. We don't have that much available on the Bangle but we could have:

• Battery level + charge state
• Air pressure/altitude?
• Temperature
• Activity type - we don't currently know this - but at least adding detection of Not Worn/Idle/Walking/Sport should be reasonably easy and we could potentially have some sleep detection

Any other ideas? If I'm changing the format of the health app I'd prefer to only make one change (as the health app will have to support analysing previously written data anyway)

I think this is a good idea for the Health App for basic recording.

Within my custom widget (will release to BangleApps when ready), I store per minute data, either averaged or otherwise, of those measures. I cater to my research program, hence the need for higher, more frequent, storing of data (1 min vs 10 min intervals). This comes at a steep price of storage (~7-14 days max).

For the average user, activity type/level is fine (e.g. not worn, rest, low, moderate, vigorous). The not worn (I think) requires the heart rate sensor to be on... so you could have mislabeling here if someone turns that off.

[gfwilliams]

espruino/BangleApps#3275

@thyttan thanks! I'd tried to find that issue and couldn't!

Interesting thought on processor usage... it would definitely make power usage debugging easier, but maybe it's rare enough to need that the Power Usage monitor app is enough...

The not worn (I think) requires the heart rate sensor to be on

Yes and no - we can use a lack of movement, and the HRM could be turned on for just a fraction of a second. Realistically if done every 10 minutes it's not going to affect power usage drastically.

[gfwilliams]

I spotted another bug filed by @myxor: espruino/BangleApps#1516

Things he mentions there that would need storing:

• Min/Max heart rate (maybe we don't store average HRM but instead just store min+max, and report average HRM as the midpoint?)
• Altitude change

I reminds me there was also a request to store the amount of time the heartrate was in one of 3 different rate bands, but that gets tricky as what do we do when the HRM sensor doesn't have a clear idea what the heartrate is?

Altitude change feels like a fun one - reading altitude every minute isn't a big deal, and especially for walking it'd be a neat metric. I'd find it interesting to figure out how many times I climb the stairs a day too

[gfwilliams]

I've just added some code to the health app (in the development app loader) - it'll now store data in a 10-byte format (not the 4 bytes we had before), so you get bpm min and max, altitude, temperature and battery level, and there's one byte free for something else in the future if we want it.

The app won't create a new monthly health file if one exists (it'll just use the old format) so unless you delete the health file for march it should have no effect - but this feels like a good improvement now