ADVrider

Go Back   ADVrider > Riding > Layin' down tracks
User Name
Password
Register Inmates Photos Site Rules Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread Rating: Thread Rating: 184 votes, 4.85 average. Display Modes
Old 05-28-2013, 06:40 PM   #8071
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by guavadude View Post
So I'm looking in BC still trying to figure this out, and in the summary list of the recorded track I have one entry that is 139 miles distance and I was traveling 25,034 mph. I ride pretty quick but not that quick.

So is this just some random stuff it's adding? I'm on 4.6 software and will probably stay here until the updates get updated.

I'm also seeing a bunch of track points that are added when ever I stop but leave the unit on. Is there a better way to track? I'm currently using the Auto Track Log recording method.
Brief loss of satellite signal resulting in GPSr thinking you were instantly 139 miles from where you actually were, and the time between recorded samples leaves the Montana with little choice other than to suggest you were travelling at MACH 40.


No method exists at this time to prevent the spider webbing of the track log when stopped, other than manually stopping and restarting the recording.

The new Garmin Oregon 6xx series has a new 'AutoStop' feature that detects when you have stopped, and stops recording track log points until you begin moving again. Works pretty well.

MAYBE Garmin will add some of these new features to the Montana in an upcoming firmware update....
atlas cached is offline   Reply With Quote
Old 05-28-2013, 06:57 PM   #8072
guavadude
de-composer
 
guavadude's Avatar
 
Joined: Aug 2009
Location: Dallas, TX
Oddometer: 663
Thx! I knew you'd know. Looks like deleting those few points cleans things up.

Do you use Auto, Distance or Time tracking?

I'm going to try distance and see if that's any better.
guavadude is offline   Reply With Quote
Old 05-28-2013, 07:00 PM   #8073
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by guavadude View Post
Thx! I knew you'd know. Looks like deleting those few points cleans things up.

Do you use Auto, Distance or Time tracking?
When I am purposely recording trails for map making, I use distance, every 3.33 Meters. This is how my Track Log Profile is set up.

If I am in my Nuvi Profile, I use Auto, More Often.

Almost never do I use time, unless I have a specific test I am running.
atlas cached is offline   Reply With Quote
Old 05-28-2013, 07:02 PM   #8074
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by guavadude View Post
Thx! I knew you'd know. Looks like deleting those few points cleans things up.

Do you use Auto, Distance or Time tracking?
Sometimes, 'deleting' a errant track log point appears to clean things up, but can still leave you with unrealistic speed between the adjoining two points.

You may consider simply 'Moving' the errant track point in between the two track points it connects with, but to a more realistic position. Helps keep speed and other statistics more accurate.
atlas cached is offline   Reply With Quote
Old 05-28-2013, 07:12 PM   #8075
guavadude
de-composer
 
guavadude's Avatar
 
Joined: Aug 2009
Location: Dallas, TX
Oddometer: 663
these are so far off it won't matter. One is 59 miles distance, another is 139 miles...basically trashing the first part of the track. These are long distances that the gps is saying took one second so that's why I'm getting the crazy speed.

I need to try a few things to trouble shoot because I think it's something other than just lost satellites, especially because this is wide open area I'm talking about.

Can weather make you lose sat link, i.e. thunder storm or overcast?
guavadude is offline   Reply With Quote
Old 05-28-2013, 08:34 PM   #8076
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by guavadude View Post
Can weather make you lose sat link, i.e. thunder storm or overcast?
In short, yes.
atlas cached is offline   Reply With Quote
Old 05-29-2013, 05:54 AM   #8077
ducnek
Misadventurer
 
ducnek's Avatar
 
Joined: Apr 2007
Location: Rooster Poot Tennessee
Oddometer: 987
Converting tracks to routes

I have a track I recorded a while back that is ~90 miles.

I want to convert this to a regular route so I can use turn by turn.

The track is something like 5400 points.

I have tried to "convert track to route" using a maximum of 49 points but it keeps locking up my BC. What am I doing wrong?
__________________
Calmer than you are.
ducnek is offline   Reply With Quote
Old 05-29-2013, 06:59 AM   #8078
trampaslake
Gnarly Adventurer
 
Joined: Aug 2006
Location: Texas
Oddometer: 238
Quote:
Originally Posted by ducnek View Post
I have a track I recorded a while back that is ~90 miles.

I want to convert this to a regular route so I can use turn by turn.

The track is something like 5400 points.

I have tried to "convert track to route" using a maximum of 49 points but it keeps locking up my BC. What am I doing wrong?
Try reducing the number of points in the track before you convert it to a route. With that many points, BC may be having trouble converting.
trampaslake is offline   Reply With Quote
Old 05-29-2013, 07:09 AM   #8079
SteveAZ
Beastly Adventurer
 
SteveAZ's Avatar
 
Joined: Sep 2002
Location: AZ
Oddometer: 1,150
I typically just set logging at go-fer-broke 1pt/sec. If the units had a faster GNSS engine I'd log as fast as the engine goes. I can throw out data later but I can't ever get it if it isn't there. Both Mapsucks and BC have filter functions if I want to "clean" them up for re-use or I can use other tools I've got...
SteveAZ is offline   Reply With Quote
Old 05-29-2013, 07:50 AM   #8080
ducnek
Misadventurer
 
