Re: [time-nuts] GPSDO control loops and correcting quantization error

2012-09-16 Thread Poul-Henning Kamp
In message 1225454799-1347767280-cardhu_decombobulator_blackberry.rim.net-1901
834519-@b27.c1.bise6.blackberry, li...@lazygranch.com writes:

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.

The main problem with two staggered DAC's is actually that all OCXO's
drift and eventually you will have to step the major DAC which will give
a glitch in the lower bits, almost no matter how much you calibrate
beforehand.

The PRS10 uses a staggered DAC internally and the steps on the major
DAC are measurable in the output signal.

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

2012-09-15 Thread Hal Murray

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 quantization error

2012-09-15 Thread Bruce Griffiths

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

2012-09-15 Thread Magnus Danielson

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 quantization error

2012-09-15 Thread Tom Harris
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] GPSDO control loops and correcting quantization error

2012-09-15 Thread lists
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.


[time-nuts] GPSDO control loops and correcting quantization error

2012-09-14 Thread Michael Tharp

Greetings nuts,

I've been working on a simple GPSDO as a starting point for further 
experimentation. I'm using a STM32 microcontroller running at 72MHz as 
the heart, with the input capture peripheral comparing the phase of the 
pulses-per-second and a 16 bit PWM DAC to drive the VFC. It's all 
working quite well from a functional standpoint although I'm sure the 
performance will be quite terrible by time-nuts standards, unfortunately 
I don't yet have the equipment to characterize precisely how terrible it 
is, but that will come later. So now that the basic functionality is 
there I've got a few questions about improving it.


First off a technical question. I'm using a Trimble Resolution SMT as 
the pulse-per-second source. It sends a supplemental timing packet that 
contains an estimate of the quantization error in its pulse output. But 
the manual isn't clear on whether that applies to the next pulse or to 
the previous one. I've seen people correct the delay by using a 
programmable delay line which seems like it would only be possible if 
the measurement was for the next pulse. But on the other hand there is a 
pulse was not generated alarm that definitely applies to the previous 
(non)-pulse which suggests that maybe other fields refer exclusively to 
the previous pulse. I can handle either way since the pulses are 
timestamped asynchronously and can be post-processed at any time but 
from some preliminary data collection it's not clear which way it's 
meant to go. Does anyone know for sure whether the quantization error is 
for the next or preceding pulse?


Secondly, a more general design question. Right now the feedback is done 
through a relatively fast PI controller. For example, here's a chart 
showing convergence at various integration coefficients:

http://partiallystapled.com/~gxti/circuits/2012/09/13-pid-ki.png
The Ki coefficient units are somewhat arbitrary due to the fixed-point 
math, but the X axis is seconds and the Y axis is number of counts at 
72MHz (13.89ns). Right now I'm using Ki=1 because it converges quickly 
enough and also don't oscillate, but these parameters are only 
particularly interesting on startup. Something much, much slower seems 
more suitable for continuous operation. But I'm thinking that the best 
solution might be to start out with fast convergence like this, then 
switch to slower parameters (for PI controller and smoothing) once some 
desired level of stability is reached. Any thoughts on this change of 
parameters, or PI tuning in general, or perhaps an entirely different 
control topology?


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. 
There is some room for expansion if I want to replace the DAC or add a 
third oscillator input for holdover. In fact, this board seems to have 
more connectors than ICs:

http://partiallystapled.com/~gxti/trash/2012/09/08-serafine.jpg

Cheers,
-- m. tharp

___
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

2012-09-14 Thread SAIDJACK
Hi M.
 
welcome to the world of GPSDO optimization, one thing you will find  is 
that there never is a time when there is no chance to improve something  :)
 
On the 1PPS sawtooth correction, the usual convention is for the following  
1PPS.
 
The easiest thing to do rather than trying to guess the GPS unit's behavior 
 is to try it out on both pulses, and also try adding and subtracting the 
number  from your raw phase measurement, then you get four streams of values, 
and it  will be instantly obvious which one is the one that reduces the 
noise most. The  other three will increase the noise over your raw,  
uncorrected measurements.
 
