WatchUSeek Watch Forums banner

1 - 20 of 39 Posts

·
Registered
Joined
·
39 Posts
Discussion Starter · #1 ·
Hi Ambit afficionados,

I saw your thread https://www.watchuseek.com/f233/abmit-route-distance-anomalies-707798.html where some wonder why the distance obtained on the Ambit differs from the one if the track is reimported to SportTracks/RubiTrack/.... (The Ambit being always shorter than SportTracks/RubiTrack/....). Did you guys get over that small issue, or are you still interested to know what explains this difference?
 

·
Registered
Joined
·
223 Posts

·
Registered
Joined
·
39 Posts
Discussion Starter · #3 · (Edited)
Still interested.
Ok, good. Before revealing how I did understand the issue, I propose that you send me via PM an Ambit log file in xml format (zipped) of one (or few) of your track. I will send you back a gpx version of it (thanks to joelc for it's python script), and you tell me what you think about what SportTrack/RubiTrack/... says about it. Ready to play? :p
 

·
Registered
Joined
·
223 Posts
Ok, good. Before revealing how I did understand the issue, I propose that you send me via PM an Ambit log file in xml format (zipped) of one (or few) of your track. I will send you back a gpx version of it (thanks to joelc for it's python script), and you tell me what you think about what SportTrack/RubiTrack/... says about it. Ready to play? :p
OK you got it, or a link to it. I'm not sure you can attach files to a PM. Anyone know if that's possible?

Anyway, you have a link to a log.
Here is the results from Ambit vs Sporttracks

Ambit Watch: 10.0
Movescount: 10.07
Ambit Track imported into SportTrack: 10.24


Oh and I've use joelc python script too.

Update:
oops... I see the attachment button now. sorry...

Update #2:
Nope, nope, I only see the attachment button in the advanced forum post window, don't see it in the PM window. So question still stands.
 

·
Registered
Joined
·
223 Posts
For sure, I would not have chosen my pseudo if I would not have ;-)
If you read French, you can read the detail of my investigations here, written episode wise (I have also a life !):

Du calcul de la distance sur la Suunto Ambit - Kikourou
Thanks so much for sharing your investigation! I don't read French but thank goodness Google does and I think it did a good enough job for me follow your work (I hope).

I had noticed that the distance numbers reported in the logs did not change with each second of log data. I even thought there must be a key to when the number jumped, but I didn't spend the time to investigate it further. Did you figure that out? If you did I must have missed it.

So, does this boil down to a simple case of rounding of the meters? Seems rounding could go either way making the distance longer or shorter. I've always thought the distances to be short. Maybe I missed the part where you explained that and if so please forgive.

Nice work and if you'd like to explain further, please do!
 

·
Registered
Joined
·
39 Posts
Discussion Starter · #9 · (Edited)
Thanks so much for sharing your investigation!
Nice work and if you'd like to explain further, please do!
Yes, I will make a short summary in english in this post, just give me some more days to write that up.
In very short, Suunto's algorithm to compute the distance is to retain only a small fraction of all logged data, the distance between two retained GPS fixes being > 2*EHPE (this is the key you missed, but I did not yet come to this point in the french write up, Watchuseek get's the scoop first!).
In that way, it approximates a smoothing of the track, to "cure" the notoriously bad GPS accuracy of the Ambit.
When you import the original track to SportTracks, SportTracks computes the distance as the sum of distance between all logs (every second).
And because the original track resembles that of a drunken driver, it gets the distance too long (this is best sen for tracks in dense forest).
So the distance computed by the Ambit is finally closer to reality, except when in dense forest and with lot of turns, where the "filtered" track will cut corners.
 

·
Registered
Joined
·
1,134 Posts
For convenience, here is the link with translation to English:
Google Translate

Indeed, the logged distance in the xml file is updated every few seconds, and not with every track point. Looks like it could be every 3,4 or 5 in this quick check I did. Apparently it can be even less often.

(See if I get all this right, ambit_cracker)

So, effectively the Ambit distance is a "smoothed" (or "filtered") value. SportTracks, etc, would use every point as logged.

You can see the "quantized" steps in the this chart of xml distance vs xml time.
As ambit_cracker says, the Ambit distance is then computed only when the distance is updated. He shows the calculation at the link. And so any in the tracks points between these distance updates are not captured in the distance (whether they be accurate positions or not). Upon upload to Movescount, the Summary and in-watch distance is used, and not recomputed from the raw track points.

This choice works well when there is more GPS track point error and the true track is straighter. It works less well when there is less GPS track error and the more zig-zaggy the true path is within the 3-to-5-7 second time frame.

