AngelSensor & HRV, a preliminary analysis

This post is authored by Marco Altini  with input from Kari Schoonbee. Kari is a biomedical engineer with HealthQ Technologies, and has been working for quite some time on mobile health technologies & optical sensors in the context of measuring heart rate and heart rate variability at different body locations.

A few weeks back I received the AngelSensor, an open platform for mobile health applications. The AngelSensor is targeted to developers, with the idea of providing an open platform on top of which developers can build different applications, relying on the raw data streams sent by the sensor via Bluetooth low energy. I loved the idea and the many opportunities it opens up. As a hacker & developer, it's extremely hard to find open platforms with decent usability & low cost. When it comes to physiological data (ECG, PPG, etc.), there is basically nothing on the market.

A part from my personal interest, in the context of HRV4Training, I saw in this sensor an opportunity to extend the app's functionalities, to be able to measure HRV not only using a chest strap or the phone camera, but also using this sensor. It's no secret that it can take some time to familiarize with the camera measurement, and it could also be that in certain cases (e.g. someone with low perfusion) it's simply hard to get a clean measurement. Thus, the idea to wear a sensor on the wrist, and take the same type of measurement via HRV4Training, seemed appealing. 

Long story short, I ordered the sensor sometime last year, and received it at the beginning of April. The version I have is the second generation of the AngelSensor, called M1, which sells for only 99USD. Here are a picture of the sensor on Alessandra's wrist and the LEDs used to acquire PPG data:

The sensor comes with an open source project, hosted on github, that you can use as a starting point for your own application. There is very little documentation, but with some help from the support staff, I managed to get all I needed to run a small experiment using this sensor and try to determine if I could use it for HRV.

Measurement setup & protocol 

Apps

I wrote a small app that could store PPG data from the AngelSensor. The sensor would normally send only heart rate data (using the standard bluetooth low energy protocol). However, if you turn the phone in landscape mode, raw data gets also sent (two channels PPG and accelerometer). A description of the protocols can be found here. The sensor sends PPG data for two wavelenghts, and the only thing my app does, is to store those two signals to a csv file.

As usual, we need a reference system to understand if the data we are collecting is reliable. I grabbed our trustworthy Polar H7, and fired up the HRV Logger on another phone, so that I could collect PPG from the AngelSensor and RR intervals from the H7 at the same time. 

Protocol

Our small experiment involved 6 minutes of measurement at complete rest, without moving the wrist, with three minutes of self-paced breathing, two minutes of deep breathing, and one final minute of self-paced breathing again. Both me and Alessandra performed the experiment, so we have N = 2. As deep breathing and the effect of RSA shows up very clearly on RR intervals, giving them a typical sinusoidal shape, including in the measurement a short segment of deep breathing would make it easy to see if the data is good enough to capture these oscillations or not. Here is a picture of the setup:

Data analysis

We will be looking at:

• Raw data
• Filtered data using different filters
• RR intervals extracted from PPG data
• HRV features

Raw data & filtering

First thing I did after storing the data was to load it in R and plot it. We can see here how the data looks quite noisy. In the second channel, at the bottom, I almost can't see the signal, while the first channel shows a lot of high frequency noise, but the PPG oscillations we are interested in, seem to be there.

As a second step, I used the filters I normally use for HRV4Training's camera based PPG acquisition & processing, hoping they would work well on this signal as well. However, as you can see from the figure below, there is still much noise in the signal (see also detail on the right end side):

Here is the complete recording. There would be no point running a peak detection algorithm on this stream, as we are full of double peaks and ripples that would make no sense in the context of HRV, where we need very accurate beat timing:

Here is when I started having some doubts. Is this normal data? Is this level of noise when not moving at all something I should expect? Am I missing something? I messaged Kari and asked for her advice, as my experience is mainly on "finger PPG", and the data I extract using the phone camera is much cleaner, I wanted a second opinion.

Kari: The wrist is definitely one of the more difficult places to get good PPG signals. There are a few physiological reasons for this, like being located at the extremities (far from the heart) but without the high density of blood vessels we find at the fingers. It is also a place that experiences plenty of movement, like swinging arms and tendons and muscles flexing under the skin when the fingers or hand is moved. This causes additional blood flow in and out of the vessels at the skin surface, superimposing upon the heart pulses. That said, it is still completely possible to get a good enough signal for HRV on the wrist under still conditions and at comfortable temperatures as our white paper shows.

As we both agreed that the data was very noisy, I tried a desperate attempt with really heavy filtering in the band where I knew this heart rate was, so between 0.75 and 1.25 Hz. After heavy filtering the PPG data for the first channel looked (obviously) much smoother, as we filtered out all the high frequency noise. The second channel was still pretty bad:

