my project page
I am sorry for the horrible layout of this page and
promise to change this as soon as I got a nice idea.
Content:
Objective: Transfer the data of a Polar pulse watch to a Palm handheld.
Here are some information about the protocol being used between the Polar S710 pulse watch
and the Polar Infrared dongle.
I started debugging/reverse engineering the protocol because I want to write a simple
program for my Palm.
The goal of this program is storing the data gathered by the pulse watch for the time no
real computer is available. The best example is a bike trip for some days where you
don't want to carry your laptop with you.
Of course the program should display the pulse curve of the data stored but not much more,
although this would be possible.
I ask Polar Electro Oy for assistance but they refused
to provide me with the information needed. So I startet reverse engineering and I make
the information available on the internet.
Here are the information I got so far. If somebody is interested in contributing or
just using the data just go ahead.
Don't be afraid of writing me an email to me@fl3.de.
Ok, that's enough of the preface.
Disclaimer
I am not responsible for any damage caused by using any software or information published
on this site.
Since reverse engineering for creating interoperability is legal in Germany,
I consider this work not being illegal.
Protocol
After setting the watch into Connect-Mode the transmission can start.
It is a simple query-response-protocol. You sent a query to the watch and receive the whole answer.
The only exception is setting the watch back to watch mode. There you don't get an answer.
A query consist of three steps.
1. Send command string to dongle.
2. Dongle sends response to command string.
3. Answer from watch if in range.
The settings for the serial port are 9600 baud, 8 data bits, no parity, 2 stop bits.
Commands
Here is a list of the commands I gathered so far. A detailed explanation of the answers from the watch
will follow later.
This is not a complete list. At least the command codes for deleting an exercise are not
contained in this list yet.
Ping |
34 A6 55 55 56 B8 25 |
User Information |
34 57 55 55 56 6C 27 |
Time |
34 AB 55 55 56 DC 26 |
Bitmap |
34 A5 55 55 56 84 25 |
Bike Setup |
34 59 55 55 56 34 24 |
Exercise-Set 1 |
34 A9 55 55 57 5A 5E B0 |
Exercise-Set 2 |
34 A9 55 55 57 4B 5E D6 |
Exercise-Set 3 |
34 A9 55 55 57 44 5E F4 |
Exercise-Set 4 |
34 A9 55 55 57 69 A1 1A |
Exercise-Set 5 |
34 A9 55 55 57 66 A1 38 |
Reminder 0 |
34 AF 55 55 57 55 5F 82 |
Reminder 1 |
34 AF 55 55 57 AA DF 81 |
Reminder 2 |
34 AF 55 55 57 AB DF 87 |
Reminder 3 |
34 AF 55 55 57 54 5F 84 |
Reminder 4 |
34 AF 55 55 57 A9 DF 8B |
Reminder 5 |
34 AF 55 55 57 56 5F 88 |
Reminder 6 |
34 AF 55 55 57 57 5F 8E |
Begin exercise data |
34 AC 55 55 56 B0 26 |
Continue exercise data |
34 A7 55 55 56 AC 25 |
Watch mode |
34 53 55 55 56 3C 27 |
Response to command string
At first I thought I had a bug in my debug tools I use on a Linux box and Windows box.
The data returned from the dongle were different on both machines.
After looking at the bits on the line using an oscilloscope I discovered that the dongle
does not send RS232-conform data. An error check implemented afterwards in my tools
validated this assumption. The response on any command string from the dongle is
not valid serial data.
The actual data returned after the command response are correct serial data.
There is always a short break of about 150ms between the command response and the actual data.
The reason for the differences in the command response I got on both machines is probably the
UART (transceiver used for serial port) used on each machine.
At this point of time the only reasonable thing to do with the command reponse is just not
check it.
Common packet structure of the watch's answer
1st.byte: 5C
2nd.byte: block type
3rd.byte: ??
4th byte: block size (high byte)
5th byte: block size (low byte) (block size=bs)
6th byte ... bs.byte: data
(bs+1).byte: checksum byte 1
(b2+2).byte: checksum byte 2
Character encoding
There is a general encoding for character data which is not ASCII.
00 |
... |
1 |
09 |
... |
9 |
0A |
... |
Space |
0B |
... |
A |
24 |
... |
Z |
25 |
... |
a |
3E |
... |
z |
Sequence of commands
Here comes the sequence of commands as executed by the software the comes with the watch
(Polar Precision Performance 3.0).
The timing is as follows:
- The software sends a command.
- The dongle replies immediately when attached.
- There is a short break of 100 to 150 ms.
- The dongle replies with the data received from the watch.
- Short break between 50 and 200 ms before the next command is sent.
The first break is required to keep the dongle reply and the watch reply apart.
Since the dongle replies with invalid data and it is not sure how many bytes the UART
will receive you have to wait for that time and discard the received data.
Actually the UART of the Palm V doesn't receive any bytes at all.
From my point of view the differences in the last break comes from the software and is
required neither by the watch nor the dongle.
In my test programs I used always the sortest values and tried it even without any breaks and
there was no error.
- Ping until response from watch
- Another ping to start the transfer
- User Information
- Time
- Bitmap
- Bike Setup
- Exercise-Set 1...5
- Reminder 0...6
- Begin exercise data
- Continue exercise data as long as there are any data
- Watch mode
The software bundled with the watch starts to query the watch with steps 1 to 8 and waits then
for the users reaction.
If the user wants to download the exercise data it continues with step 9 and repeats step 10
until no more data are received.
The user can save the downloaded data on the computer and delete the exercises on the watch.
But I don't know these commands yet.
When closing the dialog the watch will be set back to watch mode as described in step 11.