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.
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"
