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:
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:
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 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.

PHD2 Predictive PEC Guide Algorithm (PPEC)


 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:

     Guide-correction = (predicted amount * predictive gain) + (recent displacement * reactive gain)

 The ‘predictive gain’ and ‘reactive gain’ 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 ‘period length’.  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.