Willem.Minten@telenet.be

Creation date: 0ctober 15, 2004 

Last revision date: November 6, 2005 (the latest PPP SW can be found here)

You want to buy an S625X? Click on the banner below.

 

 

Is the content of this site obsolete?

·         The last major update of this site has been done for the PPP SW 4.02.037.  There is a later PPP SW 4.03.041 available here. There is one major difference between both updates that affects some parts of this document. I have summarized this in MSG 2916 of the Yahoo  S625X forum.

·         You can try to ask POLAR to report which bugs were fixed in their last software update.  It is not their policy to answer such a question.

·         The S625X contains a MASK processor, which can’t be updated. This means that the firmware bugs or anomalies of the S625X itself, still hold.

·         Cycling: some people also posted their experience with cycling facilities (MSG 2712, MSG 2837, …).  I have posted some interersting controlled test protocols for the evaluation of the basic cycling behavior of the S625X (MSG 2697,  MSG 2705, …). The only thing that is confirmed today is that it is not advised to use another MEM SET than 5 sec.

 

 

 

 

Table of contents

 

1    About this document 4

2    What to remember if you do not want to read the entire document 7

3    What’s in this report for you? 8

4    Introduction/Background. 11

5    Speed and distances in the S625X and PPP SW: the principles. 12

5.1  Displayed and measured speed sensor values. 12

5.2  Recorded speed sensor values. 13

5.3  Displayed and recorded distance values. 13

5.4  Transferred distances to the PPP SW.. 14

6    Speed and distances in the S625X and PPP SW: the real behavior 14

6.1  The real speed and distance transfer from S625X to the HRM file. 14

6.2  The real speed and distance management in the PPP SW.. 15

6.2.1  Ambiguity between LAPdistances and SATdistances. 15

6.2.2  SATdistances (SAmple Time distances) in the PPP SW.. 17

6.2.3  LAPdistances in the PPP SW.. 19

6.2.3.1  Originally measured and recorded LAPdata. 19

6.2.3.2  Other LAPdata manipulation. 22

6.2.4  Total distance ambiguity in the PPP SW.. 24

6.3  The real speed and distance management in the S625X. 25

6.3.1  Distance leaks. 25

6.3.1.1  Underestimation of the real distance due to speed cracks. 26

6.3.1.2  Underestimation of the real distance due to stopping the StopWatch. 26

6.3.2  Firmware bug:  LAPdistance recording. 27

6.3.3  Firmware bug: Instant distance bug. 31

7    Paces in limits and their limitations. 34

7.1  Programming the S625X Exercise Set (virtual trainer) 34

7.1.1  Virtual trainer “BasicSet” 34

7.1.2  Virtual trainer “IntervalSet” 37

7.2  Paces in Limits. 38

7.3  Firmware bug: PACE LIMITS. 40

8    Workouts with speed cracks. 41

8.1  Influence of the MEMory SETting. 42

8.1.1  Influence of the MEM SET on the recorded speed curve. 42

8.1.2  Influence of speed cracks on the LAPdistance recording. 43

8.1.3  Recall: influence of the displayed body speed at the LAPtime on the LAPdistance recording. 43

8.2  Influence of the running speed profile on the accuracy. 46

8.3  Distance based Interval guidance. 47

8.3.1  Firmware bug: INT DIST and RECOV DIST. 47

8.3.2  Illogical behaviors of the distance based interval trainer. 47

8.3.3  An example of a distance based interval workout with pace limits. 49

8.3.4  Conclusions. 51

9    After workout speed and distance data analysis. 52

9.1  New York Freezer 5km.. 52

9.2  New York Freezer 5 mile. 55

9.3  Conclusions. 59

10  Most important conclusions on the practical use of the S625X. 61

10.1          Functionality and design. 61

10.2          Important bugs. 62

10.3          My personal recommendations to POLAR. 64

11  Accurate Calibration. 64

11.1          What is the accuracy if you don’t calibrate? 65

11.2          What is the best calibration method? 65

11.2.1     First difference: stand-still versus flying calibration. 66

11.2.2     Second difference: blind calibration versus transparent calibration.. 66

11.2.3     Third difference: number of significant digits taken into the calibration   67

11.2.4     Fourth Difference: preferred calibration track. 68

11.3          Accurate calibration procedures. 68

11.3.1     Accurate Calibration Factor Procedure. 69

11.3.1.1     Basic Protocol 69

11.3.1.2     Calculation of the Calibration Factor: 70

11.3.2     Accurate Calibration Chart Procedure. 71

11.3.2.1     Basic Protocol 71

11.3.2.2     Calculation of the Calibration Chart: 71

11.4          Additional remarks on accurate calibration. 72

12  A Swiss Army Knife for the S625X recorded speeds and distances. 73

12.1          Preliminaries. 73

12.2          Recalculation of the CF. 74

12.2.1     Automated calculation of the CF. 75

12.2.2     The Calibration Chart. 77

12.2.2.1     The protocol  to obtain a Calibration Chart 77

12.2.2.2     Automated calculation of the Calibration Chart 79

12.3          Recalculation of recorded speed and LAPdistances in the hrm file. 81

12.4          Filtering recorded LAPdistances in the hrm file. 87

13  Dealing unstable measurements/malfunctioning speed sensor 89

13.1          Basic steps to avoid unstable measurements. 89

13.2          Speed spikes. 89

13.3          Sleeping sensor 90

13.4          Summary of erroneous recordings. 93

14  A comparison with an other accelerometer based implementation. 94

14.1          Relevant technical specifications. 95

14.2          Comparison of the recorded speed graphs. 95

14.3          Comparison of the measured workout distances. 97

14.4          Conclusions. 99

15  Triathlon – Duathlon. 100

15.1          Other S625X firmware bugs concerning speed sensor settings. 100

15.2          Swapping the speed sensors in Triathlon - Duathlon. 101

15.2.1     The three hrm files solution.. 102

15.2.2     The two hrm files solution.. 102

15.2.3     Some last remarks. 103

16  Document printing instructions. 103

1         About this document

 

I started to write this document for two reasons:

1.      When I asked POLAR feedback on several strange behaviors on speed and distance, I need to explain step by step what the problem is;

2.      After collecting all these emails, I added all the speed and distance related features of the S625X and also added my personal experience in a logical and readable way.  This clearly is a welcome addition to the S625X manual since this document makes it possible for the S625X community to use this speed and distance training mate to its maximum capabilities.

 

This document is considered as an independent reference work on the S625X. 

A few quotes of peers:

 

…I'm grateful that you wrote this report, because you have saved me months of upcoming agony and research…

Ray

 

… I am really amazed about the amount and level of information in your on line document. You can’t find that in the manual or on the POLAR site.  You saved hundreds of hours of their helpdesk…  And then you offered us the Swiss Army Knife. A superb tool to automate my calibration! POLAR should pay you for that effort…

Peter

 

…I want to express my appreciation for all your contributions. I know you have invested considerable of time and energy on the S625x. We have learned a lot from you…

Ken

 

…I found your posting and on-line document invaluable…

Ian

 

… your document is really for everyone who uses a S625X.  What I really like is the way you show me how to deal with all the problems I face…

Stephen

 

...Ik ben diep onder de indruk van je onderzoek, verslaggeving en aanbevelingen over de S625x; Je kan hier zo ongeveer op promoveren, denk ik! Heb je af-en-toe óók nog tijd om te lopen?? ...  Ik heb enig idee van de immense hoeveelheid tijd die het produceren van een onderzoek en een verslag als dat van jou kost. En dan óók nog in goed Engels, en dan óók nog dat Excel-sheet!! Menig dissertatie heeft meer blabla en minder inhoud!

Bedankt!...

Beaver

 

Personally I think I am just an exponent of the excellent S625X Yahoo discussion forum created by George Grenier:

 

