Recently on a thread I can no longer find, hardy and slowboat were discussing slower 2sec readings in realspeed. Slowboat thought it may be a bug, so I've had a look at my best track, and I agree.

The earlier version of realspeed (v 1.911) gives the same result as gpsarppro but version 1.918 and later, (up to 1.925) give slower results.
Here's what I've found.

My original results from 1.925. 2sec doppler 35.164, trackpoint 35.22, display 35.47.

gpsrpro 2 sec doppler 35.37 tracks table shows doppler 35.26 35.48 then 34.44, prior to 35.26 is 34.39

Realspeed version 1.911 2sec doppler 35.368, min 35.261 max 35.475


RS ver 1.918, 2sec doppler 35.164 min 34.445 max 35.475

notice that on 1.911 max and min speeds are the same as gpsarpro trackpoints doppler table, 35.26 and 35.48, and the result is the same.
But RS version 1.918 has the same max speed, 35.475 but a very different minimum, this is the number after the max speed, 34.44.
So it seems to me that this version is finding the highest figure then using the following figure, as minimum, instead of also evaluating the preceding number.

Time machine are you here, any thoughts???

Woops I suppose I should check to see if there is a later version than 1.925, Mal might have already fixed this.
Be back later if there is.

Thanks Nebs, yep, that's the one.

checked for latest version of realspeed and it's still 1.925.
sent an email off to Mal so hopefully we'll get an expert opinion on this

Guys, I suspect the change of result is due to a correction in the doppler algorithm some time ago. When calculating speeds from trackpoints, each trackpoint speed is an average speed between trackpoints based on a calculated distance over the time interval. This is the best measure of speed from location data.

However for doppler, each speed measure is a sample, so the better calculation method is to average the result of each interval by adding two consecutive samples and divide by two to find the average speed between those samples. Take the following example:

40, 42, 43 (wishful thinking in these windless days I know...)

The two second result should be calculated as follows:
((40+42)/2 + (42+43)/2) / 2 = (41+42.5)/2 = 41.75

If I had used the old method it would be (42 + 43) / 2 = 42.5.

If you find a result different to the one detailed above then please let me know.

Hi Mal,

With the example you gave above, is each sample taken one second apart? So the 2 second speed could be taken as (40 + 43) / 2 = 41.75?

I haven't run into this issue (not really that fussy about the extra tenth of a knot) but it's certainly something that others have complained about.


While we're on the subject, any chance of refining the 1 hour algorithm? At the moment it looks like Realspeed starts at point 1, adds up the next 3600 samples, and stores that number. Then, it starts at the point 2 and adds up everything up until sample 3601. And again for point 3.
So most points in a track are added up many thousands of times...

I think you could possibly speed it up by taking the difference between point 1 and 2 off your accumulated total, then adding the difference between points 3600 and 3601.

Obviously you'd need to restart this process if there was a dropout or an invalid point, but I think that even if you used this 'sliding window' algorithm for only ten points, then reset, you would speed up the calculation by an order of magnitude at least.

en.wikipedia.org/wiki/Running_average

Mal,

Are you saying that what the other programs say is a 2sec ave is only 1sec? That is if a doppler sequence of 41 42 43 by taking 42 and 43 and getting 42.5 you are averaging 2 instances of time 1 second apart rather than as with trackpoint (as these programs originally were written for) the 42 and 43 represents the average for the previous 1 second time period.

Mal thats a 4 second average. Its effectively sum (n)/4.

Select to expand quote

nebbian said...

Hi Mal,

With the example you gave above, is each sample taken one second apart? So the 2 second speed could be taken as (40 + 43) / 2 = 41.75?

I haven't run into this issue (not really that fussy about the extra tenth of a knot) but it's certainly something that others have complained about.

>>>>>>

Don't think so Nebs, I think Mals example simplifies things, my case is 35.26, 35.48, 34.44.
If you take 35.26 and 34.44 the highest result is ignored.

And yes calculating using Mals new method I get the later realspeed result.

I'll let the technical experts fight out the merits of the method.

Select to expand quote

slowboat said...

Mal thats a 4 second average. Its effectively sum (n)/4.

mmmm.... i disagree:
in a data sample:

40...42...43 , recorded at t=1, t=2, t=3 respectively

The average for 2 seconds, around the point "42" is found by:
(42 + 40/2 + 43/2)/2
This is the same as from mal's formula, a 2 sec average in the interval from t=1 till t=3