On the DAC resolution, it depends on the OCXO control range, and the ADEV  
performance you want to achieve. For example if your OCXO has +/-2Hz control 
 range, then a 16 bit DAC will only give you an LSB resolution of about 61  
microhertz, or 6.1E-012 (4Hz divided by 2^16). This may or may not be 
acceptable  to you.
 
If your OCXO has a more typical +/-20Hz control range, then this would go  
up to 6.1E-011 per LSB, which will definitely affect your ADEV. Usually, 
GPSDO's  use at least 20 bit control range due to this quantization effect.
 
But in the end it may also be limited by your time-interval-counter  
resolution, because every tick in your counter will equal to so many steps in  
your DAC (depending on what gains you use for your loop prediction).
 
Also, make sure to put filtering for errand pulses into your  code, every 
GPS WILL generate an errand pulse from time to time in my  experience, and 
these can be off by 10's of microseconds.. if you don't filter  these 
properly, they will lead to jumps in your frequency.
 
Hope that helps,
Said
 
 
 
 
 
 
In a message dated 9/14/2012 11:21:57 Pacific Daylight Time,  
g...@partiallystapled.com writes:

First  off a technical question. I'm using a Trimble Resolution SMT as 
the  pulse-per-second source. It sends a supplemental timing packet that  
contains an estimate of the quantization error in its pulse output. But  
the manual isn't clear on whether that applies to the next pulse or to  
the previous one. I've seen people correct the delay by using a  
programmable delay line which seems like it would only be possible if  
the measurement was for the next pulse. But on the other hand there is a  
pulse was not generated alarm that definitely applies to the previous  
(non)-pulse which suggests that maybe other fields refer exclusively to  
the previous pulse. I can handle either way since the pulses are  
timestamped asynchronously and can be post-processed at any time but  
from some preliminary data collection it's not clear which way it's  
meant to go. Does anyone know for sure whether the quantization error is  
for the next or preceding  pulse?


___
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

2012-09-14 Thread 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.


Re: [time-nuts] GPSDO control loops and correcting quantization error

2012-09-14 Thread Azelio Boriani
Also you need a super ultra fantastic voltage reference for a 32bit DAC.
Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take 10
averages and your resolution will be 1nS and so on. When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be predicted (Kalman filtering) and applied at the
same speed.

On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.ch...@gmail.comwrote:

 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.

___
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

2012-09-14 Thread Bruce Griffiths

Azelio Boriani wrote:

Also you need a super ultra fantastic voltage reference for a 32bit DAC.
   
Not really, the reference only needs to have low noise and good short 
term stability.
Long term drift in the reference voltage will be corrected by the 
feedback loop.

Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
then slow and then very slow. The levels trigger when the precision
estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take 10
averages and your resolution will be 1nS and so on.
However the noise associated with the timing resolution doesn't average 
down so quickly.
If such noise is random than at best it is reduced by SQRT(10) by 
averaging 10 measurements.

There is no real substitute for lower noise, higher resolution measurements.

When I switch level,
the number of averages is increased too but this leads to a slower DAC
update rate. This is the problem: now I'm trying to figure out if the
corrective action can be predicted (Kalman filtering) and applied at the
same speed.
   

Bruce

On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
albertson.ch...@gmail.comwrote:

   

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.

 

___
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 quantization error

2012-09-14 Thread Azelio Boriani
Yes, you are right: but actually I have a 2.5nS simple time interval
counter in the FPGA and the only way to go beyond is the average. The
sophisticated way would be to implement a tapped delay line or vernier
delay line time-to-digital converter in a bigger FPGA than the XC3S50. And,
yes, I have recently started my first GPS disciplined Rb with the same
hardware. I have eliminated the fast and slow steps from the processing,
using only the slowest one.

