[time-nuts] OCXO and fluctuations after EFC adjustment

[Taka Kamiya]

I wish such persons would write a book about the subject.  Audience will be small that it probably wouldn't make it a profitable venture.
As to coding, I wonder why it's a "touchy" subject....  In assembly time, porting one architecture to another was a major undertaking.  One didn't "port", but one would have to basically re-architect and re-code.  Also, engineers did all kinds of odd things to get job done.  It's only recently that we have almost unlimited amount of memory and more than enough speed that many of us became lazy.  If lazy isn't the right word, reusability, self-documenting, etc became more important than write a smallest and most efficient code.
Myself, I once participated in a project (just two of us....  my boss and me) where we had to use Z80 to read the data a large industrial machine puts out.  It was coming out so fast, we couldn't code to read them.  So we had to use DMA to write directly write to memory, and when there is a break in stream, switch it over to CPU control and read them out.
I also recall Sun Microsystem used two 68000 CPU because certain interrupt didn't work right and it was essential for multi-tasking.  So they used two, one executing ahead of the other.  Somehow, they coded OS to back track and made multi-tasking work.  I thought it was very clever.
As to EFC, an odd man out is SRS PRS10.  It gives you 3 ways to do it.  An EFC input from outside, a 10 turn trimmer built into the box, or a programmatic control via DAC.  As far as I know, there is no trimmer.  At least it's not user accessible.  This is a very timely discussion as I am working on PRS-10 project and 11081 project.  (two separate projects)

--------------------------------------- 
(Mr.) Taka Kamiya
KB4EMF / ex JF2DKG
 

    On Saturday, April 11, 2020, 3:02:13 PM EDT, Richard (Rick) Karlquist <richard at karlquist.com> wrote:  
 
 

On 4/11/2020 12:15 AM, John Moran, Scawby Design wrote:

> During my 50 years in the electronics industry I have always been puzzled about one aspect of crystal oscillators. They go to great lengths to use a precise piece of quartz as the heart, because of its unique properties, and then add standard external components - capacitors, varactors, Zeners, etc. to tweak its frequency. All these components vary far more than the original piece of quartz ... hence my confusion.
> 
> I know it is practically impossible to grind a crystal to exactly the frequency you want, and it then drifts over time, but what is the logic of using relatively wildly varying components to adjust the quartz? Are their temperature and ageing characteristics swamped by the superior crystal?
> 
> In all the papers I have ever read, the subject is never mentioned ... you just add a variable capacitor and/or an EFC circuit and job done.
> 
> I guess this is showing my total ignorance here, but I would like to know.
> 
> Maybe this is at the heart of Rick's usual speech?
> 
> John
> 
>

For non-oven oscillators of ordinary precision (say 10 PPM over 0 to 
50°C), the low pullability of the crystal is such that adding
adjustment capacitors is not a big hazard.  An EFC circuit that
is inside some PLL of course is only at risk of adding some noise
from the drive circuit.  I can't remember ever seeing an EFC'ed
oscillators where the EFC was driven by, say, a pot.

In the case of the 10811, I have already posted about the
reference diode of special characteristics.  I don't remember
all the exact details of how it was chosen, but it was based
on proprietary knowledge.

Another anecdote of interest is that when the first 10811's were
being tested, they exhibited very bad aging.  It was eventually
determined after a lot of investigation that oil in the piston
trimmer was migrating around and tweaking the frequency.  I
don't remember whether the fix was using a different type of
oil, or having the vendor apply it selectively, or if they
deleted the oil completely.

This type of knowledge can basically only be learned by getting
a job working with the top experts in the field.  Before I worked
for HP, it became clear that I needed to get a job there in order
to figure out how their stuff worked.  I read HP manuals as much
as I could, but actually being there was the real secret.  I
asked as many people as possible about their particular expertise
in an effort to learn as much as possible.  The right approach is
necessary to get these experts to open up.  I was careful not to
wear out my welcome.

Every person is an expert in their particular field, and there
is always something to be learned from them.  A couple of ground
rules I formulated from experience:

1.  If they tell me something that I know is wrong, I usually just
thank them for the advice and then ignore it, rather than arguing.
Or "correcting" them!  Let them continue to believe what they
want to believe.  Sometimes I find out later that actually the
person was correct and I was wrong.

2.  Be extremely careful about asking "why did you design it that
way?"  This usually causes the other person to get defensive.
Often, revealing the true reason would be embarrassing.  If the
true reason is not embarrassing, the person will volunteer it if
you talk to them long enough.

For example, the fact that many HP counters used up to four identical
microcontrollers is a very touchy subject.  I was, myself, guilty
of doing this in the 5334B.  My defense was that I inherited this
from the 5334A.  The project manager of that product himself
inherited it from previous counters.

The root cause, in case anyone is interested, is that the
microcontrollers were legacy models with only 2k of memory.
The sole vendor was not making any newer models with additional
memory.  So the only way to get more memory was to use
additional microcontrollers.  We needed more memory for
necessary features.

Since the code was written in assembly language, it would have
been a major effort to port it to a different controller.
The person who wrote the code was a major guru in those
controllers and was the only person who could do the porting.
Kind of like the Y2K Cobol coder.

Rick N6RK

_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.