LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

acquisition of heartrate from bluetooth polar wearlink

Solved!
Go to solution

Hello!

 

I'm trying to build a VI that recieve the heart rate from the polar wearlink bluetooth device for heart rate acquisition. I have build a vi, but the data from it is just gibberish for me. So I don't know how to transform it to anything useful. I'm using labview 2011. So far this VI looks like:

 

Untitled.png

 

Data data which comes out from data out looks like:

data out.png

 

Any help would be appreciated!

 

 

 

0 Kudos
Message 1 of 15
(8,375 Views)

Try researching the device to see if there is a protocol description.  The vendor/manufacturer may provide help.

http://www.medicollector.com
Message 2 of 15
(8,373 Views)

This is going to be a tough one.

 

You need to do some detective work.  If the manufacturer does not provide a specification, you can to convert it to all sorts of data formats and plot it out.

 

Right now, you have the data as a string.  Convert it to an array of bytes and plot it as signed integer, unsigned integer, etc.  Then convert it to Word and try the same.  Then convert it to single and double, etc.

 

You can tell from the string that there is some sort of pattern in the data.  Hopefully, you will see something in the data that you recognize.

Message 3 of 15
(8,364 Views)

Thank you both for taking the time to answer!

 

So I've emailed polar to see if they have any communication protocols available for me. Though it doesn't seems to have any publicly available. But I'll await an answer and see, meantime I'll try to do some detective work. Although I have no experience doing these kinds of conversions, so we will see how it goes..

0 Kudos
Message 4 of 15
(8,356 Views)

okey, i found out that the messages from the polar should look like this:

 

fe 0a f5 07 d1 4b 03 3b 03 22

fe 08 f7 08 d1 4b 03 57

fe 0a f5 09 d1 4a 03 5b 03 53

fe 08 f7 0a d1 49 03 66

fe 0a f5 0b d1 49 03 58 03 4f

fe 08 f7 0c d1 49 03 23

fe 0a f5 0d d1 49 03 20 03 1f

fe 0a f5 0e d1 4a 03 2e 03 04

fe 08 f7 0f d1 4a 03 20 fe 0a

f5 00 d1 4a 03 27 03 1d

fe 0c f3 05 d1 5f 02 48 02 4f 02 48
fe 0c f3 00 d1 64 01 02 01 48 06 34

fe 0c f3 0d d1 62 02 12 02 0b 01 3d

 

and so on. Where the third hex f3, f5 and f7 decides the message size. And the sixth hex is the heart rate.

 

The data I get from the bluetooth seems to "miss" some of the data in the transfer?! Because i get the data:

FE08F701F1000317F1000317

FE08F703

FE08F704F1000317F1000317

FE0AF506372

FE08F707F146F508F14603410343F147034D

FE0AF50A2E9

FE0AF50BF14B

FE0AF50CF1490313F70DF1490366

FE0836C

FE0AF50FF147

FE08F700F1470330F147035E036B

FE0832A

FE0AF503F147

 

I have tried several different read options to the bluetooth read function, but still the same problem. Anyone know how what to try? I add an attachment of a picture of the code and the code itself

 

Download All
0 Kudos
Message 5 of 15
(8,327 Views)
Solution
Accepted by topic author JonasL

A wild guess is this has something to do with the message size and the fact that you wire a 12 to the " bytes to read" input:

 

bytes to read  is the number of bytes to read. Use one of the following techniques to handle messages that might vary in size:

  • Send messages that are preceded by a fixed size header that describes the message. For example, it might contain a command integer that identifies what kind of message follows and a length integer that identifies how much more data is in the message. Both the server and client receive messages by issuing a read function of eight bytes (assuming each is a four byte integer), converting them into the two integers, and using the length integer to determine the number of bytes to pass to a second read function for the remainder of the message. Once this second read is complete, each side loops back to the read function of the eight byte header. This technique is the most flexible, but it requires two reads to receive each message. In practice, the second read usually completes immediately if the message is written with a single write function.
  • Make each message a fixed size. When the content of a message is smaller than the fixed size you specify, pad the message to the fixed size. This technique is marginally more efficient because only a single read is required to receive a message at the expense of sending unnecessary data sometimes.
  • Send messages that are strictly ASCII in content, where each message is terminated by a carriage return and linefeed pair of characters. The read function has a mode input that, when passed CRLF, causes it to read until seeing a carriage return and linefeed sequence. This technique becomes more complicated when message data can possibly contain CRLF sequences, but it is quite common among many internet protocols, including POP3, FTP, and HTTP.
http://www.medicollector.com
Message 6 of 15
(8,321 Views)

ah okay, now it is working. Added another bluetooth read, and the message size to bytes to read to that one. Thanks! Smiley Happy

0 Kudos
Message 7 of 15
(8,314 Views)

Hey JonasL,

 

Please post this up on the Biomedical User Group at ni.com/biomedusers - I think that group will really like what you have done!

 

Thanks,

Steve

0 Kudos
Message 8 of 15
(8,305 Views)

Hi all! Does anyone know how to JoanSl deciphered the Bluetooth parcel with sensor Polar. What parameters are read it changed?

0 Kudos
Message 9 of 15
(7,243 Views)

A solution is found. The value of heart rate in the parcel follow no writings, which can take values from 11, 21, 31... to ...E1, C1, D1, F1. In the first ten packages I make the definition of this mnemonics, and then use it as the main one.Снимок2.PNG

0 Kudos
Message 10 of 15
(7,039 Views)