Angel - the first open health sensor

[size=medium]Hi there, Q-Selfers!

Been one myself for years, and now I’m hoping to graduate to the title of Tool Maker. I’m a co-founder at a young startup that developed Angel.

Angel is about two things I care a lot about:

SERIOUS HEALTH: Angel is the only wristband that can monitor heart rate, blood oxygen, temperature and motion. In data stream mode, raw waveform for each sensor channel can be accessed at frequencies of up to 200Hz. (In comparison, most trackers out there are single channel acceleration-based devices that focus exclusively on fitness.)

OPEN TECHNOLOGY: Angel is the only tracker designed from the start for developers, researchers and Quantified-Selfers. All our protocols and APIs are completely open. This includes actual real-time access to your health metrics over Bluetooth, for any app you choose. We built Angel to disrupt the established model where the same company produces both the sensor and its software (which to us is like buying an iPhone with just one app).

I have two requests for the readers of this thread:

Our crowdfunding campaign has just launched on Indiegogo. We need your support to make Angel happen:

We’ve been getting early API requests from our developer community. I’m inviting the QS folks to chip in and help us craft the SDK. Please respond on this thread or email me directly. Here’s our newsletter outlining the basic device functionality:

Much obliged for you participation and your feedback.
Over and out,
Eugene Jorov
Co-founder, Seraphim Sense - the maker of Angel health sensor

1 Like

I’ve done some work with Bluetooth LE on Android and would be happy to help create an Open Source SDK for that platform. But before I invested much time, I’d want to be sure that the device is able to produce data that is accurate enough to be useful. I’m skeptical :slight_smile:

Regarding the Web API, see

@Eric Jain
Thank you! In controlled doses skepticism can be a healthy attitude. I’m well acquainted with your post, which is one of the few available technical sources for aspiring Tool Makers. I just wanted to emphasize for other readers that at this point we are focusing on communication protocols. Most trackers out there allow access to their data online, but Angel can also be tapped into over BLE for some real-time scenarios. For example: remote temperature/fever sensing for kids, heart rate monitoring while working out, mood tracking, various immediate health alerts, physical activity performance monitoring, etc. The desired protocol will in fact define what internal functionality is going to be supported. Our signal processing can crunch some numbers, but we need to know for example whether your app requires just the heart rate once a second, or some advanced statistics such sliding average, rise times, standard deviation, and beyond. If you already have an app in mind, it should be pretty easy to list a few of those. Please post them here or email directly to me. Much obliged.
Eugene Jorov - The first open sensor for health and fitness

[quote=“Eugene_Jorov, post:3, topic:733”]
Our signal processing can crunch some numbers, but we need to know for example whether your app requires just the heart rate once a second, or some advanced statistics such sliding average, rise times, standard deviation, and beyond.[/quote]

For the heart rate, RR intervals; all the other numbers are trivial to calculate from that. But this only makes sense if the signal is very accurate (*). Otherwise, I’d rather just have an averaged heart rate once a second.

  • How about publishing some data, e.g. Angel vs Polar H7?

Maybe it’s a good idea, even though we probably won’t get to do this till our crowdfunding campaign ends (successfully, one hopes). H7 is a good reference since it provides RR intervals. Anyway, a couple of points are already worth making:

  • RR intervals won’t help deduce signal amplitude, rise time and other parameters a physician might be interested in.
  • Average heart rate alone won’t help understand the variability which is another important parameter.
  • We are considering to make certain averaging parameters configurable, e.g. window size and smoothing function. Not sure if this is going to be useful to a lot of developers.

Regarding your comment on accuracy, you’re definitely right. I should say no more until we can share definite performance results outside the lab.

You’re right; I haven’t worked on medical applications, so I can’t say what might be useful beyond RR intervals.

Should at least document what the default parameters are!

Hi Eugene
That’s what we are looking for - a few years :-). We would be very glad to connect your sensor to our SenseView ( platform. The platform is capable to connect any type of sensor. For now we support Zephyr BH3, Zephyr HxM and BT LE sensors - Zephyr HxM Smart, SensorCon Sensor Drone, TI SensorTag (BT LE sensor support is still in Beta).

If you ask for suggestion - R-R is critical if accurate, but we have another suggestion. The main problem with sensor data (and believe me we did collect a loooot of data) is a context. “When something happened?” So additional button on a bracelet would be very helpful. For example:

  1. “I feel dizzy” - press a button - button will send a time stamp…, double press means something else etc.
  2. A SOS/panic button - for elder care or - Bracelet with sensors and dedicated button is a winning combination.

If you need a help - we can prepare a demo Angel / SenseView. We’ve already saw a lot of sensors, but all had a problem with a good designed and well worked app

Have a nice weekend

Hi Jure,

Isn’t it just awesome that we can connect here just out of the blue?
Angel was made to be open. This means integrating with platforms and apps such as yours is the very thing our sensor was built for. I’ll be taking our conversation offline to take the next step, but for other QS readers I’d like to reply to your suggestions:

  1. Angel has no buttons, but it will support gesture detection, e.g. wrist rotation, arm shake, etc. We’re trying to develop our prototype to become a water proof device, so removing buttons was the price we had to pay. It should be possible to add some kind of capacitive solution, not sure yet if this could make it into our first device.

  2. We do support fall detection which I believe is very relevant for elder care. I can’t say if having a button is necessary in this case, because it might be even better to provide an automatic distress call based on vitals signs and acceleration analysis.

Be well,
Eugene Jorov

1 Like