[time-nuts] GPS 18 behavior

Sun Jul 21 21:42:44 EDT 2013

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.    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.

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.

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

On Sun, Jul 21, 2013 at 1:55 PM, Jim Lux <jimlux at earthlink.net> wrote:
> On 7/21/13 1:35 PM, Tom Van Baak wrote:
>>>
>>> when I'm in a GPS denied environment, it's not just because we're
>>> indoors, it's because we're somewhere that GPS isn't available, so
>>> what I'm really doing is providing a sort of flywheel to keep my
>>> little modules synced with each other.  I don't need super accuracy
>>> in an absolute sense: I just need to tag the data all with the same
>>> time tag within a few seconds.
>>
>>
>> Jim,
>>
>> If the requirement is just a couple of seconds, did you consider one
>> of the high-accuracy Dallas RTC chips? That might be a simpler
>> solution than a GPS receiver (knowing when and when not to trust its
>> 1PPS, decoding NMEA, trusting NMEA, needing antenna with sky view).
>
>
> We have two requirements.. one is "know when the data was collected in an
> absolute sense": that's a "few seconds" kind of requirement because we're
> collecting data for 30 seconds anyway.
>
> But we have another requirement to be able to align multiple simultaneous
> takes within a millisecond or so.
>
>
> For what it's worth, the application is a radar that detects buried victims
> in disaster rubble, so the data we are collecting is basically heartbeats
> and breathing.  the "when was the data taken" is a "where were we when the
> data was collected" need.  The "sync" requirement comes from being able to
> find the same heartbeat in multiple data streams.
>
> http://www.dhs.gov/st-snapshot-tech-foraging has a picture of the radar and
> a test site.
>
>>
>> If the requirement were sub-second, the solution is GPS; if the
>> requirement were minutes, it's TCXO. Sounds like you're in the gray
>> area where GPS is not necessarily the simplest, cheapest, or robust
>> solution.
>
>
> As it happens, we already need to have GPS position of the data take (where
> possible), so the GPS is there and available (sometimes).
> It's the "what do I do when the GPS isn't there" that I'm working through.
>
>
>
>>
>> The other thing about multiple, portable or remote sensors is that in
>> some cases they don't actually need to agree on time or rate
>> internally as long as you can post-process the data and retroactively
>> apply a time and frequency correction to the data they have already
>> collected or are collecting. For example, if you know one is 2.3
>> seconds ahead and slow by 45 ppm you can still obtain highly accurate
>> time-stamps from it -- the unit itself does not need to be on-time,
>> or on-frequency.
>
>
> Indeed. For this application, "knowledge" is actually more important for
> sync.  The XO on the board setting the sample rate is good enough that if I
> just count clocks, and timestamp  when I get the sync pulse, I can line
> things up with a few seconds one way or another.. the data take is 30 or 60
> seconds, and even if we're WAY off, it's not going to be a millisecond off
> from a rate error at the end of 60 seconds.
>
> The "distributed sensor" problem down the road, though, I'm doing coherent
> microwave demodulation, so that's why I need the 1E-11 over 10-100 seconds.
> I'm looking for signals at 0.1 to 1 Hz (breathing and heartbeats) and if the
> transmitter and receiver are off by 1 Hz, then the difference looks just
> like a heartbeat.   To be honest, I'm not sure the distributed sensor
> (basically a bistatic radar) is doable with totally independent systems.
> What I might wind up doing is detecting the direct path and the reflected
> path simultaneously and looking for it that way.  It's basically a sort of
> phased array problem, and if you can somehow manage to get your phase
> reference distributed among all the elements with "small" phase error over
> the measurement interval, that's a good thing: less post processing, and all
> that.
>
>
>
>>
>> /tvb
>>
>>
>> _______________________________________________ time-nuts mailing
>> list -- time-nuts at febo.com To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow
>> the instructions there.
>>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

--

Chris Albertson
Redondo Beach, California