[time-nuts] OCXO and fluctuations after EFC adjustment

[Bob kb8tq]

Hi

Would you *really* want to read a book about how from August of 1986 to 
January of 1993 AVX NPO’s had some sort of issue ( not that the issue is 
clearly known, just that they are flakey) and that by 1994 the parts with 
values below 220 pf in 0805 seemed to be fixed? 

Again, the task was never to *fix* a component, simply to sort out the parts
that worked from the parts you didn’t want to use. The only feedback to the
manufacturer was via the (lack of) purchase orders. 

Somehow I doubt anybody would make it past the first page ….

Bob

> On Apr 11, 2020, at 4:48 PM, Taka Kamiya via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> 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.
> 
> _______________________________________________
> 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.