This forum has been a great help to me and thousands of others to decipher the complexities and bugs of the s625x…

Barry

 

…I have to say that I've enjoyed and greatly benefited from your contributions to it.  I just wanted to say thank you for all of the hard work you gave the group…

Will

 

 

 

 

 

For my day-to-day workouts, I don’t use the S625X any more. Some of the reasons are related to:

1.      Reliability: Once in a while I have sleeping speed sensor problems (hardware related I think). POLAR informed me “you are the only one reporting this effect”.  But I already had three S1’s showing a sleeping sensor effect;

2.      Accuracy: In the technical specifications of the manual it is claimed that the accuracy of the speed and distance sensor is “±3% or better once calibrated, definition applies to steady state conditions”. On the International site one can read “Q: How accurate is the S625X? A: Generally the S625X is at minimum 97% accurate even without calibration. The accuracy increases to 99% with calibration”.  This is not correct.  As it is proven in Section 6.3.2., the accuracy very much depends on the way how the runner/cyclist manipulates the S625X. E.g. for a perfectly calibrated speed sensor and steady running condition it is shown that every LAPrecord of a distance smaller than 4000m will result in a smaller accuracy than the 99% claim. And taking LAPS smaller than 1000m will result in reality in a smaller accuracy than 97%, even for a perfectly calibrated S1 and a steady run.

3.      Usefulness:

a.       I also train interval workouts. In practice the speed sensor is not applicable in interval workouts. There are simply too many problems involved with the speed sensor to be useful in such workouts (too long response time, firmware LAPdistance bug, distance cut-off, no separate interval and recovery distance record).

b.      For steady speed workouts the recorded speed profile is too nervous (oscillatory) for me. I can’t detect speed trends in the PPP SW speed graph.

4.      Consistency: there are many kinds of ‘distances’ involved in the S625X and PPP SW and they are inconsistent.

5.      Different view on the bug list: I collected several software and firmware bugs in Section 10.2. The general answer of POLAR is “The S625x is functioning according to the specifications, so basically there are no bugs,…”.  This is different with what I expect as a proper answer.

 

This does not mean I think the S625X is worthless.  Once calibrated correctly, the S625X reports accurately the instantaneous speed or pace.  And if distance accuracy, or any kind of after workout speed analysis, is not prevalent to you then the S625X could be an adequate training mate.

But to satisfy my personal  training needs, I switched to the SUUNTO t6 wriststop personal trainer.  After the calibration of  this training mate, I just have more speed and distance functions working correctly and more accurately ‘out of the box’ than the instant speed feedback during my steady runs.  If you want to read the (different) data management principles, extensive test results, and  my personal experience with the t6,  you can find it here (http://users.telenet.be/wy/sport/t6/t6%20Accurate%20Speed-Distance%20Measuremnt.htm ).

 

 

Due to its value for the S625X users, this document will stay available online in my personal directory. Also, I will leave my Swiss Army Knife.xls in the files section of the Yahoo S625X discussion forum too.

 

You can still feedback on this report in the Yahoo S625X discussion group http://health.groups.yahoo.com/group/S625x/, which is the home forum in which this document is created.

 

 

 

Good luck with your training mate!

 

 

Disclaimer:

I am neither a POLAR technician nor expert. So I take not any responsibility whatsoever on the content of this document and all possible effects this could have.

 

 

·         The S625X running computer is specifically designed for obtaining feedback of your body speed at steady pace. The description ‘S625X cycling and running speed and distance measurement equipment’  is more than can be achieved with this equipment.

A better description would be ‘S625X steady speed feedback equipment’

·         If you do the calibration as is proposed by the POLAR manual, you can expect an accuracy of 98% and better on the overall measured distance and overall average speed for a steady speed workout. You can raise this accuracy to 99,5% and better if you do an ‘accurate’ calibration as is explained in this document, Section 11.3.

·         If your workout is entirely interval-like (i.e. the recorded speed profile involves speed cracks) then the accuracy on the distance, even perfectly calibrated, will have an expected value of 94,5% and better.

If your workout is mixed steady pace and interval-like, then Figure 1 can be used to know the expected accuracy on the overall distance and average workout speed

 

 

Figure 1 the expected accuracy for a perfectly calibrated speed sensor is function of the running speed profile

 

·         Even for a steady run, the after workout analysis in the PPP SW of speed and distance values should be done with care (Section 9).

·         If your measured speed data shows much speed spikes or if during a steady workout your measured (accumulated) LAPdistances turn out to deviate more, you should consult Section 12.

·         In every case, you should read at least Section 3 item 2 (ambiguous distance readouts); Section 10 (basic functionalities and reported bug list) and consider reading Section 11 (Accurate calibration); and to make life easier, use the calibration support in my Swiss Army Knife.xls  (Section 12.2).

 

 

 

This report only involves running speed aspects and no cycling speed aspects of the S625X.

 

What will be the benefit for you if you go through this report?

1.      You will take into account the actual limitations of the S625X wrist computer and the S1 speed and distance sensor;

2.      IMPORTANT:

You will know the origin of the difference between the ‘sampling time distances’ (SATdistances) and the ‘LAPdistances’, where they are designed for,  where in the S625X and the software they occur, and which one is  the most accurate (and in which condition this holds);

Therefore you will have to understand where (and why) the most important inaccuracies of the distance measurement take place; and if they are important for your workout log. By knowing this you can manage your distances in an appropriate way.

 

E.g.: according to a lot of user feedback you can’t always find the distance that was shown on the S625X display afterwards in the PPP SoftWare. This is because several kinds of distances are involved (all this is not documented by POLAR, but it is very important to know it!), and because very annoying bugs play around:

·         On the wrist computer you can read two kinds of distances:

1.     The instant distance: i.e. the distance during your run or during a StopWatch pause) calculated within the S625X. 

o        This distance does not contain the firmware “LAPdistance bug” (S625X FIRMWARE BUG 6.1);

o        It is calculated from the measured speed, and is updated every 2 to 5 sec. However speed cracks make the measured speed invariant for about 9 to 11 sec, so the calculated distance is also influenced largely by inaccurate measured speed crack profiles;

o        Probably this distance also contain inaccuracies due to an inaccurate integration algorithm in the firmware (similar to PPP SW BUG 6.2);

o        This distance does contain the firmware “DISPLAY bug” (S625X FIRMWARE BUG 6.2);

o        It is visualized up to 10 meters;

2.     The distances stored in the FILES section:

o        Most of these distances do not contain the firmware “DISPLAY bug”; except for the  ‘Exe. Dist’, which  is the instant distance at the time the StopWatch was stopped.

o        It is rounded off on 100 meters;

o        The LAPS contain the recorded LAPdistances:

§         The LAPdistances contain the firmware “LAPdistance bug” (S625X FIRMWARE BUG 6.1);

§         As result of the first two firmware bugs the sum of the LAPdistances is in general not equal to the ‘Exe. Dist’.

·         In the PPP SW you can read two kinds of distances:

1.       Distance at the Time SAmples (SATdistances):  this is visualized in the Listing Table, as the graph distance axis: 

o        This distance does contain inaccuracies due to an inaccurate integration algorithm (PPP SW BUG 6.2). They are calculated  in the PPP SW from the recorded speed at the SAmple Times. Also, this recorded speed is not updated as fast as the instant distance  (MEM SET 5, 15, or 60 sec), which makes this distance normally less accurate as the LAPdistance is (should be).

o        in the Listing Table the SATdistances are visualized  up to 1 meter;

2.       recorded LAPdistances:

o        Normally these are the recorded LAPdistances in the S625X that are  transferred  to the PPP SW via an hrm-file (heart rate monitor file);

o        Hence this distance also embeds the firmware “LAPdistance bug” (S625X FIRMWARE BUG 6.1);

