Guide Algorithms

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 your image scale and the typical size of your guide stars.
If you have used the new-profile-wizard to configure your system,
the min-move parameters will be set to values that are likely to work
well for the image scale you're using. The Guiding Assistant can
also adjust these values based on its measurement of high-frequency
seeing disturbances. If you are seeing a high rate of guider
corrections and lots of direction reversals, you may be "chasing the
seeing" and adjusting the min-move values upward can be a simple way to
reduce that. Of all the detailed guiding parameters discussed
here, the two min-move values are the most likely to warrant adjustment
on a nightly basis depending on seeing conditions.

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 trending in a
consistent direction. 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. If you
set a slope weight of zero, the guide pulse will always be just the
median value of the recent history. If you set a non-zero slope
weight, that median value will be adjusted either upward or downward
based on the recent trend of guide star movements. 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.

The Z-filter
algorithm is a variation on the LowPass algorithms but operates in the
discrete frequency or "Z" domain. In terms of guiding it applies full
correction to the low frequency components caused by mount periodic
error. Higher frequencies are corrected with aggression progressively
reducing down to zero.

The Z-filter algorithm allows you to use shorter guide camera exposure
times (e.g. 1s or 0.5s) without chasing the high frequency seeing.
The advantages of shorter guide exposure time are reduced lag time for
applying corrections and smaller corrrections.

The Z-filter algorithm offers just two adjustments: Exposure Factor
(XFac) and Minimum Movement (MinMo). The virtual guide exposure time
is given by the actual exposure time multiplied by the Exposure
Factor. A given virtual expsoure time will perform simiarly to an
unfiltered algorithm using the same actual guide exposure time. For
example, an exposure time of 1s with Exposure Factor of 4 gives a
virtual expsoure time of 4s (4 x 1s) and performs similarly to
Hysteresis with Agression 100% and Hysteresis 0.0 using an exposure
time of 4s. An exposure time of 2s with an Exposure Factor of 2 also
has a virtual exxpsoure time of 4s (2 x 2s) and thus performs much the
same. The main difference is that the shorter actual exposures allow
the corrections to be applied sooner and more frequently so they are
smaller.

This feature lets you adjust the guide exposure time to optimise the
guide star SNR and guide latency. You can then adjust the Exposure
factor to get the desired guiding response. A virtual exposure time of
2s to 4s per the usual recommendation is a good starting point for the
RA axis. On the Dec axis, longer virtual exposures can be used and
can help minimise reversals that can result in backlash.

Note that when using short exposures the movement from seeing will be
more visible on the guiding graph. This does not mean the guiding is
worse. Other algorithms rely on guide exposure time to filter out the
movement from seeing. The Z-filter Exposure Factor performs the same
function.

The Z-filter also has a MinMo setting. The value should be chosen to
match the ability of the mount to accurately make small
corrections. With other algorithms MinMo is sometimes recommended to
provide some filtering e.g. to prevent reversals of the Dec axis. With
the Z-filter the recommended approach is to increase the Exposure
factor.

PHD2 Predictive PEC Guide Algorithm (PPEC)

Overview

The PPEC algorithm is different from the others in PHD2 because
of its modeling and predictive capabilities.The algorithm analyzes the tracking performance of the mount in
real-time and once that analysis is complete, it will compute guiding
corrections even before a repetitive error is actually seen.Issuing proactive guiding corrections reduces
the time delay inherent in traditional guiding and can significantly improve
performance.With the other algorithms,
which are completely reactive, guide corrections are issued only after the
error has been seen on the camera sensor.

Once guiding has begun, the algorithm analyzes the
performance of the mount and looks for tracking errors that are repetitive and
thus, predictable.The algorithm employs
a sophisticated Gaussian process model developed by a research team at the Max
Planck Institute in Germany.The mathematical details can be found in a
paper referenced here:

The PPEC algorithm will normally be used for RA, where
residual periodic error and other gear-related errors often reduce tracking
accuracy.The algorithm uses separate
time-scales for characterizing the behavior of the system:

