Hi,
vs the title, I explain :
I use an DIY designed module based on a OCXO (ConWin OH100 series) as "master clock" for a Mutec MC3+.
This eve => waouh ! Interesting stuff !
I was measuring that OCXO to a TinyFPA to do some measurements about stability.
After 2-3hours, as usual, stability is reached and the TinyPFA gives a stable figure : 10MHz +/- 0.01Hz (the limit of its resolution).
To be clear, measurement = 10 000 000. 01 MHz, and the decimal part moves from +/-0.02 over time.
So far, so good for me...
This evening, while the ocxo was running, plugged on the TinyPFA, we did some housework... (we hate that but... have to...🙂 )
=> we opened the window => température in the flat dropped from 21°C to 18°C... and then stabilize @ 18°C.
Waouh : in the mean time, the TinyPFA showed a transient of the mean frequency of the OCXO, moving from :
10M+/-0.01Hz
to
10.000 000 25MHz+/-0.01Hz
then, we closed the window etc...
and the OCXO is back to prévious state => after 2hours ! (2hours, not 5s...🙂)
Conclusion :
as the OCXO on my setup was not in a "box" but on the bench...,
NEXT :
- I'll put my DIY OCXO module into a "box", this "box" goal will be to damp the fluctuations of T.amb vs the OCXO, to see if stability is preserved in some extend.
PS : any other TinyPFA users up there ? 👍🙂
vs the title, I explain :
I use an DIY designed module based on a OCXO (ConWin OH100 series) as "master clock" for a Mutec MC3+.
This eve => waouh ! Interesting stuff !
I was measuring that OCXO to a TinyFPA to do some measurements about stability.
After 2-3hours, as usual, stability is reached and the TinyPFA gives a stable figure : 10MHz +/- 0.01Hz (the limit of its resolution).
To be clear, measurement = 10 000 000. 01 MHz, and the decimal part moves from +/-0.02 over time.
So far, so good for me...
This evening, while the ocxo was running, plugged on the TinyPFA, we did some housework... (we hate that but... have to...🙂 )
=> we opened the window => température in the flat dropped from 21°C to 18°C... and then stabilize @ 18°C.
Waouh : in the mean time, the TinyPFA showed a transient of the mean frequency of the OCXO, moving from :
10M+/-0.01Hz
to
10.000 000 25MHz+/-0.01Hz
then, we closed the window etc...
and the OCXO is back to prévious state => after 2hours ! (2hours, not 5s...🙂)
Conclusion :
as the OCXO on my setup was not in a "box" but on the bench...,
- the T.ambient directly influenced the stability of the OCXO <= I didn't expect that as such level ! Waouh !
- the momentum of this OCXO to "move" its own Fo from 10M to 10M+0.2Hz (due to fresh air from outside) and then back to 10M (when no more "fresh air") : both transitions lasted 2h !
NEXT :
- I'll put my DIY OCXO module into a "box", this "box" goal will be to damp the fluctuations of T.amb vs the OCXO, to see if stability is preserved in some extend.
PS : any other TinyPFA users up there ? 👍🙂
I had never heard of a TinyPFA, but apparently it's a thing that compares two frequencies, https://www.tinydevices.org/wiki/pmwiki.php?n=TinyPFA.Homepage
Where did the other frequency come from?
Where did the other frequency come from?
By the way, when I was at university, there were two people there working on some oven-controlled measurement set-up that had to settle very accurately to the set temperature in limited time. They found that after they had added some extra thermal capacity and thermal insulation to protect their temperature chamber from external temperature variations, it would settle very slowly. That is, it would quickly get close and then the final settling would take long.
The explanation we came up with, was that it was due to the extra pole-zero pair in the heat to temperature response caused by the thermal insulation and capacity. I'm not sure if that was the correct explanation, as thermal networks are never really lumped, but it was the best we could think of.
The first network is without extra insulation, the second with. To the extent that the lumped approximation applies at all, you get an extra zero. Under closed-loop conditions, one of the poles will end up close to but not quite at the zero, and this pole results in a long settling tail.
I don't remember many details, as it is some 30 years ago.
The explanation we came up with, was that it was due to the extra pole-zero pair in the heat to temperature response caused by the thermal insulation and capacity. I'm not sure if that was the correct explanation, as thermal networks are never really lumped, but it was the best we could think of.
The first network is without extra insulation, the second with. To the extent that the lumped approximation applies at all, you get an extra zero. Under closed-loop conditions, one of the poles will end up close to but not quite at the zero, and this pole results in a long settling tail.
I don't remember many details, as it is some 30 years ago.
So the questions are:
- how accurate was the used reference as also changing by any any external temp changes
Heating the heaters:
- this means, if the first heater (as environment or say sun) changes, a second or doubled oven is often used to lower this issue
Not how you are supposed to use them
Q1: Why not (assuming it is this oscillator that changed and not the other one)
Q2: Why do you think this is odd?
Q3: Why did you think it would be?
I was warned about thermal systems in university as well. If you're not careful you can get them to oscillate at incredibly low frequencies.
Tom