o        The last few PPP SW updates involve sometimes inaccurate LAPdistances in the LAPtimes window: i.e. the values shown in the Laptimes window do not correspond to the LAPdistances stored in the hrm file (due to the PPP SW BUG 6.4);

o        In the window LAPtimes, SPEED TAB, the last column is the accumulated LAPdistance (simple sum of the LAPdistances);

The total distance report below the graph is ambiguous: sometimes this is the accumulated LAPdistance, sometimes this is the last SATdistance (PPP SW BUG 6.7);

 

All this makes the distance readouts ambiguous. However, once you know what kind of distance you face and which  limitations are involved (bugs, different origin), things become manageable.

E.g.:

·         In general the ‘Exe. Dist’ in the S625X does not correspond with the distance at the last sample time, and both distances also do not correspond with the accumulated LAPdistance;

·         In general the ‘most correct distance’ is not always the instant distance nor the recorded LAPdistance:

o        If there was no zero speed  during your workout, the instant distance on the display will be accurate (DISPLAY bug is avoided);

o        If you only take LAPs for distances larger than 5,5km, or take only LAPs when you stand still (which is rather inappropriate during running and which also induces distance leak problems), then the LAPdistance bug is faded out in the LAPdistance recordings.

Only when *both* assumptions hold simultaneously, you will not notice a big difference between the instant distance and a corresponding LAPdistance at that specific StopWatch LAPtime.

 

 

3.      You will know how (and understand why) to calibrate correctly. This is most important since a correct calibration procedure result in accurate calibration factors which avoids ‘systematic’ errors in all your speed and distance measurements. If you want a hassle-free and accurate calibration, then probably Section 12.2 and the corresponding excel file (Swiss Army Knife.xls) is something for you. By using an easy protocol you can obtain automatically a Calibration Chart as is shown in Figure 2.

Figure 2 This ‘personal’ Calibration Chart shows the Calibration Factor (CF) as function of the mean running speed and contact surface running shoes-running surface. An excel sheet Swiss Army Knife.xls is provided to calculate automatically this highly accurate linear relationship. To obtain such an accurate graph, read Section 12.2.2.

 

4.      You will know where the S625X speed and distance measurement is extremely suited for, for what it can be used very well, and for what it is not adapted for.

5.      You will be able to use best practices of the speed and distance measurement facilities of the S625X;

6.      If you have problems to understand the programming and the virtual trainer facilities of the S625X, then you can read the basics and suggestions in Section 7.1.

 

