Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[abdominizer]

Hi,
I mentioned in my first impression review that the pace-algortitm in the GH-505 is different from the one in the GH-625. Pace in the GH-625 is faster to respond to changed actual pace while the pace in the GH-505 reacts slower.

I did another test of the pace yesterday running a fartlek (speedplay) increasing and decreasing my pace. I ran fast for distances of around 500m up to 1200m and slowed down in between for similar distances.

I think the Gh-505 uses a too long distance to average out the pace. My guess based on the behaviour of the pace is that a distance of about 6-800m is used for the average, Geoffrey, am I correct? Why was this changed from the GH-625? I think the pace worked fine before?

I would like the pace-algorithmin the GH-505 to be changed to the one used in the GH-625 which for me is a lot better!

Does anybody else have any thoughts about pace?

Sincerely,
Jonas

[ultrapetita]

I have not yet received my sample (however, there is now some hope already that I could receive it soon), but I would like to comment this:

I think GH-625's latest XII FW sets the standard for PACE calculation/display and if the new device can't achive at least the same performance, I would be quite disappointed... (the same or improved algorithm should be applied)

[Longjog @ GS-Sport-Servicecenter]

Hi Jonas,

a long time the Pace-algorythm in the GH625 was not useful at all. Then the idea of Pace1K came. Pace 1K always should show the Pace over the actual last 1km.
This distance is long enough to make gps-error at running speeds small enough to have reliable values of pace. But the implementation of Pace1k didnīt work as well as thought. Finaly the GS-Team implemented an other algorythm, I think based on the last 600 m, to calculate pace.
The display of GH625 refreshes the pace-values every some seconds in a little range.
GH 505 seems to be more "static" in calculation of pace. I like this because I have the feeling, the output is correct. With the GH 625 I think the "real" Pace is somewere arround the shown values.

To minimize the systematic GPS-error in Pace-calculation (at running-speeds) it is nessescary to take a long time or distance for the calculation. The longer the base for calculation is, the more true the calculated value is (the calculated AVG-pace of a 10 k race has a relative small error, because the relative error of the distance is small).

But the disadvantage of this method of calculation is, the longer the distance or time is, the less is the sensitivity.
So this method is not qualified for runs with fast speedchanging like interval-training.
Maybe an algorythm on the base of statistical methods (with sum of all errors is zero) is better than a method based on average methods? Geoffrey have you and your team examined this (something like the weighted average of last 100 (1/speed)-values)? The higher the number of samples the smaller the error.

Please donīt misunderstand. I not want to begin the discussion of pace-calculation again if the shown values are correct. I think we runners have to live with the low sensitivity because of the systematic GPS-error which is relative high at slow speeds like running-speed.

I like a static reliable value of GH505 more than a jumping around value (like GH625) I have to average myself.

Regards

Longjog

[TWG_TECH8]

Hi Jonas,

a long time the Pace-algorythm in the GH625 was not useful at all. Then the idea of Pace1K came. Pace 1K always should show the Pace over the actual last 1km.
This distance is long enough to make gps-error at running speeds small enough to have reliable values of pace. But the implementation of Pace1k didnīt work as well as thought. Finaly the GS-Team implemented an other algorythm, I think based on the last 600 m, to calculate pace.
The display of GH625 refreshes the pace-values every some seconds in a little range.
GH 505 seems to be more "static" in calculation of pace. I like this because I have the feeling, the output is correct. With the GH 625 I think the "real" Pace is somewere arround the shown values.

To minimize the systematic GPS-error in Pace-calculation (at running-speeds) it is nessescary to take a long time or distance for the calculation. The longer the base for calculation is, the more true the calculated value is (the calculated AVG-pace of a 10 k race has a relative small error, because the relative error of the distance is small).

But the disadvantage of this method of calculation is, the longer the distance or time is, the less is the sensitivity.
So this method is not qualified for runs with fast speedchanging like interval-training.
Maybe an algorythm on the base of statistical methods (with sum of all errors is zero) is better than a method based on average methods? Geoffrey have you and your team examined this (something like the weighted average of last 100 (1/speed)-values)? The higher the number of samples the smaller the error.

