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 from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/

View index by [date] [author] [subject]
Previous message: [M]: The Newbie asks another question!! Levelling, Aditya Damodaran
Next message: [M]: Re: The Newbie asks another question!! Levelling, Al
Next message in thread: RE: [M]: Re: Goto accuracy and slew speed, Anthony J. Kroes
Previous message in thread: Re: [M]: Re: Goto accuracy and slew speed, Email address hidden