[time-nuts] GPS 18 behavior
jimlux at earthlink.net
Sun Jul 21 16:55:20 EDT 2013
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.
> 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
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.
> _______________________________________________ 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.
More information about the time-nuts