The speedometer of my car topped out at 240 km/h. The GPS display read 231
km/h. An error of 3,75 % I guess that figures since most speedometers show a
higher speed than you actually drive for safety reasons ( you wouldn't want
a speedometer that shows a lower speed than you are actually driving: that
will result in lots of speeding tickets right :) )
But now I wonder how accurate my GPS is for checking speed. Am I really
driving 231? Is there an 95% error interval or some other statistical margin
of error I should know about? I don't know if this is relevant but I own a
SporTrak Pro and the EPE was 2 meters (using EGNOS) at that moment.
Any ideas about the accuracy?
TIA, Vincent
> But now I wonder how accurate my GPS is for checking speed. Am I really
> driving 231? Is there an 95% error interval or some other statistical
> margin of error I should know about? I don't know if this is relevant
> but I own a SporTrak Pro and the EPE was 2 meters (using EGNOS) at that
> moment.
>
> Any ideas about the accuracy?
Very accurat I would say. If you are driving straight forward that is...
In curves the GPS tends to show a little lower speed (not much).
/Tim
Hello,
I hope the german highway police will catch you soon within
a speedlimit.
If another driver at 120 km/h wants to pass a truck at 80
km/h, how should he know that there is someone behind him
running at 230 km/h?
Bye
Hi Vincent--
Ref: Misra & Enge "GPS: Signals, Measurements, and Performance" (2001)
Sec. 5.2.1 (pgs 196-197) Velocity Estimation
"The relative motion of a satellite and the user results in changes in
the observed frequency of the satellite signal. This Doppler shift is
measured routinely in the carrier tracking loop of a GPS receiver
[Section 9.6]. Given the satellite velocity, the Doppler shift can be
used to estimate the user velocity. The Doppler shift, or equivalently,
the range rate [Section 1.3.3], can be written as a projection of the
relative velocity vector on the satellite line-of-sight vector. The
measurement, however, is biased by the receiver clock bias rate (i.e.,
frequency offset), and what's actually measured is the pseudorange
rate.
"The delta pseudoranges obtained from carrier phase measurements are
proportional to the average pseudorange rates or the line-of-sight
velocity of the user relative to the satellite over the time interval.
The model for pseudorange rates can be obtained by differentiating
(5.1). It is left as an exercise to show that
[equation 5.28 is true]
where v_sup(k) [a vector quantity] is the satellite velocity vector,
known from the navigational message broadcast by the satellite; v is
the user velocity vector, to be estimated. Both v_sup(k) and v are
expressed in the ECEF coordinate frame. The user-to-satellite unit
vector 1_sup(k) is determined from an estimate of the user position;
b_dot is the bias of the receiver clock (m/s), and the
epsilon_sub_phi_sup(k) denotes the combined error doe to changes during
the measurement interval in the satellite clock, ionosphere and
troposphere. Note that the velocity of an object attached to the earth
is zero in the ECEF coordinate frame.
"The principal source of error in (5.28) throughout the 1990s was the
satellite clock frequency dithering due to SA. Now with SA gone, the
remaining errors arise from changes in the ionospheric and tropospheric
delays and in multipath, and are generally small. Problems, however,
can arise if the user dynamics are excessive. The delta ranges give
only average velocity over a time interval. High accelerations and
jerks would clearly be problematic. The PPS performance specifications
for velocity estimation (0.1 m/s rms in any direction; 0.2 m/s 2drms)
are based on a constant-velocity scenario [JPO(1991)].
"Equation (5.28) is linear in user velocity components, and can be
rewitten...
the combined set of measurements from K satellites can be written as a
set of equations compactly in matrix notation as
[equation 5.29]
where matrix G characterizes the user-satellite geometry, as defined
previously (5.10). It is interesting that the problem of estimation of
user velocity based on pseudorange rates is identical in structure to
that of estimation of user position from pseudoranges (5.9). A
least-squares solution and the DOP parameters can be defined, as
before, and related to the rms error in these estimates".
Keep in mind that most GPS receivers employ "smoothing filters" and so
instantaneous velocity reading during acceleration is not necessarily
accurate. However at constant velocity (and assuming no obstruction of
signals), the GPS receiver will likely measure velocity to an accuracy
of 0.2 m/s (0.7 kph) 2drms.
There are those that will argue (probably correctly) that steady state
velocity accuracy is even better by a factor of two or so.
-Sam Wormley
http://edu-observatory.org/gps/gps_accuracy.html
Non-mirror users will be sorted out eventually, its called natural
selection. Beauty of nature's ways, this normally coincides with the removal
of a Scandinavian speed freak from the evolutionary chain also....
8-)
/Erwin
> If another driver at 120 km/h wants to pass a truck at 80
> km/h, how should he know that there is someone behind him
> running at 230 km/h?
That is why I anticipate for one kilometre. When I see trucks or other slow
traffic , I slow down to 150-160
I happen to know a pretty deserted stretch of highway (Nimwegen-Oberhausen).
Long kilometres with no one at all in sight!
I hope this eases your mind!
My experience is that most Germans drive around 160-180 on the long
stretches (Koln-Frankfurt for example) as long as there is no "Stau" off
course.
Anyway, some Porsches/Ferraris still pass me at that speed.
But all this is OT of course. I was asking about GPS speed accuracy.
> Bye
Kind regards, Vincent
This is exactly what I wanted to know!
Thanks, Sam!
Vincent
LOL!
> Beauty of nature's ways, this normally coincides with the removal
> of a Scandinavian speed freak from the evolutionary chain also....
> 8-)
LOL again!
Who is the Scandinavian?
I'm Dutch so I assume you are referring to .....?
Vincent
Hello,
I am happy to read this, for your security and the security
of all other drivers on the highway.
Bye
You scare easily apparently. Please stay on topic.
eisbaer
I think it's pretty accurate. The topspeed of my tdi according to the
factory is 193 km/u. At topspeed in germany my car's speedometer pointed at
210 while my magellan 320 showed 193. So the gps is the one I trust best.
eisbaer
Oops, got your post confused with Tims header information. However, natural
selection works without checking nationalities.. 8-)
/Erwin
I've been using my GPS for a long time as the speedometer of choice on my
BMW motorcycle. BMW motorcycles are known for having wildly optimistic
speedos. The GPS actually lets me ride faster and stay legal, since I now
know that the 80mph on the bike's speedo is really only about 73mph, which
is a reasonable speed in a 70mph zone.
Doug
By being aware of his surroundings before comitting to a lane change.
actual for instantaneous speed below about 150mph, it is actually
pretty awful. It looks reasonably good only because of the smoothing
function.
Here is the problem in a nutshell. The CEP is on the order of 10
meters without a true dif correction. If you update position once per
second, as is typical, then the accuracy of the speedometer function
is really a question of how accurate the position of two points you
are measuring the distance between is known. If you are driving at
say 30 mph, your speed is about 45 feet per second, the error in the
positions is about 30 feet, so realistically the GPS could show a
speed anywhere from 10 to 50 mph.
As the speed increases, the relative size of the CEP error to the
actual distance becomes smaller, and the accuracy tends to increase.
I.e at 100mph, that is about 150 fps, but the error remains fixed at
15-30 feet.
Over long periods of time, the CEP remains fixed, but the baseline
becomes huge, so the error just disappears. Over 1 minute at 30mph,
the baseline is 2640 feet, but the error remains fixed at about 30
feet....
>actual for instantaneous speed below about 150mph, it is actually
>pretty awful. It looks reasonably good only because of the smoothing
>function.
>Here is the problem in a nutshell. The CEP is on the order of 10
>meters without a true dif correction. If you update position once per
>second, as is typical, then the accuracy of the speedometer function
>is really a question of how accurate the position of two points you
>are measuring the distance between is known. If you are driving at
>say 30 mph, your speed is about 45 feet per second, the error in the
>positions is about 30 feet, so realistically the GPS could show a
>speed anywhere from 10 to 50 mph.
That would be true if the positions had independent errors, and the
speed was calculated by subtracting the positions.
But in fact what GPS receivers do is considerably more complex.
There's a Kalman filter or something similar that takes into account
both position and Doppler data from each satellite being tracked,
and calculates a running estimate of your current velocity and position.
Apparently the velocity estimate tends to be quite good, better than
you'd expect from the position accuracy.
One way of thinking of this: if the error at one point is 5 m south,
the error at the next point a second later is going to be very close
to 5m south as well, because the velocity is quite accurate. So the
two errors are almost the same, not two independent vectors.
Dave
Of course this analysis would also conclude that at walking speeds the
smoothing would need to be done over periods of at least 30 seconds to
give reasonable results and that's quite clearly not the case. When I
walk and vary my speed I see the effects on the GPSr within a couple
seconds and yet the speeds are generally quite accurate even when going
2 mph or less.
I see two problems with your analysis:
1) you assume that consecutive position measurements are uncorrelated,
but actually many of the error sources are rather stable over short time
periods, incl ionospheric delays, satellite geometries, sat. clocks,
etc.
2) more importantly, you neglect the measurement of Doppler frequency
shifts through which the GPSr can determine velocity directly. In
practice I believe both velocity data and position data are inputs in
the Kalman filter process that determines the final output of the GPSr.
Neville
"matt weber" <matth...@cox.net> wrote in message
news:14j2oucm64nj6abnq...@4ax.com...
This is what I assumed too, but according to some technician at
Garmin, they utilise the doppler shift of the satellite signals in
addition to the position change, to improve the accuracy of the speed
measurement.
Anders
[snip story about driving at alarming speeds :-) ]
Does anyone else have interesting applications for GPS measurement of
speed?
When I first got a GPS last winter I used it to see how fast I ski. I was
rather shocked (I don't consider myself a fast skier) to record a maximum
of 85kph on two successive days. If I go this fast on my bike it feels
fairly exciting, but apparently less so on skis.
An idea - has anyone here used a GPS to check their terminal velocity while
skydiving?
Jeremy
> The speedometer on my truck is 5mph off as tested by a speedo shop. My gps
> always confirms that 5mph difference. It is also not uncommon for a
> speedometer that starts becoming inacurate by a small amount at first, will
> increase the error as speed increases. Try checking at a slower speed for a
> smaller error, then watch for the error to increase with your speed.
yes, I noticed that. It seems that the error has to components:
a percentage: the error increases when the speed increases
an offset: some error component that is constant
> You also might want to increase your life insurance so when you have a tire
blow out at that kind of speed your loved ones will be taken care of.
:)
My beloved wife (no kids) enjoys speed as well. You can imagine that I take
no chances at all with the tyres I buy: I change them more often than
prescribed and I buy the best quality. The tubeless tyres I have now are
made for speeds up to 350 km/h. Also I have 15 years of high speed
experience.
Personally, I'm more worried about a crossing deer or something else.
But I also climb mountains and my view of what is risky or what isn't may be
distorted. :-)
> Does anyone else have interesting applications for GPS measurement of
> speed?
> When I first got a GPS last winter I used it to see how fast I ski.
Very good idea, I never thought of that! I will try this next time I go
skiing!
> I was rather shocked (I don't consider myself a fast skier) to record a
> maximum of 85kph on two successive days. If I go this fast on my bike it feels
> fairly exciting, but apparently less so on skis.
Lets see if I can reach some rather alarming speeds on ski!
(did you know that the world speed record is 248.105km/h or 154mph can you
believe it! See: http://www.speedski.com/
These skiers have NO FEAR, (or maybe no brains! :)
Man, I don't even drive that fast!)
"Sam Wormley" <swor...@mchsi.com> wrote in message
news:3D80BB00...@mchsi.com...
If you are speaking from knowledge, then the designers of GPS
receivers are incredibly incompetent or hamstrung by VERY tiny
embedded computers. I see no reason why velocity should be calculated
by subtraction of positions. The receiver should be using a Kalman
filter with seven components in the state: position (x,y,z), velocity
(x-dot,y-dot,z-dot) and time error and should use the pseudorange and
pseudorange-rate for each satellite as observables. Once the filter
has converged (which should be a matter of seconds after satellite
lock is achieved), I would be very surprised if the speed error
(actually, the error in the magnitude of the component of the velocity
tangent to the geoid) were as much as one mile per hour.
Joseph Reuter, Wizard in Training
--------------
In theory, theory and practice are the same, but in practice they're
not.--Anon
Hi Matt--
[equation 5.28 is true]
[equation 5.29]
As you point out most GPS receivers employ "smoothing filters" and so
instantaneous velocity reading during acceleration is not necessarily
accurate. However at constant velocity (and assuming no obstruction of
signals), the GPS receiver will likely measure velocity to an accuracy
of 0.2 m/s 2drms.
I'm just having trouble with the idea that my $350 GPS III+ has twelve
separate receivers, all capable of continuous sub-Hertz resolution on
gigaHertz signals, and a processor capable of keeping up with all that.
--
.signature in flux
That doesn't explain all the times my GPSR, standing still with good
lock, indicates 2 or 3 MPH velocity; or why they seem to have some
minimum value of speed, considerably greater than 0.1 MPH, below which
they indicate zero.
--
.signature in flux
>I'm just having trouble with the idea that my $350 GPS III+ has twelve
>separate receivers, all capable of continuous sub-Hertz resolution on
>gigaHertz signals, and a processor capable of keeping up with all that.
The $110 eTrex has a 12-channel parallel receiver too.
But it isn't 12 independent "receivers" in the sense of a radio or TV
receiver. All satellites use the same transmit frequency, so only one
RF front end is needed to amplify the 1.5 GHz signal and then convert
it down to a lower frequency for the following stages. This receiver
doesn't even need to be tunable, since the frequency is fixed.
The "12 channels" really means that there are 12 sets of the hardware
that tracks individual satellites. One satellite is tracked by having
hardware generate a specific 1023-bit sequence (specific to that
satellite) with a particular clock rate and time offset relative to the
receiver's own local clock. This bit sequence is then "multiplied" by
the incoming signal in a correlator, and integrated over some time. If
the receiver has locked to the signal, the output of the integrator
will be a distinct positive or negative voltage, while lack of lock is
a signal near zero volts. Each "channel" should have two such
correlators, one operating a fraction of a bit time later than the
other one. Once the channel has locked to the signal, perfect timing
produces two equal voltage correlator outputs. If the local timing is
slipping out of sync with respect to the satellite signal, one
correlator's output will increase while the other decreases, and the
size of the difference indicates how large the error in frequency is
and in which direction, so the control loop can easily calculate how
much correction is needed.
So, how much hardware is needed for one "channel"? Not an awful lot.
You need some sort of variable-frequency clock source, probably done
using a digital oscillator. The 1023-bit pseudo-random sequence is
generated by a pair of shift registers - cheap. The correlator is
basically a controllable inverter (one input is always either +1 or -1)
and a capacitor for some integration. The clock rate of the
pseudo-random sequence is 1.023 MHz, hardly a challenge. The firmware
monitoring all this probably just has to look at the two correlator
outputs from time to time and make small adjustments to the digital
oscillator frequency to maintain lock. Every 20 ms, the incoming data
may invert in polarity (this is how the data is transmitted) so the
firmware will want to look at the correlator outputs at least that
often to collect the data - but 50 bits per second is hardly a
challenge to keep up with.
The above description is simplified - it only talks about tracking
"code phase" of the received signals. Real current receivers
apparently also look at the carrier phase of the satellite signals,
compared with the local oscillator phase, so they're more complex. But
the code bit clock and the transmitter frequency are both derived from
the same oscillator in the satellite, and they are both affected by
Doppler shift in the same way. So the same frequency adjustment is
needed to keep both the code locked and the received carrier phase
constant. The advantage of observing carrier phase is that since its
frequency is much higher, smaller local oscillator errors show up
faster as carrier phase errors, allowing more precise tracking of the
signal.
Dave
But... but... these things would keep speed error from being on the order
of 0.1 MPH, no?
> Have you ever looked at the _positions_ of the sv's being used in the
> PVT solution when these speed errors occur???
Um, no. (My dog ate my telescope?)
--
.signature in flux
>That doesn't explain all the times my GPSR, standing still with good
>lock, indicates 2 or 3 MPH velocity; or why they seem to have some
>minimum value of speed, considerably greater than 0.1 MPH, below which
>they indicate zero.
The 0.1 MPH is a steady-state value. If you're moving at a constant
speed, and the GPSR indicates a constant speed, the reading is likely
very accurate. The occasional "glitches" in speed happen when the
receiver switches satellites, or a reflected signal fools the receiver
(multipath). It's usually possible to identify when that happens.
As for slow speed being converted to zero, that's a "feature" of the
user interface, and doesn't reflect on the actual positions or speed
being calculated.
Dave
>When I first got a GPS last winter I used it to see how fast I ski. I was
>rather shocked (I don't consider myself a fast skier) to record a maximum
>of 85kph on two successive days. If I go this fast on my bike it feels
>fairly exciting, but apparently less so on skis.
Keep in mind that most GPS receivers display only the *horizontal*
component of speed. This is conventional in navigation. If you're
going that fast skiing, you're probably on a fairly steep slope. If you
measure the angle of the slope in the direction you're travelling with a
clinometer, your actual 3D speed is the GPS reading times 1/cos(slope).
For example, if the inclination along the diagonal that you're skiing
(not the slope straight down the hill - that doesn't matter) is 30
degrees, then 85 km/h indicated (2D) is actually 98 km/h across the snow
(3D).
>An idea - has anyone here used a GPS to check their terminal velocity while
>skydiving?
That's not very useful, because the GPS will give you only the
horizontal component of your motion, and you probably don't know the
inclination of your path. On the other hand, you can look at the track
log later and calculate 3D velocity. But a barometric altimeter that
calculates rate of descent is probably more useful.
Dave
> I'm just having trouble with the idea that my $350 GPS III+ has twelve
> separate receivers, all capable of continuous sub-Hertz resolution on
> gigaHertz signals, and a processor capable of keeping up with all that.
But you're OK with the idea that it has ~10 nanosecond timing accuracy
and a CPU capable of doing the math to convert pseudoranges to positions
on the earth at least once a second?
> You also might want to increase your life insurance so when you have a
> tire blow out at that kind of speed your loved ones will be taken care
> of.
Assuming that his tires were Z rated and properly inflated, I would think
that the lawsuit against the tire manufacturer would take care of that.
(Even in societies less litigious than the US, manufacturers have a
responsibility to live up to the specifications they claim, right?)
Heck, if his car can go that fast, even the car insurance payment will
probably help out for a while!
[excellent explanation snipped]
Thanks, Dave!
An excellent explanation for someone with mathematicafobia like me!
Vincent
You may get a Darwin Award too,
if you get yourself killed
by gazing at your GPS at 240 km/h
Jan
> An idea - has anyone here used a GPS to check their terminal velocity while
> skydiving?
Yes please: we had an inconclusive argument here some time ago
about what speed is actually indicated:
true 3-D speed, or projection on the ellisoid.
Anybody falling?
Jan
True enough for the normal speed display but many of the new receivers
like my etrex vista now display vertical speed as a separate component
so it would be perfect for sky diving.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/Palm
Hi Jeremy,
this may not work, since the horizontal component of the vector is
negligble during the terminal velocity phase of a skydive, and I
understand that it is only the xy rather than z axis velocity which is
reported by a gps. (I'm [prepared to stand corrected if anybody with
more knowledge says differently). I have a vista, but I'm not current
with my skydiving licence. I would be interested to see what the vista
shows as the maxiumum vertical speed.
Ian
>True enough for the normal speed display but many of the new receivers
>like my etrex vista now display vertical speed as a separate component
>so it would be perfect for sky diving.
Is that GPS-calculated vertical speed or pressure-derived vertical
speed?
The Vista is sort of a hybrid, because it *is* a pressure altimeter and
a gps wrapped up into one.
Dave
"Clifton T. Sharp Jr." <cli...@clifto.com> wrote in message
news:3D820FE4...@clifto.com...
>Anders Persson wrote:
>> This is what I assumed too, but according to some technician at
>> Garmin, they utilise the doppler shift of the satellite signals in
>> addition to the position change, to improve the accuracy of the speed
>> measurement.
Clifton T. Sharp Jr. wrote
>
>I'm just having trouble with the idea that my $350 GPS III+ has twelve
>separate receivers, all capable of continuous sub-Hertz resolution on
>gigaHertz signals, and a processor capable of keeping up with all that.
>
>--
>.signature in flux
>
With the new digital receiver technology the concept of a "receiver" and a
"processor" is getting blurred together. I expect that the typical consumer
GPS receiver is really only a "front end". By that I mean that the receiver
is only an amplifier and perhaps a down converter to an Intermediate
Frequency (IF) somewhere around 10 megahertz which feeds twelve digital
state machines that sample the IF signal and lock on to the digital data
stream. These state machines (or parallel processors or parallel receivers)
were custom designed to do just that one job so they do it very fast. The
personal Computer on your desk is comparatively much slower because it was
designed to be flexible and to run whatever software you load into it. Your
desk top PC also has to waste time pulling instructions out of memory,
perform the operation and save the results back to memory.
Dale
>
>Vincent van der Laan schrieb:
>>
>> The other day I went to germany to test the top speed of my car (most
>> highways in germany have no speedlimit, I love it!)
>>
>> The speedometer of my car topped out at 240 km/h. The GPS display read 231
>> km/h. An error of 3,75 % I guess that figures since most speedometers show a
>
>Hello,
>
>I hope the german highway police will catch you soon within
>a speedlimit.
What's the big deal ? Myself I am driving +200 whether it is on German
highways or others. Ever tried to drive slow with a BMW 750 V12 with
360 HP under the hood ?
--
Zork.
GPS Position : 51°02.171 N, 003°44.431 E, 6m (WGS84)
On theoretical grounds, I'd expect it to be a lot more accurate than a
normal analog speedometer, and that's been my experience. My eTrex Vista
indicated that my Honda's speedometer was about 3 mph low at 60 mph. I
cross-checked this with mile markers on an extremely straight (and boring,
which is why I spent the time) highway in eastern Nevada, which gave the
same results. (Admittedly, I used the GPS's clock, but if that's off by
anything like 4%, the position would be obviously wrong.)
The next time I brought the car in for routine maintenance, I asked
the dealer to check it out. Their machine gave approximately the same
result, but the warranty doesn't cover inaccuracy less than 10%, and
there's apparently no way to adjust the speedometer, short of of replacing
it. (I did think of painting over the dashboard indicator, but didn't
want to mess with the clear plastic covering.)
--
<LI><a href="http://pobox.com/~flash">Flash Sheridan</a>
<LI><a href="http://pobox.com/~spug">Stanford PalmPilot User Group</a>
"Zork" <l8tb2...@sneakemail.com> wrote in message
news:fqv5ou0niusgg8k9n...@4ax.com...
How about:
Put GPSR in Mason jar
Close Mason jar
Jump out of plane, and observe indicated vertical velocity
Mildly interesting... My Canadian version 2000 Honda Civic has almost
invisible mile/hour markings on the analog speedometer. When I'm
driving in the states, I use my yellow Etrex, set to miles/hour, as a
back up speedometer, with a direction-of-motion compass thrown in for
free.
Also, on a recent 4000 km trip in a rented van, the Etrex was useful
in checking the error in the rental speedometer.
"John Morriss" <jmor...@idirect.com> wrote in message
news:9661bda2.02091...@posting.google.com...
>On Fri, 13 Sep 2002 12:31:29 -0500, "Clifton T. Sharp Jr."
><cli...@clifto.com> wrote:
>
>
>>> possible:
>>>
>>> multi-path signal errors being introduced
>>> poor DOP ( satellite geometry )
>>
>>But... but... these things would keep speed error from being on the order
>>of 0.1 MPH, no?
>
>Who can say? I don't know. I have heard stories of people being
>accelerated to 5 hundred + some mph, and having their gps position
>show up hundreds of miles from where they are. Shortly, things return
>to *normal* and they are back where they are supposed to be ( really
>are ) 8-)))))
>
>That's rf interference, or multipath, or sv switching, or poor HDOP,
>or alien spacecraft interference ;-\
There is also an assumption that computers don't make mistakes. Hate
to tell but they do. might be something as simple as dropping 1 bit in
the RAM (which a high energy cosmic ray hitting the junction of one of
the transistor can do). DOP generally won't do it. The worst I have
ever seen was shortly after the Gulf War in Malaysia. DOP was 70, and
the position error, about 1 km, however I have seen a GPS go off the
deep end. It isn't a common occurance, but seeing the speed come up
just shy of Mach 4 and ending up in the high artic was a bit of a
surprise,couple with some error messages that are completely
undocumented. It took a reset to factor setting (and loss of almanac
data) to get it going again.
>matt weber <matth...@cox.net> writes:
>
>>actual for instantaneous speed below about 150mph, it is actually
>>pretty awful. It looks reasonably good only because of the smoothing
>>function.
>
>>Here is the problem in a nutshell. The CEP is on the order of 10
>>meters without a true dif correction. If you update position once per
>>second, as is typical, then the accuracy of the speedometer function
>>is really a question of how accurate the position of two points you
>>are measuring the distance between is known. If you are driving at
>>say 30 mph, your speed is about 45 feet per second, the error in the
>>positions is about 30 feet, so realistically the GPS could show a
>>speed anywhere from 10 to 50 mph.
>
>That would be true if the positions had independent errors, and the
>speed was calculated by subtracting the positions.
>
>But in fact what GPS receivers do is considerably more complex.
>There's a Kalman filter or something similar that takes into account
>both position and Doppler data from each satellite being tracked,
>and calculates a running estimate of your current velocity and position.
>Apparently the velocity estimate tends to be quite good, better than
>you'd expect from the position accuracy.
You are also assuming much mores sophisticated electronics then anyone
can afford to put inside a $100 consumer GPS. That GPS has to have a
raw parts cost in the $40 range. Kindly find me a GPS engine, with a
66Mhz general purpose processor with FPU, memory, display, ROM/RAM etc
that can be purchased for that kind of money. Do you have any idea
how long a generalypurpose 32bit 66 Mhz processor would run on a set
of penlight batteries? Minutes, not hours...
If you could do it in a consumer product for $100-$200, there would
be no reason for anyone to buy an Ashtech or a Trimble Survey grade
GPS. There is a reason these things cost a lot more than a consumer
unit, and are a lot larger.
>
>One way of thinking of this: if the error at one point is 5 m south,
>the error at the next point a second later is going to be very close
>to 5m south as well, because the velocity is quite accurate. So the
>two errors are almost the same, not two independent vectors.
Except that the errors ARE random, and independent unless the two
measurements are made at exactly the same time. In fact the key to
high accuracy differential measurement is being able to get the
measurements at the same time so that you know the error at the fixed
point is the same as the error at the point you are measuring. If more
time parallax in the measurement, the less likely that is to be true.
This was especially true when SA was turned on, and SA was designed to
provide a "random walk".
The major component in the error is the changes is permability and
permitivity of free space, and as long the space between you and the
sat are being bombarded with random radiation, those changes will
remain random.
IF the error vectors were constant as you suggest, then when you start
up a GPS, or when you stop moving, it should instantly report a zero
velocity. It does not. It eventually figures out after a few seconds
that the velocity is zero, because the position is a random walk about
the true location.
>>But in fact what GPS receivers do is considerably more complex.
>>There's a Kalman filter or something similar that takes into account
>>both position and Doppler data from each satellite being tracked,
>>and calculates a running estimate of your current velocity and position.
>>Apparently the velocity estimate tends to be quite good, better than
>>you'd expect from the position accuracy.
>
>
> You are also assuming much mores sophisticated electronics then anyone
> can afford to put inside a $100 consumer GPS. That GPS has to have a
> raw parts cost in the $40 range. Kindly find me a GPS engine, with a
> 66Mhz general purpose processor with FPU, memory, display, ROM/RAM etc
> that can be purchased for that kind of money. Do you have any idea
> how long a generalypurpose 32bit 66 Mhz processor would run on a set
> of penlight batteries? Minutes, not hours...
The interesting thing about GPS is that the problem is very constant and very
well defined. Develeopers thus can continue optimizing - there is no need as in
normal computer applications to start all over again.
Given that a 8086 with rather minimal hardware support was able to do this (how
much electronics on a ASIC when the first Garmins came out?), Moore's law now
gives that much more computing power to spend on _exactly_ the same problem.
Not every fast processor is a Pentium. If you look at
http://www.atmel.com/atmel/acrobat/doc0749.pdf they even show an e-map as an
example application for the ARM cores. The AT91R40008 is an actual device one
can buy (http://www.atmel.com/atmel/acrobat/doc1393.pdf) with a standby current
of 12.5 uA, and if run at 3.3 volts, it uses around 1.4 milliwatts/MHz. Thus,
185 milliwatts for 40 MHz. A bit much, so hopefully we can run at lower clock
and voltage - at 2 volts the power is less than a third.
Thomas
Never in my wildest dreams did I imagine the III+ was that close. Having
watched my GPS II be a few seconds off world time until I reset it in
some way (I forgot how), I tend to check WWV for the exact time and smile
when the GPS agrees. The III+ isn't built to be primarily a time machine.
> and a CPU capable of doing the math to convert pseudoranges to positions
> on the earth at least once a second?
Having seen 2 MHz 8080's doing complex calculations rather rapidly, that
part didn't faze me. But it is pretty cool when you throw in mapping on
a 386.
--
.signature in flux
I posted about my apartment building's high-speed flight over Lafayette
IN a while back.
> That's rf interference, or multipath, or sv switching, or poor HDOP,
> or alien spacecraft interference ;-\
In my case it was bad geometry coupled with a south-only view of the sky.
(Well, perhaps an alien or two.)
--
.signature in flux
I'm still baffled. I've had good lock and 0.6 MPH standing still for
half-hour periods. That's as close to a constant speed as is practical
(zero relative to geoid, and as constant as earth-satellite motion gets
in real terms). I'm sure propagation and other factors did it, but that
still leaves me outside that 0.1 MPH under what seemed to be normal
conditions.
--
.signature in flux
>You are also assuming much mores sophisticated electronics then anyone
>can afford to put inside a $100 consumer GPS. That GPS has to have a
>raw parts cost in the $40 range. Kindly find me a GPS engine, with a
>66Mhz general purpose processor with FPU, memory, display, ROM/RAM etc
>that can be purchased for that kind of money. Do you have any idea
>how long a generalypurpose 32bit 66 Mhz processor would run on a set
>of penlight batteries? Minutes, not hours...
First, the correlators in the GPS receiver have to remain in sync with
the transmitted signal in order to receive it *at all*. To do this,
they need a local chip clock source whose frequency depends on the
amount of Doppler shift produced by the relative velocity between
satellite and receiver, as well as local oscillator error. Once the
receiver is locked to enough satellites to navigate, the local
oscillator error is known precisely and can be factored out, leaving
only Doppler.
So *every* GPS receiver has a number proportional to Doppler shift
available for every receiver channel, as a necessary part of receiving
the signal. They could choose to ignore it, but if they want to use the
info it costs no extra hardware.
As for the CPU, there's no need for it to have a FPU. There are
libraries that can do arbitrarily complex floating point computations
using software floating point. They're slow, but produce the same
result and hardware FP implementations. A handheld GPS receiver only
calculates its position once a second, and you can do an awful lot of
software floating point operations in one second on even the simplest
processor.
About power consumption: Apparently recent Garmins use an ARM processor;
I don't know which one. I went to ARM's web site, on their "Core
Selection" page, and simply picked the first processor: ARM7TDMI. This
CPU core will run at up to 133 MHz and has both 32 and 16-bit
instruction sets. The power consumption (when made with a 130 micron
process) is 60 microwatts per MHz. That's 8 mW running at full speed.
A pair of NiMH AA cells would power this for about 500 hours. That's
slightly longer than "minutes".
(Also, this assumes that the CPU is running full-speed all the time.
The ARM is a static CMOS device, so its clock can be drastically slowed
down when it's idle, with power consumption reducing in proportion to
the clock speed change).
> If you could do it in a consumer product for $100-$200, there would
>be no reason for anyone to buy an Ashtech or a Trimble Survey grade
>GPS. There is a reason these things cost a lot more than a consumer
>unit, and are a lot larger.
I expect that those units have lower-noise receivers, since they're
trying to make precision carrier phase measurements. The software is
trying to figure out exactly *which* carrier phase cycle the receiver
antenna is located in, which I imagine is expensive. Some of these
receivers are also listening to the military GPS frequency, using it to
estimate signal delays in the ionosphere. Survey grade units are
*doing* more than consumer handhelds. Finally, these are mostly not
handheld units, are manufactured in much lower volume, and sold to an
entirely different market, so it's not surprising that they are much
more expensive.
>>One way of thinking of this: if the error at one point is 5 m south,
>>the error at the next point a second later is going to be very close
>>to 5m south as well, because the velocity is quite accurate. So the
>>two errors are almost the same, not two independent vectors.
>Except that the errors ARE random, and independent unless the two
>measurements are made at exactly the same time. In fact the key to
>high accuracy differential measurement is being able to get the
>measurements at the same time so that you know the error at the fixed
>point is the same as the error at the point you are measuring. If more
>time parallax in the measurement, the less likely that is to be true.
Which errors change significantly over the span of one second? The
atmospheric signal path isn't going to change much. The satellite
clocks aren't going to drift much in that period. Receiver noise is
independent, but it's a small part of the error.
Someone (Wolfgang?) observed that in the post-SA world the Coast Guard
DGPS corrections change only very slowly. Some manufacturer recently
obtained a patent for a single-unit differential GPS process where you
first use the receiver as a reference station at a known location,
calculating range errors for each satellite being received. Then you
use the same receiver as a rover, moving it to the location you want to
survey, and simply assume that the errors haven't changed since you
measured them. Apparently this gives good accuracy up to *30 minutes*
between the reference and "rover" observations. All of this says that
the errors don't change much over the span of one second.
>This was especially true when SA was turned on, and SA was designed to
>provide a "random walk".
But SA is no longer a factor in any GPS use today, and people are asking
what sort of velocity accuracy they get today.
>The major component in the error is the changes is permability and
>permitivity of free space, and as long the space between you and the
>sat are being bombarded with random radiation, those changes will
>remain random.
How much random variation in time of flight can be expected over a
period of one second?
>IF the error vectors were constant as you suggest, then when you start
>up a GPS, or when you stop moving, it should instantly report a zero
>velocity. It does not. It eventually figures out after a few seconds
>that the velocity is zero, because the position is a random walk about
>the true location.
There is still noise, and some error in the measurements. But the
information that Sam posted suggests that the error is on the order of
0.2 m/s. You were suggesting that two measurements taken one second
apart could have 5 or 10 m of *difference* in their position errors,
and that velocity is calculated only by position difference, so the
velocity errors could be 5 or 10 m/s. In fact, velocity errors are not
zero, but they're nowhere near as large as you suggested.
Dave
>Not every fast processor is a Pentium. If you look at
>http://www.atmel.com/atmel/acrobat/doc0749.pdf they even show an e-map as an
>example application for the ARM cores. The AT91R40008 is an actual device one
>can buy (http://www.atmel.com/atmel/acrobat/doc1393.pdf) with a standby current
>of 12.5 uA, and if run at 3.3 volts, it uses around 1.4 milliwatts/MHz. Thus,
>185 milliwatts for 40 MHz. A bit much, so hopefully we can run at lower clock
>and voltage - at 2 volts the power is less than a third.
The current ARM cores seem to use much less power. The ARM7TDMI when
built with a 130 micron process uses 0.06 mW/MHz. The ARM720T, which
has the same CPU plus cache, MMU, and write buffer, uses 0.2 mW/MHz in
the same process. This is operating at 1.2 V.
So power consumption drops dramatically as feature size and power supply
voltage decrease.
Dave
>> But you're OK with the idea that it has ~10 nanosecond timing accuracy
>Never in my wildest dreams did I imagine the III+ was that close. Having
>watched my GPS II be a few seconds off world time until I reset it in
>some way (I forgot how), I tend to check WWV for the exact time and smile
>when the GPS agrees. The III+ isn't built to be primarily a time machine.
Internally, it has to be able to measure time that accurately. The
speed of light is 3e8 m/s, so 10 nS error in timing is 3 m error in
apparent distance to the satellite. However, handheld GPS receivers
make no attempt to update the screen with anything like that accuracy.
But a GPS receiver board designed for timing can provide an external
timing signal accurate to a few tens of nanoseconds.
Dave
What happened to your position during that period? Did it actually
proceed at 0.6 MPH in some direction, more or less? Or did it just
wander around within an area of a few meters in radius? If the latter,
what was the speed of motion calculated from successive points?
I wonder whether the "0.6 MPH" speed was just due to a bug in the user
interface, not a calculated result. Even with some amount of random
(phantom) motion, it seems very unlikely that the random motion would
always be at 0.6 MPH - it should fluctuate up and down.
What receiver was this?
Dave
"Lawrence Glickman" <lgli...@ameritech.net> wrote in message
news:grq9ouc2hv0c9b399...@4ax.com...
> On Sun, 15 Sep 2002 10:11:04 -0500, "Clifton T. Sharp Jr."
> <cli...@clifto.com> wrote:
>
> >I posted about my apartment building's high-speed flight over Lafayette
> >IN a while back.
>
> Yes indeed, that is what I was trying to remember.
> Sometimes buildings really do those things, but usually only with the
> help of a tornado or hurricane.
>
> >> That's rf interference, or multipath, or sv switching, or poor HDOP,
> >> or alien spacecraft interference ;-\
> >
> >In my case it was bad geometry coupled with a south-only view of the sky.
> >(Well, perhaps an alien or two.)
>
> I've never seen a -real- alien, nor have I ever seen a UFO.
> I feel kind of left-out, considering how many people ( some credible )
> who claim to have seen these things ;-\
>
> Whatever is / might be *out there* seems to be beyond our reach. That
> might be a good thing, otoh, it might not. The idea that they would
> arrive with a cure for cancer is a bit naive IMHO. Rather, they might
> take a fancy to harvesting us like cattle.
>
>
> Lg
matt weber wrote:
> There is also an assumption that computers don't make mistakes. Hate
> to tell but they do.
You mean like the time my old GPS 45 (not so old at the time) directed
me to the wrong waypoint (ie, not the one I specified and the name of
which was displayed on the screen). I was in Pamlico Sound in North
Carolina, USA, and having just recently obtained the GPSR, was blithely
relying on it to navigate to Ocracoke, and not maintaining my dead
reckoning. Only when the soundings started to look funny, and the marks
off in the distance as well, did I realize the error. When I got close
enough to positively ID the next mark, it confirmed that the GPSr had
directed us to the wrong mark (one also in my list of waypoints, but not
in the route I was using). It would have taken me right across Brandt
Shoal, which my boat probably would have done successfully (4' 8"
draft), but someone with a deeper keel might have gotten a surprise.
I very carefully chacked the coordinates entered for each waypoint, and
it was clear that internally the GPSR had 'crossed' the two - select one
by name and it directed you to the other.
Chastened, I have ever since kept a dead reckoning track whenever I'm
out of sight of the next mark, and never again trusted a GPSR implicitly.
BTW, I sent the unit off to Garmin under warranty, with the screwy
waypoints still programmed inside. Without any sort of acknowledgement
of any problem, they quietly replaced the unit with one with a revised
firmware load. I never saw the problem again.
B.A.S.
P.S. I have a predilection for driving fast myself, but have you ever
seen what a car wrecked whilst doing 200+ kph looks like? That chunk of
metal that just fell off the truck around the turn up ahead can split
the most expensive tire, and that deer crossing the road from out of
nowhere doesn't follow any traffic rules. Such events are out of your
control, and I'd rather *not* be doing over 120 kph when either
happens... Which I guess is why as the father of two young kids I don't
wind it up like I used to...
> Jeremy Mortimer <mort...@ifrc.org> writes:
>
>>When I first got a GPS last winter I used it to see how fast I ski. I
>>was rather shocked (I don't consider myself a fast skier) to record a
>>maximum of 85kph on two successive days. If I go this fast on my bike
>>it feels fairly exciting, but apparently less so on skis.
>
> Keep in mind that most GPS receivers display only the *horizontal*
> component of speed. This is conventional in navigation. If you're
> going that fast skiing, you're probably on a fairly steep slope. If
> you measure the angle of the slope in the direction you're travelling
> with a clinometer, your actual 3D speed is the GPS reading times
> 1/cos(slope).
Hang on - is this actually true? I assumed so at first, but on reflection
I realised that since the GPSr knows your position and motion in three
dimensions, it would be simpler as well as more accurate (in cases where
it matters) for the speed indication to be the velocity in three
dimensions, not just the horizontal component.
The slope was probably 20-25 degrees, which would give up to about 93kph.
>>An idea - has anyone here used a GPS to check their terminal velocity
>>while skydiving?
>
> That's not very useful, because the GPS will give you only the
> horizontal component of your motion, and you probably don't know the
> inclination of your path. On the other hand, you can look at the
> track log later and calculate 3D velocity. But a barometric altimeter
> that calculates rate of descent is probably more useful.
I can see how horizontal drift off a straight descent might be of
interest to skydivers, but this seems a pretty singular example of a case
where the horizontal component of motion would be more useful than the
velocity in three dimensions.
Can you confirm that this is how a GPSr actually behaves? (Mine's a
Vista, if it makes any difference).
Jeremy
Jeremy Mortimer wrote:
> da...@cs.ubc.ca (Dave Martindale) wrote in
> news:alt842$ao0$3...@mughi.cs.ubc.ca:
>
>
>>Jeremy Mortimer <mort...@ifrc.org> writes:
>>
>>
>>>When I first got a GPS last winter I used it to see how fast I ski. I
>>>was rather shocked (I don't consider myself a fast skier) to record a
>>>maximum of 85kph on two successive days. If I go this fast on my bike
>>>it feels fairly exciting, but apparently less so on skis.
>>
>>Keep in mind that most GPS receivers display only the *horizontal*
>>component of speed. This is conventional in navigation. If you're
>>going that fast skiing, you're probably on a fairly steep slope. If
>>you measure the angle of the slope in the direction you're travelling
>>with a clinometer, your actual 3D speed is the GPS reading times
>>1/cos(slope).
>
>
> Hang on - is this actually true? I assumed so at first, but on reflection
> I realised that since the GPSr knows your position and motion in three
> dimensions, it would be simpler as well as more accurate (in cases where
> it matters) for the speed indication to be the velocity in three
> dimensions, not just the horizontal component.
Vertical position is not know with the same precission as horizontal
position and thus it can make the whole answer less accurate. This was
particularly true in the past when SA was present. Since most of the
standard methods were developed during SA there seemed to be no reason
to change this. On planet earth we thinkg alitude changes are
significant but truth be know the earth is fairly smooth. What seems
like a steep slope for your car is actually only a few percent and
horizontal speed represents this very well in practice. Of curse sky
divers, skiers, and hot air ballonists may have different tale.
>
> The slope was probably 20-25 degrees, which would give up to about 93kph.
>
>
>>>An idea - has anyone here used a GPS to check their terminal velocity
>>>while skydiving?
>>
>>That's not very useful, because the GPS will give you only the
>>horizontal component of your motion, and you probably don't know the
>>inclination of your path. On the other hand, you can look at the
>>track log later and calculate 3D velocity. But a barometric altimeter
>>that calculates rate of descent is probably more useful.
>
>
> I can see how horizontal drift off a straight descent might be of
> interest to skydivers, but this seems a pretty singular example of a case
> where the horizontal component of motion would be more useful than the
> velocity in three dimensions.
>
> Can you confirm that this is how a GPSr actually behaves? (Mine's a
> Vista, if it makes any difference).
>
> Jeremy
>
>
>
Your vista behaves like other gps receivers for velocity but it has a
separate reading for vertical speed so, if you wish you could correct
the overall speed on this unit with a calculator.
Dale
It wandered randomly within a small imaginary circle. It didn't occur to
me to keep a track log to investigate.
> I wonder whether the "0.6 MPH" speed was just due to a bug in the user
> interface, not a calculated result. Even with some amount of random
> (phantom) motion, it seems very unlikely that the random motion would
> always be at 0.6 MPH - it should fluctuate up and down.
More often I'd get a fluctuation, something like 0.0 - 0.6 - 0.7 - 0.0 -
0.7 - 0.6 - 0.8 - 0.6. Seemed like anything 0.5 or under was shown as
zero. But that one time, it was fairly steady.
> What receiver was this?
This was with my old GPS II. I haven't played with the III+ as much as
I played with that one.
--
.signature in flux
>> What receiver was this?
Is the GPS II one of the old single-channel receivers like the 38 and
45? Or is it a 12-channel receiver?
Dave
>> Keep in mind that most GPS receivers display only the *horizontal*
>> component of speed.
>Hang on - is this actually true? I assumed so at first, but on reflection
>I realised that since the GPSr knows your position and motion in three
>dimensions, it would be simpler as well as more accurate (in cases where
>it matters) for the speed indication to be the velocity in three
>dimensions, not just the horizontal component.
The GPS receiver internally calculates your 3D velocity, and it could
certainly report that. But navigation is normally done in 2D, with 2D
maps and positions on a (nearly) spherical surface. When the pilot in
an aircraft calculates that he's 500 miles from the destination, that
really means 500 miles on the surface, not the actual path length at 6
miles above the surface, and not including the extra diagonal distance
during the descent. So, to be consistent with this, speed and distance
to go are all reported as 2D measures. Vertical speed is dealt with
independently.
Dave
It's a single-channel. Handles up to eight birds.
--
.signature in flux
By looking in his mirror?
> Bye
--
I don't suffer from Insanity... | Linux User #16396
I enjoy every minute of it... |
|
http://www.travellingkiwi.com/
|