Re: [time-nuts] GPSDO control loops and correcting quantization error
gandal...@aol.com said: When some other form of external control is used, such as a DAC output for example, it's not uncommon to find the voltage reference output left disconnected and the control circuit fed from an alternative supply. On the other hand, many DACs need an external reference. A reference coming out of an OCXO is probably going to have a good temperature coefficient. :) -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
I did some experiments with a charge-transfer D/A and at least as far as I can see, that has the potential to go beyond 30 bits. The key observation is, as others have pointed out, that we only really care about relative local linearity, the PLL loop will take care of everything else. What I did was take a large-ish low-leakage capacitor and put a voltage follower after it, to drive the EFC pin. The PLL loop, implemented in software, controlled two fet-switches which would deliver positive or negative pulses to the capacitor through matched resistors. The software involvement allows for trivial calibration of any unbalance between the switches resistors, and even, if you manage to measure and model it, I didn't, the capacitors leakage current. By controlling the length of the pulses, you can get incredibly small steps in your output voltage while retaining a wide dynamic range. The neat thing is that you do not need a particularly precise or stable reference voltage for this design. Ideally you would want to drive the switches with constant current sources, but if you put an 10bit ADC on the voltage followers output, so you know the approximate voltage over the capacitor, it is trivial to model the charge delivered per unit time in software. At the time I had not read the HPJ article about the 3458A, and if I do it again, there are several tricks from there I would employ: Balanced pulses to linearize switch-noise and multiple drivers of different strengths for faster capture. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantization error
Hal Murray wrote: d...@montana.com said: Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution will be headache enough. You will gain a real education in good grounding practice, shielding, power supply stability and noise, and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that tune. The trick for this application is that you don't need full accuracy over the full range of the DAC. All you need is roughly linear and stable around the operating point. The PLL will take care of any offset. Any gain error is just a minor change to the overall gain. This thread started with 16 bit PWM DAC. I think that matches the requirements. I would expect a problem area would be filtering the PWM output. Anything you don't filter out will turn into close in spikes. It might be fun to try to measure them. 64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds. Has anybody compared DDS style DACs with PWM? The idea is to spread the pulses out to make the filtering easier. Instead of 10, you would get to work with 1010101010 Using a synchronous filter for the PWM DAC eases the additional filtering required considerably. 24 bit resolution is readily achieved by combining the outputs of a pair of PWM sources sharing a single synchronous filter. Bruce ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantization error
On 09/15/2012 12:08 AM, Hal Murray wrote: d...@montana.com said: Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution will be headache enough. You will gain a real education in good grounding practice, shielding, power supply stability and noise, and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that tune. The trick for this application is that you don't need full accuracy over the full range of the DAC. All you need is roughly linear and stable around the operating point. The PLL will take care of any offset. Any gain error is just a minor change to the overall gain. This thread started with 16 bit PWM DAC. I think that matches the requirements. I would expect a problem area would be filtering the PWM output. Anything you don't filter out will turn into close in spikes. It might be fun to try to measure them. 64K/72 MHz is about 1 ms. 32bits at 72 MHz is 60 seconds. Has anybody compared DDS style DACs with PWM? The idea is to spread the pulses out to make the filtering easier. Instead of 10, you would get to work with 1010101010 PWM has the fantastic power of putting most energy into the lowest frequency, which makes analog filtering extra hard, so you need to move the bandwidth down or use higher degrees filter for a good filter slope. The filter bandwidth puts an upper limit to the PLL bandwidth. I've done a inverse PWM spectrum modulation, which isn't all that hard, and it has significant improvements over PWM. Another approach is to use the sigma-delta approach which smooths the frequency spikes out to noise. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi If the objective is to build a GPSDO that *needs* a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider. The output of your GPS has jitter on it. How much jitter is a that depends sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb. If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way. What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others. No free lunch… Bob On Sep 15, 2012, at 3:36 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I did some experiments with a charge-transfer D/A and at least as far as I can see, that has the potential to go beyond 30 bits. The key observation is, as others have pointed out, that we only really care about relative local linearity, the PLL loop will take care of everything else. What I did was take a large-ish low-leakage capacitor and put a voltage follower after it, to drive the EFC pin. The PLL loop, implemented in software, controlled two fet-switches which would deliver positive or negative pulses to the capacitor through matched resistors. The software involvement allows for trivial calibration of any unbalance between the switches resistors, and even, if you manage to measure and model it, I didn't, the capacitors leakage current. By controlling the length of the pulses, you can get incredibly small steps in your output voltage while retaining a wide dynamic range. The neat thing is that you do not need a particularly precise or stable reference voltage for this design. Ideally you would want to drive the switches with constant current sources, but if you put an 10bit ADC on the voltage followers output, so you know the approximate voltage over the capacitor, it is trivial to model the charge delivered per unit time in software. At the time I had not read the HPJ article about the 3458A, and if I do it again, there are several tricks from there I would employ: Balanced pulses to linearize switch-noise and multiple drivers of different strengths for faster capture. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
I also have a z3801 so perhaps I will face the same issue at some point. The question I have is the following. If a uproc is inserted between the rcvr and the chassis to intercept the init command. Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? Not trying to do some complete re-emulation. But what I outline above would not be difficult. I would use whats called an SXB chip. cheap simple... Regards Paul WB8TSL On Thu, Sep 13, 2012 at 5:08 PM, Azelio Boriani azelio.bori...@screen.itwrote: Are you sure that the GPS unit is defective? Can you test it alone? On Thu, Sep 13, 2012 at 10:44 PM, Mike S mi...@flatsurface.com wrote: On 9/13/2012 2:00 PM, Chris Albertson wrote: On Thu, Sep 13, 2012 at 10:53 AM, Mike S mi...@flatsurface.com wrote: Search for oncore vp (which is what a z3801a needs), and you won't find ANY, at any price. Really? It can't use the newer UT? I thought the UT is identical except for better performance. Yes, really. The z3801a starts by sending a @@Ca (self test) command. None of the later models have that, so it fails. When they brought the self test back with the M12s, it was changed to @@Ia. Then it sends @@Cg (go to Position fix mode). They don't have that, either, it was changed to @@At on the UT/GT/SL, @@Gd on M12s. There are probably others, but that's more than enough to make anything later than a VP fail. ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
Hi The only way to find out is to actually do it. Right now the init string keeps you from seeing any further into the process. Bob On Sep 15, 2012, at 2:11 PM, paul swed paulsw...@gmail.com wrote: I also have a z3801 so perhaps I will face the same issue at some point. The question I have is the following. If a uproc is inserted between the rcvr and the chassis to intercept the init command. Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? Not trying to do some complete re-emulation. But what I outline above would not be difficult. I would use whats called an SXB chip. cheap simple... Regards Paul WB8TSL On Thu, Sep 13, 2012 at 5:08 PM, Azelio Boriani azelio.bori...@screen.itwrote: Are you sure that the GPS unit is defective? Can you test it alone? On Thu, Sep 13, 2012 at 10:44 PM, Mike S mi...@flatsurface.com wrote: On 9/13/2012 2:00 PM, Chris Albertson wrote: On Thu, Sep 13, 2012 at 10:53 AM, Mike S mi...@flatsurface.com wrote: Search for oncore vp (which is what a z3801a needs), and you won't find ANY, at any price. Really? It can't use the newer UT? I thought the UT is identical except for better performance. Yes, really. The z3801a starts by sending a @@Ca (self test) command. None of the later models have that, so it fails. When they brought the self test back with the M12s, it was changed to @@Ia. Then it sends @@Cg (go to Position fix mode). They don't have that, either, it was changed to @@At on the UT/GT/SL, @@Gd on M12s. There are probably others, but that's more than enough to make anything later than a VP fail. ___ time-nuts mailing list -- time-nuts@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 437c6604-20a5-4e05-be99-9e26b01d8...@rtty.us, Bob Camp writes: If indeed 32 bits matters, then instability at the 32 bit level will show up. [...] No free lunch Absolutely agree there. My point was merely that the requirements for the DAC after a software-PLL are very narrow and specific, compared the the quality metrics of DAC's in general, and that low cost methods are available to meet those needs, so there is no need to spend a fortune on a general X bit DAC, if cheaper special purpose one will do. One of the advantages of the charge-transfer DAC concept is that there is only thermal noise for a stable output, there is no reference voltage which can suffer from tempco or noise bleed-through. You'll have the tempco of your integration capacitor to deal with, but already around 16-20 bits you will be ovenizing everything anyway. The noise on EFC voltage changes can be given an almost arbitrary high frequency spectrum which will filter out long before it reaches the EFC input of the OCXO or Rb. In steady state, my experiment fired a single 40nsec pulse every some seconds, and I never managed to detect these pulses on the output of the voltage follower, because the integration capacitor is a glorified low-pass filter. Even at high update rates, it would be possible to use a PRNG to spread out the spectrum of the update noise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi The real answer is that you don't need anything near 32 bits. Anything with a 1.0x10^-13 AVAR isn't going to have much of a tuning range on the EFC. 22 bits will do just fine for a 1 ppm EFC range part with 1.0 x10^-12 at 1 second. With that sort of sensitivity you will have a *very* hard time getting the voltage into the OCXO without a gotcha right at the terminals, unless the unit has a fully isolated EFC input. That rules out roughly 99.99% of all OCXO's. Bob On Sep 15, 2012, at 3:12 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 437c6604-20a5-4e05-be99-9e26b01d8...@rtty.us, Bob Camp writes: If indeed 32 bits matters, then instability at the 32 bit level will show up. [...] No free lunch Absolutely agree there. My point was merely that the requirements for the DAC after a software-PLL are very narrow and specific, compared the the quality metrics of DAC's in general, and that low cost methods are available to meet those needs, so there is no need to spend a fortune on a general X bit DAC, if cheaper special purpose one will do. One of the advantages of the charge-transfer DAC concept is that there is only thermal noise for a stable output, there is no reference voltage which can suffer from tempco or noise bleed-through. You'll have the tempco of your integration capacitor to deal with, but already around 16-20 bits you will be ovenizing everything anyway. The noise on EFC voltage changes can be given an almost arbitrary high frequency spectrum which will filter out long before it reaches the EFC input of the OCXO or Rb. In steady state, my experiment fired a single 40nsec pulse every some seconds, and I never managed to detect these pulses on the output of the voltage follower, because the integration capacitor is a glorified low-pass filter. Even at high update rates, it would be possible to use a PRNG to spread out the spectrum of the update noise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
On Sat, Sep 15, 2012 at 11:11 AM, paul swed paulsw...@gmail.com wrote: I also have a z3801 so perhaps I will face the same issue at some point. The question I have is the following. If a uproc is inserted between the rcvr and the chassis to intercept the init command. Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. The could be a pretty huge upgrade. Enough maybe to just replacing working GPS cards. The newer Oncores have 10X or more better performance. You uP would have to introduce a small delay but not much if it is just passthrough data. The latest GPSes run on 3 volts rather than 5. It might be worth building a DC/DC converter on the same card as your uP because the new 3V GPS are that much better. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantization error
Second the comments on implementing a 16 bit DAC. You need separate analogue/digital grounds, superb voltage references, and lots of attempts to get a good design that actually uses the L.S. bit (rather than losing it in the noise). What you can do is use a second DAC to offset the 16 bit DAC. The offset DAC need only be 8 bit, as long as it is stable. I used this to autozero the output of a photomultiplier amplifier, and I needed about 20 bits to get the correct resolution. However, it can be tricky to adjust the offset DAC without jumps in the output. Incidentally superb experimental design, circuit boards taped to an odd piece of cardboard, with jumpers leads to tie everything together :). I use a dab of hot melt glue to do similar, and it can be used to secure wiring as well. On 15 September 2012 07:01, Don Latham d...@montana.com wrote: Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution will be headache enough. You will gain a real education in good grounding practice, shielding, power supply stability and noise, and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that tune. Don Chris Albertson On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp g...@partiallystapled.com wrote: Finally, do people think a 16 bit DAC is adequate or should I consider building a 32-bit one? I looked at a few designs when putting this together but decided to keep it simple until things were up and running. Having a 32-bit DAC would give you enough range so that you could drop in any OCXO you might have. But if you can have trimmer resisters to selected for your specif OCXO then 16-bits should be enough. If it were me, I'd want the DAC steps to be smaller than what the phase detector can measure. Said another way a 32-bit DAC might eliminate the need for scale and offset trimmer resistors. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Neither the voice of authority nor the weight of reason and argument are as significant as experiment, for thence comes quiet to the mind. De Erroribus Medicorum, R. Bacon, 13th century. If you don't know what it is, don't poke it. Ghost in the Shell Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Tom Harris celephi...@gmail.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
As Bob mentions there may be more to it then just nailing that particular command. But worth taking a look after I deal with the wwvb psk issue. As far as the 5 to 3 V I would just use a 3 term reg like the cherry semi chip. But there are plenty of alternates. It will take 5 in and give 3.3 out at plenty of current. I think the discussions useful as to exactly what the correct new rvcr would be that is available and for $5. ;-) Regards Paul On Sat, Sep 15, 2012 at 9:09 PM, Chris Albertson albertson.ch...@gmail.comwrote: On Sat, Sep 15, 2012 at 11:11 AM, paul swed paulsw...@gmail.com wrote: I also have a z3801 so perhaps I will face the same issue at some point. The question I have is the following. If a uproc is inserted between the rcvr and the chassis to intercept the init command. Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. The could be a pretty huge upgrade. Enough maybe to just replacing working GPS cards. The newer Oncores have 10X or more better performance. You uP would have to introduce a small delay but not much if it is just passthrough data. The latest GPSes run on 3 volts rather than 5. It might be worth building a DC/DC converter on the same card as your uP because the new 3V GPS are that much better. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
The could be a pretty huge upgrade. Enough maybe to just replacing working GPS cards. The newer Oncores have 10X or more better performance. You uP would have to introduce a small delay but not much if it is just passthrough data. ... Has anybody looked at the software inside the Z3801A? How much work would it be to reverse engineer things enough so that you could adapt it to talking to a new GPS board without having to rediscover every last detail? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO control loops and correcting quantization error
The PWM DAC should have perfect differential linearity, which I believe is all that matters in this application. (That and no missing codes.) Not so when you try to combine two DACs to make one higher resolution DAC. -Original Message- From: Tom Harris celephi...@gmail.com Sender: time-nuts-boun...@febo.com Date: Sun, 16 Sep 2012 12:00:55 To: Discussion of precise time and frequency measurementtime-nuts@febo.com Reply-To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] GPSDO control loops and correcting quantization error Second the comments on implementing a 16 bit DAC. You need separate analogue/digital grounds, superb voltage references, and lots of attempts to get a good design that actually uses the L.S. bit (rather than losing it in the noise). What you can do is use a second DAC to offset the 16 bit DAC. The offset DAC need only be 8 bit, as long as it is stable. I used this to autozero the output of a photomultiplier amplifier, and I needed about 20 bits to get the correct resolution. However, it can be tricky to adjust the offset DAC without jumps in the output. Incidentally superb experimental design, circuit boards taped to an odd piece of cardboard, with jumpers leads to tie everything together :). I use a dab of hot melt glue to do similar, and it can be used to secure wiring as well. On 15 September 2012 07:01, Don Latham d...@montana.com wrote: Michael: Actually implementing a 16 bit DAC to its 1-bit minimum resolution will be headache enough. You will gain a real education in good grounding practice, shielding, power supply stability and noise, and other Murphy intrusion. A 32 bit DAC IMHO, is impossible, and that's the name of that tune. Don Chris Albertson On Fri, Sep 14, 2012 at 11:21 AM, Michael Tharp g...@partiallystapled.com wrote: Finally, do people think a 16 bit DAC is adequate or should I consider building a 32-bit one? I looked at a few designs when putting this together but decided to keep it simple until things were up and running. Having a 32-bit DAC would give you enough range so that you could drop in any OCXO you might have. But if you can have trimmer resisters to selected for your specif OCXO then 16-bits should be enough. If it were me, I'd want the DAC steps to be smaller than what the phase detector can measure. Said another way a 32-bit DAC might eliminate the need for scale and offset trimmer resistors. Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Neither the voice of authority nor the weight of reason and argument are as significant as experiment, for thence comes quiet to the mind. De Erroribus Medicorum, R. Bacon, 13th century. If you don't know what it is, don't poke it. Ghost in the Shell Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Tom Harris celephi...@gmail.com ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] New wrist Watch
Jim Lux writes: It won't be state of the art (I think tvb's cesium wrist watch does that.. but it doesn't have the non-digital display you want) One would think wristwatches based on the Symmetricom CSAC would be on the market by now. Surely the prices some are willing to pay for high-end mechanical watches would support the $1500 cost of the module. A modest, cellphone-like lithium cell would be enough for a day's use (even with the CSAC's full-power mode of 120 mW), then recharge it each night. Cheers, Peter ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
