[time-nuts] GPS 18 behavior

Scott McGrath scmcgrath at gmail.com
Mon Jul 22 12:48:40 UTC 2013


You might want to look at what these guys have done for 40 years or so. Www.geophysical.com

They have the ability to embed GPS coordinates while recording. 

Sent from my iPhone

On Jul 21, 2013, at 4: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.



More information about the Time-nuts_lists.febo.com mailing list