Jump to content

Track log bug: Why does it exist.


gallet

Recommended Posts

I've seen about 10 million threads about it but as yet I fail to understand how it occurs. I'm not particularly bothered by it I just want to understand why it is proving so intractable.

 

I pulled out an old Venture (monochrome) last week and remembered that it registers very slow moving speeds unlike the new HCx.

 

I've seen allusions to the problem being to do with the chipset, but no further explanation about how it could come about. I mean either the chipset is measuring position constantly or it is not, and if it is what's the big deal about the math.

 

Why can't the HCx divide distance by time as well as earlier gpsr's? this surely has to be one of the most simple calculations that a gps can make.

 

One would think that collecting more satellite data would enable the HCx to record even slower velocity. I cannot see/understand where exactly the problem lies. So the gpsr sees me at point X at time T, then it sees me at X1 at time T1, but if the calculation is below 2kph it will not give me a reading. Why? it's either programmed to or it is not.

Link to comment

Well, I don't know the full answer, but part of it lies due to the fact that it isn't the simple calculation you think.

 

1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

2. It appears that the distance on the odometer gets calculated via integration of the velocity with respect to time. This isn't the only type of navigation system that does this. The track log distance is a measurment between the track log points. It makes sense to do this because the velocity data is stripped off the track logs when you save them, but you'll still want the distances to enable TracBack operations.

 

3. Thus, the problem is when the velocity reads zero, as you noted. Integrating zero velocity gives zero distance. Also, it may just not do the calculation when it reads zero.

 

4. One or both of two things are likely happening:

 

a. The lower velocity gate for the HCx below which it does not work out the doppler shift is higher than that of the older models. There might be a reason for this (see my next point).

 

b. The HCx obviously receives and processes weaker signals. These weaker signals can have more error built in, since the system is more susceptible to multi-path, etc. Also, given this condition, it is more difficult to calculate the doppler shift (signal interference causes havoc on the ability to accurately measure the frequency) at low speeds (small doppler shifts).

 