Since the pace and distance in the Ambit are intertwined with both the GPS data and Fused Speed, I wonder if this choice is a consequence of that algorithm.
If anyone has a log with 1sec and FusedSpeed Off, does that show any different distance logging behavior? (increment every second vs every few seconds)


Ambt XML distance.jpg
 

·
Registered
Joined
·
39 Posts
Discussion Starter · #11 · (Edited)
Indeed, the logged distance in the xml file is updated every few seconds, and not with every track point. Looks like it could be every 3,4 or 5 in this quick check I did. Apparently it can be even less often.
(See if I get all this right, ambit_cracker)
I just repeat what I said:
the logged distance is updated every time that the distance to the last update exceeds 2*EHPE (info not yet on the french post). The proof (here, Y abscissa represents distance between consecutive logs retained by the Ambit for distance calculation) in the attache image.
And concerning your suspicion about FuseSpeed, the test has been done by a guy on the french forum, no difference. Seems that FuseSpeed is only used for speed, but not for distance calculation.
 

Attachments

·
Registered
Joined
·
41 Posts
For convenience, here is the link with translation to English:
Google Translate

Indeed, the logged distance in the xml file is updated every few seconds, and not with every track point. Looks like it could be every 3,4 or 5 in this quick check I did. Apparently it can be even less often.

(See if I get all this right, ambit_cracker)

So, effectively the Ambit distance is a "smoothed" (or "filtered") value. SportTracks, etc, would use every point as logged.

You can see the "quantized" steps in the this chart of xml distance vs xml time.
As ambit_cracker says, the Ambit distance is then computed only when the distance is updated. He shows the calculation at the link. And so any in the tracks points between these distance updates are not captured in the distance (whether they be accurate positions or not). Upon upload to Movescount, the Summary and in-watch distance is used, and not recomputed from the raw track points.

This choice works well when there is more GPS track point error and the true track is straighter. It works less well when there is less GPS track error and the more zig-zaggy the true path is within the 3-to-5-7 second time frame.

Since the pace and distance in the Ambit are intertwined with both the GPS data and Fused Speed, I wonder if this choice is a consequence of that algorithm.
If anyone has a log with 1sec and FusedSpeed Off, does that show any different distance logging behavior? (increment every second vs every few seconds)


