is this SA ?
Frank Hollis
>Is this an example of SA The car was parked for about 3 hours with my 12map
>powered on I did not drive this track.
>
>
>begin 666 sa.jpg
>M_]C_X `02D9)1@`!`0```0`!``#_VP!#``@&!@<&!0@'!P<)"0@*#!0-# L+
No. It's an example of being a plonker.
Please delete all newgroups from your subscribed list unitl you're
read news.announe.newusers
__
Frank J Hollis - fr...@chem.u-net.com http://www.chem.u-net.com/
These opinions have not been passed by 3 committes, 7 subcommittees
and 2 working parties. So they can't be the opinions of my employer
Steve Yeager
distance, but it looks like SA. Also, please don't include any binary
attachments in your NG posts. Put them on the web page instead and include
the link to it instead. 150 KB messages on NG can drive a lot of people
crazy. Not everyone has a cable modem or DSL yet, so, please be
considerate.
"newsflash" <u...@aol.com> wrote in message
news:sgjshrl...@corp.supernews.com...
Sam Wormley
>
> Yes, this looks like SA. I didn't convert the coordinates into actual
> distance, but it looks like SA. Also, please don't include any binary
> attachments in your NG posts. Put them on the web page instead and include
> the link to it instead. 150 KB messages on NG can drive a lot of people
> crazy. Not everyone has a cable modem or DSL yet, so, please be
> considerate.
>
Steve--That is NOT what SA looks like. See:
http://www.cnde.iastate.edu/staff/swormley/gps/Data/99081201.gif
http://www.cnde.iastate.edu/staff/swormley/gps/Data/99081301.gif
http://www.cnde.iastate.edu/staff/swormley/gps/Data/99081401.gif
http://www.ualberta.ca/~norris/navigation/GPS/PlotSA.html
__________________________________________________________________________
Sam Wormley - http://www.cnde.iastate.edu/staff/swormley/gps/check_sa.html
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Steve Yeager
3 minutes. Please note the magnification scale on the original picture.
This is exactly how your hairball was started. I have done pictures like
yours and his myself.
"Sam Wormley" <swor...@cnde.iastate.edu> wrote in message
news:390AD9E2...@cnde.iastate.edu...
Sam Wormley
>
> Your SA picture is collected over a long period of time, his only during the
> 3 minutes. Please note the magnification scale on the original picture.
> This is exactly how your hairball was started. I have done pictures like
> yours and his myself.
>
I count 27-28 points on the plot, and assuming uniform sampling
that comes out to be one data point evry 6 minutes and 40 seconds.
So it is entirely possible that the jagged picture is due to under
sampling. The north-south excursion is about 500 meters, which is
about five times more than one would expect from SA alone.
-Sam
Steve Yeager
> that comes out to be one data point evry 6 minutes and 40 seconds.
> So it is entirely possible that the jagged picture is due to under
> sampling. The north-south excursion is about 500 meters, which is
> about five times more than one would expect from SA alone.
>
you accurate position under all or even the best conditions. Poor
geometry, obstructions, reflections, radio interference, etc. Perhaps I use
SA as a general term for all the errors you may encounter. I made similar
tests just out of interest with my GPS extended out of the window and
sometimes the position takes long walks for no apparent reason. If you
want, you can look at my hairball at http://www.erols.com/syeager/gps :)
Juri Munkki
>I count 27-28 points on the plot, and assuming uniform sampling
>that comes out to be one data point evry 6 minutes and 40 seconds.
>So it is entirely possible that the jagged picture is due to under
>sampling. The north-south excursion is about 500 meters, which is
>about five times more than one would expect from SA alone.
SA is pretty easy to observe on a handheld Garmin, if you change
the tracklog to record points every few seconds or so. The default
setting of using resolution-based tracklog gathering will try to
convert SA into line segments - it looks very messy. Using a fixed
recording interval will result in smooth plots.
I haven't looked at the picture that started this thread. I just thought
I would mention this, in case anyone wants to observe SA while sunbathing
at the beach or while waiting in the car.
Basic stuff:
Large, sudden jumps in position are most likely due to changes in
satellite visibility. If most satellites are for instance South of
you, then the error will be greatest on the North/South direction.
If even one satellite can be aquired North, geometry will improve
radically and the reduction in error will cause a sudden leap in
position. Without SA, the errors would of course be less and thus
the leaps would also be smaller.
--
Juri Munkki jmu...@iki.fi What you see isn't all you get.
http://www.iki.fi/jmunkki Windsurfing: Faster than the wind.
John Galvin
Juri Munkki wrote in message <8eh0uq$o56$1...@nntp.hut.fi>...
>
>Large, sudden jumps in position are most likely due to changes in
>satellite visibility. If most satellites are for instance South of
>you, then the error will be greatest on the North/South direction.
>If even one satellite can be aquired North, geometry will improve
>radically and the reduction in error will cause a sudden leap in
>position. Without SA, the errors would of course be less and thus
>the leaps would also be smaller.
>
>--
>Juri Munkki jmu...@iki.fi What you see isn't all you get.
>http://www.iki.fi/jmunkki Windsurfing: Faster than the wind.
>
Some GPS receivers do not instantaneously begin using data from a newly
acquired satellite. Instead, they will slowly increase the "weighting" of
the newly acquired satellite in the position solution, over a period of
time. This tends to reduce the incidence of sudden jumps in reported
position. Eventually, it will still end up reporting a position that is
largely different than before the new satellite was acquired. The real
value of this time variant weighting is that, there is a very high
probability that a newly acquired satellite that just barely exceeds the snr
threshold, will be lost just as quickly as it was acquired. This would
result in a second large jump in the reported position. The time variant
weighting tends to reduce these sorts of large jumps in reported position.
John Galvin
Janne Sinkkonen
> Some GPS receivers do not instantaneously begin using data from a
> newly acquired satellite. Instead, they will slowly increase the
> "weighting" of the newly acquired satellite in the position
> solution, over a period of time.
Jumps are optimal if one only cares about the error of the
position. What you describe makes sense if one gives some weight to
the errors of speed as well. Alternatively, one may say that in the
first case there's an underlying model where position is independent
across time - in the latter case there is a model with some
continuity in position, which makes the concept of speed make sense.
It would be nice if these things could be selected by the user.
--
Janne
Bob Gross
>It would be nice if these things could be selected by the user.
can be set wrong will be set wrong by the stupid user who refused
to RTFM. Then he will complain that the product should have kept
him from setting it wrong. In general, in a prototype product
that is being used by trained users, then having all of those
special settings is a good thing. In general, in a finished
consumer product that is being used by untrained users, then
having as much automatic as possible is the way to go. This was
learned in the School of Hard Knocks, Silicon Valley Campus,
class number 1989-301.
---Bob Gross---
Janne Sinkkonen
> Yes, but remember, these are "consumer" products. Anything that
> can be set wrong will be set wrong by the stupid user who refused
> to RTFM. Then he will complain that the product should have kept
> him from setting it wrong. In general, in a prototype product
> that is being used by trained users, then having all of those
> special settings is a good thing. In general, in a finished
> consumer product that is being used by untrained users, then
> having as much automatic as possible is the way to go. This was
> learned in the School of Hard Knocks, Silicon Valley Campus,
> class number 1989-301.
Good point and I agree with you. Still, I would _personally_ like to
see such a feature.
--
Janne
John Galvin
As I've pointed out in this newsgroup many times before, the speed reported
by GPS receivers is not calculated by taking the derivative of position with
respect to time. Speed, or more correctly, velocity is calculated in much
the same manner as position. It's just that the measured doppler shift of
the carrier frequency for each individual satellite is used, instead of the
pseudorange. So there may very well not be a large jump in reported
velocity, even though there is one in reported position. The real value of
the time variant weighting of the satellite data, is during temporary
obstruction of the signal from one or more satellites. In that case, the
GPS receiver can begin "estimating" the pseudorange and doppler shift for
the satellite(s) that are no longer being received and use that in the
position and velocity solution. Once this estimating is begun, the receiver
begins to smoothly de-weight the contribution of that satellite over time,
until it is not being used at all. Should that satellite signal become
available again, the de-weighting is reversed until that satellite's data is
being fully used again. The price to be paid for this is, as you have
implied, a somewhat slower improvement in positional accuracy, in the case
where an additional satellite signal becomes available and stays available.
The time constant used in the weighting/de-weighting algorithm will
determine how slow the response is. There is some suggestion that this time
constant could be a function of the intended application platform. That is,
aircraft Vs automobile Vs marine Vs pedestrian.
For the technically pedantic reader, I am fully aware that the preceding
explanation has taken some liberties in the area of terminology. It was
done to keep the focus on the matter at hand.
John Galvin
Janne Sinkkonen wrote in message ...
>It would be nice if these things could be selected by the user.
>
>--
>Janne
>
Mark McIntyre
>SA is pretty easy to observe on a handheld Garmin, if you change
>the tracklog to record points every few seconds or so.
How can you change this ???
Mark McIntyre
Juri Munkki
>On 30 Apr 2000 10:12:42 GMT, jmu...@alpha.hut.fi (Juri Munkki) wrote:
>
>>SA is pretty easy to observe on a handheld Garmin, if you change
>>the tracklog to record points every few seconds or so.
>
>How can you change this ???
On a GPS 12 Map (or GPS III+):
Main menu ->
Track Logs ->
menu -> Setup Logging ->
Interval: Time
Interval value: xx seconds
The track log will fill up relatively quickly, if the interval is short.
Instead of using time interval, you can also use distance interval, if
you set the distance short enough. This way if you are staying still and
SA is moving very slowly, the track log may last longer. If you start
moving quickly, it will be used faster.
Even resolution mode will allow you to see SA in effect, but the interval
value has to be set really low.
Janne Sinkkonen
> As I've pointed out in this newsgroup many times before, the speed
> reported by GPS receivers is not calculated by taking the derivative
> of position with respect to time. Speed, or more correctly,
> velocity is calculated in much the same manner as position. It's
> just that the measured doppler shift of the carrier frequency for
> each individual satellite is used, instead of the pseudorange.
Are you sure even the cheapest handhelds do this?
For example Garmins has a thermometer to compensate for drifts in its
own oscillator. Unless the carrier frequencies of the satellites are
compared to each other, I fail to see how the unit can accurately
measure Doppler shifts.
--
Janne
Sam Wormley
Thomas Tonino
> For example Garmins has a thermometer to compensate for drifts in its
> own oscillator. Unless the carrier frequencies of the satellites are
> compared to each other, I fail to see how the unit can accurately
> measure Doppler shifts.
Actually you can. What is meant that any 4 satellites will not only give
you position, but also rate of change of position. When a 5th sat comes
into view, the calculated position changes. The fifth sat will together
with any 3 out of the previous 4 also deliver a rate of change of
position.
This second speed may be different from the first, just as the first
position was different from the second. But just as the positions are
similar, the speeds also will be similar. Ans even if the position would
move a hundred meters back, both velocities could tell you you are going
forward.
If you have more than 4 sats in view you throw away information if you
calculate the position. It is better to start with thre 4 sats again to
determine the speed instead of using the thinned out data that is the
position.
And why there is a temperature compensated clock? My guess is that this
is locked against the satellites. It allows you to calculate a position
if you do not receive all sats at once, but in quick (or slow, if your
clock is very stable) succession: such as when passing an intersection.
Thomas
Janne Sinkkonen
> Actually you can. What is meant that any 4 satellites will not only give
> you position, but also rate of change of position. When a 5th sat comes
> into view, the calculated position changes. The fifth sat will together
> with any 3 out of the previous 4 also deliver a rate of change of
> position.
>
> This second speed may be different from the first, just as the first
> position was different from the second. But just as the positions are
> similar, the speeds also will be similar. Ans even if the position would
> move a hundred meters back, both velocities could tell you you are going
> forward.
>
> If you have more than 4 sats in view you throw away information if you
> calculate the position. It is better to start with thre 4 sats again to
> determine the speed instead of using the thinned out data that is the
> position.
Are you essentially saying that it is better to differentiate before
computing the position than afterwards?
Some receivers (for example Garmins) use overdetermined solutions.
But I think I got the point (or a point, if you meant something else. :))
> And why there is a temperature compensated clock? My guess is that this
> is locked against the satellites. It allows you to calculate a position
> if you do not receive all sats at once, but in quick (or slow, if your
> clock is very stable) succession: such as when passing an intersection.
Garmins also 'learn' a compensation curve (compensation as a function
of temperature). It suggests that the compensation is somehow used to
acquire the lock (but all this now seems to be unrelated to the
velocity thing).
--
Janne
Thomas Tonino
> Are you essentially saying that it is better to differentiate before
> computing the position than afterwards?
Yes.
> Some receivers (for example Garmins) use overdetermined solutions.
>
> But I think I got the point (or a point, if you meant something else. :))
Good for Garmin. But at the moment you have a position and an extra
satellite comes into range, the position will change, even if you are
stationary. If you differentiate position to get speed, you'd see a
spike.
If you use the satellites that you see to determine a speed directly,
the extra satellite will make that speed more accurate. Maybe it will
jump as well - but from the old to the new speeds, and not with some
wild excursion in between to make up for the difference in positions.
> Garmins also 'learn' a compensation curve (compensation as a function
> of temperature). It suggests that the compensation is somehow used to
> acquire the lock (but all this now seems to be unrelated to the
> velocity thing).
I think it makes it faster. The clock must run at the ciorrect speed for
lock to occur. If it does, lock can be very quick.
Thomas
Wolfgang Rupprecht
[ On the theory that the best way to draw out discussion on usenet is
to state something wrong, let me let me state how I picture this as
working and perhaps the heavy-weights will correct any
misconceptions. -wsr ]
Janne Sinkkonen <ja...@nnets.fi> writes:
> Are you essentially saying that it is better to differentiate before
> computing the position than afterwards?
From what I understand, one can also argue that the Doppler
information is essentially a primary datum collected.
The way I see it, the satellites transmitter's and GPS receiver's
local oscillators have to be phase locked before data can be
recovered. The Doppler data could then be directly generated by
measuring the frequency control signal to the receiver's VCO(*). One
would use temperature lookup table to correlate the VCO control at
that ambient temperature back to an actual frequency offset -- the
Doppler.
The temperature lookup table could be recalibrated periodically by
calculating the expected Doppler from delta-position / delta-time
calculations.
-wolfgang
(*) I assume that each correlator's VCO is really a digital PLL
connected to a cheap crystal oscillator. That would allow one to use
the same temperature compensation table to relate the PLL control
setting to the PLL output frequency for each of the correlator
"channels".
--
Wolfgang Rupprecht <wolfga...@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
Joe Mehaffey
I believe that the correct term would be that the oscillator in the GPS
receiver is FREQUENCY locked to the satellite's clock and not PHASE
locked. The phase is constantly chaning between the local GPS
oscillator and any given SV's oscillator. However, the FREQUENCY of
the local GPS oscillator can be locked and then the phase can (or is) be
used to determine rate of change of distance between a given SV and the
GPS.
Please let me know if I have this concept incompletely understood.
Joe Mehaffey
--
Got a Question about GPS technology? Looking for a GPS FAQ site?
See: http://joe.mehaffey.com
Wolfgang Rupprecht wrote:
> The way I see it, the satellites transmitter's and GPS receiver's
> local oscillators have to be phase locked before data can be
> recovered. The Doppler data could then be directly generated by
> measuring the frequency control signal to the receiver's VCO(*). One
> would use temperature lookup table to correlate the VCO control at
> that ambient temperature back to an actual frequency offset -- the
> Doppler.
>
>
Wolfgang Rupprecht
Joe Mehaffey <j...@mehaffey.com> writes:
> I believe that the correct term would be that the oscillator in the GPS
> receiver is FREQUENCY locked to the satellite's clock and not PHASE
> locked. The phase is constantly chaning between the local GPS
> oscillator and any given SV's oscillator. However, the FREQUENCY of
> the local GPS oscillator can be locked and then the phase can (or is) be
> used to determine rate of change of distance between a given SV and the
> GPS.
>
> Please let me know if I have this concept incompletely understood.
I understand the PLL/FLL distinction.
I just don't see a simple way to do a frequency lock without also
doing a phase lock. Wouldn't the correlator tracking circuits be
"edge sensing" in the sense that they try to line up the phase of the
transmitted signal and that channel's VCO because doing so gets one
the largest correlation? I'm of course assuming that the spread
spectrum "chips" (as in a Spread spectrum data bit, not an integrated
circuit) are clocked by the same clock that generates the
transmitter's 1.5Ghz RF signal. Perhaps thats wrong and I was
simplifying things too much in my mind???
-wolfgang
Dave Martindale
>I believe that the correct term would be that the oscillator in the GPS
>receiver is FREQUENCY locked to the satellite's clock and not PHASE
>locked. The phase is constantly chaning between the local GPS
>oscillator and any given SV's oscillator. However, the FREQUENCY of
>the local GPS oscillator can be locked and then the phase can (or is) be
>used to determine rate of change of distance between a given SV and the
>GPS.
In the case of the Garmin receivers, I doubt if the local oscillator
is even frequency locked. Most likely, it simply runs free. The
software knows the error in the frequency (either from the temperature
and lookup table at startup, or from recent observations if locked)
and simply factors this frequency error into its calculations of
what to load into the receiver channels, along with other things like
Doppler shift which also affect the receive frequency.
If the receiver has sufficient frequency agility to compensate for
the Doppler shift of a rapidly-moving satellite, compensating for a
(known) local oscillator error should require no extra hardware, just
a bit of extra computation.
Dave
Dave Martindale
>I just don't see a simple way to do a frequency lock without also
>doing a phase lock.
I don't think you can either phase or frequency lock to the satellite
signals at all - since every satellite has a different Doppler shift.
You *could* frequency lock the local oscillator to GPS time, by
taking the time offset that pops out of every position calculation,
filtering it, and using it to steer the local oscillator.
But, as discussed in a previous article in this thread, I don't see
why you need to frequency lock the local oscillator at all - all you
really need to know is what its current frequency error is.
>Wouldn't the correlator tracking circuits be
>"edge sensing" in the sense that they try to line up the phase of the
>transmitted signal and that channel's VCO because doing so gets one
>the largest correlation?
To get a good signal out of the correlator, you have to match the
transmitted frequency both in instantaneous phase and chip rate.
If the chip rate is wrong, the phase soon slips and you lose the
signal. But again, every channel of the receiver is operating at
a slightly different chip rate due to Doppler shift.
>I'm of course assuming that the spread
>spectrum "chips" (as in a Spread spectrum data bit, not an integrated
>circuit) are clocked by the same clock that generates the
>transmitter's 1.5Ghz RF signal. Perhaps thats wrong and I was
>simplifying things too much in my mind???
No, that's correct. The 50 Hz data stream, the 1.023 MHz chip clock,
and the 1575.42 MHz transmitter oscillator are all synchronized to
the same master clock. That's why counting carrier cycles can give
such good accuracy - because the carrier and chip clocks are locked
together at the transmitter.
Dave
Joe Mehaffey
I would think that frequency would be locked by using an output of the
Kalman filter to "lock" the frequency using long term filtered GPS
time. I do not believe you can lock anything directly to any of the
SV's signals as there is <almost> constant and contantly changing
doppler on those signals.
John Galvin
No, that is not how it works.
There is a master oscillator, that is locked to GPS time. This master
oscillator is used, efectively to measure the shift in carrier frequency for
each satellite. THAT, is the doppler shift. This doppler shift, suitably
corrected for relativistic effects, is the differential velocity between the
receiver and the satellite. If you take 3 of these velocities, you can
calculate the net ecef xyz velocity. From that you can extract the ground
speed and bearing. All this can be done without ever calculating what your
position is. This calculation is entirely independent of any position
calculation.
There is an important distinction here, in that velocity is being derived
from the measured doppler shift using the carrier tracking loop. The
carrier tracking loop is much quieter than the code tracking loop that
measures the pseudorange to the satellite. Furthermore, if you were to take
the derivative of the pseudorange, with respect to time, it would be even
more noisy than the already noisy, pseudorange. The carrier tracking loop
derived doppler shift, fundamentally measures the velocity with no
derivative involved. Since we're starting with a quieter signal and then
NOT taking a derivative, we end up with a much much better velocity
estimate.
Perhaps we are in agreement here. I can't tell. You have used the term
"rate of change of position". To me, this implies taking the derivative of
position with respect to time. This is not being done.
John Galvin
Thomas Tonino wrote in message <390D7AE0...@bio.vu.nl>...
>Janne Sinkkonen wrote:
>
>> For example Garmins has a thermometer to compensate for drifts in its
>> own oscillator. Unless the carrier frequencies of the satellites are
>> compared to each other, I fail to see how the unit can accurately
>> measure Doppler shifts.
>
>Actually you can. What is meant that any 4 satellites will not only give
>you position, but also rate of change of position. When a 5th sat comes
>into view, the calculated position changes. The fifth sat will together
>with any 3 out of the previous 4 also deliver a rate of change of
>position.
>
>This second speed may be different from the first, just as the first
>position was different from the second. But just as the positions are
>similar, the speeds also will be similar. Ans even if the position would
>move a hundred meters back, both velocities could tell you you are going
>forward.
>
>If you have more than 4 sats in view you throw away information if you
>calculate the position. It is better to start with thre 4 sats again to
>determine the speed instead of using the thinned out data that is the
>position.
>
>And why there is a temperature compensated clock? My guess is that this
>is locked against the satellites. It allows you to calculate a position
>if you do not receive all sats at once, but in quick (or slow, if your
>clock is very stable) succession: such as when passing an intersection.
>
>
>Thomas
>
John Galvin
Thomas Tonino wrote in message <390D9500...@bio.vu.nl>...
>Janne Sinkkonen wrote:
>
>> Are you essentially saying that it is better to differentiate before
>> computing the position than afterwards?
>
>
>> Some receivers (for example Garmins) use overdetermined solutions.
>>
>> But I think I got the point (or a point, if you meant something else. :))
>
>Good for Garmin. But at the moment you have a position and an extra
>satellite comes into range, the position will change, even if you are
>stationary. If you differentiate position to get speed, you'd see a
>spike.
>
Yes, I think we are in agreement there.
>If you use the satellites that you see to determine a speed directly,
>the extra satellite will make that speed more accurate. Maybe it will
>jump as well - but from the old to the new speeds, and not with some
>wild excursion in between to make up for the difference in positions.
>
Yes, this is one of the original points I was trying to make. When you say
"determine a speed directly", Do you mean, the doppler shift derived
velocity of that satellite, with respect to the GPS receiver? If yes, I
totally agree.
>> Garmins also 'learn' a compensation curve (compensation as a function
>> of temperature). It suggests that the compensation is somehow used to
>> acquire the lock (but all this now seems to be unrelated to the
>> velocity thing).
>
>I think it makes it faster. The clock must run at the ciorrect speed for
>lock to occur. If it does, lock can be very quick.
>
Well, no. Actually, it does not have to run at the correct speed for lock
to occur. The apparent doppler shift will be wrong though. The carrier
tracking loop relies on the master oscillator being at precisely the correct
frequency, to accurately measure the doppler shift. If the master
oscillator is at the wrong frequency, the carrier and code tracking loops
can still be locked, but they will produce incorrect data. This is normal
when lockon is first achieved. Once 4 satellites are being received, the
4th dimension (time) can be calculated from the pseudorange data. This
"time" data, is then used to correct the frequency of the master oscillator.
I know it sounds like wheels within wheels, but it does all work.
John Galvin
John Galvin
Yes, I am sure that even the cheapest units do this. The thermometer in the
Garmin's is used primarily to establish a starting point for the carrier
tracking loop, when you first turn the power on. After that, the reference
oscillator tracks the incoming satellite signals. So long as you have at
least 4 satellites in the solution, you can solve for GPS time. This
GPS time, is used to keep the reference oscillator precisely locked to
GPS time. This is what makes measurement of doppler shift possible.
John Galvin
Janne Sinkkonen wrote in message ...
>"John Galvin" <lgalvin...@pacbell.net> writes:
>
>> As I've pointed out in this newsgroup many times before, the speed
>> reported by GPS receivers is not calculated by taking the derivative
>> of position with respect to time. Speed, or more correctly,
>> velocity is calculated in much the same manner as position. It's
>> just that the measured doppler shift of the carrier frequency for
>> each individual satellite is used, instead of the pseudorange.
>
>Are you sure even the cheapest handhelds do this?
>
>For example Garmins has a thermometer to compensate for drifts in its
>own oscillator. Unless the carrier frequencies of the satellites are
>compared to each other, I fail to see how the unit can accurately
>measure Doppler shifts.
>
>--
>Janne
>
John Galvin
Janne Sinkkonen wrote in message ...
>Are you essentially saying that it is better to differentiate before
>computing the position than afterwards?
>
There is no differentiation going on. The velocity of each satellite
relative to your receiver is measured directly, with no differentiation.
>Some receivers (for example Garmins) use overdetermined solutions.
>
>But I think I got the point (or a point, if you meant something else. :))
>
>> And why there is a temperature compensated clock? My guess is that this
>> is locked against the satellites. It allows you to calculate a position
>> if you do not receive all sats at once, but in quick (or slow, if your
>> clock is very stable) succession: such as when passing an intersection.
>
>Garmins also 'learn' a compensation curve (compensation as a function
>of temperature). It suggests that the compensation is somehow used to
>acquire the lock (but all this now seems to be unrelated to the
>velocity thing).
>
Not just Garmin's. Most, if not all, GPS receivers continually adapt the
temperature compensation curve, to account for aging of the master
oscillator. This temp compensation is not needed once lockon is achieved.
It only helps to narrow down, the search for the first satellite. That is,
the receiver can make an accurate guess as to how to adjust the master
oscillator to be very close to the same frequency as the clock in the GPS
satellites. Not having a close guess, means that the receiver would have to
search a much wider range of apparent carrier frequencies, before lockon
would occur.
Once lockon with 4 satellites does occur, the master oscillator is then
synchronized to the GPS clock on board the satellites. Here, there is a
turnabout and the temp compensation curve is then updated to reflect what
control voltage to the master oscillator is being used for a given
temperature.
John Galvin
Dave Martindale
>I know it sounds like wheels within wheels, but it does all work.
"Any sufficiently advanced science is indistinguishable from magic".
(So who said that?)
Dave
John Galvin
I told myself I wasn't going to get into this any deeper, but oh well, here
goes.
From the Navstar GPS User Equipment Introduction:
1.4.2.5 Carrier Tracking and Data Detection
The receiver tracks the satellite carrier by adjusting the frequency
synthesizers to produce a
stationary phase at the output of the code tracking loop.
So, in that sense the carrier tracking loop is a phase locked loop
More:
1.4.2.4 Code Tracking
The code tracking loop is used to make pseudorange measurements between the
GPS satellites
and the GPS receiver. The receiver's code tracking loop generates a replica
of the C/A-code of
the targeted satellite. The estimated doppler is removed by the phase
rotation circuit prior to the correlator.
In order to align the received signal with the internally generated replica,
the internally generated code is systematically slewed past the received
signal. Typically the output of the correlator is integrated over 1 to 10
ms. If correlation is not detected the phase of the internally generated
code is advanced by one chip. If correlation is not detected after the whole
code has been searched the doppler is adjusted and the process repeated
until correlation is achieved. Code synchronization is initially maintained
by also correlating the received signal with half chip early and late codes.
A simple feedback system keeps the prompt ("on time") code correctly
positioned. To extract the carrier which is still modulated by the
navigation message, the prompt code is subtracted from the incoming signal.
The delay that the receiver must add to the replica code to achieve
synchronization (correlation), multiplied by the speed of light, is the
pseudorange measurement. Once the carrier is reconstructed, the center
frequency of the replica code is adjusted using Doppler measurements from
the carrier tracking loop to achieve a precise frequency lock to the
incoming signal, thereby allowing more precise pseudorange measurements.
The bandwidth of the code tracking loop is typically 0.1 Hz, which implies
that independent measurements are available at approximately 10 s intervals.
Be careful here. That statement about adjusting the center frequency of the
replica code to achieve precise frequency lock, might lead one to believe
that this is a frequency locked loop. In a true PLL as opposed to a DLL
(delay locked loop), the control effort in response to phase error is to
adjust the frequency of the VCO. In this case, the VCO is a bit more
complicated, since it is the replica code generator. One important
distinction here, is that a PLL does not necessarily operate with zero
static phase error. Here, the non-zero phase error, is the fractional part
of the pseudorange itself. The integer part for L1 C/A is in units of
something like 300 meters. In order for the correlator to stay
"synchronized" to the incoming data, we must use a PLL.
Typically the correlators and the carrier tracking loops are implemented in
DSP firmware, except for Garmin which inexplicably uses an x86 processor
;-). Everybody should understand that there are 12, count 'em 12, carrier
tracking loops. One for each channel. Each one, tracks an individual
satellite's recovered carrier frequency, with zero static frequency error.
This can only be done with true PLLs. By comparing the average frequency of
the carrier tracking loop's VCO with the master oscillator, we get the
doppler measurement. While we are on the subject, the master oscillator, is
of course phase locked to GPS time derived from the time solution.
You mentioned the open loop scheme of letting the master oscillator free run
but keeping track of temperature and taking that into account. There are
probably some receiver designs out there like that, but it is far more
common to adjust the master oscillator (VCXO) to keep it in sync with GPS
time. If you don't do this, you can't output accurate 1 pps timing pulses.
Also, keeping it in sync, allows you to adapt the temperature compensation
correction curves as the crystal ages. That is, you keep track of what
voltage is required to keep the master oscillator synced to GPS time and use
that to update the temp correction curves. One more reason to keep it in
sync, is that it makes calculating the position solution significantly
easier.
You mentioned that the satellites transmitter and GPS receivers local
oscillator must be phase locked before data can be recovered. That is sort
of true in a backhanded way. Since the receiver's local oscillator is
synthesized from the master oscillator, which is in turn phase locked to GPS
time, it is sort of true, but obscures the methodology. Also, data can and
is recovered prior to the master oscillator achieving phase lock to GPS
time. The data will not be accurate, but it is recovered. This happens
every time you achieve initial lockon. The last part of lockon, is to sync
the master oscillator with GPS time. Before that, you can still have
(innaccurate) pseudorange and doppler measurements. Don't forget, you only
have one local oscillator per IF stage. It would be hard decide which sat
to phase lock it to, considering doppler shift, general and special
relativity, etc.
John Galvin
Wolfgang Rupprecht wrote in message ...
>
>[ On the theory that the best way to draw out discussion on usenet is
>to state something wrong, let me let me state how I picture this as
>working and perhaps the heavy-weights will correct any
>misconceptions. -wsr ]
>
>Janne Sinkkonen <ja...@nnets.fi> writes:
>> Are you essentially saying that it is better to differentiate before
>> computing the position than afterwards?
>
>From what I understand, one can also argue that the Doppler
>information is essentially a primary datum collected.
>
>The way I see it, the satellites transmitter's and GPS receiver's
>local oscillators have to be phase locked before data can be
>recovered. The Doppler data could then be directly generated by
>measuring the frequency control signal to the receiver's VCO(*). One
>would use temperature lookup table to correlate the VCO control at
>that ambient temperature back to an actual frequency offset -- the
>Doppler.
>
>The temperature lookup table could be recalibrated periodically by
>calculating the expected Doppler from delta-position / delta-time
>calculations.
>
>-wolfgang
>
>(*) I assume that each correlator's VCO is really a digital PLL
>connected to a cheap crystal oscillator. That would allow one to use
>the same temperature compensation table to relate the PLL control
>setting to the PLL output frequency for each of the correlator
>"channels".
John Galvin
I think, with a small change in wording, what Wolfgang is saying will make
sense. The local oscillator, is phase locked to GPS time, not any
individual satellite's transmitter. The local oscillator is phased locked
to GPS time by virtue of it's being synthesized from the master oscillator,
which is phase locked to GPS time. There is no requirement that the local
oscillator be phase locked to GPS time, it's just easier to implement that
way. Everybody, don't confuse the local oscillator, with the "vco's" used
in the code and carrier tracking loops. These "vco's" are typically
implemented in firmware, as are the code and carrier tracking loops.
John Galvin
Joe Mehaffey wrote in message <390DB46F...@mehaffey.com>...
>Hi Wolfgang,
>I believe that the correct term would be that the oscillator in the GPS
>receiver is FREQUENCY locked to the satellite's clock and not PHASE
>locked. The phase is constantly chaning between the local GPS
>oscillator and any given SV's oscillator. However, the FREQUENCY of
>the local GPS oscillator can be locked and then the phase can (or is) be
>used to determine rate of change of distance between a given SV and the
>GPS.
>
>Please let me know if I have this concept incompletely understood.
>
>Joe Mehaffey
>--
>Got a Question about GPS technology? Looking for a GPS FAQ site?
>See: http://joe.mehaffey.com
>
>
>Wolfgang Rupprecht wrote:
>> The way I see it, the satellites transmitter's and GPS receiver's
>> local oscillators have to be phase locked before data can be
>> recovered. The Doppler data could then be directly generated by
>> measuring the frequency control signal to the receiver's VCO(*). One
>> would use temperature lookup table to correlate the VCO control at
>> that ambient temperature back to an actual frequency offset -- the
>> Doppler.
>>
>>
John Galvin
Yes, I think I see what you're saying. The receivers correlator for a given
sat must be phase locked to that sat's transmitter clock. Ok, but it seems
a bit obfuscating to me. Relativity and doppler shift cloud the waters
here.
John Galvin
Wolfgang Rupprecht wrote in message ...
>
>I understand the PLL/FLL distinction.
>
>I just don't see a simple way to do a frequency lock without also
>doing a phase lock. Wouldn't the correlator tracking circuits be
>"edge sensing" in the sense that they try to line up the phase of the
>transmitted signal and that channel's VCO because doing so gets one
>the largest correlation? I'm of course assuming that the spread
>spectrum "chips" (as in a Spread spectrum data bit, not an integrated
>circuit) are clocked by the same clock that generates the
>transmitter's 1.5Ghz RF signal. Perhaps thats wrong and I was
>simplifying things too much in my mind???
>
>-wolfgang
John Galvin
Dave Martindale wrote in message <8ekjag$5vi$1...@newcastle.cs.ubc.ca>...
>Wolfgang Rupprecht <wolf...@dailyplanet.wsrcc.com> writes:
>
>>I just don't see a simple way to do a frequency lock without also
>>doing a phase lock.
>
>signals at all - since every satellite has a different Doppler shift.
>
>You *could* frequency lock the local oscillator to GPS time, by
>taking the time offset that pops out of every position calculation,
>filtering it, and using it to steer the local oscillator.
>
You just designed a phase locked loop. The time offset is directly
proportional to the phase error. If you feedback phase error, you have
created a phase locked loop.
>But, as discussed in a previous article in this thread, I don't see
>why you need to frequency lock the local oscillator at all - all you
>really need to know is what its current frequency error is.
>
You don't have to. It's just easier to implement and results in better
performance. It's going to be a royal pain to generate low jitter, high
accuracy 1 pps, if you don't.
>>Wouldn't the correlator tracking circuits be
>>"edge sensing" in the sense that they try to line up the phase of the
>>transmitted signal and that channel's VCO because doing so gets one
>>the largest correlation?
>
>To get a good signal out of the correlator, you have to match the
>transmitted frequency both in instantaneous phase and chip rate.
>If the chip rate is wrong, the phase soon slips and you lose the
>signal. But again, every channel of the receiver is operating at
>a slightly different chip rate due to Doppler shift.
>
Which is why you have an oscillator (implemented in firmware) dedicated to
each correlator channel, that can be independently tuned.
John Galvin
Geoff Lambert
Arthur C Clarke
Charles Gallo
-- PGP Key on Request
For the Children RKBA!
Thomas Tonino
> Perhaps we are in agreement here. I can't tell. You have used the term
> "rate of change of position". To me, this implies taking the derivative of
> position with respect to time. This is not being done.
It also was not what I meant. I meant the position and speed relative to
each satellite - pseudorange speed if you like. I realize my explanation
was totally unclear.
Thomas
Alan Silverstein
Any smoothly functioning technology will have the appearance of magic. -- Clarke
Any smoothly functioning technology is indistinguishable from a "rigged" demo.
Any technology distinguishable from magic is insufficiently advanced.
Advanced technology: It's too complicated for me.
Any sufficiently advanced bug is indistinguishable from a feature. -- Kulawiec
Janne Sinkkonen
> Janne, take a read of:
> http://www.navcen.uscg.mil/gps/geninfo/gpsdocuments/gpsuser/gpsuser.pdf
Thanks. It seems very thorough. :)
--
Janne
Janne Sinkkonen
> Janne, take a read of:
> http://www.navcen.uscg.mil/gps/geninfo/gpsdocuments/gpsuser/gpsuser.pdf
It has an 'error budget' on p. 3-3.
The error budget contains 8.2 meters in 'Ephemeris prediction and
model implementation' within the control segment, which is almost as
much as the lower level for ionospheric errors. The total 95% per
satellite UERE with C/A code is cited to be 15.7-23.1 meters (which
would give 95% EPE=25...37 meters at HDOP=1.6).
This sounds a lot, and more than you wrote in
http://www.deja.com/getdoc.xp?AN=618130343 (citing Trimble). Your
Trimble source estimates per satellite total UERE to be 5.8 meters (or
11.6 at the 95% level).
So even these quite authorative sources seem to differ.
The document doesn't say anything about the autocorrelations, but it
says that the UERE "closely resembles Gaussian over the long term
(days to months)". (This doesn't mean that the position errors are
Gaussian - because HDOPs are not, the position error has longer tails
than a Gaussian).
--
Janne
Sam Wormley
Robert S. White
...
>Which is why you have an oscillator (implemented in firmware) dedicated to
>each correlator channel, that can be independently tuned.
This has been an excellent technically correct series of explanations
by John. One minor point in regards to the statement above, IME each
correlator channel has both a code and a carrier Numerical Control
Oscillator (NCO) hardware register that is updated by firmware/software.
A quadrature detector for each channel generates In-phase (I) and
Quadrature-phase (Q) data that is sent to various
hardware/firmware/software detectors among which is an arc-tangent
detector which shows the relative phase difference between the
received signal and the individual channel's carrier oscillator (NCO).
The carrier loop can even "aid" the code tracking loop. Frequency
lock is common but you need to count carrier cycles for kinematic
solutions.
--
Robert S. White
e-mail reply to (add .'s): rswhite shift2 home com
or do a "Reply To All" for direct eMailed cc'd followups.
Robert S. White
>I would think that frequency would be locked by using an output of the
>Kalman filter to "lock" the frequency using long term filtered GPS
>time.
That is called "State 3 track" when the navigation solution closes
the frequency loop. This is done under low signal conditions (most
often caused by jamming) when the GPS receiver's hardware based
frequency/phase dectection (like an arc-tangent detector) is too
noisy to give reliable info.
I do not believe you can lock anything directly to any of the
>SV's signals as there is <almost> constant and contantly changing
>doppler on those signals.
Not so. Under normal GPS SV signal tracking conditions both
code and carrier lock is maintained independent of the full navigation
solution. This is called "State 5 track".
John Galvin
Yes, of course 2 oscillators. That makes perfect sense. I don't know what
I was thinking.
You mention carrier aided code tracking. My guess here, is that since the
carrier tracking loop has a higher bandwidth, that in times of high
acceleration, knowledge of this, is fed forward into the code tracking loop
to try to prevent it from losing lock. In this way, the code tracking loop
can stay locked even under perturbations significantly beyond it's
bandwidth.
John Galvin
Robert S. White wrote in message ...
>In article <KxqP4.3137$wB6....@news.swbell.net>,
lgalvin...@pacbell.net says...
>...
>>Which is why you have an oscillator (implemented in firmware) dedicated to
>>each correlator channel, that can be independently tuned.
>
> This has been an excellent technically correct series of explanations
>by John. One minor point in regards to the statement above, IME each
>correlator channel has both a code and a carrier Numerical Control
>Oscillator (NCO) hardware register that is updated by firmware/software.
>A quadrature detector for each channel generates In-phase (I) and
>Quadrature-phase (Q) data that is sent to various
>hardware/firmware/software detectors among which is an arc-tangent
>detector which shows the relative phase difference between the
>received signal and the individual channel's carrier oscillator (NCO).
>The carrier loop can even "aid" the code tracking loop. Frequency
>lock is common but you need to count carrier cycles for kinematic
>solutions.
>
Dr. Joel M. Hoffman
>software knows the error in the frequency (either from the temperature
>and lookup table at startup, or from recent observations if locked)
This implies that the unit knows the temperature. Is there a way of
getting the Garmin III+ to tell the user what temperature it is?
-Joel Hoffman
(jo...@exc.com)
Mark J.
Hoffman <jo...@exc.com> writes
The only way I know is to Power up the Garmin while holding down the
Enter button.
Mark.
--
mailto:ma...@iridium.demon.co.uk
Thomas Schmidt
...
> This implies that the unit knows the temperature. Is there a way of
> getting the Garmin III+ to tell the user what temperature it is?
http://celia.mehaffey.com/dale/secret.htm
--
-------------------------------------------------------------------
Thomas Schmidt e-mail: sch...@hoki.ibp.fhg.de