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.


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 Ok, that's enough of the preface.


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.


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.


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 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.
  1. Ping until response from watch
  2. Another ping to start the transfer
  3. User Information
  4. Time
  5. Bitmap
  6. Bike Setup
  7. Exercise-Set 1...5
  8. Reminder 0...6
  9. Begin exercise data
  10. Continue exercise data as long as there are any data
  11. 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.