At this point I could run my peak detection algorithm, as well as my artifact correction as they are used in HRV4Training. In red, you can see all peaks that differ more than 25% from the previous one (RR interval time differences). This is a pretty simple but effective way to detect artifacts in ECG & PPG data, and a necessary step before we compute HRV features, that would otherwise be highly affected by artifacts:

At this point we really overdid it with the filtering, and I was expecting to have artificially reduced the variability. However, as we will see later, we still had the opposite problem.

Kari: PPG signal quality is influenced by a host of factors on the sensor side as well, including the wavelength of light used (green usually works best), the layout of the optical sensor and the quality of the amplifiers and digitisers on the backend. When the signal gets too close to the noise floor as in this case, the filtering required to get a smooth waveform will distort the shape of the pulse in a way that makes it nigh on impossible to get accurate peak-to-peak distances. It's important for all the frequencies in the pulse waveform to be preserved in order to find the most accurate location of the peak. It looks like Marco's filtering resulted in combining some of the broad-spectrum noise with the signal, while removing some of the higher harmonics of the true pulse waveform. 

RR intervals

Once we detected our peaks, we can start looking at the RR intervals time series and how our PPG-derived RR intervals match with what we collected using the H7. Unfortunately, even after heavy filtering, we still have much noise, with RR intervals jumping much more than the H7 ones:

Two interesting aspects we can spot from the figure above:

• The H7 trace, in blue, clearly shows the deep breathing segment. As I was discussing at the beginning, deep breathing results in the effect of RSA being obvious on the RR intervals, as you can see from second 180 to 300, as paced breathing lasted 2 minutes. Unfortunately, we cannot spot the effect of RSA in the AngelSensor trace.
• Our RR interval correction works quite well, removing all huge artifacts and many of the smaller ones, however, the signal still doesn't really looks like the polar one (at a beat to beat level).

Heart rate and heart rate variability

The final step is to look at heart rate and heart rate variability features. What do we get if we use the RR intervals time series extracted above to compute heart rate and rMSSD, the two features we are mainly interested in?

We get good heart rate and bad rMSSD. There seem to be some sort of correlation between the rMSSD features extracted from the H7 and AngelSensor (even more so in the other measurements below), but they are really off and highly overestimated:

Here is my data, again very good match for heart rate, but inaccurate (even though correlated) rMSSD:

(light) physical activity

Just out of curiosity, I took a short recording under very light physical activity. The first minute here is at rest, while the second and third I was moving around. In this case the sensor stops reporting heart rate, as it is probably unable to compute it. We can see the noise becomes really huge and there is probably little to do even to get heart rate data out of this signal:

Summary & considerations

The AngelSensor does not seem to be usable for heart rate variability analysis. Despite providing raw PPG data, the data seems too noisy and therefore unreliable for the level of accuracy we need when computing HRV features. On the other hand, heart rate data could be measured easily and reliably when at rest. Intuitively, we just need to count how many times the blood flows to be able to extract heart rate data. This is a much easier task, as we don't even care where the peak exactly is. On the other hand, HRV is a different story, and better quality data is needed.

This being said, I'm positive on the experience with this sensor, the code and support provided by the company, and I am definitely hoping they will continue on this route. This is not a device for consumers, but it is a device for developers, and as such, it's totally fine if it feels still like a prototype. This is a great effort in supporting developers with a user friendly, cheap & open sensor. There are obvious limitations, even if this is already the second iteration of the product, there is definitely room for improvement. I am personally looking forward to the next generation, and hopefully this post will also be useful to them as they try to understand developers' needs. If someone at AngelSensor has other ideas on how to make use of this PPG raw data and better filter it, let us know and we'll definitely look into it.

Until then, you can keep using HRV4Training's unique camera based measurement, that keeps performing extremely well with respect to both chest strap and full ECG data. Some details on our latest clinical trials here.

Kari: I noticed that there is a waveform control service in the AngelSensor documentation scheduled for the v2 release. If it allows developers to adjust parameters such as the LED brightness, it may be possible to a obtain better optical signal from the device.

Follow @marco_alt

Useful resources

• MIT presentation showing some interesting approaches to deal with noise using accelerometer data, something that works for heart rate (not variability), and might be attempted using the AngelSensor raw data streams, as they also provide accelerometer data.​ I liked this one because it shows how old is this technology, and how clearly it's not about the technology, but about how it is used and about how we process the data.
• All data used in this analysis (PPG & RR intervals). Please note that timestamps are incorrect, you need to assume that PPG data is at 100 Hz and reconstruct the time array yourself.

​Like the app and the blog?

If you like the app and or the blog, take a minute to review HRV4Training on the Apple store. ​​​​Thank you!

HRV4Training on Facebook

HRV4Training is on Facebook. We use this page as a centralized place for feedback, discussions, feature requests, bug reports and to introduce new features and changes in the app. 

Especially for the ones that are not much into Twitter, feel free to use the Facebook HRV4Training page as a place to open discussions around HRV, training, performance and more. ​​