Hi

The GPS does an estimate against the local crystal frequency. It generates the PPS off of it's estimate. The less often it updates the estimate the more odd things you see as the crystal drifts.

Of course, the crystal can have trouble all it's own. If the crystal has a rapid rate of frequency change over a narrow temperature range, the GPS simply can't keep up with the crystal.

Bob

On Dec 28, 2012, at 5:27 PM, Fabio Eboli FabioEb@quipo.it wrote:

Yes, we have yet another proof that the oscillator in (cheap?) GPS
receivers can be a source of troubles... shall we start to design Ovenized
GPS Receivers (OGPR) too? Or ovens for GPS receivers.

On Fri, Dec 28, 2012 at 11:35 PM, Bob Camp lists@rtty.us wrote:

On 28/12/12 23:35, Bob Camp wrote:

A typical GPS off the shelf solves the position solution every second,
having a 1 Hz report rate. This includes clock corrections. Some GPSes
is capable of higher report-rates.

Most GPS receivers only have TCXOs, and even if tossing in an OCXO,
excessive heat can throw the frequency and hence the GPS solution way of
the mark. For many GPS reference stations, rubidiums is used to steer
the internal clock, and the quality of that lock can affect how well it
tracks it and have secondary frequency issues.

So, it comes as no surprise that the GPS module is temperature
sensitive. The metrology labs measure and compare the temperature
stability of various GPS-receivers,

There are also filters that can provide temperature effects, but the
TCXO is where it usually hurts most.

Cheers,
Magnus

Hi

…. except… A navigation GPS doesn't care much about the time solution. Updating the location is a much higher priority than updating the time. The typical "solution" is to let the time estimate coast for a while and update it much less often than the location.

Bob

On Dec 28, 2012, at 7:18 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:

Bob,
That is simply not accurate - if the solution rate is 1/second, then all
parameters are solved in that time frame. There are 4 indpendent variables
and minimal processing power is required to solve all four equations.
Although I am not very familiar with commercial receivers, that is what
happens in the Rockwell, Trimble and IEC military units. If the output is
more than once per second it is usually an output of the Kalman Filter,
not a "true" measurement.

Michael / K7HIL

On Fri, Dec 28, 2012 at 6:20 PM, Bob Camp lists@rtty.us wrote:

Hi

Indeed the solution is done once per second or so. In the solution they weight the significance of position versus time. If you accept a larger time error in the solution, you can come up with a smaller location error.  Is that a bit of mathematical sleight of hand? - of course it is. Can you keep doing it forever? - no you can't. Eventually you need to get the time back up to date.

Put another way - if all that was going on was the same solution process in every receiver - there would be no differences in results. Software is software. The hardware in a low cost timing receiver is the same as the hardware in a low cost "location only" receiver. The difference is the firmware. You can indeed shoot timing firmware into some location receivers and turn them in to timing receivers.

Bob

On Dec 29, 2012, at 12:14 AM, Michael Perrett mkperrett@gmail.com wrote:

Fabio,

Happens in all the GPS receivers we have tested here. The difference between receivers is how fast they can recognize this error and how fast they can re-aquire once they shut off the 1PPS output due to tcxo instability.

There was a recent thread here about effects of adding a fan to a Z380x and the behavior you have seen is one of the reasons why that is a bad idea.

Some receivers like Rockwell, Trimble etc allow for external 10MHz input from an ocxo or atomic clock, and some GPSDOs make use of that feature. Having a very stable and accurate 10MHz reference for the GPS is also supposed to reduce time to second fix.

Bye,
Said

Sent From iPhone

On Dec 28, 2012, at 14:27, Fabio Eboli FabioEb@quipo.it wrote:

On 12/28/12 9:14 PM, Michael Perrett wrote:

how is the output of a Kalman filter not a "true measurement".. it's
essentially the composite of many measurements, weighted by the
uncertainty of those measurements, and, if properly setup, the
uncertainty of the filter output is less than any of the component
measurements.

Or by "true measurement" do you mean a "point solution" at an instant in
time, which I don't think you would get from any receiver that uses any
form of tracking loop, because what is the output of that tracking loop
but some estimate of the observable, filtered through the loop filter.
After all, you need to measure/estimate both code phase and rate.