View attachment 764770
I have been using the Ambit in my walks (relative open, mostly flat suburban streets) for several months and comparing it to my other GPS watches (Garmin FR110 and FR405cx and a Timex Run Trainer) and my Garmin Etrex 30 handheld. I have few measured tracks (Google Earth and my Car's Odometer) and in general the Etrex had been proven very accurate. The Ambit seems to me to have a fairly sensitive GPS and is much better in acquiring and maintaining lock than the other watches, and sensitivity wise, is nearly equal to the Etrex. On the otherhand, all the watches (both Garmin and Timex) measure the distance within 1% of the actual one. Also, their logged tracks are smooth and match fairly accurately the real track when viewed in Google Earth. The Ambit (firmware 1.5.10) shows the following behavior:

1. When worn as a watch, the track looks very wiggly with a strange and periodic lateral deviation from the actual path. The measured distance is generally 2-3% over the actual distance.

2. When carried in my pocket in a fairly stationary position, the track is much smoother (not as smooth as the other watches or the handheld, but close enough) and the measured distance is less than 1% (on the low side) of the actual one.

3. This behavior is nearly independent whether the FusedSpeed is enabled or not. I tried it in the "running", "walking", "trail running" and "trekking" modes with similar results.

Clearly, one cannot measure the distance in a brute-force way, by adding all the 1 sec measured differentials. However, Garmin (and even Timex) managed to filter the data in an inteligent manner that results in both, a smoother and accurate track and a more accurate distance calculations.
 

·
Registered
Joined
·
39 Posts
Discussion Starter · #14 ·
Clearly, one cannot measure the distance in a brute-force way, by adding all the 1 sec measured differentials. However, Garmin (and even Timex) managed to filter the data in an inteligent manner that results in both, a smoother and accurate track and a more accurate distance calculations.
You sum it up nicely. What my investigation shows, is that Suunto too did manage to filter the data in an intelligent manner, too bad they don't provide the filtered gpx file that I could create by changing slightly joelc python script.
 

·
Registered
Joined
·
223 Posts
You sum it up nicely. What my investigation shows, is that Suunto too did manage to filter the data in an intelligent manner, too bad they don't provide the filtered gpx file that I could create by changing slightly joelc python script.
I wanted to say thanks again for sharing and did you say how you filtered the data before to make the distance to come out closer to what we'd expect?
 

·
Registered
Joined
·
39 Posts
Discussion Starter · #17 ·
A few examples of Ambit tracks from french forum colleagues (I don't have an Ambit ;)():

kikous.GIF

D: distance in km
ST: SportTracks(2)
CG: Course Generator - DPSite - Course à pied et technologie
1s: original Ambit xml data
filtré: my filtered xml data
ST 1s/Ambit %: difference in % between distance computed by Ambit and ST from original file
ST filté/Ambit %: difference in % between distance computed by Ambit and ST from filtered file

You can see for some tracks of runs in moutains with wood coverage, the difference between distance computed by Ambit and ST from original file can reach 23% ;-(
And I have arguments to demonstrate that these 23% are not due to no taking account of steep slopes in the distance calculation, because neither Ambit, nor ST does so.
srwilson, you are really on the least problematic side of the issue. Using the filtered file, ST is in agreement with Ambit, but that is no surprise by the method used.
Two out of the 13 files suffered from "Wild Phubar" effects, but by correcting by hand the distance using info from xml log, everything agrees well.

When the difference between distance computed by Ambit and ST from original file is below 5%, I would say Ambit distance estimate is quite accurate.
But when it reaches 23%, there is a good chance the Ambit underestimates the distance. By how much (1%, 2%, 5%), no way to know for sure :-(
 

·
Registered
Joined
·
47 Posts
For people willing to go deeper in current investigation, I have just published version 1.4 of ambit2gpx.py python script, with a new option --suunto (changes of the script for supporting this new option have been provided by ambit_cracker, thanks goes to him!). With this new option, script is producing the filtered gpx track used by Ambit for measuring distance.

ambit2gpx.py 1.4 is downloadable from here: Downloads - ambit2gpx - conversion tool from suunto ambit xml format to gpx format - Google Project Hosting
 

·
Registered
Joined
·
1,134 Posts
Hi.
got to thinking about this thread. Crackin' good job, ambit_cracker.
Anyway, I can now see 3 sources of distance errors from the Ambit:
1. Raw accuracy of recorded track points. Could make the track either longer or shorter depending on how they occur. All GPS will have this, and it's purely a function of accuracy. A straight route with errors will get measured Long, and turns with errors often gets measured Short.
2. The 2*EHPE method only keeps 1/N track points - maybe 1/3 or maybe 1/7 depending on the EHPE value at the moment. This will introduce errors primary going round turns, by cutting them diagonally.
3. The 2*EHPE method is applied even at the end of the run, so some of the final track points usually are omitted. The error will be 0 to 2*EHPE. Maybe on a short run with 'poor' reception it could be another incremental fraction of a % in pace or distance.

Sunnto should fix #3. This is a pure bug IMHO. Small... but to those Suunto engineers, it ought to matter.

#2 could be addressed with an improved algorithm, so I tried a few things which I though might help on turns.

My first method was to use the GPS_Heading value logged in xml, and look for changes which indicate a turn. But that doesn't work, because it's actually a trailing value that seems to be an average of the past 10 or so seconds. Nice and smooth, but since it's not instantaneous it doesn't help identify turns.

So my second approach was to raw calculate the instantaneous heading from the current and previous track point. It's a "noisier" (fluctuating) value for sure. But if you pick a high enough value for the "change in heading" you can generally identify real turns within about the first 1-3 seconds. At least in the one track I tried, running at ~9:00min/mile.
Of course I still include all the track points captured normally by "2*EHPE."

Visually here's what it does:
Red is all the raw track points: SportTracks computes the distance as 4.07miles
Blue is my algorithm: Include "2*EHPE" points, my "turn" points (anything >= 0.27 radians/second), and the final track point (which added about 18 meters). SportTracks says: 4.04mi
Green is the Ambit filtered track points: Only 2*EHPE points. SportTracks says: 4.01miles

What's the absolute truthful total distance? No clue, but at least now the round turns aren't chopped so much.
How'd I pick 0.27 radians/second. Umm, because 0.3 missed a few of the first points in a couple turns in my log file. :)

This run was an out & back, and I didn't turn in place and you can see in the second picture that the Red and Blue lines capture that rounded turn a bit better.

Oh yeah, the Raw track point count was about 2200. The ambit filtered it down to about 500. My algorithm added back about 150.

3 Track summary.jpg
RW Red Raw Blue 027 Green Ambit.jpg
BCL Red Raw Blue 027 Green Ambit.jpg

Honestly, I try not to live my life counting the last fraction of a percent... but this was really just a kind of strange way for me to have some fun, and refresh my Excel trigonometry skills.
 

·
Registered
Joined
·
39 Posts
Discussion Starter · #20 ·
Nice additional study, or_watching. In your case, it is kind of nit picking, but it would be nice to see what it would give on "Paulotrail bauges" track I cited yesterday, where the Ambit/ST dichotomy is 23%.
 
1 - 20 of 39 Posts
Top