Heart Rate study
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Heart Rate study

by kneaded on Sat Feb 16, 2019 10:42 am


I'm new to all of this, so please forgive me if I use the wrong words or phrases.

I'm working to build a device to measure and record cardiac signals, in particular, heart rate variability, for a 90 minute or longer session. I am expecting/planning to use my Polar H10 heart rate "strap", but will remove the strap and use cardiac leads. The H7 sensor and strap are a single unit. I'm not opposed to buying that to learn/ test on.

There are Android apps that somewhat do this. However they crash after 30 minutes of data, and I have not yet found out how (if it's possible) to get the raw data, as they seem to automatically do number crunching/ statistics.

I've been able to find (but not yet connect) my bluetooth LE Polar H10 to my Pi3B+. The data set has the potential to be 15,000 data points.

First use would be a lab/ office type situation. There does exist a future option of needing to be battery based.

Question 1) What is the ideal board to use- Pi, Feather, Arduino, etc. Does it really matter? Am I going down a lousy path by learning Python & Pi?

Question 2) If I wanted to add other biological measurements later (breathing rate, galvanic skin response, etc) would that make a difference for which system I used?

Question 3) I've found all my answers, so far, by randomly browsing the web for hours. Is there a particularly good source of information or mentor you could point me to?

Question 4) Is this a field that it's best to start with not quite right, premade solutions and then improve from there or is better to start on the final path at the start. Some fields it's easiest to learn with basic tools, other fields you waste your time having to relearn as there are critical differences between "cheap/basic/ entry level" equipment and "refined/ finished/ final" equipment.

Thank you!!

Posts: 2
Joined: Sat Feb 16, 2019 9:49 am

Re: Heart Rate study

by adafruit_support_mike on Sun Feb 17, 2019 1:27 am

For starters, it will help you to know how BLE works as a protocol. You don't have drill all the way down to the spec, but there are some general points of importance.

First, BLE splits devices into two categories: 'central' and 'peripheral'. Central devices initiate and control data connections. Peripherals can advertise their presence (emit a standard "I'm here" message periodically), but otherwise they wait for a central to tell them what to do. That arrangement puts most of the cost and complexity in the central, leaving peripherals free to be simpler, smaller, lower energy, etc.

As an aside, BLE and what's now known as Bluetooth Classic are different and incompatible protocols. They just happen to be managed by a working group that loves confusingly-similar names.

Bluetooth Classic is a top-heavy protocol: every BT-C device has to belong to a certain pre-defined category, and has to send/receive a set of messages defined for that category. That's great for interoperability.. your computer knows how any BT-C keyboard will behave without needing to install drivers, and the keyboard manufacturer knows its device will be able to talk to any computer that speaks BT-C. It's not so good for special-purpose devices like heart monitors, myoelectric sensors, or EEGs though. The only way to get support for your data protocol is to publish it as part of the BT-C spec, and then you're locked into that protocol until you can convince the working group to release an addendum for anything you want to change.

BLE is more nimble. There are standard device profiles and message sets that you can use if you want, but you're also free to create your own messages if you prefer. There's a set of general rules for how BLE messages are organized, but you have a lot of freedom within that framework.

That makes communicating with a central device more of a challenge. If you create your own messages, your central device needs software that understands those messages. That means BLE systems mostly have two pieces: the peripheral you carry around, and a program that runs on the central.


If you want to capture data from a Polar H10 peripheral, you'll need to create a program that knows how to talk to a Polar H10.. what kinds of messages it can emit, and how/when to ask for specific pieces of information. Remember that the software on the central device tells the peripheral device what to do, so there could be 'start collecting data' and 'stop collecting data' messages the central needs to know about.

The starting point for that will be the documentation for the Polar H10, and that will most likely come from the Polar Developers website:


You'll have to check with them to see what's available.

Generally speaking though, it sounds like you want to create a new piece of software that will run on the central device, and whose primary focus will be on storing data. You can use any kind of computer for that, as long as it has BLE support. All of the major operating systems have something, and on the RasPi, it will be the BluEZ code stack:


The code works, but the documentation is sparse. Learning to use it is kind of a self-study research project.

For a general overview of BLE, we have a manual in the shop that's co-authored by one of our own engineers:


Posts: 57106
Joined: Thu Feb 11, 2010 2:51 pm

Re: Heart Rate study

by jps2000 on Mon Feb 18, 2019 2:56 am

I use a feather nrf52 and the central custom hrm example to read out polar H7 receivers.
These HRM send data at a constant rate every second. There is the heart rate and RR intervals.
The heart rate is a strongly integrated value that ist very tolerant to poor contact or movement artifacts
The RR is not. It is important to know that one transmission may contain 0 to 4 RR values. depending on heart rate. ( below 60 not every second a RR is ready.
So you need to write RR values in a buffer for analysis.
To get RR values you need to modify the following routine in the example

Code: Select all | TOGGLE FULL SIZE
void hrm_notify_callback(BLEClientCharacteristic* chr, uint8_t* data, uint16_t len)
  // https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.heart_rate_measurement.xml
  // Measurement contains of flag byte0 and measurement (8 or 16 bit) + optional fields
  // if byte0's bit0 is 0 --> measurement is 8 bit, otherwise 16 bit.
  // RR is uint16_t and only available if bit5 is set. if HR <  data rate some atre not transmitted if HR >> data rate  multiple transmissions ?? occurs ???????
  // more than 1 byte???  --> to be tested!!!!!!!!!!!!!!!!!!!!!

/* Data transfer rate is always 1 sec.
 * Hence sometimes more than one RR value or none is sent
 * RR data are stored in an array. Zero values to be omitted.
 * hrm_notify callback can be called multiple times after the other. loop is not entered
 * --> fill buffer already  in this routine
 RR[0] = 0;     // reset RR                         
 RR[1] = 0;
 RR[2] = 0;
 RR[3] = 0;
      HR = data[1];
      electrode = (data[0] & 0x07)>>1;     // electrode contact (2,3)?
      if(data[0] & 0x10)                  // RR data available? --> flag bit5 = 1?       if(data[0] & 0x10)   
      if(len >= 4  )  RR[0] = ((uint16_t)data[3] << 8 | data[2]);         
      if(len >= 6  )  RR[1] = ((uint16_t)data[5] << 8 | data[4]);       
      if(len >= 8  )  RR[2] = ((uint16_t)data[7] << 8 | data[6]);
      if(len >= 10 )  RR[3] = ((uint16_t)data[9] << 8 | data[8]);
      RR[0] *= 0.9766;            // use multiply iso 1/1.024 
      RR[1] *= 0.9766;
      RR[2] *= 0.9766;
      RR[3] *= 0.9766;     

#ifdef debug
      Serial.print("Sensor ");
      Serial.print(" HR ");           
      Serial.print( HR,0);                   
      Serial.print(" RR: ");   
      Serial.print(" ; ");
      Serial.print(" ; ");
      Serial.print(" ; ");
      Serial.println(" ms ");

Posts: 393
Joined: Fri Jun 02, 2017 4:12 pm

Re: Heart Rate study

by kneaded on Thu Feb 21, 2019 2:22 pm

Thank you both for the assistance! I've had some other stuff come up, so haven't had the time to fully go through your suggestions. It might be next week before I get to dig into this project.

Thank you!!

Posts: 2
Joined: Sat Feb 16, 2019 9:49 am

Please be positive and constructive with your questions and comments.