Hi
On May 19, 2016, at 12:46 PM, Attila Kinali attila@kinali.ch wrote:
On Thu, 19 May 2016 07:40:15 -0400
Bob Camp kb8tq@n1k.org wrote:
One advantage of doing all the compensation off of a single sensor is that
if there are cross effects and if you can characterize them, you can
correct them out. Put another way, if the pressure reading changes by
0.01% per C, having a reasonable idea of the temperature of the sensor lets
you take care of that.
But munching everything into a single system makes the thing mathematically
intractable. Seperating the values, compensating them for induced errors
first and then using them is much easier and less error prone.
Having all the outputs from a single sensor or multiple sensor makes the math
no harder or easier. If the pressure sensor moves 0.01% per C with a separate
pressure sensor and a separate temperature sensor …. the math is the same as
if it comes off a single device. You have the same effect to train out and the same
math to do it.
Also, composite sensors have higher uncertainties and drift
then single sensors.
That’s often the difference between a $10,000 sensor and a $1 sensor rather
than an integrated part.
Even more so: the integrated temperature sensors
are intended for use with the main sensor as a compensation tool.
Which is one of the reasons they work for that purpose.
The specs
of the temperature sensor are good enough if the drift/hysteresis of the
temperature sensor is less than the one of the main sensor. That you can
read out the temperature sensors value is more a goody for those applications
when a temperature sensor is needed but not high accuracy/precision required.
Again, a delta between a $10,000 sensor and a $1 sensor is indeed that you can
likely read the Fluke / Hart setup to a lot higher level of accuracy.
What is usually a good approach is to use the temperature sensors on
barometric and hygrometric sensors only for their temperature compensation.
At most, use the temperature sensor for cross checking and detecting faults.
For real temperature measurements, I would use a wirewond Pt sensor
on a 24bit ADC with a stable reference.
I would prefer a set of at least three SPRT’s each with their own readout and to calibrate
them each with an independent triple point cell. That most certainly would do a much better
job of producing accurate temperature. Of course, that’s not going to fit into a modest $10K
budget.
Temperature effects are by far the largest effects we have to deal with.
Having a stable and reliable measurement system for temperature is not
only worthwhile, but actually a requirement before you start compensating
anything else
But is +/- 0.0001 K good enough or do we need +/- 0.000001 K. Oddly enough, it turns out
that you can do a really good job compensating most frequency sources with a much more
modest relative accuracy. It also turns out that gradients will get you long before anything
much below 0.1C applies.
Things like sensor drift and sensor hysteresis … that’s not quite so easy to
take care of. The only hope there is that they are small enough to be
neglected. The same issue with hysteresis is actually a big limit on
humidity compensation of some devices. They adsorb water vapor at a very
different rate than they desorb.
Modeling that can be really messy.
Hysteresis can be properly modeled and compensated. The problem is, that
the math behind it becomes nasty very quickly. Often just using a simple
second order diff equation system and letting a Kalman filter estimate
the parameters is easier than modeling a full memory system... under the
condition that one can excite the system reliably and isolate/estimate
the other effects well enough.
It’s generally not the math that is the issue…..Try modeling a humidity effect that takes < 1 minute
to adsorb and a couple of months do desorb. Hysteresis in OCXO’s can turn out to be dependent
on rate, range, starting point, and air flow direction. Something over a thousand independent
test profiles (six directions, eight rates, ten ranges, ten starting points ..) may be needed to fully train it out.
Bob
Attila Kinali
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
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.
Wulf,
On 05/19/2016 11:04 AM, DG2OM@gmx.de wrote:
Some answers to comments:
Magnus,
I don’t think I have made a closed loop. It works like UTC for poor man. I gathered data from different master clocks and from a weather station and produced a new software corrected time scale for my own. But you are right. The correction is the best fit for this specific data-set and will be worse if applied to another. The ADEV plot should be clipped to trusted values - maybe 500000 sec. I intend to apply a hardware compensation. Therefore I was happy to find a barometric pressure sensor 144SC0811-Baro at an auction side some weeks ago for less than one tenth of the normal prize. Approximate 240 kOhm should be needed from the output of this module to the base of Q6B for compensation.
If you have an open loop measure of your clock and pressure, then fit
the pressure variations over the full data set and produce a corrected
value for the full dataset, then this troublesome as you now have used
the samples after the beginning to affect the beginning. You have
provided feedback and correction. This is useful to show potential of
such correction.
If you only used one dataset for match the coefficient and then use a
new dataset to correct using the new pressure data and the coefficient,
then that will be more representative of real-time performance even if
you do it as batch-processing as an after the fact setup.
What you want to do is to look at the corrected curve and see if there
is any other terms, that can be quadratic, differential or integral
variants (just to give you some ideas) of the pressure data and that may
be a hint about further improvements of the model that allows even
better compensation model.
James,
when I made the correlation the best fit was obtained comparing a frequency difference data-set delayed 1 hour to the pressure measurements. But I have to dig into the data-set again – there might be an error calculating the MJD from Middle European Time. As far as I understood from Corby´s measurements, the frequency reacts immediately to a pressure change without delay. For the compensation, a delay does not matter very much. Pressure changes are normally very slow.
The model should always be verified so that major components is found.
The proportional component seems strong thought.
Poul-Henning,
The measurement is made in normal environment. Temperature measurements of the Thunderbolt, which was two meter away, show daily variations of 1-2 degree C and an additional drop of 2 degree during the weekend. Humidity measurements are not made. Temperature effects as well as aging are still left in the residuals of my data. The aging of this specific instrument is nearly zero. The frequency was adjusted 6 month ago and the drift is less than 1E-12 during this time.
Humidity and pressure play a role with surrounding temperature in
cooling in that it they will shift the thermal resistance through which
the cooling of the ovens goes, either being higher increase the
conductance, and varies the load of the oven which will not perfectly
match the load and hence the temperature varies.
Bjørn,
I have the temperature measurements inside the Thunderbolt and temperature measurements from a temperature Data-logger placed inside the HP5065A. This datalogger has a temperature resolution of around 0.4 degC.
Attila,
I know the SHT11 from the old days when a LPT-port could be controlled by the user.
It is a nice device. But I bought the 144SC0811 which can be used by adding only one resistor.
Corby,
It would be nice to see the results with temperature compensation. There are lots of sources producing temperature sensitivity. All have a different time constant. AS Poul-Henning found out, the rate of temperature change is the worst problem. In my eyes temperature compensation is much more complicated then compensation for barometric pressure.
Pressure compensation is an interesting approach, thanks for
illustrating it!
Cheers,
Magnus
In message 20160519184616.39fd0ca08628b0843ce72a1e@kinali.ch, Attila Kinali writes:
For real temperature measurements, I would use a wirewond Pt sensor
on a 24bit ADC with a stable reference.
And where would you put the sensor ?
Where do you find a temperature so representative, that it makes any
sense to sample it with 24 bits ?
Temperature effects are by far the largest effects we have to deal with.
Which is why you'd be much better of with 20 sensors at 16 bits,
than a single sensor at 24 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.
In message 573EDC73.9040603@rubidium.dyndns.org, Magnus Danielson writes:
Humidity and pressure play a role with surrounding temperature in
cooling in that it they will shift the thermal resistance through which
the cooling of the ovens goes, [...]
Once we get below 5e-13, the temperature effects on electronic components
should not be ignored either.
The C-field circuit in particular. (Yes, I'm still working on it, just not
very fast...)
--
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.
when I made the correlation the best fit was obtained comparing a frequency difference data-set delayed 1 hour to the pressure measurements. But I have to dig into the data-set again there might be an error calculating the MJD from Middle European Time. As far as I understood from Corby´s measurements, the frequency reacts immediately to a pressure change without delay. For the compensation, a delay does not matter very much. Pressure changes are normally very slow.
I once tested an LPRO to measure the exact pressure sensitivity for a
analogue compensation circuit, and the data suggested a delay of
around 1/2 to 1 hour for best correlation between pressure and
frequency.
Although the 3 LPRO's I tested were better that the Temex and 2
FEI5680's I also tested, there were still times that they did not
match quite so well, and for no obvious reason.
I should try testing for a delay on some of the other data sets, but
since the reference for it was a M12+T, it's a problem extracting the
data from the noise.
I know the SHT11 from the old days when a LPT-port could be controlled by the user.
It is a nice device. But I bought the 144SC0811 which can be used by adding only one resistor.
I managed to get a cheap NOS one a while back too, but have not got
around to setting up a proper reference with it yet. It is not
affected by temperature too much, which makes it easier to use - but
considering the price they normally expect people to pay for it, it
should be good!
It would be nice to see the results with temperature compensation. There are lots of sources producing temperature sensitivity. All have a different time constant. AS Poul-Henning found out, the rate of temperature change is the worst problem. In my eyes temperature compensation is much more complicated then compensation for barometric pressure.
In many regards pressure is simpler, but I do wonder if the mechanical
causes may just not be repeatable enough to properly compensate out.
I've not seen much real detail about the exact causes of pressure
sensitivity in rubidiums.
Angus.
Hej Poul-Henning,
On 05/20/2016 04:27 PM, Poul-Henning Kamp wrote:
In message 573EDC73.9040603@rubidium.dyndns.org, Magnus Danielson writes:
Humidity and pressure play a role with surrounding temperature in
cooling in that it they will shift the thermal resistance through which
the cooling of the ovens goes, [...]
Once we get below 5e-13, the temperature effects on electronic components
should not be ignored either.
Well, yes. Many of the older gear uses components in loops who's
environmental performance isn't stellar by any means.
The C-field circuit in particular. (Yes, I'm still working on it, just not
very fast...)
I was actually wondering how that was getting along.
When I get the time, it would be fun to improve on things.
Humidity, temperature, pressure, powergrid voltage...
Cheers,
Magnus
In message 57410D11.8050802@rubidium.dyndns.org, Magnus Danielson writes:
The C-field circuit in particular. (Yes, I'm still working on it, just not
very fast...)
I was actually wondering how that was getting along.
Slowly, we're starting our house-building project now, so I've got a bit
more than usual on my plate.
When I get the time, it would be fun to improve on things.
Humidity, temperature, pressure, powergrid voltage...
The power-grid thing is solved for all I care, the Traco TEN60 DC/DC provides
a 24V rail stable to within a millivolt for EUR100
http://phk.freebsd.dk/hacks/HP5065A/20150930_dcdc/index.html
My plan is to design a new A18 containing:
Traco TEN60
Suitable -24 V DC/DC converter (to replace the one on A15
Filtering
"ideal-diode" input circuit to choose between AC and DC supplies
(Currently using: http://www.mini-box.com/Y-PWR-Hot-Swap-Load-Sharing-Controller)
Just need the time to do so...
--
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.
Hoi Poul-Henning,
On Fri, 20 May 2016 09:52:39 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
Temperature effects are by far the largest effects we have to deal with.
Which is why you'd be much better of with 20 sensors at 16 bits,
than a single sensor at 24 bits.
Does the HP5065 have such huge temperature gradients/differentials inside?
Attila Kinali
--
Reading can seriously damage your ignorance.
-- unknown
In message 20160522164909.9fbc6cc820403cc70904e337@kinali.ch, Attila Kinali writes:
Hoi Poul-Henning,
On Fri, 20 May 2016 09:52:39 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
Temperature effects are by far the largest effects we have to deal with.
Which is why you'd be much better of with 20 sensors at 16 bits,
than a single sensor at 24 bits.
Does the HP5065 have such huge temperature gradients/differentials inside?
Yes.
--
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 May 22, 2016, at 10:49 AM, Attila Kinali attila@kinali.ch wrote:
Hoi Poul-Henning,
On Fri, 20 May 2016 09:52:39 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
Temperature effects are by far the largest effects we have to deal with.
Which is why you'd be much better of with 20 sensors at 16 bits,
than a single sensor at 24 bits.
Does the HP5065 have such huge temperature gradients/differentials inside?
At least 5C offset relative to an external sensor. Likely more in some rack installations. Past
that it depends on how close the item of interest is to the oven assembly.
Bob
Attila Kinali
--
Reading can seriously damage your ignorance.
-- unknown
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.