[time-nuts] Low cost synchronization

[Brooke Clarke]

Hi Mike:

It may not be possible to get what you are asking for as a stand alone 
time keeper but I think could be done by periodically resetting.

Using a radio signal for resetting has problems with the coverage area 
and/or power consumption.

Maybe the resetting signal could be an audio time code optimized for 
this application.  The user could call an 800 phone number and a 
microphone in the device would hear the code and reset.  Or at a public 
meeting the audio code could be put on the P.A. system so all present 
would be synchronized.

If the microphone can hear the beeper of another unit there might be a 
way to use a button on a unit to cause it to send it's audio time sync 
signal so other nearby units would sync to it.

The device could learn it's aging rate at each reset and so change the 
divisor number to match the current aging rate.

After sync the device might emit beeps or Morse code telling the user 
how far off it was allowing the user to gauge how often they need to resync.

A TCXO should work for this.

Have Fun,

Brooke Clarke, N6GCE
-- 
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com



Mike Ciholas wrote:

> Hi,
> 
> I have a challenging research project to build thousands, perhaps 
> millions, of devices that maintain mutual synchronization.  The 
> devices need to be low cost (under $20 retail, $8 manufacturing), 
> small in size (key chain fob), and low power (operate at least 18 
> months on a battery).  Synchronization ideally needs to be within 
> a second or two over a year but there is some leeway to trade 
> cost for performance here up to perhaps 10 seconds of variation 
> per year.  Ideally, the device works anywhere in the world but we 
> may have to limit it to North America.
> 
> 1. Crystal Modeling
> 
> First idea was to get stable 32.768KHz watch crystals, perform a 
> factory initial calibration, and use a temperature sensor to 
> correct for the crystal temp curve.  This idea is the cheapest, 
> simplest, works everywhere, and uses the lowest power.
> 
> Initial tolerance on the crystals is +/- 20 ppm (I've not found 
> better in commodity parts), which equates to +/- 10 minutes a 
> year, clearly unacceptable.  I suspect that if I did an initial 
> factory calibration and tracked temperature, I might improve this 
> to +/- 2 ppm much like Maxim did with this part:
> 
> http://pdfserv.maxim-ic.com/en/ds/DS32kHz.pdf
> 
> But even so, +/- 1 minute per year is not really good enough.  I 
> suspect getting to a few seconds (+/- 0.1ppm) is unrealistic with 
> any algorithm one can come up with.  The base physics is simply 
> not that predictable.
> 
> 2. WWVB Receiver
> 
> A second idea is to provide some external reference and the most 
> logical choice is WWVB as used in several wrist watches.  A 
> little more cost but manageable.  We've dissected several wrist 
> watches and found they use a small ferrite antenna.  The 
> reception performance is spotty, however.  I was unable to lock 
> at work (lots of equipment) but did well at home (electrically 
> quiet).  If we go to the NE tip of Maine, that's twice as far 
> from WWVB as we are here, so I wonder if the watch will ever pick 
> up the signal.  The saving grace is that the device needs to get 
> the signal only sporadically, once a week or even once a month 
> would do it since we can feed that back into correcting the local 
> crystal.
> 
> The negatives are that such a device is limited to the US and 
> nearby, and it may have poor performance in many locales due to 
> weak signals, local interference, and the small antenna rod we 
> are limited to due to size (less than 1 inch).  It does cost 
> more, maybe $1-2 more in production quantity.  Right now, this 
> seems like the best option available to us.
> 
> There are similar time broadcasting stations in Europe and China.  
> We could build a unit that works in those regions, either as 
> different models, or as a unit with multiple receivers.  Still 
> not global, but perhaps covering 50% of the world's population?
> 
> 3. GPS Receiver
> 
> A more precise external reference, use a GPS receiver.  This gets 
> us global coverage and is very precise.  Uses a lot of power, so 
> we would only activate it very briefly and not very often (once a 
> week perhaps) to save battery.
> 
> Major issue here is cost.  Best I can do for an OEM module is 
> around $25 in qty which busts the budget severely.  It also has 
> similar problems of being used in a place with no sky visibility.  
> Size can be a problem in the cheaper modules.  Some modules are 
> quite small:
> 
> http://www.u-blox.com/products/lea_la.html
> 
> Cute, huh?
> 
> 4. GPS Time Receiver
> 
> This is fantasy land.  I don't need the 100ns time reference, all 
> I need is something good to one second or so.  In this case, it 
> seems possible to receive only 1 satellite, decode the digital 
> data, and extract the time.  It would be off by the variation in 
> pseudo range which can't be corrected for.  But I don't care 
> about that level of accuracy.
> 
> The question is, if you don't have to track multiple satellites 
> and don't need to recover the pseudo range accurately, can you 
> build a wickedly cheaper GPS time receiver?  My expectation is no.  
> You probably can get down to maybe half if you are very diligent, 
> which still puts me out of the budget plus has a ridiculous high 
> NRE.  Unless this already exists, anyone?
> 
> 5. Cellular
> 
> We've done extensive work with embedded cell phone modules.  
> These modules are most often used for wireless remote monitoring 
> and transport digital data.  They do get the time from the cell 
> system.
> 
> Again, cost is a major issue.  An OEM cell module runs over $65 
> in qty so this idea is sunk.  It would also suffer from lack of 
> global and local coverage.
> 
> 6. TV Stations
> 
> TV stations broadcast a time signal that VCRs/DVRs use for clock 
> setting.
> 
> Again, lack of global or even regional coverage.  Some TV 
> stations, annoyingly, broadcast the wrong time, too.  Cost is 
> probably high, but this idea was rejected before this was 
> investigated.
> 
> 7. Atomic Reference
> 
> Still research, but NIST has a small scale atomic reference:
> 
> http://www.nist.gov/public_affairs/releases/miniclock.htm
> 
> Unfortunately, not ready for commercial apps, probably will be 
> too expensive, and it uses too much power.  The best I could do 
> on power is to power it up periodically and adjust the local 
> crystal to it which integrates long term error.
> 
> 8. Other?
> 
> So, did I leave anything out?
> 
> It seems obvious to me that no amount of effort to make a local 
> crystal stable will meet the requirements.  Thus we need to look 
> for external references.  The best we can do is WWVB as it is the 
> only thing that can possibly meet our cost objectives.  If it 
> works in the continental US, that would be acceptable for now.
> 
> That leaves me with two basic questions:
> 
> 1. How well do the WWVB wrist watches work?
> 
> 2. What merchant silicon exists for receiving WWVB?
> 
> On the first, the three watches we bought do sync up here (950 
> miles from WWVB).  I wonder how well they work in Maine and 
> Florida (1900 miles from WWVB).
> 
> On the second, I've only found these leads so far:
> 
> http://www.mas-oy.com/archive/da9180.pdf
> http://www.ortodoxism.ro/datasheets/Temic/mXyzuryv.pdf
> 
> These chips appear to be basic receiver circuits using an 
> external 60KHz crystal as a filter.  At 60KHz, I was wondering 
> why there aren't direct digital radios?  It would seem like 
> building in the DSP logic would be cheaper/better than the old 
> fashioned methods shown here and could greatly enhance the 
> ability to pick out weak WWVB signals.  Has anyone performed such 
> experiments, basically digitize the antenna signal and done DSP 
> on it?
> 
> Thanks for all who read this far!
>