On Sat, Jun 10, 2017 at 11:33 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Hi,
I was about to make this very point myself. The resolution of the ADC
needs to be higher than the limit you try to achieve. There is several ways
to reason about it, but one is that the system is a bit slugish you want to
have higher resolution in order to react of changes before they overshot
the limits you want to keep. Another benefit is that you get away from the
bang-bang behavior you get when having too few bits.
For an oven you can however cheat some by not requiring linearity in the
"too cold" region of temperature. You do want some linearity as you start
to come into the right range in order to slow down the heating in order not
to do a big overshot.
I have seen a little too much cases where there been too few bits both on
ADC and DAC sides. Some of it you can overcome, but it runs into trouble.
Get good dynamics, it makes the rest of the design easier.
OK, following the advice both above and below. Let's try some real-world
numbers...
Lets say my goal is regulation within 0.1C. After filtering I have 10
"good" bits in my ADC. That is 1024 counts. My set point is S.
I scale the ADC so that 0 == (S - 0.5) and 1023 == (S + 0.5) This means
that each ADC count is 0.001 degree C and within the 0.1C range there are
100 ADC counts.
But what if there are only 8 good bits after filtering The each count is
0.004 degree C and there are 25 counts within the 0.1C range.
The uP's ADC is nominally 12 bits. Getting 10 "good" noise free bits
might be asking to much but 8-bits is pretty reasonable.
Cheers,
Magnus
On 06/07/2017 08:32 PM, Bob kb8tq wrote:
Hi
There is a gotcha with the initial assumption: You want the loop to be
quiet at a level well below 0.1C. If it is bouncing around that much,
the second order (rate defendant) tempco of a normal crystal will
become a pretty major issue.
Simple rule of thumb - add at least two bits past whatever the target is.
More or less, if you are after 0.1C and that comes out to 6 bits, you
need
eight solid bits to get things to work properly.
--
Chris Albertson
Redondo Beach, California
Hi
The next issue is that “noise” has a pretty broad definition in this case.
If you are looking at set point, it also would include temperature drift and
aging. Neither one seem to show up on the standard MCU ADC data sheets :)
It can even be a bit difficult to find them on some (but certainly not all)
standalone ADC specs.
Next layer to the onion:
If we want to hold the oven at some temperature +/- 0.1 C, the control loop
needs to go from full on to full off over that range. For grins, let’s assume
that the output is a 16 bit DAC. You will map (somehow) the full range of the
output into a 0.2 C input range.
If you have a P only controller, the output will step at the granularity of the
ADC over the 0.2C range. If you have 4 extra bits, you will get 16 x 2 = 32
output levels. That’s not really making the 16 bit DAC earn it’s living.
A PI controller can (at least theoretically) fill in all of the states of the 16 bit DAC regardless
of the input granularity. If the P is very small and the I is very large it will
do this fairly seamlessly. In the example above setting P to < 1/ 2^11 would
likely do the trick. This all may (or may not) let you hit the P value (or P to I ratio)
you desire.
Why does the output DAC matter? Each time the DAC steps, the current
in the heater changes. That power change times the thermal resistance gives
you a temperature step. It is yet another source of “noise” to the crystal.
Minimizing thermal noise is one of the many things that gets you better ADEV.
Bob
On Jun 10, 2017, at 3:24 PM, Chris Albertson albertson.chris@gmail.com wrote:
On Sat, Jun 10, 2017 at 11:33 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Hi,
I was about to make this very point myself. The resolution of the ADC
needs to be higher than the limit you try to achieve. There is several ways
to reason about it, but one is that the system is a bit slugish you want to
have higher resolution in order to react of changes before they overshot
the limits you want to keep. Another benefit is that you get away from the
bang-bang behavior you get when having too few bits.
For an oven you can however cheat some by not requiring linearity in the
"too cold" region of temperature. You do want some linearity as you start
to come into the right range in order to slow down the heating in order not
to do a big overshot.
I have seen a little too much cases where there been too few bits both on
ADC and DAC sides. Some of it you can overcome, but it runs into trouble.
Get good dynamics, it makes the rest of the design easier.
OK, following the advice both above and below. Let's try some real-world
numbers...
Lets say my goal is regulation within 0.1C. After filtering I have 10
"good" bits in my ADC. That is 1024 counts. My set point is S.
I scale the ADC so that 0 == (S - 0.5) and 1023 == (S + 0.5) This means
that each ADC count is 0.001 degree C and within the 0.1C range there are
100 ADC counts.
But what if there are only 8 good bits after filtering The each count is
0.004 degree C and there are 25 counts within the 0.1C range.
The uP's ADC is nominally 12 bits. Getting 10 "good" noise free bits
might be asking to much but 8-bits is pretty reasonable.
Cheers,
Magnus
On 06/07/2017 08:32 PM, Bob kb8tq wrote:
Hi
There is a gotcha with the initial assumption: You want the loop to be
quiet at a level well below 0.1C. If it is bouncing around that much,
the second order (rate defendant) tempco of a normal crystal will
become a pretty major issue.
Simple rule of thumb - add at least two bits past whatever the target is.
More or less, if you are after 0.1C and that comes out to 6 bits, you
need
eight solid bits to get things to work properly.
--
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.
In message 017AC7D5-751B-4084-A3B3-E5132509C180@n1k.org, Bob kb8tq writes:
You may well use a custom set of control parameters for the warmup phase.
The easiest way to avoid overshoot is to use a properly damped PI(D),
which is exactly the same thing you want once you are out of the
warmup phase, so why bother with two different code paths ?
But related to this is the question of output/heater resolution[1].
While it is tempting to use a PWM output, it is a recipe for noise
injection, and I would not even try it.
Delta-Sigma strategies for spreading the noise-spectrum are
interesting, but will not save you if the required heater power
ends up being a small rational fraction (1/2, 1/3, 1/4 ...) of the
full scale.
So a proper DAC is called for.
I wonder if a "4-20mA" DAC like the AD5421 is a usable programmable heater ?
[1] It is relevant to point out that, as always the 'I' term
should not be enabled until the P(ID) output is no longer clamped.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
On Sat, Jun 10, 2017 at 12:59 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
Delta-Sigma strategies for spreading the noise-spectrum are
interesting, but will not save you if the required heater power
ends up being a small rational fraction (1/2, 1/3, 1/4 ...) of the
full scale.
How many output bits are required? Most uPs have quite a few digital
output pins. Each pin could drive a heater resister. Values of the
resisters organized by power of two. Again note the title (poor mans...)
resisters cost almost zero. Even of driver transistors are needed you'd
get change back from a dollar bill.
The reason I ask "how many bits" is because the above is reasonable with 4
to 6 effective bits but not reasonable with 24
I say "effective" because we can dither the low order bits to gain maybe 6
effective bits form 4 real bits (we can filter the switching noise from a
low frequency dither)
--
Chris Albertson
Redondo Beach, California
Hi,
On 06/10/2017 09:59 PM, Poul-Henning Kamp wrote:
In message 017AC7D5-751B-4084-A3B3-E5132509C180@n1k.org, Bob kb8tq writes:
You may well use a custom set of control parameters for the warmup phase.
The easiest way to avoid overshoot is to use a properly damped PI(D),
which is exactly the same thing you want once you are out of the
warmup phase, so why bother with two different code paths ?
But related to this is the question of output/heater resolution[1].
While it is tempting to use a PWM output, it is a recipe for noise
injection, and I would not even try it.
Delta-Sigma strategies for spreading the noise-spectrum are
interesting, but will not save you if the required heater power
ends up being a small rational fraction (1/2, 1/3, 1/4 ...) of the
full scale.
So a proper DAC is called for.
I wonder if a "4-20mA" DAC like the AD5421 is a usable programmable heater ?
[1] It is relevant to point out that, as always the 'I' term
should not be enabled until the P(ID) output is no longer clamped.
A proper DAC is clearly called for.
PWM is worst possible waveform, as it puts highest amplitude to the
lowest frequency etc, thus it has a 6 dB/Oct roll-off. I once decided to
move the spectrum components around so that the MSB has the highest
frequency and LSB the lowest. With a simple one-pole filter this creates
overtones of even amplitude. I used this to cram a few more bits out of
a DAC, with really good result.
The sigma/delta approach is even better in doing this, even if my
approach gets similar results, with a fairly crude approach.
Cheers,
Magnus
Hi,
As a side comment. I've seen an OCXO misbehave such that it was
bang-bang regulating. For a short while it was heating up and then the
crystal was cooling down slowly until the heater was turned on again,
shortly. The effect being that the temperature of the crystal was
essentially a saw-tooth shaped thing, and the frequency and phase
reflected that very clearly, and ADEV is full of the systematic noise of
the oven.
For another OCXO I noticed a distinct bump in the ADEV at 7 s. I looked
carefully and could even see the oscillation in the phase-data. Then I
also found it in the oven current. Turned out that as I turned the oven
on, it GREATLY overshot and rang as a bell on the overn
current/temperature. The vendor was given notice and they dug into it
and sent out two engineers to explain it to me. They could explain it
correctly, and then tried the sales-guy to cover it up and say it worked
well enough for others and THAT is when I decided they where running an
uphill game. Anyway, I think some engineers learned the hard way that
you need to adjust the design as you change critical parts of the design.
Even a "simple" setup for testing can be quite revealing.
Cheers,
Magnus
On 06/10/2017 09:50 PM, Bob kb8tq wrote:
Hi
The next issue is that “noise” has a pretty broad definition in this case.
If you are looking at set point, it also would include temperature drift and
aging. Neither one seem to show up on the standard MCU ADC data sheets :)
It can even be a bit difficult to find them on some (but certainly not all)
standalone ADC specs.
Next layer to the onion:
If we want to hold the oven at some temperature +/- 0.1 C, the control loop
needs to go from full on to full off over that range. For grins, let’s assume
that the output is a 16 bit DAC. You will map (somehow) the full range of the
output into a 0.2 C input range.
If you have a P only controller, the output will step at the granularity of the
ADC over the 0.2C range. If you have 4 extra bits, you will get 16 x 2 = 32
output levels. That’s not really making the 16 bit DAC earn it’s living.
A PI controller can (at least theoretically) fill in all of the states of the 16 bit DAC regardless
of the input granularity. If the P is very small and the I is very large it will
do this fairly seamlessly. In the example above setting P to < 1/ 2^11 would
likely do the trick. This all may (or may not) let you hit the P value (or P to I ratio)
you desire.
Why does the output DAC matter? Each time the DAC steps, the current
in the heater changes. That power change times the thermal resistance gives
you a temperature step. It is yet another source of “noise” to the crystal.
Minimizing thermal noise is one of the many things that gets you better ADEV.
Bob
On Jun 10, 2017, at 3:24 PM, Chris Albertson albertson.chris@gmail.com wrote:
On Sat, Jun 10, 2017 at 11:33 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Hi,
I was about to make this very point myself. The resolution of the ADC
needs to be higher than the limit you try to achieve. There is several ways
to reason about it, but one is that the system is a bit slugish you want to
have higher resolution in order to react of changes before they overshot
the limits you want to keep. Another benefit is that you get away from the
bang-bang behavior you get when having too few bits.
For an oven you can however cheat some by not requiring linearity in the
"too cold" region of temperature. You do want some linearity as you start
to come into the right range in order to slow down the heating in order not
to do a big overshot.
I have seen a little too much cases where there been too few bits both on
ADC and DAC sides. Some of it you can overcome, but it runs into trouble.
Get good dynamics, it makes the rest of the design easier.
OK, following the advice both above and below. Let's try some real-world
numbers...
Lets say my goal is regulation within 0.1C. After filtering I have 10
"good" bits in my ADC. That is 1024 counts. My set point is S.
I scale the ADC so that 0 == (S - 0.5) and 1023 == (S + 0.5) This means
that each ADC count is 0.001 degree C and within the 0.1C range there are
100 ADC counts.
But what if there are only 8 good bits after filtering The each count is
0.004 degree C and there are 25 counts within the 0.1C range.
The uP's ADC is nominally 12 bits. Getting 10 "good" noise free bits
might be asking to much but 8-bits is pretty reasonable.
Cheers,
Magnus
On 06/07/2017 08:32 PM, Bob kb8tq wrote:
Hi
There is a gotcha with the initial assumption: You want the loop to be
quiet at a level well below 0.1C. If it is bouncing around that much,
the second order (rate defendant) tempco of a normal crystal will
become a pretty major issue.
Simple rule of thumb - add at least two bits past whatever the target is.
More or less, if you are after 0.1C and that comes out to 6 bits, you
need
eight solid bits to get things to work properly.
--
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.
In message 73A71EF4-EB76-4965-B3D5-53F9DD5BF0FA@n1k.org, Bob kb8tq writes:
If we want to hold the oven at some temperature +/- 0.1 C, the control loop
needs to go from full on to full off over that range.
...ehhh, what ?
You will map (somehow) the full range of the output into a 0.2 C input range.
Uhmm... no ?
The full DAC range maps to the heat you need for supply at the two
ambient temperature extremes.
For instance if you were building a -40...+70C OCXO, ideally
DAC code 0 should correspond to +70C and DAC code 65535 to -40C ambient
That means that one DAC step corresponds to a change in ambient temperature
of (+70 - -40) / 65536 = 1.7 milliKelvin.
A more realistic temperature range for a time-nut build would be +10...+40C.
DAC bits mK
--------------------
10 29.3
12 7.3
14 1.8
16 0.5
--------------------
10 bits would cause I-hunting in your PI(D) but the measurement noise
would probably dither that for you.
12 bits would allos a trivial implementation.
If you go for a double or tripple oven/dewar design, you probably
need 14 bits.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
Hi
On Jun 10, 2017, at 4:10 PM, Chris Albertson albertson.chris@gmail.com wrote:
On Sat, Jun 10, 2017 at 12:59 PM, Poul-Henning Kamp phk@phk.freebsd.dk
wrote:
Delta-Sigma strategies for spreading the noise-spectrum are
interesting, but will not save you if the required heater power
ends up being a small rational fraction (1/2, 1/3, 1/4 ...) of the
full scale.
How many output bits are required? Most uPs have quite a few digital
output pins. Each pin could drive a heater resister. Values of the
resisters organized by power of two. Again note the title (poor mans...)
resisters cost almost zero. Even of driver transistors are needed you'd
get change back from a dollar bill.
If you believe that you have a “background” TC of 1x10^-8 / C (for a variety of reasons), that
will drive a few things. For right now simply take it as another arbitrary parameter, just like
the +/- 0.1C we started with.
If you want the controller noise to not be the limiting factor at an ADEV floor of 1x10^-12,
that drives you to a noise floor of < 0.1 mK. You can then work through the various thermal
gains to come up with a level of DAC bits that you need. You could equally as well decide
on a 1x10^-13 floor and / or might have a 1x10^-9 sensitivity.
Bob
The reason I ask "how many bits" is because the above is reasonable with 4
to 6 effective bits but not reasonable with 24
I say "effective" because we can dither the low order bits to gain maybe 6
effective bits form 4 real bits (we can filter the switching noise from a
low frequency dither)
--
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.
In message B90B65D3-5E09-4C1C-ADE1-100A0A26D418@n1k.org, Bob kb8tq writes:
If you want the controller noise to not be the limiting factor at an ADEV floor of 1x10^-12,
that drives you to a noise floor of < 0.1 mK. You can then work through the various thermal
gains to come up with a level of DAC bits that you need. You could equally as well decide
on a 1x10^-13 floor and / or might have a 1x10^-9 sensitivity.
Which gets us back to what SRS does for low noise:
Implement the low noise stuff, the PI(D) loop, in analog, but
tune/calibrate/adjust the analog circuitry with DAC's set (infrequently)
by a uC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
Hi
On Jun 10, 2017, at 5:15 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message B90B65D3-5E09-4C1C-ADE1-100A0A26D418@n1k.org, Bob kb8tq writes:
If you want the controller noise to not be the limiting factor at an ADEV floor of 1x10^-12,
that drives you to a noise floor of < 0.1 mK. You can then work through the various thermal
gains to come up with a level of DAC bits that you need. You could equally as well decide
on a 1x10^-13 floor and / or might have a 1x10^-9 sensitivity.
Sounds like a sound plan.
Bob
Which gets us back to what SRS does for low noise:
Implement the low noise stuff, the PI(D) loop, in analog, but
tune/calibrate/adjust the analog circuitry with DAC's set (infrequently)
by a uC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.