ducnek's Avatar
 
Joined: Apr 2007
Location: Rooster Poot Tennessee
Oddometer: 987
Quote:
Originally Posted by trampaslake View Post
Try reducing the number of points in the track before you convert it to a route. With that many points, BC may be having trouble converting.
How do I do that? Manually? The track has like 5400 points! iM IGNERT
__________________
Calmer than you are.
ducnek is offline   Reply With Quote
Old 05-29-2013, 07:52 AM   #8081
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by ducnek View Post
How do I do that? Manually? The track has like 5400 points! iM IGNERT
I like to use the JaVaWa RTW Tool.

More info here.
atlas cached is offline   Reply With Quote
Old 05-29-2013, 08:26 AM   #8082
SteveAZ
Beastly Adventurer
 
SteveAZ's Avatar
 
Joined: Sep 2002
Location: AZ
Oddometer: 1,150
Quote:
Originally Posted by ducnek View Post
How do I do that? Manually? The track has like 5400 points! iM IGNERT
If you open the track in Mapsucks or BC there's a button to "filter" which will allow you to reduce the track points by time, distance or algorithm in a very user-friendly way. The algorithm attempts to keep the points that will preserve the shape of the track and can be set to automatically decide the number of points or you can set the maximum points...
SteveAZ is offline   Reply With Quote
Old 05-29-2013, 09:45 AM   #8083
dvmvm
Adventurer
 
Joined: Dec 2012
Oddometer: 23
Quote:
Originally Posted by guavadude View Post
these are so far off it won't matter. One is 59 miles distance, another is 139 miles...basically trashing the first part of the track. These are long distances that the gps is saying took one second so that's why I'm getting the crazy speed.

I need to try a few things to trouble shoot because I think it's something other than just lost satellites, especially because this is wide open area I'm talking about.....
I discovered that these crazy speeds are caused by extra logged points from the file ".position.gpx". The file .position.gpx contains the last known position before power off.
If you have the tracklog switched on before a satellite fix AND you are standing still, it puts the location from .position.gpx in the tracklog. However it does NOT take the accompanying timestamp from that file. Instead it takes the current timestamp.
As speed is calculated as distance from previous to current point divided by time from previous to current point, you get unrealistic high speeds due to this wrong timestamp.
It is best to remove these points completely from the tracklog, and not "move them", because they have the wrong time stamp.

If you are moving during satellite fix, this extra point is not added and you get a more realistic average speed between the last and current position. Moving during power-on and start-up could be used as a work around.
When you move it is logical that the last known position is not valid, so it is not used. This part is correct I think.

When no fix is found and the Montana is not moving, one might think it is logical to log the last known position with the current time stamp. But if the Montana has been relocated it should be better to log the last known timestamp. However I see no reason to log this last known position at all. Most people don't want to see a 139mile straight line on the map. This point seems also to be used in the tripcomputer calculations causing unrealistic large errors in traveled distance.
dvmvm is offline   Reply With Quote
Old 05-29-2013, 10:05 AM   #8084
DRTBYK
Long Haul Adventurer
 
DRTBYK's Avatar
 
Joined: Mar 2003
Location: North Central Washington (state)
Oddometer: 5,046
Quote:
Originally Posted by dvmvm View Post
I discovered that these crazy speeds are caused by extra logged points from the file ".position.gpx". The file .position.gpx contains the last known position before power off.
If you have the tracklog switched on before a satellite fix AND you are standing still, it puts the location from .position.gpx in the tracklog. However it does NOT take the accompanying timestamp from that file. Instead it takes the current timestamp.
As speed is calculated as distance from previous to current point divided by time from previous to current point, you get unrealistic high speeds due to this wrong timestamp.
It is best to remove these points completely from the tracklog, and not "move them", because they have the wrong time stamp.

If you are moving during satellite fix, this extra point is not added and you get a more realistic average speed between the last and current position. Moving during power-on and start-up could be used as a work around.
When you move it is logical that the last known position is not valid, so it is not used. This part is correct I think.

When no fix is found and the Montana is not moving, one might think it is logical to log the last known position with the current time stamp. But if the Montana has been relocated it should be better to log the last known timestamp. However I see no reason to log this last known position at all. Most people don't want to see a 139mile straight line on the map. This point seems also to be used in the tripcomputer calculations causing unrealistic large errors in traveled distance.
Great sleuthing dvmvm. Have you sent this to the Montana Team? Would be good to get a fix for this one.
__________________
Cheers,

Dan
All Things GPS
Reviews at www.GlobeRiders.com
DRTBYK is offline   Reply With Quote
Old 05-29-2013, 11:26 AM   #8085
atlas cached
OX Ambassador
 
atlas cached's Avatar
 
Joined: Jun 2012
Oddometer: 687
Quote:
Originally Posted by DRTBYK View Post
Great sleuthing dvmvm. Have you sent this to the Montana Team? Would be good to get a fix for this one.
I immediately recognized dvmvm's work for what it was, and forwarded it to the Montana Beta team pronto!
atlas cached is offline   Reply With Quote
Reply

Share

Thread Tools Search this Thread
Search this Thread:

.
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump


Times are GMT -7.   It's 11:18 PM.


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ADVrider 2011-2014