[time-nuts] GPS 18 behavior

[Jim Lux]

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