Guide Algorithms
Guiding Theory
Guide Algorithm Parameters
Guiding Theory
The default guiding
algorithms in PHD2 are well-established and should work well for most
users. Unless you already have some experience with guiding and
understand the basics, you should probably be cautious about changing
algorithms. However, you may have some special circumstances that
require changes or you may simply want to experiment with the different
algorithm choices. The Advanced Dialog settings in PHD2 make it
easy to do that. Each algorithm has a set of parameters that
controls how observed changes in guide star position (star deflections)
are translated into guiding commands that are most likely to restore
the star to its initial position.
Before
discussing the
details of these parameters, it is worth reviewing a little guiding
theory and looking at what these algorithms are trying to accomplish.
Setting aside
adaptive optics devices, which are entirely different, conventional
guiding faces enormous challenges. The problem at hand is how to
move machinery that weighs tens or even hundreds of pounds with a level
of precision that will not cause streaked or oblong stars. This
type of guiding can only hope to deal with tracking errors that are
"slow and steady", not "fast and random." Sources of slow and
steady (correctable) errors include the following:
- Certain kinds of mechanical imperfections in right ascension gears, including those that cause periodic error.
- Smalll errors in the sidereal tracking rate of the mount
- Atmospheric refraction - stars appear to move more slowly as they near the horizon
- Limited kinds of mechanical deflection and flexure - but not differential flexure
- Mis-alignment of the right ascension axis on the celestial pole
So
what isn't included in the above and isn't correctable by conventional
guiding? Unfortunately, it's a very long list, of which a few
are:
- Atmospheric seeing ("turbulence")
- Gear noise, roughness, and vibration
- Differential flexure - relative movement between the imaging scope and the guide scope
- Wind gusts, cable snags, grit in the drive gears
- And lots more...
The
common denominator shared by the guide algorithms is the need to
somehow react to the slow and steady deflections while ignoring the
rest. This is a difficult problem at best because any given guide
star
deflection is likely to have contributions from many of these sources.
And if that isn't hard enough, remember that real-world
mounts are never perfect - so the move you ask for will not be exactly
the move you get. Usually, the most important requirement
for any algorithm is
to avoid over-correcting, wherein the mount is being pushed back and
forth and the guiding never stabilizes. A typical
approach in these algorithms is to apply "inertia" or "impedance" to
the guiding
corrections. That means making corrections that follow a pattern
and are generally consistent with corrections that have been made
before, while being reluctant to make corrections that require a big
change in direction or amplitude. Resistance to changes in
direction is particularly important in declination, where gear backlash
is a common problem. Hopefully, this background will give you
enough insight into the basics of guiding so that the various guiding
parameters used in PHD2 will make sense.
Guide Algorithm Parameters
In
PHD2, the various guide algorithms can be applied to either the right
ascension or declination axes. Most of these algorithms
include a minimum move
parameter. This is used to avoid making guide corrections that
are overly small, are unlikely to have any effect on star shape, and
are mostly due to transient seeing effects. These values are
entered in units of pixels, so you need to think about them in the
context of how large your star images are. The default values
work well for short-to-medium focal length systems, but you may
need to increase them if you are working at long focal lengths and
expect stars to have larger diameters.
The hysteresis
algorithms keep a history of the guiding corrections that have been
made in the recent past, and these are used to help compute the next
guide correction. The hysteresis
parameter, expressed as a percentage, specifies the "weight" that
should be given to this history as opposed to looking only at the
star deflection in the current guide frame. Consider an example
where the hysteresis parameter is 10%. In that case, the next
guiding correction will be 90% influenced by the star movement seen in
the current guide frame and 10% by the corrections that have been made
in the recent past. Increasing the hysteresis value will smooth
out the corrections at the risk of being too slow to react to a
legitimate change in direction. The hysteresis algorithms also
include an aggressiveness parameter,
again expressed as a percentage, that is used to reduce
over-correcting. On each frame, PHD2 computes how far it thinks the mount
should move and in what direction(s) it should move. The aggressivness
parameter scales this. For example, take a case where the star deflection
has been evaluated and a corrective move of 0.5 pixels is warranted.
If the aggressiveness is set to 100%, a guider command will be
issued to move the mount the full 0.5 pixels. But if the
aggressiveness is set to 60%, the mount will be asked to move only 60%
of that amount, or 0.3 pixels. If you find your mount is always overshooting
the star, decrease this value slightly (say, by 10% steps). If you find PHD2 always seems to be lagging
behind the star's motion, increase this by a little bit. A little can
go a long way here.
The ResistSwitch
algorithm behaves much as its name implies. Like the hysteresis
algorithms, it also maintains a
history of past guide corrections, and any change of direction must be
"compelling" in order to issue a reversing guide command. This
is appropriate for declination guiding, where reversals in
direction are both suspect and likely to trigger backlash
in the gears. For that reason, ResistSwitch is the default
algorithm for declination but not for right ascension, where valid
direction reversals are expected. Starting with Release 2.4.1,
two additional parameters are available for fine-tuning the
ResistSwitch algorithm. The first is "aggression", a percentage
amount that controls how much of the computed guide correction will be
issued. Reducing this parameter can help to avoid over-shooting
with mounts that have little or no backlash. The second parameter is a
checkbox labeled "Fast switch for large deflections." If this is
checked, PHD2 will react immediately to a large change of direction
rather than waiting for three consecutive deflections in the new
direction, which is the normal behavior. This can help to more quickly recover
from large excursions in Dec, perhaps caused by wind, cable snags, or
other mechanical shifts The definition of a "large deflection" is
3x the minimum-move value. So if PHD2 is over-reacting to
direction changes, you can tune the behavior with the min-move
parameter or disable the "fast switch" option altogether. It is
worth remembering that "less is usually better" when it comes to Dec
guiding, so don't try to over-tune these parameters.
The LowPass algorithms
also employ a history of recent guiding corrections in order to compute
the next correction. The starting point for the computed move
is the median value of the guide star deflections that have
occurred in recent history. This means that the star deflection
seen in the current guide frame has relatively little impact on
calculating the next move and the algorithm is very resistant to quick changes. But the history accumulation also
includes a calculation to determine if deflections are moving in a
consistent direction or "getting worse." The slope weight
parameter, expressed as a percentage, determines how much influence
this should have in calculating the actual guider movement - it is
there to keep the algorithm from being overly sluggish. Because
the low-pass algorithm is so resistant to quick changes, it is probably
most applicable to declination guiding.
The LowPass2
algorithm is a variation of the original LowPass algorithm with
somewhat different behavior. It also maintains a history of
guiding corrections, but the next correction is simply a linear
extension of the commands that have come before it (i.e. a slope
calculation). This continues until a significant change in
direction is seen, at which point the history is cleared. The
algorithm has two adjustable properties: minimum-move and
aggressiveness. Minimum-move has the same effect as it does in the
other guide algorithms, and aggressiveness (percentage) is a way of further
dampening the size of the guide corrections. LowPass2 is a very
conservative, high-impedance algorithm that may be a good choice for
users with good seeing conditions and well-behaved mounts with little or no declination backlash.