On Fri, Sep 14, 2012 at 9:50 PM, Bruce Griffiths bruce.griffi...@xtra.co.nz
 wrote:

 Azelio Boriani wrote:

 Also you need a super ultra fantastic voltage reference for a 32bit DAC.


 Not really, the reference only needs to have low noise and good short term
 stability.
 Long term drift in the reference voltage will be corrected by the feedback
 loop.

  Anyway, yes, in my GPSDO the controller has 3 levels: at startup is fast,
 then slow and then very slow. The levels trigger when the precision
 estimate is 10E-9 and 10E-11. If you have a resolution of 10nS then take
 10
 averages and your resolution will be 1nS and so on.

 However the noise associated with the timing resolution doesn't average
 down so quickly.
 If such noise is random than at best it is reduced by SQRT(10) by
 averaging 10 measurements.
 There is no real substitute for lower noise, higher resolution
 measurements.

  When I switch level,
 the number of averages is increased too but this leads to a slower DAC
 update rate. This is the problem: now I'm trying to figure out if the
 corrective action can be predicted (Kalman filtering) and applied at the
 same speed.


 Bruce

  On Fri, Sep 14, 2012 at 8:52 PM, Chris Albertson
 albertson.ch...@gmail.comwrote:



 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.



 ___
 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 quantization error

2012-09-14 Thread Don Latham
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.


Re: [time-nuts] GPSDO control loops and correcting quantization error

2012-09-14 Thread Chris Albertson
-- Forwarded message --
From: Don Latham d...@montana.com
Date: Fri, Sep 14, 2012 at 2:01 PM
Subject: Re: [time-nuts] GPSDO control loops and correcting quantization error
To: Discussion of precise time and frequency measurement time-nuts@febo.com


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.

I think the step size would be close to the same with the 32 bit DAC
but the reason you use it is so you can control just about any OCXO,
Rb or other things you drop in.  In other words I'd use the extra bits
to extend the voltage range.  But while in use, I doubt you'd ever
change the highest 16 or 18 bits

Also if you are building a general purpose controller for OCXOs and
Rb, remember that some Rb oscillators use RS-232 control to set the
frequqecy.  It might be good to build in an RS232 port.   The firmware
in the uP can always be changed but hard to add the DB9 connector
later.

One otherthing I was doing when I was working on a design like this
was to discipline both an XO and an Rb from the same GPS.  Almost like
building two controllers but you save some because you can use one uP
and one GPS interface.   Now that you have a disciplined Rb it can be
used for hold over in case the GPS goes away.   I thought it would be
unlikely for GPS to actually fail but allowing for hold over would
make the entire unit portable.


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

2012-09-14 Thread Michael Tharp

On 09/14/2012 05:31 PM, Chris Albertson 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.


Probably true, luckily as others have mentioned the long-term stability 
of the DAC and its voltage source are less important.



I think the step size would be close to the same with the 32 bit DAC
but the reason you use it is so you can control just about any OCXO,
Rb or other things you drop in.  In other words I'd use the extra bits
to extend the voltage range.  But while in use, I doubt you'd ever
change the highest 16 or 18 bits

Also if you are building a general purpose controller for OCXOs and
Rb, remember that some Rb oscillators use RS-232 control to set the
frequqecy.  It might be good to build in an RS232 port.   The firmware
in the uP can always be changed but hard to add the DB9 connector
later.

One otherthing I was doing when I was working on a design like this
was to discipline both an XO and an Rb from the same GPS.  Almost like
building two controllers but you save some because you can use one uP
and one GPS interface.   Now that you have a disciplined Rb it can be
used for hold over in case the GPS goes away.   I thought it would be
unlikely for GPS to actually fail but allowing for hold over would
make the entire unit portable.


I had this idea as well, although not for disciplining the Rb (which 
unfortunately mine cannot, it's a less popular Efratom model clearly 
pulled from telecom application and has no external control that I can 
see) but just as a backup timing source for holdover. I've mentioned it 
here before, but the gist would be to estimate its frequency while GPS 
was working, then if GPS fails use the Rb instead either by dividing it 
by the last known frequency or by adding the error to the measurement 
loop. That said, I would like the holdover performance with just the 
OCXO to be as good as possible in its own right.


I'm planning to make a future version of this project available but this 
first revision is mainly an experimentation platform and wouldn't be of 
much use to someone who doesn't have the same equipment as me. Stay tuned...