My guess is that the lower velocity gate was raised to try to avoid the errors caused by the very weak signals at low doppler shifts. An attempt was made to lower it in one of the last updates, but it still causes problems. The older, non-high sensitivity GPS's didn't suffer from this problem, but when they lost a signal, you lost everything (i.e. time didn't change, dropouts on the tracks, etc.). You still didn't get an accurate distance if you lost a signal that the HCx would pick up.

 

Improvements in certain areas often require compromises elsewhere. Thus, you are able to get a signal and therefore a position and track information in areas where you would not receive a signal at all before. However, the weak signals cause problems with other calculations.

 

This is the simplest way I can explain my theory of what is going on. I don't know for sure that it is really what is happening, but it is based on my knowledge of how the system works.

 

I personally prefer getting the signal on my HCx rather than dropping it on my Legend. As long as I recognise that the odometer works the way it does, there are work arounds that are not that difficult, so, like you, I'm not bothered by it but would be very happy if they are able to come up with a solution.

Edited by dogwalkers2
Link to comment

Well, I don't know the full answer, but part of it lies due to the fact that it isn't the simple calculation you think.

 

1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

2. It appears that the distance on the odometer gets calculated via integration of the velocity with respect to time. This isn't the only type of navigation system that does this. The track log distance is a measurment between the track log points. It makes sense to do this because the velocity data is stripped off the track logs when you save them, but you'll still want the distances to enable TracBack operations.

 

3. Thus, the problem is when the velocity reads zero, as you noted. Integrating zero velocity gives zero distance. Also, it may just not do the calculation when it reads zero.

 

4. One or both of two things are likely happening:

 

a. The lower velocity gate for the HCx below which it does not work out the doppler shift is higher than that of the older models. There might be a reason for this (see my next point).

 

b. The HCx obviously receives and processes weaker signals. These weaker signals can have more error built in, since the system is more susceptible to multi-path, etc. Also, given this condition, it is more difficult to calculate the doppler shift (signal interference causes havoc on the ability to accurately measure the frequency) at low speeds (small doppler shifts).

 

My guess is that the lower velocity gate was raised to try to avoid the errors caused by the very weak signals at low doppler shifts. An attempt was made to lower it in one of the last updates, but it still causes problems. The older, non-high sensitivity GPS's didn't suffer from this problem, but when they lost a signal, you lost everything (i.e. time didn't change, dropouts on the tracks, etc.). You still didn't get an accurate distance if you lost a signal that the HCx would pick up.

 

Improvements in certain areas often require compromises elsewhere. Thus, you are able to get a signal and therefore a position and track information in areas where you would not receive a signal at all before. However, the weak signals cause problems with other calculations.

 

This is the simplest way I can explain my theory of what is going on. I don't know for sure that it is really what is happening, but it is based on my knowledge of how the system works.

 

I personally prefer getting the signal on my HCx rather than dropping it on my Legend. As long as I recognise that the odometer works the way it does, there are work arounds that are not that difficult, so, like you, I'm not bothered by it but would be very happy if they are able to come up with a solution.

Your explanation is very much in line with my thinking on it, too. The strange thing is that the high-sensitivity Sirf Star III chipset on the 60CSx doesn't seem to have this problem, so it may be chipset-specific problem. If that's the case, it may or may not be able to be fixed via a firmware update.

Link to comment
My guess is that the lower velocity gate was raised to try to avoid the errors caused by the very weak signals at low doppler shifts. An attempt was made to lower it in one of the last updates, but it still causes problems. The older, non-high sensitivity GPS's didn't suffer from this problem, but when they lost a signal, you lost everything (i.e. time didn't change, dropouts on the tracks, etc.). You still didn't get an accurate distance if you lost a signal that the HCx would pick up.

 

This is an interesting explanation. However, if this is the case, the same problem should occur with the 60csx and the 76csx. Also, the odometer for an older unit should read a similar result because of the effect of dropping the signal. However, the reports posted in here indicate that the significant discrepancy between the odometer and the track log only occurs with the new units.

Link to comment

The problem, as I've seen posted on other forums, is a firmware bug with the MTK chipset so that at low speeds it outputs non changing data. The GPS unit sees the same position so zero distance and calculates zero speed.

 

The bug was fixed by May 2007 so the question is whether an early problem chipset inside existing GPS units can be accessed and updated. Given the amount of time that has passed it appears the answer is no.

Edited by Frabble
Link to comment

The 60cx/60csx & 76cx/76csx with their SirfIII chipset, the position wanders around when sitting still. Maybe with this new unit garmin was trying to eliminate some of the wandering that so many people have complained about, but obviously by doing so the unit isn't sensitive enough to movement.

 

How is the gps unit suppose to know what location change(movement) is real and what is false? The only way they can really control what data the unit records is through some sort of speed filtering. I have a feeling you either have to deal with some false data showing up in the track log/Odometer(wandering) or have a unit that drops to much data(odometer bug).

 

Maybe there is some happy medium, but if there was wouldn't they have fixed the wandering issues the SirfIII units have? those units have been out since fall of 2005 & they have done nothing to really curb the issue.

Link to comment

1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

Is this correct? Doesn't the gps measure the distance between two points and the time between two points and use this for the velocity calculation? Surely this would be a simpler way of measuring tiny velocities?

Link to comment
How is the gps unit suppose to know what location change(movement) is real and what is false? The only way they can really control what data the unit records is through some sort of speed filtering. I have a feeling you either have to deal with some false data showing up in the track log/Odometer(wandering) or have a unit that drops to much data(odometer bug).

 

Maybe there is some happy medium, but if there was wouldn't they have fixed the wandering issues the SirfIII units have? those units have been out since fall of 2005 & they have done nothing to really curb the issue.

What do they need to fix? Sirf III has an option called Static Navigation which filters position data for low speeds. This is fine for motor vehicle navigation but undesirable for walking speeds so it's disabled for "Trail" units.

 

The Odometer and Track log are two different things. The odometer is one of the default fields displaying the real time data on the Trip Computer which tells you how it sees things as the are. If "wandering" is an issue then change the Track Log recording method to be based on Distance.

Link to comment
1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

Is this correct? Doesn't the gps measure the distance between two points and the time between two points and use this for the velocity calculation? Surely this would be a simpler way of measuring tiny velocities?

It is true that the GPSr uses doppler shift to determine velocity. Do some simple math, remembering the your position accuracy my be off by 20 feet in either direction. If you are actually travelling at, say 60 mph, you should cover 88 feet per second. But if, after a second, the GPS shows you only went 68 feet, the unit will report your velocity at about 43 mph. If it shows you went 108 feet, it will show your speed at over 73 mph. Doppler shift is accurate to about .1 mph.

 

My read on the track log bug goes back to early reports that these high sensitivity chips reported your position as moving small amounts, even if you were perfectly stationary. The trick is how to filter out that "noise," while still giving you a decent track log. Judging only be reports in this forum, the SiRF software seems to have done a reasonably good job of that (although still not perfect). Media Tek doesn't appear to have it quite right yet.

Link to comment

Well, I don't know the full answer, but part of it lies due to the fact that it isn't the simple calculation you think.

 

1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

2. It appears that the distance on the odometer gets calculated via integration of the velocity with respect to time. This isn't the only type of navigation system that does this. The track log distance is a measurment between the track log points. It makes sense to do this because the velocity data is stripped off the track logs when you save them, but you'll still want the distances to enable TracBack operations.

 

3. Thus, the problem is when the velocity reads zero, as you noted. Integrating zero velocity gives zero distance. Also, it may just not do the calculation when it reads zero.

 

4. One or both of two things are likely happening:

 

a. The lower velocity gate for the HCx below which it does not work out the doppler shift is higher than that of the older models. There might be a reason for this (see my next point).

 

b. The HCx obviously receives and processes weaker signals. These weaker signals can have more error built in, since the system is more susceptible to multi-path, etc. Also, given this condition, it is more difficult to calculate the doppler shift (signal interference causes havoc on the ability to accurately measure the frequency) at low speeds (small doppler shifts).

 

My guess is that the lower velocity gate was raised to try to avoid the errors caused by the very weak signals at low doppler shifts. An attempt was made to lower it in one of the last updates, but it still causes problems. The older, non-high sensitivity GPS's didn't suffer from this problem, but when they lost a signal, you lost everything (i.e. time didn't change, dropouts on the tracks, etc.). You still didn't get an accurate distance if you lost a signal that the HCx would pick up.

 

Improvements in certain areas often require compromises elsewhere. Thus, you are able to get a signal and therefore a position and track information in areas where you would not receive a signal at all before. However, the weak signals cause problems with other calculations.

 

This is the simplest way I can explain my theory of what is going on. I don't know for sure that it is really what is happening, but it is based on my knowledge of how the system works.

 

I personally prefer getting the signal on my HCx rather than dropping it on my Legend. As long as I recognise that the odometer works the way it does, there are work arounds that are not that difficult, so, like you, I'm not bothered by it but would be very happy if they are able to come up with a solution.

 

Well said my good man.

Link to comment
1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

Is this correct? Doesn't the gps measure the distance between two points and the time between two points and use this for the velocity calculation? Surely this would be a simpler way of measuring tiny velocities?

It is true that the GPSr uses doppler shift to determine velocity. Do some simple math, remembering the your position accuracy my be off by 20 feet in either direction. If you are actually travelling at, say 60 mph, you should cover 88 feet per second. But if, after a second, the GPS shows you only went 68 feet, the unit will report your velocity at about 43 mph. If it shows you went 108 feet, it will show your speed at over 73 mph. Doppler shift is accurate to about .1 mph.

 

That has nothing to do with doppler shift. The doppler shift is the change in frequency of em radiation (or sound waves) from an object moving towards or away from an observer. GPSr uses triangulation (or trilateration) and the time it takes to receive satellite signal. The longer it takes to receive the signal, the farther you are from the satellite. By using 3 satellites, the known distance from said satellites, and the atomic clocks in the satellites, the GPSr can calculate its exact position. It can calculate speed by the change in that position over time

Edited by Hiker2008
Link to comment
1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

Is this correct? Doesn't the gps measure the distance between two points and the time between two points and use this for the velocity calculation? Surely this would be a simpler way of measuring tiny velocities?

It is true that the GPSr uses doppler shift to determine velocity. Do some simple math, remembering the your position accuracy my be off by 20 feet in either direction. If you are actually travelling at, say 60 mph, you should cover 88 feet per second. But if, after a second, the GPS shows you only went 68 feet, the unit will report your velocity at about 43 mph. If it shows you went 108 feet, it will show your speed at over 73 mph. Doppler shift is accurate to about .1 mph.

 

That has nothing to do with doppler shift. The doppler shift is the change in frequency of em radiation (or sound waves) from an object moving towards or away from an observer. GPSr uses triangulation (or trilateration) and the time it takes to receive satellite signal. The longer it takes to receive the signal, the farther you are from the satellite. By using 3 satellites, the known distance from said satellites, and the atomic clocks in the satellites, the GPSr can calculate its exact position. It can calculate speed by the change in that position over time

That's a description of how it calculates position (it actually needs four satellites to get a 3D position). However, even though it could calculate velocity as a change in position, GPS's generally don't as that method suffers from considerable inaccuracy (most update at a rate of once per second, assume a position error of only 1 metre, this could result in a potential maximum velocity error of 2 m/s - that's 7.2 km/h or 4.4mph - as we all know, the real position errors are greater than that (this is the same reasoning as Sputnik 57 used above, only worded differently)). They use the dopper shift, taking into account the satellite position and velocities, working out the geometry and resolving for the reviever velocity.

Link to comment
1. A GPS calculates velocity from the doppler shifts (change in frequency due to motion) of the signals it is receiving from the satellites, so it's not simply distance divided by time.

 

Is this correct? Doesn't the gps measure the distance between two points and the time between two points and use this for the velocity calculation? Surely this would be a simpler way of measuring tiny velocities?

It is true that the GPSr uses doppler shift to determine velocity. Do some simple math, remembering the your position accuracy my be off by 20 feet in either direction. If you are actually travelling at, say 60 mph, you should cover 88 feet per second. But if, after a second, the GPS shows you only went 68 feet, the unit will report your velocity at about 43 mph. If it shows you went 108 feet, it will show your speed at over 73 mph. Doppler shift is accurate to about .1 mph.

 

That has nothing to do with doppler shift. The doppler shift is the change in frequency of em radiation (or sound waves) from an object moving towards or away from an observer. GPSr uses triangulation (or trilateration) and the time it takes to receive satellite signal. The longer it takes to receive the signal, the farther you are from the satellite. By using 3 satellites, the known distance from said satellites, and the atomic clocks in the satellites, the GPSr can calculate its exact position. It can calculate speed by the change in that position over time

...However, even though it could calculate velocity as a change in position, GPS's generally don't as that method suffers from considerable inaccuracy....They use the dopper shift, taking into account the satellite position and velocities, working out the geometry and resolving for the reviever velocity.

 

OK. I found some documentation that says you are correct.

But I think that "4th satellite" you speak of is really just the center of the earth -- and we know that distance so no signal is required?????

Edited by Hiker2008
Link to comment

You are going to have to prove that. I cannot believe that the GPSr is capable of detecting any doppler shift let alone one so small caused by a movement of only a couple miles per hour, especially considering atmospheric affects.

Looky here: http://gpsinformation.net/main/gpsspeed.htm or here: http://www.sciencedirect.com/science?_ob=A...80cbcac8b025e4a or here: http://forums.gpsworld.com/archive/index.php?t-10.html

Link to comment

But I think that "4th satellite" you speak of is really just the center of the earth -- and we know that distance so no signal is required?????

Actually, the distance to the centre of the earth varies (at sea level or on a mountain, for example; also, the earth is not a sphere, it is an oblate spheroid, the description of which is what makes up the datum, such as WGS84). But, that's not the reason behind the fourth satellite.

 

The fourth satellite is used to solve the time issue. As you know the satellites have atomic clocks on board...very expensive. The clocks in a GPS receiver are not expensive at all (we wouldn't be able to afford otherwise). The extra satellite compensates for this imperfection. See http://www.trimble.com/gps/howgps-timing.shtml

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...