You could record raw signals off the air, and post process by
correlating over a long time span to get a "unfiltered" measurement
(although, I suppose the "integrate and dump" inherent in the
correlation provides a sin x/x sort of frequency response)

On Sat, 29 Dec 2012 12:18:56 -0800, Said Jackson saidjack@aol.com
wrote:

I am going to have to add that feature to my shopping list of what to
look for when I upgrade from my Garmin GPS18-5.

One feature I found interesting in the GPS18-5 is that the adjustable
dead reckoning time can be set to disable the timing pulse output when
there is no current navigation solution.

Hi,

Often these receivers can output either a filtered solution or an
"unfiltered" solution.

The kalman filter will do measurement updates once a second with
pseudorange and delta range measurements. In between - to get 10Hz or
whatever - they will use the kalman filter to predict the
position/velocity.

Sure, the pr/dr measurements are filtered both by the tracking loop and by
the integration time. But that filtering is on another scale than using a
filter to predict outputs at a higher rate than what the point solution is
available at.

--

  Björn

Hi Bob,

I am curious about the sacrifice time and get better position. I have not
seen any discussions about that in manuals, books or papers. Do you have
reference?

What would be the difference between timing and navigation versions of
cheap commercial receivers?

1. Timing receivers are often stationary, navigation receivers are
   typically not stationary for extended periods of time. So a timing
   receiver can benefit from a time only solution. Ie you have a known
   (x,y,z)/(lat,lon,h) position and solve only for time, reducing the unknown
   from (x,y,z,t) to only (t). The known position can be had from a) full 4D
   single fix solution or better from b) a site survey taking the mean
   position from many hours of measurements or also good from c) an
   independently surveyed position of the antenna position. This mode will of
   cause improve time when there are fewer than 4 satellites tracked.

2. Timing versions might get an upgraded oscillator. Maybe a TCXO instead
   of a standard XO.

3. Navigation receivers integrations will not require high accuracy PPS
   output from the receiver. If you can save some cents on PPS generation
   hardware by having 500ns resolution of the PPS instead of 1-10ns
   resolution - the navigation receiver will not even have hardware resources
   to generate a decent 1PPS.

To my knowledge, the accuracy of (x,y,z,t) is given by the "geometrics" of
the satellites tracked. The receiver reports this in the DOP (dilution of
precision). There is PDOP (3d position), HDOP (horizontal position), HDOP
(vertical position) and TDOP (Time). There is not much the receiver can do
in normal operation with four or more tracked satellites to select between
position and time accuracy. The relationship is given by the geometry of
the measurements!

For a navigation receiver, there must be a time solution that is (scaled
by c) more or less at the same accuracy as the position. Having 3 meter
accuracy means the receiver time is good to 10ns. However the navigation
receiver does not need to communicate this timing accuracy to the outside.
It does not have to calibrate filter/processing delays. Slowly varying
delays in analog filters due to temperature changes can also be ignored.
Delays due to LNA and cables can also be ignored if you have a spec at
1PPS of 1us.

--

Björn

Hi Björn,

On 29/12/12 23:42, bg@lysator.liu.se wrote:

I've long assumed that T-receivers have the additional T-only positional
mode. I recall the Motorola Oncores having a whole bunch of different
positional modes, where timing mode is one amongst many others.

Don't think so. The noise and systematic stability is as important for
positional as for timing versions, the timing version can benefit of the
fixed position.

No. We should have seen this in the clock jitter. They have the same
clock as the core-clock of the ASIC. The PPS is actually a variant of a
1 ms measurement timer that the GPS uses to grab samples of channel
phase and integrated I&Q values for all channels. The 1 ms timer holds
the actual system time of the GPS, which is then adjusted to the real
GPS time using different algorithms, but using the solution from the
positioning. The PPS is trivial to produce as a predicted event with
that solution in hand. Since the hardware support has a limited
resolution, it's trivial to calculate the error of the predicted PPS
from the actual time, so a sawtooth error could be sent out.

Saving resolution in the PPS generator clock doesn't help much, as you
need a certain clock rate and you need to divide it down regardless. The
amount of logic cost to do a coarser vs a core clock is essentially
nothing compared to what 12, 16, 20 or 24 channel correlator setup cost,
so going to core clock resolution is no real saviour.

