[GPS_Standard] VE2ZAZ
Bob Bownes
bownes at gmail.com
Thu May 27 19:00:36 EDT 2010
Alternate solution might be to skip the PWM and go to a real 14 16 bit
DAC. Not like there aren't plenty of spare pins on the 18f2220. Gets
rid of the dither math too.
On Thu, May 27, 2010 at 6:49 PM, Dave Platt <dplatt at radagast.org> wrote:
> grahamh at austin.rr.com wrote:
>> Dave:
>>
>> You might want to pull a data sheet on the CERMET trimmer you
>> are using for course set. The sample spec sheet I pulled shows
>> resistance tolerance of +/- 100 ppM per degree C !
>
> The one I chose looked to be a good deal better than that, if
> I recall correctly. It's a 20-turn precision pot. not just
> a small trimmer.
>
> Something I could do, I suppose, is to coarse-adjust the pot to
> where I like it, measure it, and then replace it with a voltage-
> divider pair of low-tempco fixed resistors. I've got some Vishay
> bulk-metal-foil resistors sitting around and could probably find
> a pair which made close to the right ratio. That would eliminate
> at least this one point of potential temperature sensitivity.
>
>> Also review the voltage tolerance versus temperature of the
>> single chip regulators. They are typically not good enough for controlling
>> a disciplined oscillator. You may want to consider precision voltage
>> sources, rather than common single chip regulators.
>>
>> Consider all voltage tolerances in terms of the frequency control sensitivity
>> of the device you are controlling. You will find that you are dealing
>> with control voltages that need to be stable in the range of tens of microvolts
>> DC.
>
> Yup... and that's a bit difficult for practical reasons.
>
> In the case of the VE2ZAZ design (as I've implemented it) there seem
> to be several points of vulnerability. The control output voltage from
> the VE2ZAZ board is based on the +5 supply on that board (since it
> comes from the PIC's PWM output) and can drift. Switching the
> filter op amp to use a separate, more precise set of rails wouldn't
> help. The +5 I feed to my coarse-adjust pot could drift.
>
> Based on my experiments with the Efratom oscillator, I rather strongly
> suspect that the +12 being fed to the oscillator itself may be
> equally critical. The oscillator's effective pull-range (when the
> control voltage is adjusted from 0 to +5) seems to depend significantly
> on the oscillator input voltage... if I reduce the oscillator power to
> +9, the adjustment range decreases. This makes me think that the
> internal varicap may be referred to the oscillator's positive rail
> voltage... and a drift in this voltage might have the same effect as
> drift on the control input. I couldn't find any sign that the
> Efratom provides a "reference voltage" output... I should re-check this.
>
>> What you are fighting might not be the oscillator, but the design
>> of the course expander and control circuits you built.
>
> You're quite right. I tried to be careful in the design and
> selection of parts, but it's entirely possible that it's acting
> as the performance limiter at the moment. Warming up various
> components on the board with a hot-air pen might tell me if this
> is indeed the case.
>
> I wonder, though... would things necessarily be any better if I
> bypassed the whole coarse-adjust system, and fed the VE2ZAZ
> control-voltage output to the oscillator? Doing so might simply
> make the problem move around... I'd eliminate sensitivity to thermal
> drift from the cermet 20-turn pot and the 78L05, but would multiply
> by a large factor (5:1 or 10:1) the sensitivity to any drift from the
> 7805 which powers the VE2ZAZ board.
>
> Thanks for your suggestions and ideas - all good and worth following
> up!
>
> 73,
>
> Dave
> ______________________________________________________________
> GPS_Standard mailing list
> Home: http://mailman.qth.net/mailman/listinfo/gps_standard
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:GPS_Standard at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>
More information about the GPS_Standard
mailing list