HP5065A environmental sensitivities
This is my first contribution to the Time-Nut list, but I am a follower for several years.
I have made 30 days phase difference measurements of an HP5065a versus a modified Thunderbolt GPSDO (got a MV180 oscillator) with a Fluke PM6681,
and recorded the results with Timelap. Starting signal of the PM6681 was the 5MHz of the HP5065A, stop signal the 10MHz from the Thunderbolt. A single
measurement was triggered once a second from the PPS of the TB.
I also have a weather station at 6 km distance away, which records barometric pressure at time intervals of 10 minutes. Out from these measurements, I divided
my phase measurements into 10 minute intervals, calculated the 10 min average frequencies and made a linear regression with the 10 minute pressure measurements.
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Then I corrected the original 10 min average frequency measurements with the result from the linear regression and imported the original and the corrected
datasets into Timelap.
The influence of the barometric pressure to the ADEV for long time intervals is shown in the picture.
Just for fun, to render the pressure sensitivity visible for the human eye, I removed the noise of the GPSDO by generating a plot of overlapping 1 day
frequency averages in 10 minute time intervals. On the second picture you can compare it with the 10minute pressure data from the weather station. I think,
it is quite impressive. The calculated slope out of these overlapping averages was with 3.74e-14/hPa a little bit different compared with the non overlapping dataset.
Best regards
Wulf
Hi Wulf,
On 05/18/2016 08:57 AM, DG2OM@gmx.de wrote:
This is my first contribution to the Time-Nut list, but I am a follower for several years.
I have made 30 days phase difference measurements of an HP5065a versus a modified Thunderbolt GPSDO (got a MV180 oscillator) with a Fluke PM6681,
and recorded the results with Timelap. Starting signal of the PM6681 was the 5MHz of the HP5065A, stop signal the 10MHz from the Thunderbolt. A single
measurement was triggered once a second from the PPS of the TB.
I also have a weather station at 6 km distance away, which records barometric pressure at time intervals of 10 minutes. Out from these measurements, I divided
my phase measurements into 10 minute intervals, calculated the 10 min average frequencies and made a linear regression with the 10 minute pressure measurements.
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Interesting!
Then I corrected the original 10 min average frequency measurements with the result from the linear regression and imported the original and the corrected
datasets into Timelap.
The influence of the barometric pressure to the ADEV for long time intervals is shown in the picture.
Just for fun, to render the pressure sensitivity visible for the human eye, I removed the noise of the GPSDO by generating a plot of overlapping 1 day
frequency averages in 10 minute time intervals. On the second picture you can compare it with the 10minute pressure data from the weather station. I think,
it is quite impressive. The calculated slope out of these overlapping averages was with 3.74e-14/hPa a little bit different compared with the non overlapping dataset.
Now, after the fact fitting of curve has a drawback in that you can make
the fit as really good but there you measure the reference, hence you
have a closed loop. The challenge now is to use a feed-forward scheme to
take the measures from the pressure and use to adjust the C-field of the
5065 and then measure against the Thunderbolt. I would guess it won't be
exactly the same, not as good, but it will be then the actual performance.
Cheers,
Magnus
HI
Very neat !!!
Bob
On May 18, 2016, at 2:57 AM, DG2OM@gmx.de wrote:
This is my first contribution to the Time-Nut list, but I am a follower for several years.
I have made 30 days phase difference measurements of an HP5065a versus a modified Thunderbolt GPSDO (got a MV180 oscillator) with a Fluke PM6681,
and recorded the results with Timelap. Starting signal of the PM6681 was the 5MHz of the HP5065A, stop signal the 10MHz from the Thunderbolt. A single
measurement was triggered once a second from the PPS of the TB.
I also have a weather station at 6 km distance away, which records barometric pressure at time intervals of 10 minutes. Out from these measurements, I divided
my phase measurements into 10 minute intervals, calculated the 10 min average frequencies and made a linear regression with the 10 minute pressure measurements.
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Then I corrected the original 10 min average frequency measurements with the result from the linear regression and imported the original and the corrected
datasets into Timelap.
The influence of the barometric pressure to the ADEV for long time intervals is shown in the picture.
Just for fun, to render the pressure sensitivity visible for the human eye, I removed the noise of the GPSDO by generating a plot of overlapping 1 day
frequency averages in 10 minute time intervals. On the second picture you can compare it with the 10minute pressure data from the weather station. I think,
it is quite impressive. The calculated slope out of these overlapping averages was with 3.74e-14/hPa a little bit different compared with the non overlapping dataset.
Best regards
Wulf<HP5065A ADEV.png><HP5065A freq and pressure.png>_______________________________________________
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.
<DG2OM@...> writes:
I also have a weather station at 6 km distance away, which records
barometric pressure at time intervals of
10 minutes. Out from these measurements, I divided
my phase measurements into 10 minute intervals, calculated the 10 min
average frequencies and made a
linear regression with the 10 minute pressure measurements.
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Did you notice or calculate any time delay/offset in the correlation
between your pressure data and the frequency data? That is, anything much
larger than the 10 minute interval of your data, say, on the order of an
hour.
Whether there is a time delay or not may help point to the actual
mechanism causing the frequency change.
In message loom.20160518T194757-827@post.gmane.org, James Flynn writes:
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Did you also control for temperature ?
Air pressure, in particular at high relative humidities changes the
thermal properties of air so there is bound to be some cross coupling
were temperature sensitivities appear as pressure sensitivity.
--
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.
I got a slope of 3.86E-14/hPa frequency difference versus pressure.
Did you also control for temperature ?
Air pressure, in particular at high relative humidities changes the
thermal properties of air so there is bound to be some cross coupling
were temperature sensitivities appear as pressure sensitivity.
What are time-nuts using for monitoring the environment?
I have been playing a little with the Bosch BME280 - doing air pressure,
temp and relative humidity in a small form factor. Easy to interface to
Raspberry Pi or Arduino.
https://www.bosch-sensortec.com/bst/products/all_products/bme280
https://github.com/adafruit/Adafruit_Python_BME280
http://www.satsignal.eu/raspberry-pi/monitoring.html#BME280
--
Björn
On Thu, 19 May 2016 06:33:38 +0200
"Björn Gabrielsson" bg@lysator.liu.se wrote:
What are time-nuts using for monitoring the environment?
The Sensirion SHT21 has become the gold standard silicon based
humidity sensor over the past years. Even though it's quite old
(IIRC close to 10 years) it has performance metrics that still
rival modern sensors. Its rather "large" package with the 1mm
pitch makes it one of the easier to solder sensors as well.
It's only drawback is its relatively large price of €6
As for barometric sensors, the ones by Measurment Specialities
are quite good. The MS5607-02BA03 for example does a resolution
of 2.4Pa with a long term stability of 100Pa/a.
There is also the MS5611-01BA03 which offers 1.2Pa resolution,
but also doubles the price and I am not so sure whether that
tiny bit more resolution is more than just noise.
A little advice: If you want to measure pressure with high precision,
you should think about temperature stabilizing the sensor.
The same is true for humidity, but does not work as well, as temperature
stabilization (aka heating) changes the relative humidity and thus
the measurement value depends quite a bit on how the air around the
sensor flows.
Also, provide good and low noise power to the sensors. These are
precision instruments with high resolution ADCs. To work properly
they need a clean power source.
I have been playing a little with the Bosch BME280 - doing air pressure,
temp and relative humidity in a small form factor. Easy to interface to
Raspberry Pi or Arduino.
The only Bosch sensor i've ever used was a BMA250 acceleration sensor.
It worked reasonably well, but i've never evaluated it for precision
or accuracy. But at least it looks like Bosch does not exagerate
in their datasheets.
Attila Kinali
--
Reading can seriously damage your ignorance.
-- unknown
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.
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.
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.
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.
Best regards
Wulf Oelschlägel
Hi
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.
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.
Bob
On May 19, 2016, at 1:49 AM, Attila Kinali attila@kinali.ch wrote:
On Thu, 19 May 2016 06:33:38 +0200
"Björn Gabrielsson" bg@lysator.liu.se wrote:
What are time-nuts using for monitoring the environment?
The Sensirion SHT21 has become the gold standard silicon based
humidity sensor over the past years. Even though it's quite old
(IIRC close to 10 years) it has performance metrics that still
rival modern sensors. Its rather "large" package with the 1mm
pitch makes it one of the easier to solder sensors as well.
It's only drawback is its relatively large price of €6
As for barometric sensors, the ones by Measurment Specialities
are quite good. The MS5607-02BA03 for example does a resolution
of 2.4Pa with a long term stability of 100Pa/a.
There is also the MS5611-01BA03 which offers 1.2Pa resolution,
but also doubles the price and I am not so sure whether that
tiny bit more resolution is more than just noise.
A little advice: If you want to measure pressure with high precision,
you should think about temperature stabilizing the sensor.
The same is true for humidity, but does not work as well, as temperature
stabilization (aka heating) changes the relative humidity and thus
the measurement value depends quite a bit on how the air around the
sensor flows.
Also, provide good and low noise power to the sensors. These are
precision instruments with high resolution ADCs. To work properly
they need a clean power source.
I have been playing a little with the Bosch BME280 - doing air pressure,
temp and relative humidity in a small form factor. Easy to interface to
Raspberry Pi or Arduino.
The only Bosch sensor i've ever used was a BMA250 acceleration sensor.
It worked reasonably well, but i've never evaluated it for precision
or accuracy. But at least it looks like Bosch does not exagerate
in their datasheets.
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.
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 errorprone.
Also, composite sensors have higher uncertainties and drift
then single sensors. Even more so: the integrated temperature sensors
are intended for use with the main sensor as a compensation tool. 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.
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.
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.
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.
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