From feedback on the internet S625X discussion groups and forums (e.g. http://health.groups.yahoo.com/group/S625x/ ; http://www.runnersworld.co.uk/forum/forummessages.asp?dt=4&UTN=39571&srchdte=0&last=1&V=6&SP= ), I noticed that most of the S625X users are very satisfied with its speed and distance measurements. However there were a lot of questions going around on some specific behavior for which no answer could be found:

1.      Why the distances shown on the S625X display do not  correspond with the distances reported in the PPP SoftWare?

2.      When running on a track, why is the recorded distance of the first LAP always shorter than the distances of the following LAPs?

3.      Why is the measured distance of an interval workout always shorter than the measured workout of a tempo workout on the same path?

4.      At the start of a run or at a sudden change of the running speed, the speed or pace value on the display sometimes takes about 9 to 11 seconds to adapt. Is this a bug, or is this imposed by the used technology, or a result of the specific implementation done by POLAR? And does this latency influences my hrm file and average workout speed?

 

A starting point for me was the used inertia or acceleration based measurement technology patented by DYNASTREAM (http://www.dynastream.com/home/).  On this site there is a white paper describing the basic working principles of the POLAR S1 speed and measurement sensor (http://www.dynastream.com/datafiles/SpeedMax%20White%20Paper%20v4_1.pdf ).

If you are really interested in this accelerometer technology, then the online thesis of Gross Stirling (http://www.geomatics.ucalgary.ca/Papers/Thesis/other/RossSterlingThesisUofADec03.pdf) is something for you.

 

 

FIRST REMARK:

Do not seek in this report to speed and distance recording comparisons with other ‘technologies’ (e.g. TIMEX GPS BODYLINK - http://www.timex.com/bodylink/ - ; e.g.  SONIC Radar Speed System  - http://www-scf.usc.edu/~milindgu/Projects/RSS.htm -). A good attempt to outline these different ‘technologies’ is done in http://www.milbourn.plus.com/sdm/ . But an excellent global comparison of the ‘products’ implementing these technologies (as is done for bicycle power recordings in http://www.biketechreview.com/archive/pm_review.htm)

is to my knowledge not available these days.

 

However, in Chapter 14 a comparison is made with an instrument that uses the same accelerometer technology to record running body speed and running distances.

 

 

SECOND REMARK:

It is assumed that the reader is aware of the content of the manual of the S625X and the Polar Precision Performance SoftWare (PPP SW).  If you have problems to understand the programming of the S625X, then you can read the basics of it in Section 7.1.

 

 

 

 

In this chapter I assume the behavior of the S625X as if there are no firmware bugs.

5.1   Displayed and measured speed sensor values

 

I had three observations concerning the displayed values on the S625X wrist computer:

1.      There is an immediate visualization of the measured heart rate on the display. This can be verified when you observe an almost immediate raise of your heart rate at the display when you stand up from a lying down position;

2.      A smooth change in body running speed also becomes visual at the display relatively fast;

3.      A sudden huge change in body running speed takes more time to reflect on the display, and thereafter it also takes a little while before the new body speed is reached at the display.

 

The reason behind this different reaction speed could be the following:

1.      As can be read in the white paper http://www.dynastream.com/datafiles/SpeedMax%20White%20Paper%20v4_1.pdf the speed measuring device involves in principle foot accelerometer measurements, and thereafter several mathematical translations towards a forward body speed. At this time I have the experience that the delay involved is about 2 seconds. I.e. there is about 2 seconds latency between a slightly changed body speed and the indirectly measured and calculated body speed shown at the display.

2.      When a sudden high speed change is detected by the accelerometers in the speed sensor there is a much longer latency taking place. Probably also some 're-initialization' takes place in the speed sensor electronics and in  the S625X data measurement part before a modified calculated speed is ready to be transmitted to the display.  I have the experience that the delay involved with this re-initialization is about 7 to 9 seconds, and that an extra 2 seconds is necessary to fine-tune the calculated speed to the body speed. Overall, the delay involved with a high speed change can thus take up 9 to 11 seconds.

 

 

5.2   Recorded speed sensor values

 

I imagine the mutual behavior of the sensors, the S625X display and the hrm recorded speed values as follows:

1.      during a steady run the measured speed is displayed instantly with an observable delay of 2 to 5 seconds; at speed cracks the instant speed is delayed for about 9 to 11 sec

2.      the heart rate is displayed instantly without any delay;

3.      At the sampling times defined by MEMory SET, the displayed signals (except from the distance)  will be recorded in the hrm file. This is visualized schematically in Figure 3 for the displayed running speed.

Figure 3: Displayed versus approximated speed profiles

This means that the hrm speed data (red bullets and lines) assumes at most a ‘linear’ varying body speed change within each sampling period. E.g. when the display (blue curve) shows at the sampling times low speed values but in between high speed values, this high speed value is neglected in the hrm data file. The recorded speed is assumed to be the calculated body speed at the sampling time and not the average speed within the sampling period (this is also verified in this report).

In the FILE menu of the wrist computer the recorded speed values are visualized up to 0,1km/h.

 

 

5.3   Displayed and recorded distance values

 

Summarizing, the wrist computer is able to receive and display the stream of sensor speed values continuously and almost instantaneous (at steady pace a delay of about 2 seconds, at speed cracks a delay of 7 to 9 seconds). 

From this stream the distance can be calculated and displayed continuously on the wrist computer. The displayed value of the distance is visualized up to 10 meters. Internally the distance data is known up to at least one meter (the distance data of a LAP sent tot the PPP SW is up to 1 meter of accuracy).

 

However, after exercising, the FILE menu (SAMPLES submenu) does not show distances but speed values at sampling times. Hence, in contradiction to the stream of sensor speed values, the stream of calculated and displayed distances is not recorded at the sampling times:

1.      When the LAPbutton is pressed during an exercise (but also automatically when the StopWatch is stopped), the LAPtime and the displayed instant distance ran during that LAP is also recorded separately in the wrist computer exercise file.  This can be observed after exercising in the FILE menu, LAPS submenu, of the wrist computer.

2.      When the StopWatch is stopped, the displayed instant distance is also stored as “Exe. Dist” in the S625X. ;

The distance values in the FILES menu are only visualized up to 0,1 km.

 

 

5.4   Transferred distances to the PPP SW

 

The exercises recorded in the wrist computer can be uploaded to the PPP SW. This software stores the recorded data in a  hrm-file (heart rate monitor file) on the computer hard disk. This data-file:

·         does not contain at the sampling times distance values. Only speed values, heart rate, temperature, etc are recorded and collected in the hrm data file section [HRData] (if set so), but no distance values;

·         does contain the LAPdistances, i.e. the distances ran in each LAP.  All the recorded values at the LAPtimes are collected in the hrm data file section [IntTimes].

Since also the StopWatch time at a LAP event is recorded and transferred to the hrm file section [IntTimes],  the average LAPspeed and LAPpace can be calculated in the PPP SW.

 

There is no immediate reason why the real measured distance at the sampling times should be recorded and transferred also. I assume this would lower the capacity of the exercise recording dramatically, without gaining much useful information.

 

 

 

This chapter is split into three major parts: (1) the transfer of the data from the S625X to the HRM file; (2) the behavior of the data in the PPP SW; and (3) the behavior of the data in the S625X.

 

6.1    The real speed and distance transfer from S625X to the HRM file

 

The upload process of the sampled sensor values of a workout from the heart rate monitor (wrist unit) to the hrm-file on the hard disk (via the PPP SW) is not bug free.

 

PPP SW BUG 6.1 (Release 4.02.037) The hrm file uploaded form the wrist unit is sometimes incomplete: (a) (only Release 4.02.035 and earlier versions) the last sampled sensor values are not transferred from the wrist unit into the [HRData] section of the hrm file;  (b) the assigned nonzero timers in the wrist unit are not copied properly in the hrm file section [Params]; (c) the assigned nonzero pace limits in the wrist unit are not copied properly in the hrm file section [Params].

[

PROOF:

(a)     (Deleted)  àupdate your PPP SW so all samples are uploaded correctly.

(b)    the transferred hrm file will not assign the nonzero timers of a programmed workout in the [Params] section, they remain zero:

Timer1=00:00:00.0

Timer2=00:00:00.0

Timer3=00:00:00.0

(c)     the transferred hrm file will not assign the nonzero pace limits of a programmed workout in the [Params] section, they remain:

Upper1=0

Lower1=0

Upper2=0

Lower2=0

Upper3=80

Lower3=5

]

 

The most important consequence of the missing pace limits assignment in the hrm file is that in the PPP SW graph,  only the programmed heartrate limits can be shown on the graph, the programmed pace limits not (yet). Probably this is a coming feature (I hope).

 

 

 

6.2   The real speed and distance management in the PPP SW

 

 

6.2.1  Ambiguity between LAPdistances and SATdistances

 

The graph of the speed as function of the time can be shown directly from the hrm data file.

 

Since no SAmpling Time distances are recorded in this hrm file, it is slightly more difficult to show the graph of the speed as function of the distance. The horizontal graph distance axis is obtained in the PPP SW by numerical Integration of the stream of transferred (sampled) speed values. They are called in this document the SATdistances (SAmple Time distances)

 

Recall:

From Section 5.3 we know that:

·         for steady paces the LAPdistances should be more accurate than the SATdistances, because the displayed instant distances are updated more frequently (POLAR feedback: “around every 2 to 5 seconds”) than the frequency the displayed speeds are recorded (minimal period =5 sec, MEM SET).

·         when a LAP contains speed cracks, the LAPdistance should be more accurate (crack latency of 9 to 11 seconds) than the SATdistance (speed crack latency 10 to 15 seconds).

 

Hence, the SATdistances should be an approximation of the displayed instant distances shown on the wrist computer. This ideal situation is visualized in Figure 4: The colored surfaces below the speed curves represent the distances accumulated during that sampling period.

 

Figure 4: On the wrist computer displayed (green) and in the PPP SW approximated (yellow) sampling period distance: ideal case.

 

The green surface indicate the distance increment at the wrist computer display during a sampling period, the yellow surface indicate the distance increment in the PPP SW during the same sampling period.

 

As result the PPP SW sometimes pop up with strange unexpected results.  E.g. if one shows in the PPP SW the LAPmarkers above the speed curve as function of the distance, then the LAPdistances (belonging to the family of the green surfaces because they originate from the displayed instant distance  -hence this is normally the most correct distance-) are put on top of the SATdistance axis (belong to the family of the yellow surfaces (hence normally approximations). Then it is possible that the LAPtime does not correspond any more to the sampling times of the sampling time distances right before and after the LAPmarker. This is shown in Figure 5 .

Figure 5 The sampling time at the cursor (vertical dashed line) shows 0:19:30, the elapsed time at the first next LAPmarker 3 shows 0:19:18

 

A possible way to solve this annoying ambiguity among the LAP- and SATdistances in the PPP SW,  is to adapt the inaccurate distance data with the most accurate distance data available. When the LAPdistance is the most accurate (this should be so),  this can  be done by changing (rescaling) slightly all the sampled running speed values contained in that LAP.  Then also the SATdistances are scaled slightly in such a way they agree with the LAPdistances.

However, due to a bug in the LAPdistance recording (S625X FIRMWARE BUG 6.1, see Section 6.3) the recorded LAPdistance is *only* more accurate in the case  long LAPdistances are recorded, and hence this rescaling procedure is not applicable: it  could overwrite the most accurate with the inaccurate distance data.  By doing this, it still  resolves the ambiguity among the LAP- and SATdistance date within one workout. But at the same time this induces even more problematic ambiguities:

1.      the over all accuracy within that workout goes down, and

2.      as result workout distance data becomes incomparable to other workout distance data.

After reading my comments on the LAPdistance recording (Section ) this will become clear.

 

In an accompanying excel sheet (Swiss Army Knife.xls, see Section 12.4) a conversion method is used that solves these distance ambiguities without creating other problems.

 

 

6.2.2  SATdistances (SAmple Time distances) in the PPP SW

 

From Section 6.2.1 we know that the SATdistances approximate the displayed SATdistances. Only in very few cases these distances can influence the real important LAPdistances (Section 6.2.3.2). So, wrong calculated sampling time distances do influence directly the graphs, but only have a relative influence on the LAPdata, unless the sampling time distances are used for other purposes (e.g. see Section 12.4)

 

PPP SW BUG 6.2 (Release 4.02.037): (a) The calculated sampling time distance at time 0 sec is for a nonzero speed at time 0 sec not zero, but between 10 to 40 meters.; (b) The way the sampling time distances are calculated does not correspond with an accurate method, e.g. the backward integration rule.

[

PROOF:

The first part:

Consider a workout at steady pace (flying start condition), shown in Figure 6.

In the graph, the cursor is moved to its most left position (red dashed vertical line). Clearly this cursor can not be moved to distance 0m. Hence, according to the cursor time value shown below the graph there is a distance already at the start of the exercise at time 0 sec.

 

Figure 6 Steady pace workout for which the LAPbutton is used to record the running time and distance.

This distance at time 0 sec can be found by clicking on the ‘overview icon’ (list, see cursor arrow on the graph window). In this list window (shown left of the graph) the distance can be displayed by selecting some options after right clicking in the table window (shown on top of the table window). The first line shows a distance of 0,019 km at time 0sec.

Whenever there is a speed at time 0sec different from zero speed, the sampling time distance at time 0sec will be not zero, as is shown in the figure.

 

The second part:

POLAR clearly implemented a relative inaccurate algorithm in the PPP SW:

·         As numerical integration method there is a Square Rule implemented instead of a more accurate trapezoidal rule;

·         The integration method itself is also implemented in the Forward direction instead of the more correct and more generally accepted backward direction. This results in the bug (a).

·         At each time sample the calculated distance increment is probably rounded off to 3 digits only (0,001km;  0,001mi).  Joris Geurts detected  that the PPP SW (and probably also the S625X) works with 16 bit signed integers (MSG 1434).

By programming this inaccurate algorithm in excel, the same distance data can be retrieved as the ones calculated within the PPP SW (which could confirm in some sense my assumptions).

The difference with the more correct backward trapezoidal rule can be observed in the following table:

Sampling speed data

Last sampling time

PPP calculated distance (forward square rule, rounded off at each sample)

Excel calculated distance (backward trapezoidal rule)

Average distance error per time sample

Difference at last sampling time

Figure 6

0:05:30

1,112 km

1,094 km

16 m

18 m

Figure 11

0:05:25

1,116 km

1,093 km

20 m

23 m

 

So, strictly spoken this is not a software bug, but the result of the choice of POLAR to implement an inaccurate algorithm (applicable for cycling speed profiles but not for running speed profiles they are really different).  For very steady runs the deviation of the PPP SW distance towards the accurate calculated one, is relative small.  When there is running speed changes involved or when the distance calculation starts, the PPP SW will deviate much with the accurate calculation.

Since there are much better and more accurate algorithms available at no extra calculation power or cost, I feel this is a design flaw that should be corrected in an update of the PPP SW.

]

 

If you don’t know the FSR (Forward Square Rule) and BTR (Backward Trapezoidal Rule), you can find more information on this in an answer to Joris in MSG 1435.

If the same integration rule is implemented in the S625X, the same holds for the calculated LAPdistances in the S625X. I have no proof, but I feel the Lapdistance bug S625X FIRMWARE BUG 6.1 is partially due to this inaccurate algorithm.

 

 

 

 

6.2.3  LAPdistances in the PPP SW

 

6.2.3.1  Originally measured and recorded LAPdata

 

The LAPdata can be shown in a separate window if you click with your right button on the curve, select ‘laptimes’, and then select the second tab ‘speed’.

Then you will get a speed data window which looks like this (I changed the titles to make the meaning of the columns clear):

 

 

 

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,935

11,935

1,575

1,575

2.

0:14:36,5

0:06:50,7

13,1

4:22

13,413

12,629

1,565

3,140

3.

0:19:18,1

0:04:41,6

6,0

9:29

6,134

11,039

0,494

3,634

4.

0:20:26,7

0:01:08,6

12,8

5:27

10,065

10,981

0,210

3,843

 

The values colored red are originally recorded values. The values in blue are calculated from the red ones in the PPP SW.

 

PPP SW BUG 6.3 (Release 4.02.037) The LAPpaces are calculated correctly, the LAPspeeds not.

[

PROOF: A correct calculation of the LAPspeed and LAPpaces (column 5 and 6) based on the LAPdistances and LAPtimes (columns 2 and 8, I calculate up to a second, so I used the LAPtimes

0:07:46

0:06:51

0:04:42

0:01:09

  ):

 

LAP

Correct LAPspeed km/h

Correct LAPpace min/km

1

12,17

04:56

2

13,71

04:22

3

6,31

09:30

4

10,96

05:27

 

One notice the LAPpace is calculated correctly, the LAPspeed not... Also the workout speed (colored in purple) is wrong (it should be 11,28km/h).

]

 

 

PPP SW BUG 6.4 (Release 4.02.037). The LAPdistances (second last column) differ (purple font) from the ones recorded in the wrist computer and transferred to the HRM file.

[

PROOF: The LAPdistances can be observed in the hrm-file section [IntTimes]. There the LAPdistances are:

LAPnr

LAPdistance

1

1,575

2

1,565

3

0,494

4

0,210

 

In Release 4.02.037 the LAPdistances are shown as:

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,940

11,940

1,575

1,575

2.

0:14:36,5

0:06:50,7

13,1

4:22

13,406

12,628

1,564

3,139

3.

0:19:18,1

0:04:41,6

6,0

9:23

6,200

11,055

0,490

3,639

4.

0:20:26,7

0:01:08,6

12,8

5:34

9,836

10,982

0,205

3,844

Clearly the three last LAPdistances differ from the hrm file data.

This behavior is not recurrent: i.e. for some workouts there is no difference between the recorded hrm file LAPdistances and the ones shown in the PPP SW Release 4.02.037; for others there are differences.

 

Most probably the LAPdistances in the PPP SW (used in the LAPtimes window and in the graph) also depend on the sampled speed values: This can be shown as follows:

·         A modification of  the LAPdistances in the hrm file (section [IntTimes] ) outside the PPP SW, will not always result in a change of the reported LAPdistances in the PPP SW;

·         A modification of the sampled speed values in the hrm file (section [HRData], e.g. by replacing it by 2/3rd of its original value) outside the PPP SW, will often result in a change of the reported LAPdistances in the PPP SW.

The speed at the accumulated LAPtime does not have that influence. But the average LAPspeed and LAPpace also are influenced in the same way because they depend on the LAPdistance.

As result, except from the first four columns, the speed and distance values in the LAPtimes window and the LAPmarkers in the graph are not always related with the LAPdistance data in the field [IntTimes] of the hrm file.

 

If one traces back the previous PPP SW releases, one can clearly observe different behaviors on this issue.

I haven’t found a proper reason for that specific behaviour.

]

 

If you select the first tab ‘heartbeat’, you get limited speed and distance data (Release 4.02.034 and 4.02.035 data):

LAP

Accumulated LAPtime

LAPtime

Heartbeat at acc. LAPtime

Max HB in LAP

Average HB in LAP

Min HB in LAP

LAPdistance

km

LAPpace min/km

1.

0:07:45,8

0:07:45,8

158

159

154

144

1,575

4:55

2.

0:14:36,5

0:06:50,7

164

175

169

158

1,565

4:22

3.

0:19:18,1

0:04:41,6

116

170

129

113

0,494

9:29

4.

0:20:26,7

0:01:08,6

138

138

120

115

0,210

5:27

 

If you observe the popup window when you put your cursor on al LAPmarker you see the following data:

Time: accumulated LAPtime

LAPtime

LAPdistance

LAPpace

Heart beat at accumulated LAPtime

Average HB in LAP

LAPspeed

 

 

 

6.2.3.2  Other LAPdata manipulation

 

It is clear that the accuracy of the measured LAPdata should be maintained when manipulations on these data are done within the PPP SW:

1.      When an additional LAP is created in the PPP SW, the LAPdistance and LAPtime of that additional LAP and the split LAP has to be to be recalculated properly.

2.      When an originally recorded and transferred LAP is deleted, the next LAPdistance and LAPtime have to be recalculated.

3.      When speed spikes are filtered out in the PPP SW, the corresponding LAPdistance has to be corrected by the calculated difference in sampling distances imposed by flattening the speed spike.

 

 

6.2.3.2.1 Adding a LAP

 

Assume the following LAPdata transferred to the PPP SW

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,935

11,935

1,575

1,575

2.

0:14:36,5

0:06:50,7

13,1

4:22

13,413

12,629

1,565

3,140

3.

0:19:18,1

0:04:41,6

6,0

9:29

6,134

11,039

0,494

3,634

4.

0:20:26,7

0:01:08,6

12,8

5:27

10,065

10,981

0,210

3,843

 

After adding an additional LAP at time 0:09:00 in the PPP SW (right click on a graph, select ‘laptimes…’, and then push the button ‘New’) the LAPdata becomes:

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,935

11,935

1,575

1,575

2.

0:09:00,0

0:01:14,2

13,6

3:44

14,014

12,251

0,331

1,906

3.

0:14:36,5

0:05:36,5

13,1

4:24

13,270

12,639

1,272

3,177

4.

0:19:18,1

0:04:41,6

6,0

9:29

6,134

11,061

0,494

3,672

5.

0:20:26,7

0:01:08,6

12,8

5:27

10,065

11,002

0,210

3,881

 

PPP SW BUG 6.5 (Release 4.02.037) The sum of the distance of the added LAP and the remaining LAP is not equal to the old (not yet split) LAPdistance

[

PROOF:

·         Yellow background: The sum of the distance of the added LAP and the remaining LAP should be equal to the old (not yet split) LAPdistance. This is not the case: 0,331+1,272 = 1,603 (should be 1,565).

·         As result also all other calculations of both LAPs are wrong.

·         Grey background: as result  the global workout distance is changed

]

 

6.2.3.2.2 Deleting a LAP

 

Assume again the following LAPdata transferred to the PPP SW

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,935

11,935

1,575

1,575

2.

0:14:36,5

0:06:50,7

13,1

4:22

13,413

12,629

1,565

3,140

3.

0:19:18,1

0:04:41,6

6,0

9:29

6,134

11,039

0,494

3,634

4.

0:20:26,7

0:01:08,6

12,8

5:27

10,065

10,981

0,210

3,843

 

After deleting LAP 2 in the PPP SW  (right click on a graph, select ‘laptimes…’, select the second LAP and then push the button ‘Delete’);  the LAPdata becomes:

LAP

Accumulated LAPtime

LAPtime

Speed at  acc. LAPtime

LAPpace min/km

LAPspeed km/h

Average speed so far

LAPdistance

km

Distance so far

1.

0:07:45,8

0:07:45,8

12,3

4:55

11,935

11,935

1,575

1,575

2.

0:19:18,1

0:11:32,3

6,0

5:39

10,495

11,078

2,041

3,616

3.

0:20:26,7

0:01:08,6

12,8

5:27

10,065

11,017

0,210

3,825

 

PPP SW BUG 6.6 (Release 4.02.037) The sum of the distance of the deleted LAP and the next LAP is not equal to the distance of the new LAP.

[

PROOF:

·         Yellow background: The sum of the distance of the deleted LAP and the next LAP should be equal to the distance of the new LAP. This is not the case.

·         As result also all other calculations of this new LAP is wrong.

·         Grey background: as result  the global workout distance is changed

]

 

6.2.3.2.3 Filtering speed spikes in a LAP

 

Every speed spike result in an extra accumulation of distance of the LAP in which the speed spike occurs. By observing the sampling speeds one can calculate the effect on the distance if the speed spike is removed. It can be verified that the new LAPdistance is equally reduced by that amount of speed spike related distance.

 

In Section 13.2 it is shown what the impact is of speed spikes on the distance accuracy.

 

At this time (release 4.02.037) the speed spike removal has to be done manually. Right click on a speed graph which contains spikes; select the pull-down menu <Copy>; <Error Correction>.  You get a popup window as is shown in Figure 7 .

Figure 7 Speed spike removal

 

Select in that window the TAB<speed>; in this TAB  you can use the arrows left and right to move the cursor on to a spike (left of figure), and click below the spike to cut it off (right of figure). Then press on the button ‘accept’ to accept the spike cut off.

 

 

Summarising:

·         accuracy is lost if one adds, deletes or modifies  LAPs in the PPP SW;

·         the accuracy is preserved if one deletes speed spikes in the PPP SW

 

6.2.4  Total distance ambiguity in the PPP SW

 

The distance reports of two different workouts are shown in Figure 8.

Figure 8 All distance reports of two workouts collected

In the colored exercise commentary boxes below the graphs, the total accumulated Laptime is shown (i.e. the end time of the StopWatch).  Also a total workout distance value is shown.

PPP SW BUG 6.7 (Release 4.02.037) The total workout distance shown in the commentary boxes below the graph is sometimes the cut-off value of the accumulated LAPdistance and sometimes the cut-off value of the distance at the last sample time. Since both distances can have big differences, this distance report is ambiguous.

[

PROOF:

See Figure 8.

Workout to the right: the PPP SW total distance report below the graph shows 9,3km. The accumulated LAPtime is 9,328km (LAPtimes window, <speed> tab) and the last calculated sampling time distance is 9,195km (last listing table distance value).  From this one can assume the displayed distance is the cut-off value of the accumulated LAPdistance.

Workout to the left: the PPP SW total distance report below the graph shows 10,8km.  The accumulated LAPtime is 11,151km (LAPtimes window, <speed> tab) and the last calculated sampling time distance is 10,805km (last listing table distance value).  From this one can assume the displayed distance is the cut-off value of the accumulated LAPdistance.

]

 

 

6.3   The real speed and distance management in the S625X

 

6.3.1  Distance leaks

 

There are two kind of situations for which an underestimation of the run distance occurs.

1.      at speed cracks

2.      when you stop the recordings.

 

6.3.1.1  Underestimation of the real distance due to speed cracks

In Section 5.1 it is shown that the measured and displayed speed not always follows instantly the body speed.  At speed cracks there is a latency of around 10 sec before the displayed speed is synchronized with the body speed. This result in an underestimation of the measured distance. A detailed discussion of this issue is given in Chapter 8; also a graph that represents the distance leak for different sorts of workouts given in Section 8.2.

Such distance underestimations often occur and infuence both the LAPdistances and SATdistances.  The LAPdistances should give more accurate distance data since distances in the S625X are updated more frequently than the SATdistances (which depend on the MEM SET update frequency). 

Hence it is important to be aware of it. Some real life examples:

·         when you run for 2000 meters at steady pace on a 400m track, and when you start form a stand still position, your first manually measured LAP will have a significant lower measured distance and than the other manually measured LAPdistances.

·         When you run in the city a specific trip, then you will measure a significant lower trip distance report in your PPP SW when you have to stop several times at red lights.

·         When you calibrate your speed sensor from and to a stand still position at a certain marker, you will underestimate the real distance between the markers. You can fade this underestimation out by doing a very long calibration run in order to move to the right of the graph shown in Figure 19.  This raises the accuracy of your measured calibration distance.

 

6.3.1.2  Underestimation of the real distance due to stopping the StopWatch

An exercise recording is paused by stopping the StopWatch with the STOP/HALT button (lower left button). With this the registration of the sensor values at the sampling times can not proceed, and the accumulated distance ran so far freezes at the display. The other sensor values (speed, pace, heart rate are still continuously measured and displayed Then two things can occur:

·         Press the LAPbutton: then the Stopwatch continues and the recordings will proceed from the time the STOP/HALT button was pressed. Also the frozen distance value at the display is released and changes again as function of the measured speed on the display. This is shown in Figure 9.

Remark that the real time recording facility does not work correctly when the Stopwatch continues after it was paused. This is because in the hrm file the real time is recorded at the StopWatch time stamp 0s only (timing firmware bug?).

Figure 9 Effect of pausing and continuing the StopWatch on the displayed distance and speed

 

·         Press a second time on the STOP/HALT button: Then the exercise is stopped and the displayed frozen instant distance is stored at that StopWatch time as the ‘Exec. Dist.’. Also a last LAPrecord is taken, which stores the ‘LAPtime’ (=total workout time) and the ‘LAPdistance’.  This principle is shown in Figure 10.

Figure 10 Effect of stopping an exercise on the recorded LAPvalues and sampling speed

Since it is most unlikely that stoptime corresponds to a sampling time, there is a distance leak in the SATdistances at the end of the recording process.  As long as these data are only used for graphing, this kind of distance leak will not influence the relevant numerical LAPdistances.  By setting the MEM SET on 5 sec, the SATdistances leak at the end will be small, and for long runs totally faded out.

 

 

 

6.3.2  Firmware bug:  LAPdistance recording

 

Consider Figure 6. This is a workout at steady pace (flying start condition) for which at only one time the LAPbutton is used i.e. to record the exercise time for a pre-specified distance.

Some seconds after running that pre-specified distance the STOP/HALT button is pressed two times, resulting in a second LAPdata recording.  The obtained graph in the PPP SW is displayed with the distance as horizontal axis.

 

S625X FIRMWARE BUG 6.1 Every LAPdistance is overestimated by 10 to 40 meters, depending on the speed at the time the LAPbutton is pressed (manually or by autoLAP).

[

PROOF:

Consider now an identical workout at steady pace for which around each 100m the LAPbutton Is pressed manually. The results are shown in Figure 11. Also the distance is used as horizontal axis.

Figure 11 Same steady pace workout as in Figure 6, but now recorded with multiple manual LAPs around each 100m.

The cursor in this graph is placed at the last recorded speed value (StopWatch time 00:05:25).

Since the last three LAPdistances are placed far beyond the last calculated sampling time distance and hence the third and second last one do not cross the sampling time speed curve (red curve), there is something wrong. The recorded LAPdistance values can be found in the ‘laptimes’ window, shown at the left of the graph. Compare the distances:

·         at the sampling time most close to the LAPtime of LAP 11:  à time 0:05:20 distance 1,098km (to be retrieved in the table window);

·         at LAPtime 11: à time 0:05:21,9  accumulated LAPdistance 1,267km (to be retrieved in the ‘laptimes’ window).

 

 

Clearly every LAPdistance is a bit bigger than its original value calculated from the displayed distance. After summing up several LAPdistances this result in an accumulated LAPdistance (i.e. the exercise distance) far beyond the last sampling time distance. Maybe the same algorithm of the PPP SW is used to calculate distances from speeds in the wrist computer (see Section 6.2.2): I have the feeling that the inaccurate integration algorithm used in the PPP SW could be implemented even wrong in the S625X. As result an accumulation of the wrong Initial Condition at the start of each LAP could produce that excess of distance. Right or wrong, the recorded LAPdistances are not constructed correctly by the displayed distance values.

 

 

 

 

Also for the ‘autolap’-feature ‘ON’ the same conclusions hold. In Figure 12 an example is given.

Figure 12 Steady pace workout with the autolap set on 500m

 

Observe first that LAPs 18 and 19 are way out of the range on the graph, showing that the accumulated LAPdistances are very inaccurate. The last recorded and calculated sampling time distance at [0:44:05] is 8,847 km, the accumulated LAPtime at [0:44:05,3] is 9,124 km, resulting in a difference of 227 meters or more than 3%.  One can verify that for the same workout distance the more the LAPbutton is used, the higher the accumulated LAPdistance is. This is a serious accuracy problem since from Section 5.3 we know that the LAPdistances should be the most accurate ones (with regard to the sampling time distances).

In this figure one also can see in the ‘laptimes’ window that the LAPdistances never equal  500m.  Observing the wrist display during the workout it holds that the LAPbeep sounds just as every time an extra 500m was reached at the display. The excess of each LAPdistance above  500 meter could originate form the discrete addition of  the calculated distances about  every 2 seconds. True or not, when for whatever reason a previous LAP is finished beyond 500 m, the next LAP will have to be in general shorter than 500 m to make the autolap feature work as is meant to be.

 

To compare the influence of the LAPspeed on this effect, the same workout distance is also  done by hiking. The ‘laptimes’ window is shown in Figure 13.

Figure 13 Steady pace walking with the autolap set on 500m, same exercise distance as in Figure 12

 

From the above two figures one can  conclude  that the recorded LAPdistances are function of the speeds at the LAPtimes:

Steady pace workout

Average surplus distance  per LAPdistance

For running at around 12 km/h

16,5 m

For walking at around 5km/h

3,3 m

It can be verified that  the LAPdistances are more correct if around each LAPtime the displayed speed shows 0 km/h (which is impossible for steady speed workouts).

 

The results on  the accumulated LAPdistance are summarised below:

Exercise

accumulated LAPdistance

Running at constant pace 1 LAPtime

8,779 km

Running at constant pace, autolap 500m

9,103 km

Walking at constant pace, autolap 500m

8,916 km

 

 

These and other tests show that the following rule-of-thumb can be used to predict the influence of the LAPdistance bug:

Average surplus distance per LAP is about 

10 meters (for a low body speed  at the LAPtime event),

 to 40 meters (for a high body speed at the LAPtime event).

 

From this rule-of-thumb one can derive the minimal LAPdistance to be respected to obtain a certain distance (and mean speed) accuracy. E.g.:

·         if one assumes a perfectly calibrated S625X, and one wants to obtain at least a 99% accuracy for a steady high speed workout, then the minimal LAPdistance is

·         if one assumes a perfectly calibrated S625X, and one wants to obtain at least a 97% accuracy for a steady moderate to high speed workout, then the minimal LAPdistance is

Some other figures on the LAPdistance accuracy are given in Table 1  of Section 12.1.

Remark also that this calculation assumes that the accuracy is only influenced by the excess LAPdistance recording, which is in reality not the case. There are still other measurement errors etc.

It should be clear that the 97% accuracy is a ‘not calibrated’ accuracy specification of POLAR, and that this accuracy is used in the above formula for which a perfectly calibrated S625X is assumed.

 

In Section 8.1.3 it is shown that for a displayed body speed of 0 km/h  at the LAPtimes, this recorded LAPdistance accuracy problem disappears.

]

 

 

6.3.3  Firmware bug: Instant distance bug

 

In Section 5.3 and Section 5.4 it is assumed that the instant distance is also recorded at each time the LAPbutton is pressed.  This is not always the case.

 

S625X FIRMWARE BUG 6.2 Every time a zero speed is displayed:  (a) the instant displayed distance is overestimating the distance by about 30 meters;  (b) the recordings of the LAPdistances diverge with the same value with the  instant distance on the display.

[

PROOF:

The following data table collects some interesting figures of several workouts:

 

 

Column I (colored blue) shows for each exercise the accurately calculated SATdistance. This column is used as reference since for each workout (i.e. each row) a comparable reference is needed.

The columns J to P are used to compare the different workout data. Also, some important data cells are colored.

Row 2 to 5 shows running data. Rows 6 to 8 show walking data. The walking data are comparable to the running data with that difference that the walking data are most often more explicit.

Consider the running data:

·         Steady speed profile:

o        Row 2: (see top graph of Figure 18) steady speed profile, only one LAP is used. This exercise is used as neutral exercise.

o        Row 3: (see middle graph of Figure 18) same steady speed profile, autoLAP 500m is used. As already known from Section  6.3 (S625X FIRMWARE BUG 6.1) each of the 18 LAPs result in a distance error of 10 to 40 meters. As result the accumulated LAPdistance becomes 9,1km which is 289 meter (about 16 m per LAP) or 3,2% higher than the accurate SATdistance.

5.    Interval speed profile:

o        Row 4: Interval profile 440meter medium steady speed, 60meter walking speed. Each 500 meter (i.e. at the end of each  walking phase) the LAPbutton is pressed manually.  Since the body speed at the time the LAPbutton Is pressed is lower than the exercise of Row 3, the accumulated LAPdistance differ less: 157m (about 9 m per LAP)

o        Row 5: (see bottom graph of Figure 18) Same interval profile, but the walking speed is replaced by a 20 sec stand still; the LAPbutton is pressed when the displayed body speed became 0km/h. Two effects occur:

a.Since the displayed body speed at the time the LAPbutton Is pressed is much lower (0km/h) than the exercise of Row 3, there is no LAPdistance bug, and the  accumulated LAPdistance stays in line with the SATdistance (about 1 m extra per LAP due to the slower update process)

b.      The total instant distance however largely over-estimates the SATdistance: 630 meter or about 6,8% .

The instant distance becomes bigger for each zero body speed transient, but the accumulated LAPdistance not. So, the assumption that the LAPdistances stem from the instant distances on the display is wrong.

At the end of the interval workout this result in:

Ø A displayed distance of 9,23km, inconsistent with the sampling time distance of 8,6km;

Ø An ‘Exe. Dist.’ of 9,2km (recalled from the <FILE> menu in the S625X as the Exercise distance),  consistent with the last instant displayed distance.

Ø An ‘accumulated LAPdistance’ of 8,628km (recalled from the hrm file or the PPP SW), inconsistent with the instant displayed distance ‘Exe. Dist.’ , but consistent with the sampling time distance.

 

From the  running workout data of column N one could assume that the  mean error of the displayed instant  distance  per zero body speed transient is about 30 meters.

 

]

 

 

As result it is at this time not advised to catch a zero speed on the display  during any kind of workout. Every ‘temporary halt’ of the body,  every ‘sensor error’ (this displays zero speed), or even every unknown instant zero speed on the display (e.g. by taking a sharp corner) will raise the displayed instant  distance by about 30 meters; but not the recorded LAPdistance.

 

 

 

Since it is claimed by POLAR that the displayed distance is updated more frequently than the sampled speed (every 2 to 5 seconds instead of every 5, 15 or 60 seconds), and since from the previous table one can see a relative consistent  sampling time distance at the events the LAPdistances or displayed distances become inconsistent,  I  feel  that  the discussed strange distance related behaviors  of the S625X  (S625X FIRMWARE BUG 6.1 and S625X FIRMWARE BUG 6.2) are to be considered as firmware bugs.

 

 

 

 

 

 

 

7.1   Programming the S625X Exercise Set (virtual trainer)

 

The S625X embed two types of Exercise Set programming: the BasicSet (with setting ‘Int OFF’) and the IntervalSet (with setting ‘Int ON’).

If you don’t want to do a programmed workout you can select the BasicUse option (template E0).

There is a possibility to have five programmable templates stored in the S625X (E1-E5, each of them can be a BasicSet or an IntervalSet). At the start of a workout (before starting the stopwatch running) a selection can be made between one of the programmable templates E1-E5 or the BasicUse template E0: this is done by press-and-hold the upper right button.

 

The programming of the Exercise Set E1-E5 can be done in the S625X (in <Options>; <Exercise SET>) or in the PPP SW (via <Connection with heartrate monitor>). In the PPP SW a database of programmed exercises can be made.

 

Figure 14 summarizes the basic programming steps of the Exercise Set of the S625X:

Figure 14 Programming of the virtual trainer Exercise Set E1-E5 of the S625X. The Interval setting can be interpreted as a virtual Timer2: beside the countdown time, also a target Heartrate, target Distance and a Manual key press can be used to start the transition to the next phase.  Also the Recovery can be interpreted as a virtual timer too (Countdown timer and target Heartrate defining the transition). Timers and Recovery (except Interval) are the only items that can be set ‘OFF’ also.

 

7.1.1  Virtual trainer “BasicSet”

 

The first programming feature in the BasicSet are the (countdown) three Timers. The three timers can be set independently of each other. Timers just ‘beep’ and do not involve any additional recording of sensor data.  At the start of the first Timer the S625X beeps once, at the start of the second Timer the S625X beeps twice,

Ø       During a workout the Timers act in a carrousel. I.e. when Timer1 is set ON 1min and Timer2 is set ON 3min and Timer3 is set OFF. During StopWatch running the timers are activated like Timer2, Timer2, Timer1, Timer2…

 

The other programming feature in the BasicSet is the Limits. There are also three different sets of Limits that can be set (Limits1, Limits2, and Limits3).  The limit type can be ‘HR’, ‘% of HRmax’ or ‘Pace’.  E.g. if one selects as Limits1 type “HR’, one has to set the high (LimHIGH) and low (LimLOW) threshold values.

It is not possible to set a different Limit type for the three limits, so once you choose for Limits1 ‘HR’, the type for Limits2 and Limits3 is also ‘HR’.

Ø       To change the Limits during a workout you need to press-and-hold the upper right button. This selects the next Limits set.

Ø       When a measured values is above or below the threshold values of the active Limits (1, 2 or 3), there are three kinds of feedback:

à      the S625X ‘beeps’ continuously.  If value<LimLOW,  low pitch beeps are produced. If value>LimHIGH,  high pitch beeps are produced. The beeps can be set off/on by press-and-hold the upper left button.

à      the lower part of the display is reserved for the visualization of the measured Limits values:

                                                                                                    i.      A ‘+’ sign  indicates the measured value is above LimHIGH. The value shown after the sign is blinking

                                                                                                  ii.      No sign indicates the value is within the Limits zone. Then the value shown is not blinking

                                                                                                iii.      A ‘-’ sign  indicates the measured value is below LimLOW. The value shown after the sign is blinking

à      The right part shows an arrow beside the UP-button if the measured value is above LimHIGH; it shows an arrow beside the DOWN-button if the measured value is below LimLOW.

 

Several people experience that the feedback of the important signs  ‘+’ (↑) or ‘-‘ (↓) is too small to be useful. Also the pitch of the audible feedback does not provide enough resolution to hear a difference. Several recommendations are suggested  to improve this weakness (see the Wish List thread MSG 585 of member joris_g, and MSG 596).

 

It is not possible to couple Timers and Limits in BasicSet. It would be a good idea if POLAR would create the possibility to let the runners choose themselves if the limits are to be coupled with the timers or not in BasicSet.

 

 

There are also Summary Limits in BasicSet, but they only have a background reporting and no instant guidance functionality.

There is also a possibility to select the Recovery Type which acts a virtual timer, and defines the end of the Recovery phase: time based (act as a countdown timer) or heart rate based (threshold value  to be reached). During the recovery the heartrate or running speed is not sampled and stored on the timeline. Only the decayed value (time, heartrate) is stored.

Ø       If you do another recovery calculation, the previous recovery information will be deleted. So, per workout there is only the latest recovery saved.

 

 

Figure 15 shows a graphical representation of the influence of the above settings during a BasicSet workout. 

Figure 15 Graphical representation of the instant BasicSet guidance and the heart rate recording in the S625X. The colours used are similar to the colors used in Figure 14. The arrows at the S625X pictures show the buttons to be pressed to obtain the transitions shown with similar arrows having the same color. The different beeps (short, long, single, double …) feedback the user which kind of new state the virtual trainer starts.

Ø       During the recording, the upper, middle and lower line of the display can be set individually:

o        The middle line can be set by a press (several times eventually) on the lower right button;

o        After the middle line is set, the upper line can be set by a press (several times eventually) on the upper right button;

o        The lower line can be set by a press-and-hold (several times eventually) on the lower right button. If Pace is set as limits type and if the instant measured signal is within the limits range, the lower display line can show the instant  ‘HR’, instant ‘% of HRmax’, ‘HRmean’ or instant ‘Pace’. If Pace is not set as Limits type, the instant pace can not be shown on the lower line.

If one runs out of the active limits set, the lower line shows the offset value: