Re: Help with Autoguiding Problem - DEC guide problem


Dave, thanks for sharing your experience as well. I have been in contact with AP (Roland)
and he believes my DEC issue is most likely a problem associated with my guiding
parameters and not the mount itself. This was based upon performing the DEC
measurements that AP describes on their Tech Support page. Below is Roland's
explanation regarding the DEC issues due to incorrect guiding parameters. I found it so
useful, although it is a bit lengthy, I beleive many will find it insightful and useful.


I guess I should have included in the instructions to set the button Normal/Reverse so that
a North button push caused the star to go North and a south button push would cause a
star to move south just so that no doubt would remain about the proper direction that the
star moved when you pushed the buttons.

In any case, from what I could tell in your description, the star did not move in the wrong
direction. Is that correct?

If that is correct, then the mount is doing what it's supposed to do. You have a bit of a
time delay in the reversal, but normally this would not cause an oscillation of the guide
star (I will discuss the time delay below). What will cause an oscillation is a loop gain that
is larger than 1. In other words, if the error of the guide star is 1 pixel, then the maximum
command that should ever be sent to the mount cannot exceed a button push time that
moves the star more than 1 pixel. That said, it is easy to set the parameters wrong so that
the loop gain does become larger than 1, and then you will indeed get oscillations because
each time the program senses an error it will overcorrect this error.

Now I will explain how the parameters can be set wrong. Normally when you do a
calibration run, Maxim will send the mount in the two directions for a period of time at the
rate that you set and for the time that you set. For instance, you may set it for 0.5x and 5
seconds. Assume that the mount went 50 pixels in RA in that amount of time. The
program then calculates that the system motion parameter is 10 (i.e 50 pixels/5 seconds).
It then places that number in the parameters. Theoretically, at the celestial equator, the
Dec parameter will also be 10. Chances are that the number that is calculated by the
program will be lower. This is almost always due to delay time in reversing the motor
gearbox in Dec.

Let's say it takes 4 seconds to reverse Dec and your programmed cal time is only 5
seconds, then the star will only move for 1 second or 10 pixels. The program then sets
this DEC parameter number to 2. The resultant gain in Dec will then be 5 times what it is
in RA, and the system will be totally unstable. By the way, RA never has any delay in
reversal because the motor never actually reverses, it just slows down and speeds up, but
you knew that, yes?

So, how to set up the calibration run so that the system gain will be correct and the loop
gain never exceeds 1? Very simple, once you understand where the errors are coming
from. First, figure out how long it takes for Dec to reverse by counting the seconds it takes
at 1x to see star motion in the test you just did. If it takes more than 1 second, then you
might want to firm up the worm mesh. If this is tight, check to make sure that the small
spur gear is not slipping on the end of the worm. There is a set screw holding this spur
and it could conceivably come loose and allow the spur to rotate a small amount before it
actually drives the worm itself. You can check all that by removing the motor gearbox
cover and examining the gear assembly.

If all checks out, then the next thing to do is to run a calibration on a star near the
celestial equator. Set the mount up at 1x (never calibrate at any lower setting), add enough
backlash compensation in the keypad so that the star comes back all the way to its origin
in Dec, and run the cal time for as long as possible to get the longest pixel spread without
running it off the edge of the chip. I like to run for at least 10 seconds at 2000mm focal
length, more for shorter scopes. This will insure that the parameter numbers are accurate.
Once you have made a successful cal run, check the parameter numbers. They should be
very similar (the angle between RA and DEC should be close to 90 degrees if the camera
was oriented E-W etc). In any cal run near the equator the numbers will always be almost
the same, if they are not, then that is an indication that you have set the system up wrong.
Once you have a good cal run, remove all backlash compensation in the keypad and do a
guiding test. It should guide properly in both axes.

One other thing that can cause a guiding problem is the setting in Maxim for Declination.
It is best not to set any number in there. Leave it at 0. That way there is no possibility that
the loop gain will be higher than 1. If you put any number in there, the program boosts
the loop gain artificially and this can cause problems. You can lower the loop gain below 1
by lowering the agressiveness setting. I usually set it to 0.8 or 80%.

Try these things and monitor your guiding. By the test you did, there does not seem to be
any reason why the mount should overshoot in Dec. Normally the dec drift is always in one
direction, and if the loop gain is 1 or less, the star will always be bumped back toward
zero and the drive will never actually reverse. There is no reason that the Dec axis will go
more than 1 pixel if it gets a 1 pixel command from the camera software. The only reason
it would go 2, 3 or 5 pixels is if the loop gain was 2, 3 or 5, which means that the cal
numbers are 2, 3 or 5 times lower than they should be. Check them after each cal run.
They should never be much different in DEC for any given system focal length.

Roland Christen

--- In ap-gto@..., "mogulskier_groups" <mogulskier_groups@...> wrote:

I have had a similar problem. If I turn off DEC guiding altogether,
I get very smooth guiding. As soon as I resume guiding in DEC, it
does that same thing that James is experiencing.

Here is some new info.

Using ACP for automated sessions, I was doing a mosaic of M31.
Guiding was the smoothest I'd seen. Maxim was reporting RMS of about
0.05 pixels at 2.96"/pixel (or about 0.15 arcsecs). Then the
Meridian flip happened. ACP handles this extremely well. It did its
plate-solve and pointing correction and started the guider again.
This time, I noticed the odd DEC guiding issue again. Nothing had
changed except the meridian flip. I thought that a cable must have
been snagging or something. (I was monitoring the system from inside
using XP's Remote Desktop application). So I went outside and
checked... everything was fine - no snags, etc. So, I assumed that
it must have been that my system was out of balance. I made a mental
note of the DEC angle in relation to one of the tick marks, lostened
the clutches and checked the balance. There was nothing I could do
to improve on the balance, so I returned the DEC back to its
position, tightened the clutches, and went back inside.

Funny thing, ACP was taking an image during all that. Of course,
that 4 minute image was ruined, but I was amazed at how ACP did a
plate resolve before the next image, adjusted to the DEC displacement
from me not puting back "exactly" where it was before (off by about
4.34 armins) and continued with the imaging run.

Here's the new info though... after doing this... the DEC problem
disappeared. Is there something to this? What could loosening the
DEC clutches, rotating about 90 degrees toward the north side and
then back (M31 was near the zenith when I did this) could have done
to resolve the DEC problem? And what could a meridian flip possibly
be causing inside the mount to get itself into this situation?

Is it possible James and I are dealing with sticky gears?

James, maybe you could give this a try?

Additional info:
After M31 went behind an obstruction, I went back to imaging the
horsehead nebula on the East side of the meridian. Guess what? The
DEC issue returned. Since it was getting late, I didn't try going
out and rotating the DEC to see if that would solve the problem again.


--- In ap-gto@..., "jiprovi" <jiprovi@> wrote:

I have been struggling with a DEC guiding issue. I have a 2006
with a meade 12" LX200R and 80mm guide scope with FLI6303E main
and ST402 guide camera. My problem is associated with the only the
DEC axis - the guiding along the RA axis is excellent (RMS < .2
at 3000mm, 3x3binning). My DEC guiding performance is much worse
RMS > 0.8 pixels with many times exceeding 1.5 pixels. I know that
when the DEC is performing properly, the RMS guide errors are
typically <.2 for 10 min and longer exposures. I have this DEC
problem running either MaxIMDL or CCDSOFT and using different
as guiders (ST402 or ST2000). My guiding arrangement has been with
off-axis-guider or with a guide scope - both produce same DEC
The DEC guiding seems to not want to compensate for guide errors -
ie, i watch the DEC guide error creep up from .2 pixels, .4, .6, 1.5
and stay at 1.5 for maybe 30 sec and then it will begin to correct
get back to less than .2 pixel error. So what i have done to try
isolate the issue?

1 - ran the pulseguide DEC test: results look very normal
2 - turned off all other software apps except for MaxIMDL to guide
3 - turned off power to everything except for guide camera and
4 - tried all variations of the min and max guide values and
sensitivity values (1 - 10)

Still no joy - I finally decided to loosen the bolts to the DEC worm
and reset the worm to worm gear following Roland's direction about
using light finger touch to press worm down while tighening bolts
checking to smooth operation after ---- still no joy

So, does anyone have any ideas what maybe my issue? The DEC test
suggests the mount is ok, so could I have some unwanted signals on
guide cable that is messing things up?

Any comments/suggestions are appreciated.


PS: polar alignment seems very good - PoleAlignMax says I am within
20arcsecs both el/az and when the DEC correction is turned off the
errors are very small with no variation greater then .1 pixel with
gradual increase to 1 pixel after 6 min.

Join to automatically receive all group messages.