Search results for:

Just as a hint:
To do that you probably need a reference breath signal. Some here are using the polar H10 chest belt which has an accellerometer build in (so probably much directer acces to breathing than PPG). This signal is sent via BTLE (I do get it here on Linux with a python program).
And there is the "HRM Accelerometer event recorder" which right now stores raw PPG, HR and RR from H10, acc from bangle. Should be not too hard to add Acc from H10 here with which you would then collect all the data you probably will need on the way trying to get breathing from PPG.

yes

If you seal that you loose the pressure sensor, but can swim

So its a decision about priority

Not an authorative answer, but what I know from reading the forums:
Shower should be fine but don't swim.
Reason is a small hole for the pressure sensor. If you seal that you loose the pressure sensor, but can swim then. There was a thread about this some 2 months or so ago.

Another thing to check: I started to store the watch face down when not wearing it some time ago. At least in daytime then the heartrate monitor seems to "see" that its not worn through the light and doesn't use its LEDs anymore. That considerably improved battery time for me.
Of course this is a work-around. Better would be a real recognition (eg. via accelerometer, temperature, ...) and stop all sensors when not worn. Also a stamina mode would be good, stopping sensors below a battery threshold. (so lots of nice projects for software development :-)

First two months, now two days doesn't sound like bad battery but like activated services.
Two months is realistic without sensor, if you use heart rate regular or gps or ... (possibly without knowing), battery gets drawn quickly.
Try disabling stuff in health app, ... and check again.

Thats interesting. Do we know who gets public and who random addresses?
Is that device type dependent (so do all H10 have random?) or configured when cloud connected?

[rssi = Received Signal Strength Indicator, so change is to be expected here due to distance difference.]

Agree in all points

Just to make sure there is no misunderstanding:
I did the test with H10 (we need @Fteacher for the OH1)

