The small circuit board on the drives has a set of test points. They
are together so that a plug can be inserted and leads made to connect
a dual channel oscilloscope. The test points are the Schmitt
triggered signals from the photocells at the encoder disk. There are
two pots on the board that set the triggering levels.

These adjustments are rather touchy. At slow speeds of the the motor
shaft, note it only turns once every 4 seconds at sidereal rate, you
will see a rounded square wave at each of the terminals. At high
speeds, 15000 rpm at full slew, these wave forms become sinusoidal
looking.

These two wave forms are the two components of a bi-quad
speeed/direction signal. Ideally they should be of similar size and
90 degrees out of phase. (bi-quad) These signals go to the computer
where they are converted with appropriate logic to speed, pulses per
second, and direction. The computer uses this information to
determine how far the scope has moved and in which direction. This is
a very common control scheme.

The two pots should be set so that the two signals look similar and as
close to 90 degrees apart as possible. I assume that Meade uses a jig
to hold the drive, runs the motor and sets the pots for some optimum.
The final quality of the signals generated will depend not only on the
setting of the pots, but exactly how well the encoder mask has been
placed.

It looks to me like they position the mask by looking at the raw
signals as well. The mask is positioned and then clamped by
tightening the gear box housing. The tab is then cut off. It is very
difficult to redo this adjustment, but it can be done. I can describe
how to do this in some detail if you need to know. Post me privately
please.

A good service manual would of course have all of this information in
it. But there is no service manual available that I know about. I
have a good one in my mind. :-)


Good luck -- Doc G


John Teel wrote:
>
> Rob,
>
> Thanks for the info! I'm going to try and check out the output of the encoders
> using an oscilloscope this weekend. I'm currently looking thru the archives
> and reading several articles written by Doc G trying to find out details on
> this procedure. I'm also looking at the schematics that Doc put together. In
> one of the articles on the Dec drive he mentioned that there were two pots and
> two testpoints for adjusting the level at which the trigger circuit operates.
> Do these adjust the high and low level of the pulse train? I guess I'll start
> out by simply observing the pulse train at low slew speeds and then see what
> changes as I increase the slew speed (levels shifting,etc.). Hopefully I'll
> find a loose wire or a bad solder joint that as you mentioned is maybe adding
> extra capacitance which acts to filter the pulses at higher frequencies.
>
> So how difficult is it to get access to these RA encoder pots and testpoints?
>
> Any comments, Doc?
>
> Thanks all,
> John
>
> >
> > ----- Original Message -----
> > Sent: Friday, June 01, 2001 1:07 AM
> > Subject: [M]: Goto accuracy and slew speed
> >
> >
> > >........realized tonight that if
> > > I decrease the maximum slew speed from "8" down to "5" then my pointing
> > errors
> > > decrease to around 5 arc-min for medium slews (< 90 degrees) and around
> > 5-15
> > > arc-min for large slews. Has anyone else experienced this increase in
> > accuracy
> > > at slower slew speeds? It makes sense that this would increase accuracy
> > but
> > > I've never seen this mentioned anywhere. The pointing error that I get at
> > high
> > > slew speeds is almost entirely in RA and almost none exists in DEC. Also
> > the
> > > error is always because the RA drive overshoots the target coming from
> > either
> > > direction.........
> >
> > The fact that the problem is only in the RA and always
> > involves overshoot is consistent with a situation where the microcontroller
> > is
> > receiving too few pulses per revolution of the RA encoder wheel at the
> > higher
> > slew speeds. As a result, the controller tells the telescope to slew an
> > additional
> > amount in order to count off the number of pulses it "knows" it should get
> > when
> > the motor moves the scope by the amount that you commanded.
> >
> > I've not seen previous discussion of that kind of failure on mapug, so it is
> > just
> > possible that you're breaking new ground. I certainly hope so, because
> > fresh
> > problems are the life-blood of mapug, not to mention salvation from time
> > zone
> > confusion. Whenever the time zone questions and answers come up, I start
> > worrying about how to remember whether it's spring back, fall forward, or
> > fall
> > back, spring ahead. No amount of logical analysis (by me, anyway) can solve
> > that
> > problem, but I can't help trying, and I know perfectly well that I'll just
> > waste a
> > lot of time and then finally give up and humiliate myself by asking someone
> > which
> > way it's supposed to go (usually someone far less clever than myself). When
> > they
> > flippantly toss off the answer without even thinking, it's the other shoe
> > dropping,
> > another little stab in the gut.
> >
> > Anyway, at high motor RPM, the frequency generated by the encoder
> > slots is probably around 10 kHz (just a rough guess). You try counting that
> > fast and
> > see how well you can do. But seriously, if the encoder circuit board is out
> > of tune,
> > meaning the LED's are dirty or whatnot, or the bias pots are wrong, or
> > there's a
> > bad solder joint, then some of the pulses won't make it through the input
> > chip as
> > bona-fide pulses. High frequency pulses are more likely to get lost because
> > capacitative leakage differentially attenuates higher frequencies. It's
> > sort of like
> > fast pulses are shorter pulses, and short things are easier to lose than
> > long things.
> >
> > Sounds like a warranty type motor/main board replacement is the answer,
> > unless
> > you want to dig in the archives for DIY info about the encoder circuits and
> > how to
> > tune them. On the other hand I could be completely wrong in my analysis.
> > If it were my scope, I'd stick an oscilloscope on the encoder to check it
> > out.
> > Unfortunately, while the encoder mini-pc board is likely to be the problem,
> > it's
> > also possible that the main board is undercounting pulses coming from the
> > encoder
> > for some reason, and who knows where that might happen or how to prove it
> > other than by swapping out the main board. Have you talked to Meade about
> > it?
> >
> > By the way, it makes no sense at all that operating at high slew speeds
> > would impair
> > the accuracy of a GOTO with this scope (when it is working properly, that
> > is!!).
> > The control mechanism is as digital as a DVD, and there's no significant
> > slippage in the
> > gearing. There will be total conservation of pulses in such a system, so
> > the same
> > accuracy of GOTO would be obtained throughout hours (or days) of slewing
> > around
> > (at any speed) after a single alignment operation. If an lx200's GOTO
> > accuracy falls
> > off as the night wears on (without changing the alignment at all), then
> > something is
> > wrong with the scope's control system, IMHO. Or else the Earth is starting
> > to spin
> > differently than it has for a while.
> >
> > Rob P
> > Pittsburgh PA
> >
> >
> >
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses f to Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/

View index by [date] [author] [subject]
Previous message: [M]: JMI Focuser NGF-S, JPKam
Next message: Re: [M]: OT: Dec motor failures, R. A. Greiner
Next message in thread: Re: [M]: Re: Goto accuracy and slew speed, Ben Fillmore
Previous message in thread: RE: [M]: Re: Goto accuracy and slew speed, Anthony J. Kroes