-- m. tharp

___
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

2012-09-14 Thread Hal Murray

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


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


[time-nuts] GPSDO control loops and correcting quantization error

2012-09-14 Thread Don Oconnor
Hello all, 



Most voltage controlled XOs have a voltage reference output. Is it necessary 
for the DAC output / frequency control input, to track this voltage reference 
output?



Thank You



Don O'Connor
___
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

2012-09-14 Thread GandalfG8
Hi Don,
 
I don't know if I've misunderstood your question, but as I understand it  
the voltage reference output is a fixed voltage from an internal  regulator 
that can then be used as the supply to an external control  circuit.
For example, it could be used as the feed voltage for a variable resistor  
that has its wiper connected to the EFC input to allow for manual frequency  
adjustment.
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.
 
Regards
 
Nigel
GM8PZR 
 
In a message dated 14/09/2012 23:10:59 GMT Daylight Time, eg...@wowway.com  
writes:

Hello  all, 

Most voltage controlled XOs have a voltage reference output. Is  it 
necessary for the DAC output / frequency control input, to track this  voltage 
reference output?

Thank You


Don  O'Connor
___
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 quantization error

2012-09-14 Thread Azelio Boriani
If it is a reference then tracking is not the correct term: it shouldn't
move. If it is a reference then can be used for the DAC.

On Sat, Sep 15, 2012 at 12:10 AM, Don Oconnor eg...@wowway.com wrote:

 Hello all,



 Most voltage controlled XOs have a voltage reference output. Is it
 necessary for the DAC output / frequency control input, to track this
 voltage reference output?



 Thank You



 Don O'Connor
 ___
 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] GPSDO control loops and correcting quantization error

2012-09-14 Thread Don Oconnor
Nigel,

Yes, you understood and answered the question.

Thank you

Don O 


I don't know if I've misunderstood your question, but as I understand it  
the voltage reference output is a fixed voltage from an internal  regulator 
that can then be used as the supply to an external control  circuit.
For example, it could be used as the feed voltage for a variable resistor  
that has its wiper connected to the EFC input to allow for manual frequency  
adjustment.
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.
 
Regards
 
Nigel
GM8PZR 
 
In a message dated 14/09/2012 23:10:59 GMT Daylight Time, eg...@wowway.com  
writes:

Hello  all, 

Most voltage controlled XOs have a voltage reference output. Is  it 
necessary for the DAC output / frequency control input, to track this  voltage 
reference output?

___
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

2012-09-14 Thread David
On Fri, 14 Sep 2012 15:08:53 -0700, Hal Murray
hmur...@megapathdsl.net 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.

One thing you sure want is a DAC that is monotonic.  Differential
nonlinearity larger than the least significant bit can cause some
rather peculiar servo loop problems.

___
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

2012-09-14 Thread Azelio Boriani
My 2.5nS TIC? Very simple: a 400MHz counter start-stop gated with the two
signal to compare. I have published here the VHDL code for it few months
ago. Really nothing new but simple and useful for a 35-40nS GPSDO PPS
output from an OCXO. The Rb PPS wondering is actually under evaluation
against the Z3815A.

On Sat, Sep 15, 2012 at 12:08 AM, Hal Murray hmur...@megapathdsl.netwrote:


 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


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

___
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

2012-09-14 Thread Bob Camp
Hi

Very few VCXO's have reference outputs. Some OCXO's have reference outputs. The 
gotcha there is the oven current. You can easily get multiple mV sort of 
changes in the  OCXO ground voltage as the oven current cycles over a fairly 
narrow range. That significantly impacts the usefulness of the reference, since 
they share a common ground.

Bob

On Sep 14, 2012, at 6:10 PM, Don Oconnor eg...@wowway.com wrote:

 Hello all, 
 
 
 
 Most voltage controlled XOs have a voltage reference output. Is it necessary 
 for the DAC output / frequency control input, to track this voltage reference 
 output?
 
 
 
 Thank You
 
 
 
 Don O'Connor
 ___
 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.