·Short-term: for high-frequency errors such as
those caused by gear roughness or seeing·Medium-term: for residual periodic errors, typically occurring
at intervals less than or equal to the worm period·Longer-term: for steady drift and for lower
frequency (longer time interval) harmonics that can be caused by the
interaction of multiple gears in the drive train

The short-term behavior is used to identify the
unpredictable noise in the system, which is essentially filtered out in order
to identify components that are predictable.For most mounts, the medium-term component is likely to be the most
important.If you’re following best
practices, you will have programmed periodic error correction in your mount (assuming
that feature is available to you).Doing
this reduces the amount of work that needs to be done by PHD2, and the PEC
correction in the mount is normally saved permanently.This approach is preferable to having to
measure and infer the periodic error behavior every time you set up your
equipment.That said, PEC in the mount
is never perfect, and you will often see residual repetitive errors even when
PEC is active.These often arise when
the tracking errors occur with a frequency that is not a harmonic (integer
fraction) of the mount’s worm period – most PEC implementations can’t deal with
those.You can also get residual
periodic errors if they are dependent on the mechanical loading of the mount or
if the mount’s behavior has changed since the PEC was programmed.The PPEC algorithm can be quite effective at
identifying and reducing these errors because it doesn’t depend on the worm
period and is always doing a fresh analysis of the mount’s current behavior.

The PPEC algorithm will also detect and proactively correct
for drift errors.Although drift is
typically handled well by any of the guide algorithms, the corrections will
always lag the error by some amount.For
some use cases – perhaps spectroscopy, photometry or comet-tracking – this
might be a problem, in which case PPEC may deliver better results.

Since PPEC employs a learning process, it will usually take about
2 worm periods to model the mount and become fully effective.During this training period, the algorithm
will behave more like the ‘hysteresis’ algorithm, so you won’t normally see a
performance penalty while the internal model is being built.Instead, you’re likely to see a steady
improvement in tracking as the model is refined and the algorithm shifts seamlessly
from hysteresis to predictive-mode. This improvement can usually be seen even before the medium-term mount behavior is fully modeled.

Since the PPEC model is implicitly tied to the state of the
gear train, it must be re-learned if the mount is slewed to a new target.For the same reason, it can’t be retained
across different guiding sessions, which is why conventional PEC is
important.However, the PPEC model will
remain intact during dither operations and while guiding is paused (via
automation) for activities like focusing.For the most common use-case, namely imaging the same target for
multiple hours with periodic dithering, the PPEC model will remain valid.In any case, the learning process and
transition from one mode to the other is handled automatically, so you won’t
need to pay it any attention.

Algorithm Details

Once the training period is completed, the PPEC algorithm
computes the guide correction using two factors.One is reactive, based on the displacement of
the guide star in the most recent exposure.The second is predictive, based on the output from the Gaussian process model
constructed during the training period.Each of these terms includes a separate gain or aggressiveness factor,
so the final guide pulse amount is a sum:

The ‘predictivegain’ and ‘reactivegain’
parameters are exposed in the Advanced Dialog, and their default values for
these parameters should work well for most mounts.You should be conservative about changing
them because bad choices for these parameters can definitely make your guiding
worse.

During the training period, the algorithm needs to identify
periodic errors in the observed guide star movement.For initial trials, you can use
the worm period of your mount as the starting point for the ‘periodlength’.This gives the
algorithm a good starting point, but you should also leave the ‘auto-adjust
period’ option checked.This
tells the
algorithm to adjust the period as needed to better control whatever
periodic
errors it finds. Once you have run the altorithm multiple times
and are happy with the results, you can leave this field set to
whatever value was computed in the previous sessions.

The ‘min-move’
parameter affects only the reactive component of the algorithm.If the measured star displacement is less
than this amount, the reactive component will be set to zero.However, the predictive component of the
algorithm will still be computed and applied.