Using the other (old) method of calculation only considers a data sample with two data points, over the interval (using sample above) t=1.5 to t=3.5, giving (42/2+43/2)
this still consders a 2 sec interval, but has reduced accuracy, due to fewer data points....

ok i hope thats right...

nope. If the data set is filtered correctly* each point will represent the information in the previous second.

So for 2 seconds, you average 2 points.

When using positions to calculate 2 sec speeds, you need 3 points to calculate the distance intervals between the points. Then it is effectively taking the average speeds between the two sample intervals.

*this requires an understanding of sampling theory, nyquist critereon, and other signal processing concepts, but to summarise, if the data is not filtered correctly inside the GPS you are basically guessing what happens between the points since you have no idea what happened between those samples. The GP3S tech group has had extended arguments on the validity of this but through some persistence and testing its basically been proven to be a critical factor in the accuracy in handheld units. As a result, Locosys (GT31) are working on applying more appropriate filtering to get even higher accuracy levels.

Got no problems with it, not that anal or egotistical that I'm worried about point something (could be also that I'm not quick enough to worry about that level)

My opinion is that if you use the same program all the time then you have a level playing field with your previous results, ok it may not be precise but you can see the movement.

Just my POV, not what I think everyones should be

Real-speed appears to be calculating a 4 second average in the 2 second category for doppler. So the speeds calculated in realspeed will often read a bit lower that what you actually did.

shoot. Sorry I didnt read Mals comment close enough. He is effectively applying a filter in post processing. Its a simple symmetric finite impulse response low pass filter, which gives some smoothing effect.

This is not what is used by alternative software.

Sorry Mal and Tim, I'll rinse my eyes before reading next time!

Tim, I'm not sure that this filter improves accuracy- it depends on what information you are actually looking for. Nor does it strictly represent a "2 second average speed"

Select to expand quote

slowboat said...

shoot. Sorry I didnt read Mals comment close enough. He is effectively applying a filter in post processing. Its a simple symmetric finite impulse response low pass filter, which gives some smoothing effect.

This is not what is used by alternative software.

Sorry Mal, I'll rinse my eyes before reading next time!

Frooom, like most GPS calc discussions, flew through about a foot and a half above elmo height

Select to expand quote

Elmo said.
My opinion is that if you use the same program all the time then you have a level playing field with your previous results, ok it may not be precise but you can see the movement.

Just my POV, not what I think everyones should be

Nup, I want all the points I'm entitled too!!!! Otherwise I feel I'm being cheated.

Not to mention being anal about precision and accuracy.

Select to expand quote

decrepit said...

Elmo said.
My opinion is that if you use the same program all the time then you have a level playing field with your previous results, ok it may not be precise but you can see the movement.

Just my POV, not what I think everyones should be

Nup, I want all the points I'm entitled too!!!! Otherwise I feel I'm being cheated.

Not to mention being anal about precision and accuracy.

He said with tongue firmly planted in cheek....

Just sail quicker

Well its easy for some!!!!!!!!!!!!

Select to expand quote

Bender said...

Well its easy for some!!!!!!!!!!!!

You to can be a fat basket and sail quicker

You could also set the GPS to data record too

Thats gold just like getting a 50m penalty for naught

When ya crack 37 again I'll let it go

D'oh

Select to expand quote

Bender said...

D'oh

Sorry mate couldn't resist[}:)][}:)]

Going to hobble of to watch starwars with my beloved now

Select to expand quote

slowboat said...

shoot. Sorry I didnt read Mals comment close enough. He is effectively applying a filter in post processing. Its a simple symmetric finite impulse response low pass filter, which gives some smoothing effect.

This is not what is used by alternative software.

Sorry Mal and Tim, I'll rinse my eyes before reading next time!

Tim, I'm not sure that this filter improves accuracy- it depends on what information you are actually looking for. Nor does it strictly represent a "2 second average speed"

whoa!
"simple symmetric finite impulse response low pass filter"
lol.. thats just a bit beyond me
My interpretation of the calc was just an average based on a set of values with corresponding time values: S:=[40,42,43] and correspondingly t:=[1,2,3] - discreet values, not actual gps data.... (my knowledge of signal processing is well..... non-existant really)
I guess that as the methods are looking at a slightly different interval the accuracy couldnt really be compared properly.
Personally I'd favor mals method with data points representing the instantaneous speed, recorded once every second. For data that represents an averaged 1 sec interval, i'd probably favor the other method.