What does this mean? (don't know what "our BTHRM discussions" was about)
What problems did you have before?

Actually in a python app here I did include the id hardcoded to make sure to not get the H10 of my wife. So very sure id stays the same also over long time.

Did the experiment. ( [], [data], [], [data])
Id stayed the same (even though having the word "random" at the end.
(2v12.101)

Altitude relative to start of run/hike would't need any calibration and still be pretty useful (unless your so high that thin air is a concern I guess thats what is of interest to most hikers anyway, or am I wrong here @uname)

Yes.

I am hesitant to ask for recordings though before having done a whole iteration.
Typically then one finds some improvements or missing parts (eg in the file format or naming convention or ...) that are easyly corrected before building the recording library but difficult thereafter.

The first thing to do would be to collect raw PPG data, as it comes to the algorithm, with a reference HR from another, trusted, sensor.

So to me that would be the second thing after having implemented testing harness and at least one algorithm to be parametrized and done that with two or three short recordings of myself.

I do not yet have a external HRM to test with, do y'all have any recommendations or know what to stay away from?

I can confirm that Polar H10 works like a charm. In addition to HR it also provides PP-Interval which is also stored by recorder (and used by HRV app).
H10 also provides medical grade ECG signal and has an ACC (eg for respiratory movements, steps,...) No bangle app for those yet, but its available via GATT Bluetooth, so should be not too big a problem to include. I do get it in desktop already.
Only disadvantage is price in my opinion, so if its only about HR, there are sure cheaper alternatives.

Just posted some summery that I wrote some time ago, put didn't post so far:
http://forum.espruino.com/conversations/­372681/?offset=50#16454552

Happy to have more helping hands on this topic :-)
No promise here (!), but my plan was to have a basic test harness ready this weekend (maybe including a rewrite of the algorithm in python).

Actually wrote that summery some time ago already, but wanted to post it only after having some code ready - then some unexpected urgent tasks came into the way preventing any work on bangle unfortunatly. Plan to spent some time this weekend though finally.

The following is a compressed summery of what I found out so far (No code from me so far. Credit goes to gordon, helmrich, myownself and others)
Please correct me where I am wrong or point me to good information I did't find so far.

Where is the problem?

• As all smartwatches, bangle usese optical sensing ("PPG" = "Photoplethysmography") not electrical as chestbelts do in order to measure heart related information.
  
• This type of sensor signal is much more vulnerable to disturbance, especially by movement, and therefore considerably more difficult to interpret.
  
• On the other hand it contains additional information that eg. could enables estimation of oxygen saturation (SpO2) and more.
  
• There is a proprietory interpretation software blob from the chip manufacturer, but we try to stay open source if possible.
  (http://forum.espruino.com/conversations/371899/#16355245)
  
• Here is some literature on how such algorithms work:
  http://forum.espruino.com/conversations/372681/#16387616
  http://forum.espruino.com/conversations/373033/?offset=25#16668809
  
  

What is the current state?

• Right now heart rate estimation is implemented in C within espruino.
  http://forum.espruino.com/conversations/­372681/#16388080
  
• For most people HR estimation works pretty ok in rest, but not good while moving. Some people also have wrong reading at rest.
  http://forum.espruino.com/conversations/373033/#comment16423860
  
• In addition to the HR espruino provides a confidence measure. The confidence is a pretty good indicator of the validity of the HR. You shouldn't trust HR below confidence of ~90. Some apps (eg daisy or circle clock) can use that and hide unreliable readings.
  http://forum.espruino.com/conversations/372681/#16387732
  
  
  

How can I have a quick look or start experimenting?

• For a quick start, you may want to just paste this code into left side of WebIDE
  http://forum.espruino.com/conversations/­372681/?offset=25#16390275
  Yellow is the raw input signal, red the improved filtered one and after a while you can see all recognised peaks marked in purple over the red graph.
  You can see how good the current algorithm works for you (and see that there is even low hanging fruit for improvement still)
  
• The "HRM Accelerometer event recorder" App allows a more detailed analyses by recording this data and more on a computer/phone into a csv file. https://banglejs.com/apps/?id=hrmacceven­ts
  With this csv you can start analysing and testing in whatever tool/language you prefer.
  As the name suggests also acceleration data is recorded, which so far is not used at all in espruino HRM. Including it should really make a difference.
  https://github.com/espruino/BangleApps/issues/1248
  This app is also a good example to learn how to get all the relevant sensor readings.
  
• Gorden has setup a test harness and repository to collect test data: https://github.com/gfwilliams/EspruinoHRMTestHarness http://forum.espruino.com/conversations/373033/#comment16554946
  
  

What is the plan?

• Set up a test harness where a potential algorithm can be optimized and reproducably evaluated on a train/validation/test set of recordings.
  
• Collect a good (increasing level of difficulty; from different persons) set of recordings of bangle PPL and Acc sensor data toghether with refernce data from a good external sensor via BLE
  
• Try differnt algorithms starting with basic ones as eg.
  
  • just ignore all PPL readings above a certain threshold of movement measured by Accelerometer
    
  • Improve peak finding (as with the eye one sees very clear peaks that are not found)
    
    

Result of attempts so far and analysis:

• http://forum.espruino.com/conversations/373033/?offset=25#16653576
  
  

How can I get reliable heart rate right now?
(until me/you/somebody finds the time to improve the algorithm)

• Use a BT chest belt. Bangle can recieve, show, store heartrate via bluetooth.
  

I looked at the algorithm some time ago:
http://forum.espruino.com/conversations/372681/#16388080

So as I understand its really not that complicated: bandpass filter and peak recognition as the main steps and a median filter to remove outliers and estimate confidence.

When I looked into the data, the peak detector seems to be not that reliable. I found many peaks easily detectable by the eye after the bandpass, but missed by the peak detector. So to find a robust peak detector seems to be a valuable task.
The other obvious thing is to include accelerometer readings to suppress movement artifacts.

For a quick start, you may also want to just paste this code
http://forum.espruino.com/conversations/372681/?offset=25#16390275
to the left side of the WebIDE. (leave clock before. If you are in launcher menu the graphs don't get disturbed by watch/widget updates)
After a while you should see the detected peaks marked.

See http://forum.espruino.com/conversations/372681/#16388080

I try to put together a summery of the current state (promised this a while ago) later this evening or tomorrow.
Best thing to start is to use "HRM Accelerometer event recorder" App to record the raw sensor data, ideally together with some reference from a bluetooth belt. This writes csv, so you can look and analyse with whatever tool/language you prefer.
Also you can use this script as example and see how to get all the relevant values.

Ah, ok, I see. Good reason.
Do we know the time span the data provides? Stating that could bring back the "clear information" part of the menu.
(I remember questions and misunderstandings coming up in the forum from time to time)

Apropos "The 2-day update". I liked that menu with choice and clear information .
Is there a reason that those options do not exist for bangle 2?

You might want to experiment with https://gtsam.org/.
Maybe too heavy weight for your final application, but good to get a feeling for what is ultimately possible with state of the art professional filtering. There are IMU only examples somewhere.

What device are you using? At some time, I failed similarly with IDE Flasher on Ubuntu, but succeeded on using it on Android.

I am on 2.12 and see the lighting up also.
In settings LCD i disabled all but button (esp. twist).
I still can reproduce the lighting up through shaking, and its not much that is needed:
When laying flat on a table and putting something heavy on the table, thats enough.
Need to search where else the trigger can be (some app?)

@myownself: for your half frequency readings: Did you try to look at the data eg. with code above from gordon? Maybe just looking at it you may see whether the frequency is not visible or it is clearly there but peak detection fails for some reason.
The first steps of the algorithm until peak detection are very simple. Should be reproducible in jupyter within half an hour or so to be able to have an even closer look.