Please donīt misunderstand. I not want to begin the discussion of pace-calculation again if the shown values are correct. I think we runners have to live with the low sensitivity because of the systematic GPS-error which is relative high at slow speeds like running-speed.

I like a static reliable value of GH505 more than a jumping around value (like GH625) I have to average myself.

Regards

Longjog

Dear all

Let me explain the alogrithm here:

For GH-625

To calculate the total distance for 3 min at beginning; (ex.10km/hr will have around 600m)
-To get pace by 3min/dist;
-Update pace by every 3s shift (=3min/dist(3'3" to 3"));

GH-505 is same as GH-625;

Just distance calculation has little different;
GH-625 is to accumlate distance by every point;
GH-505 is by every 3 point in order to cancel GPS error, so the total distance is getting improved.

Maybe there will case pace something difference.

Sincerely,

Geoffrey

[Hubert]

Hi all,

let me add my comments to the pace discussion:

Finaly the GS-Team implemented an other algorythm, I think based on the last 600 m, to calculate pace.
The display of GH625 refreshes the pace-values every some seconds in a little range.

It's not exactly like that. I have found the latest posting by Geoffrey, where he explained:

The inital pace is base on the beginning 3 mins to calculate. (=3min/dist).
And re-calculate by every 3 sec shifting. (=3min/ dist)

This all applies to the GH-625 algorithm.

For the new GH-505 I have to admit, that I didn't take much care about the pace values
(maybe I should do next time...).  But I can tell the reason, why I didn't watch the pace:

From the long and very detailed discussion about pace for GH-625, I had to understand, that:

I think we runners have to live with the low sensitivity because of the systematic GPS-error which is relative high at slow speeds like running-speed.

In the meantime I have accepted the fact, that we have to decide whether we want to have a
* Low sensitive but rather constant value showing an average of last 3 Min. (or similar) or
* High sensitive but randomly jumping value showing an almost current value.

Both are not what I originally wanted to have and what compares to what you are used to from
higher speed moving (bike or car).

So I know, that pace won't never be perfect. However - for me the GH-625 calculation was okay.

Whatever algorithm we might have - I always will have in mind, that the shown pace is not my true pace !
And I have accepted, that with current technology it will not be possible to show an exact value.

And "exact" means for a runner to see the difference between a pace of 4:30 or 4:40 (Min./km)
And this could be very important (especially in a competition).

So as a summary, for me it doesn't matter which algorithm we use. Both are not more than a guess.

Regards, Hubert

[abdominizer]

Dear all

Let me explain the alogrithm here:

For GH-625

To calculate the total distance for 3 min at beginning; (ex.10km/hr will have around 600m)
-To get pace by 3min/dist;
-Update pace by every 3s shift (=3min/dist(3'3" to 3"));

GH-505 is same as GH-625;

Just distance calculation has little different;
GH-625 is to accumlate distance by every point;
GH-505 is by every 3 point in order to cancel GPS error, so the total distance is getting improved.

Maybe there will case pace something difference.

Sincerely,

Geoffrey

Geoffrey (and everybody else),
Thank you for explaining how pace is calculated! However, I'm a bit puzzled over how two so símilar calculations can produce so different results. At an even pace the readings of GH-625 and GH-505 are very similar (I don't think the pace of the GH-625 jumps around more than the pace of the GH-505). My major concern is that after a change in pace it takes a long time for the pace of the watches to get back to similar values. My feeling is that the pace in the GH-505 lags more and is slower to react, the pace in the GH-625 seems better at reflecting current pace. This is just an subjective feeling and I have not confirmed it with another device. Maybe someone with a bicycle computer or spedometer can test this?

I know the pace will always have to use a distance or time for averaging out the GPS errors, I don't want to go back to the pace algorithm that was in my GH-625 a year ago when it was jumping all around the place. But if the algorithm uses a too long time or distance the pace function will only be usable if your pace is constant. Even small changes in actual pace will create a pace reading in the watch that is wrong.

As I said, my feeling is that the pace-algorithm used in the GH-625 is better and I would rather have the same in the GH-505. But if other users like the GH-505 algorithm better I can live with that to. But in that case I would like to suggest implementing another pace-choice in the custom pages. A new "short pace" or maybe "pace 60 seconds" which uses a shorter time for averaging. I know this will create a pace that jumps more up and down but it will be very useful for pacing in intervals and speedplay! This would be a logical complement to the pace function that is good for pacing a steady pace race or time trial over longer distances.

Sincerely,
Jonas

[Longjog @ GS-Sport-Servicecenter]

A new "short pace" or maybe "pace 60 seconds" which uses a shorter time for averaging. I know this will create a pace that jumps more up and down but it will be very useful for pacing in intervals and speedplay!

Sincerely,
Jonas

Hi Jonas,
this short time will create such a big error, that Pace-Values will jump in such big steps you canīt use it.
To have reliable values you will need a distance for calculation around 600 meters. If you can run as fast, no problem.
You can make a test yourself: the speed is 1/pace. Take your bike and drive at a low speed of 10 km/h (=6 min/km Pace) and watch the speed in display. It is jumping in a relative big range. Than drive 20 km/h. Range is getting smaller.
Result:
You canīt use GPS-signals for sensitive pace-calculation at running-speeds.
Solution for this could be a foot-pod.
Regards
Longjog

[Hubert]

Hi Jonas,

Thank you for your suggestion: 

But in that case I would like to suggest implementing another pace-choice in the custom pages. A new "short pace" or maybe "pace 60 seconds" which uses a shorter time for averaging. I know this will create a pace that jumps more up and down but it will be very useful for pacing in intervals and speedplay! This would be a logical complement to the pace function that is good for pacing a steady pace race or time trial over longer distances.

This is (more or less) what I'm suggesting for a long time ! Here for example my last posting I remember:

... I think, that 3Min. might be too long for some situations:
For speed training I sometimes run short distances like 200m (< 50 sec.)
or 400m (< 100 sec.) and it would be nice to get a feeling of pace for those
distances too. And as you can easily see, here 3Min. are too long !

I know, that a longer distance makes the pace value more reliable.
But a shorter time applies more to the basic idea of current pace.
Basicly we want to see the pace of this moment, not of the last 3min.
So, we have to find a compromise of these two requirements.
And 3min. are not so bad... But what about 2Min. ? Or 1Min. ?

You know: My favorite solution would be a configurable value, so that users can
decide what they consider to be more important.

I know, that Geoffrey does'nt like this ("... not user friendly "). But I think, this could satisfy a lot of users.
If GlobalSat thinks, it's too complicated for users to decide whether they need a 1Min. base or a 3Min.
base for calculation, you could also offer just 3 modes and call them "Normal, Smooth" and "Very Smooth"
(or what ever you like...).

Regards, Hubert

[Hubert]

Hi all,

today I wanted to make another Pace test.
Unfortunately I mis-configured my main custom page to show the Pace Avg, instead of Pace.

During my run, I didn't notice that at once and for a long while I thought, I'm watching the pace.
And when running at a constant speed I had the feeling, that the two values (GH-625 and GH-505)
where showing nearly the same.
However - I wanted to see, what would happen, running up a hill. With reduced pace.
With a little delay, the GH-626 showed the pace getting slower (values increasing) as expected.
The value of GH-505 remained nearly constant.

On top of the hill, I could increase my speed again. But for the first 60-90 sec. the GH-625
still showed pace getting slower. This was expected, because of the averaging and the delay.
After this 60-90sec. the GH-625 showed again, that pace was getting faster (pace values
decreasing). So - that was fine.

But what about the GH-505 ?
While running up the hill, the GH-505 didn't show any change in pace. Even on top of the hill
it didn't show any other value. But then, while GH-625 already noticed, that speed was going
faster, the GH-505 slowly showed higher values for pace (slower speed).
So - I first thought (like decribed by others), the delay of the GH-505 could be almost double as
long as for the GH-625.

When running on, at almost constant speed, I later noticed, that the pace display on the
GH-505 was completely stuck. For more than 4-5km always the same value. Exactly.
I already had an idea, that it was the highest value of the run.

At the second hill, I had to run again very slowly. And: The pace value of GH-505 came
alive again ! It gathered some higher values and "saved" it. Even after the hill. The value
never came down again.

As I said in the beginning: I wasn't watching the Pace, I configured the Pace Avg value.

But: What I saw, wasn't the average. Never !  For me, it looks like the slowest pace.
And btw.: What does "average" mean ? Average of what ? Of the whole distance ?
I think so. What else could it be ?
For sure, it wasn't the average of the whole distance. This was different.

If somebody likes to test this... would be interesting !

Regards, Hubert

[Longjog @ GS-Sport-Servicecenter]

Hi Hubert,
I have watched what you are discribing with the firmware the watch was delivered with. Since installing Version 1005061 avg-funktion and Pace are working fine. 

Regards

Longjog

[Hubert]

Hi Hubert,
I have watched what you are discribing with the firmware the watch was delivered with. Since installing Version 1005061 avg-funktion and Pace are working fine. 

Thanks Longjog for your hint ! Yes - what I told was about old FW !
I finally made my FW update now and will see what has changed.

Sorry for telling a long story about already solved problems 

Regards Hubert

[abdominizer]

... I think, that 3Min. might be too long for some situations:
For speed training I sometimes run short distances like 200m (< 50 sec.)
or 400m (< 100 sec.) and it would be nice to get a feeling of pace for those
distances too. And as you can easily see, here 3Min. are too long !

I know, that a longer distance makes the pace value more reliable.
But a shorter time applies more to the basic idea of current pace.
Basicly we want to see the pace of this moment, not of the last 3min.
So, we have to find a compromise of these two requirements.
And 3min. are not so bad... But what about 2Min. ? Or 1Min. ?

You know: My favorite solution would be a configurable value, so that users can
decide what they consider to be more important.

I know, that Geoffrey does'nt like this ("... not user friendly "). But I think, this could satisfy a lot of users.
If GlobalSat thinks, it's too complicated for users to decide whether they need a 1Min. base or a 3Min.
base for calculation, you could also offer just 3 modes and call them "Normal, Smooth" and "Very Smooth"
(or what ever you like...).

Regards, Hubert

Hello all,
I like Huberts suggestion about a configurable value for averaging the pace, with this I could find a value that suits me. If this is not an option because it's "not user friendly", I would at least like to have a couple of diffrent "smoothing modes" to chose from like Hubert suggests! I have been discussing this with my runner friends and they also agree and say this would be something they would look for when buying a GPS watch.

Sincerely,
Jonas

[Roger C]

I read in Forerunner 305 manual that they have 10 different calculating pace modes depending of how fast you are running/jogging/walking, just copy/paste that thing...

/Roger

[ultrapetita]

Hello all,
I like Huberts suggestion about a configurable value for averaging the pace, with this I could find a value that suits me. If this is not an option because it's "not user friendly", I would at least like to have a couple of diffrent "smoothing modes" to chose from like Hubert suggests! I have been discussing this with my runner friends and they also agree and say this would be something they would look for when buying a GPS watch.

Sincerely,
Jonas

One vote for this! Agree 100%! This is what we have been asking for over one year.

[Longjog @ GS-Sport-Servicecenter]

We did have a long discussion about the pace and pace1K a time ago. GPS accuracy is limiting the pace-calculation. If you want to have the pace more sensitive, the reliability will be not good. I think the solution could be a foot pod, but not to have other algorythms for GPS because you canīt use them. The pace value will jump in a big range.
Regards

Longjog