[time-nuts] GPS 18 behavior

[Jim Lux]

On 7/21/13 6:42 PM, Chris Albertson wrote:
> I think the way to keep the sensors in sync is to use the same method
> they use to keep cell towers in sync.  Basically each tower has a GPS
> receiver and also a good local oscillator.  The GPS disciplines the
> oscillator and the timing is taken from that oscillator, not directly
> from the GPS.  If the GPS signal is blocked the system continues
> normally however the oscillator may drift without the connection to
> GPS.  Then later when the GPS is available again the oscillator is
> corrected.    The system can run for a few days in holdover with no
> GPS connection.
>
> I think you were talking about a system that switches to a backup 1PPS
> signal.


Today, I have a system with multiple modules physically connected by a 
cable that need to be sync'd to maybe 1 millisecond.  I was thinking 
about using the 1pps from the GPS as the sync, if it was available all 
the time, even in GPS denied areas; that would make it always use the 
same sync from the same device, even if it's not synchronized to some 
external time scale.  Since the GPS receiver doesn't put out the 1pps 
all the time, I can sync another way, and drive that sync process from 
the GPS if it's available.

The long term system will have multiple modules separated by some 
distance that need to be synced and frequency disciplined, but they 
might have GPS, so that could be used to discipline a clock in the usual 
way. As a practical matter, I'm more a fan of using GPS for knowledge 
and adjust the output using a DDS rather than steer the oscillator, 
because that allows a higher Q resonator, but that's a matter of 
engineering details.

There's also the situation where you're totally GPS denied, but that's 
an even more tricky problem.


   That is not the way to do it.  The GPS should discipline a
> 10MHz crystal (or whatever) and then you divide that by 10,000,000 to
> get your 1PPS.  Then when the GPS fails there is no interruption, no
> mode change.   Such a system only needs to have access to GPS now and
> then.  So if you have to go under a pile of concrete and loose access
> to the sky there is no "hiccup".   This would work for the distributed
> system too.  Your 1E-11 over 10 to 100 seconds would be met even if
> GPS were out for a few hours.

Yes, that would do.  It turns out, though, that although you could 
tolerate a slow drift, assuming you can figure out what it is, it makes 
life harder if the two modules have drifted 1E-9 relative to each other 
after 10 minutes.



>
> You cn do the same for location data too.  When you walk under a
> concrete roof the GPS goes away.  So you use an inertial system.  The
> GPS continuously corrects the inertial nag and if you loose GPS they
> is some drift but you don't loose position data.
>


Interestingly, there's a lot of people who have tried this, and it 
doesn't work quite as well as they hope.  Basically you're talking a 
strapdown IMU, and such an IMU on a person doesn't work all that well. 
Imagine a policeman with a walkie talkie.. the radio gets picked up and 
used and sees fairly high accelerations over short durations, with high 
jerk as well.  If you were to strap a bunch of accelerometers and gyros 
to a person's skin (not their clothes, which bounce around and slide) 
you could do better.

I was at a DARPA thingie the other day where there were a bunch of 
exhibitors with personal tracking systems.. there's a lot of handwaving 
about whether they can actually reliably achieve, say, 1-2 meter 
position accuracy.  In a tactical environment, 1-2 meters is the 
difference between life and death (e.g. which side of the wall or street 
are you on).


> All of this can be done in a small hand held battery powered system.

mmmmm.. maybe. how long does the battery last<grin>...

You're not going to be running a 10811 Double Oven XO on a couple AAA 
batteries.  The CSAC is 120 mW.

A single AAA battery is about 1 Watt hour, for comparison.

Yeah, it's doable, but it's non trivial..