4

I am trying to read data transferred by heart rate monitors over bluetooth , but I really don't know how to read the bytes returned by the heart rate monitors.

It may be possible that each vendor has their own way of wrapping data into bytes. But how can I convert those bytes into some readable format, so that I can analyze the change in it?
Like ASCII values or some hexadecimal values.

I tried code of MyTrack application, but that didnt work for me.

MyTrack Parse Heart Rate Data

I am trying to read the bytes in Android, as of now I am getting these data but don't know which field represents what.

55 04 00 38 00 15 af    

14 b0 00 38 00 13 b1    

55 04 00 38 00 13 b1

55 04 00 38 00 12 b2
Nickolaus
  • 4,785
  • 4
  • 38
  • 60
Hunt
  • 8,215
  • 28
  • 116
  • 256
  • Thanks for adding the data--but you'll need more. Record data at known heart rates. For the data above, if your heart rate was around 177, then I'd guess the last byte represents the heart rate (af, b1, b2) and the two proceeding bytes may be the time. You'll need more data and testing to know for sure. – Nate May 03 '12 at 12:44
  • @Nate , no those bits are not representing heart beats , i tried so many combination even by subtracting , adding etc but still didnt find a way to decode it – Hunt May 25 '12 at 07:56

3 Answers3

5

Hopefully, your heart rate monitor follows the data specification defined here:

Heart Rate Measurement at Bluetooth.org

As far as I can tell, here's how to apply the info in that document:

  1. Take your first hex byte, 55, and convert that to binary: 01010101.
  2. Since Bluetooth data is little-endian, think of the right end of that sequence as bit 0 and the left end as bit 7.
  3. Now you can look at the documentation for the Flags field of the Bluetooth message. Bit 0 of the flags field tells you whether the heart rate data is 8-bit or 16-bit. In your case bit 0 is 1, so you have 16-bit data.
  4. Look at the next two hex bytes in your first sample: 04 00.
  5. Convert that to decimal. Now this part I'm not sure about. If I convert 04 00 to decimal I get 1024, so I must be doing something wrong. Perhaps coincidentally, if I reverse these digits and convert 00 40 to decimal, I get 64, which is a likely heart rate value for someone sitting at their computer (mine is 62 right now). Maybe someone can comment on how to interpret this part.

In my case, with a Wahoo Blue HR, data is coming back like this:

14 46 59 03 58 03

Converting 14 to binary (00010100) and looking at bit 0 (0) tells me that the heart rate is 8-bit, so I just need the second hex byte (46). Converting that to decimal gives me 70.

Unfortunately, I don't know how to interpret your second sample. The first hex byte, 14, indicates an 8-bit value, but that would make the heart rate value B0, or 176 -- not a likely value for someone sitting at their computer. I also wouldn't expect a single device to switch between transmitting 8-bit and 16-bit values, but I guess it's possible.

This SO question includes code for doing these conversions, and it's working for me. I just wanted to try and understand the documentation before implementing it.

Community
  • 1
  • 1
arlomedia
  • 8,534
  • 5
  • 60
  • 108
1

Unless you can find some documentation for the heart rate monitor transfer specs, you are going to need to analyze the data and decipher the format. One way to do this is to create controlled variations in the data being sent from the heart rate monitor (such as swapping between a person at rest and a person who is jogging), and then look for the differences and patterns in the data.

At the minimum, I would expect the data to consist of time and heart rate values, but there most certainly will be other fields as well such as a header, packet identifier and length, and checksum values.

Nate
  • 557
  • 3
  • 8
  • yeah but i am asking how to dechipher or disect the data as when i print bytes i am getting some unreadable value – Hunt May 03 '12 at 04:38
  • 1
    How to decipher? You look at the values, you think, you guess, you tweak, you try, you test. Rinse and repeat until satisfied. There are no shortcuts when decoding an unknown dataformat. Hard labor is the way. – bos May 03 '12 at 06:16
  • All you have are the bytes, so think of it as trying to break a secret code. As @bos says, you're just going to have to try and keep trying. Re-read my answer and follow the suggestion. – Nate May 03 '12 at 12:36
0

I haven't looked at your data, but with some monitors I have decoded from ANT, ANT+ the data stream includes the time in milliseconds between beats as well as HR from the last three beats. The advise to get data from a consistent HR is the best place to start. Then keep in mind that the number you see displayed is likely rounded from as many as three or four beats.

Robert Lee
  • 1