Guide Algorithms

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

  

News & Resources

February 12, 2017 - PHD2 v2.6.3 Released

October 28, 2016 - PHD2 Best Practices

June 12, 2016 - PHD2_Broker package available

December 29, 2015 - Tutorial: Analyzing PHD2 Guiding Results

December 20, 2015 - Tutorial: Off-axis guiding on comets with PHD2