The RAIM algorithm can naturally prune of satellites giving too large
time/pseudo-range errors, above some limit. The number of available
channels allows for all in view birds to be selected, rather than having
a selected sub-set which gives the best geometry. RAIM with enough
channels will prune on actual pseudo-range errors rather than expected
xDOP from geometry basis and contribute to lower numbers.

The biases of C/A code tracking is large enough that most of those
issues can be overlooked. You can however shift DOP from the x, y and z
into TDOP performance of the t solution by letting each and every
pseudo-range be used in a pure T-RAIM pruning and then position solution.

The pseudo-range of a satellite can be written as:

p_sat = sqrt( (X - X_sat)^2 + (Y - Y_sat)^2 + (Z - Z_sat)^2) + c*(T - T_sat)

where p_sat is being measured for each sat and X, Y, Z and T is the
solution when applied for a number of sats (4 needed for 3D+T position).
When X, Y and Z is known from before, this equation becomes trivial to
solve, but also you can see that any precision/error that previous was
distributed over X, Y, Z and T is now only sent out on T. If X, Y and Z
is of sufficient precision, the T solution will benefit. Also, this
explains why only one sat is needed, as the equation system becomes
trivial and straight-forward.

The Misra & Enge book covers timing receivers in sub-chapter 6.3.

Actually, one old Meinberg GPS timing receiver used this fact and has a
single channel with old-school analogue interpolators and alternates
among the satellites.

Cheers,
Magnus

Hi

The gotcha is that often the "navigation" and "timing" receivers are identical in terms of hardware. There is no upgraded hardware in the timing device.

When you put a receiver into position hold, you are telling it "I don't care about the location solution". It reduces the weight of that part of the filter. Yes, that's only one way to look at it and there are other ways to look at it.

Bob

On Dec 29, 2012, at 5:42 PM, bg@lysator.liu.se wrote:

On 12/29/12 6:34 PM, Bob Camp wrote:

or, another conceptual model is: I'm fixed, I know where the
transmitting satellite is, and can calculate range and doppler a priori,
so anything else must be local clock variation and propagation.  And you
can average out the propagation among multiple satellites (or use one
satellite as your timing reference)..

Particularly if you are post processing and have precise ephemeris data
for the satellites....

Hi

The interesting thing is that you sometimes can get a position hold receiver to report it's estimated location…. Not so much on current product, but on some of the old stuff.

Bob

On Dec 29, 2012, at 9:51 PM, Jim Lux jimlux@earthlink.net wrote:

Bob,

Our Position-Hold enabled units (Fury, Mini-JLT, various CSAC units, and GPS-405 support accurate position reporting in ECEF, NMEA, and various other standards.

Users can select how many fixes are averaged for the position report.

They can also be instantly switched back and forth between position hold, and mobile mode using simple English SCPI commands. Some of them have built in 3 axis accelerometers that allow instant detection of when the vehicle starts moving so it can be switched into mobile mode at that time.

We recently did a test by putting an antenna in a side window in the office that had maybe 10% view of the sky, then let the unit run in mobile mode while doing the auto survey. After two days, we switched it into position hold mode. Most of the time it sees only one sat direct, all others are only seen through multipath. The results are astonishing, SD went down from about 30ns+ to about 8ns. Spikes to +/-150ns went away completely.

I can post some GPSCon graphs of this  significant improvement during the test next week if there is interest.

Bye
Said

Sent From iPhone

On Dec 29, 2012, at 18:56, Bob Camp lists@rtty.us wrote:

Hi

The more interesting event is when you re-flash a +/- 1 us navigation receiver and it instantly becomes a < +/- 100 ns timing receiver without position hold engaged.

Bob

On Dec 29, 2012, at 10:20 PM, Said Jackson saidjack@aol.com wrote:

Hi Magnus,

Look at the uBlox6 lineup. Position receivers are available with XO or
TCXO - timing only with TCXO.

http://www.u-blox.com/images/stories/linecards_u-blox_gps_modules_2012.pdf

--

Björn

Moin,.

On Sat, 29 Dec 2012 19:20:16 -0800
Said Jackson saidjack@aol.com wrote:

PHK reported something similar a quite while ago:
http://phk.freebsd.dk/raga/sneak/

More graphs are always desirable :-)

		Attila Kinali

--
There is no secret ingredient
-- Po, Kung Fu Panda