Supplemental Information

Astronomical Seeing
Use of Binning
Dithering Operations
Common Mount Problems
Uni-directional Dec Guiding
Variable-Delay Guiding
Differential Flexure
AO Devices
Logging and Debug Output
Equipment Profiles
Ask for Coordinates Aux Mount
Simulator Parameters
Multiple Program Instances
Keyboard Shortcuts
Software Update

Astronomical Seeing and Guiding

It’s difficult to get far in imaging and guiding without coming to grips with astronomical seeing.  This is a complex subject so only the bare minimum can be covered here.  “Seeing” is the term given to the positional jitter and sudden brightness changes of stars we see (or photograph) through a telescope.  With the naked eye, we see this as “twinkling” because our eye can’t resolve the tiny positional movements of the star.  It is atmospheric turbulence, caused by the movement of thermal cells at various levels in the Earth’s atmosphere. Light is refracted as it passes through each atmospheric cell, so when you look at a star, you’re really looking up through a column of air that is behaving like a column of little lenses.  The refraction of the light by each cell depends on its temperature, and the cells generally have different temperatures.  And because the atmosphere is very dynamic, these elements are all moving around at various speeds, coming into and then leaving the column of air you’re looking through.  Particularly with longer focal lengths, this atmospheric seeing is the single biggest source of the guide star movement we see with a properly working mount, and it can’t be “guided out”.  The movement of the atmospheric cells means the guide star position is changing at rates of 10’s to 1000’s of times per second, and amateur-grade equipment, even adaptive optics devices, can’t react quickly enough to correct for it. Professional observatories are able to do it to a large extent by employing very expensive measurement devices, artificial stars, and mechanisms that can both deform the mirror and shift the image at very high frequencies.  For these observatories, most of the seeing disturbances originate in the upper layers of the atmosphere and those are the layers that are used for seeing models and most seeing forecasts.  For amateurs and especially for those who image from urban or backyard locations, seeing problems also arise from sources close to the telescope.  Heat convection from hard ground surfaces or neighboring rooftops create lower frequency "boiling" behavior that degrade guiding and imaging performance.  Ground-level heat can also create tube currents and uneven layers of hot air inside the telescope tube - these also can masquerade as low-frequency seeing effects.  Users should do what they can to avoid or mitigate these situations and, when working in locations with high daytime temperatures, should expect it will take many hours after sunset for the equipment temperatures to equilibrate.

From a guiding perspective, we are always “under-sampling” the seeing behavior.  By the time we’ve taken an exposure, downloaded the image, computed the location of the guide stars, and then transmitted a guide command, the star position on the sensor has moved – probably 100’s of times.  As the exposure time decreases, these measurement errors become even larger, a phenomenon known as "aliasing". You're exposed to aliasing any time you watch a TV show or a film that has rapidly spinning objects like automobile wheels.  Over the years, you've been conditioned to ignore it but, really, are those car wheels actually spinning backwards during the chase scene?  This aliasing effect happens because the exposure rate of the film equipment - e.g. 60 frames/sec - is too slow to accurately meaure the movement of the spinning objects.   Getting back to auto-guiding, we’re always dealing with outdated information about the actual guide star position – and that doesn’t even take into account whatever shortcomings the mount has in precisely executing the guide commands it receives.  The star movements we can correct for - drift, periodic error, atmospheric refraction, mechanical deflections, etc - are hiding in a sea of noise created by the seeing conditions. One of the major objectives of the PHD2 guide algorithms is to identify and react to the tracking errors that can be corrected while ignoring the spurious effects of seeing that can't be corrected.   Your choice of  guide camera exposure times can make this job easier.

Seeing and Exposure Times

The high-frequency, seeing-induced star motion seen by the guide camera is strongly affected by the length of your guide exposure.  Look at the following plot to see how the observed range of guide star motion decreases as the exposure time is increased:


Essentially, the camera sensor is averaging the changing light pattern of the star and smoothing the result.  Measurement uncertainty is still present because of under-sampling, but the longer exposures make it easier for PHD2 to isolate and identify the lower frequency errors that really can be improved through guiding.  Obviously, there is a practical upper limit to the exposure time.  Typically, it will be limited by the length of time your mount can run on its own without needing a correction.  Small errors from periodic error, drift, flexure and other sources need to be corrected before they become large enough to ruin an image.  Finding the right balance will always depend on both the seeing conditions and the quality of the equipment.  As a starting point in PHD2, we typically recommend using exposure times of around 2 seconds and lower exposures of at least 0.5 sec only if the mount requires it and then only if guiding is active on multiple stars.

Use of Binning

Many of the guide cameras available in PHD2 support hardware-level binning, which may be helpful in situations where you are guiding at long focal lengths or have a guide camera with very small pixels. These scenarios often result in having to use faint guide stars, and the guider images may be substantially over-sampled.  Over-sampling provides no real benefit, and the projection of a faint star disk onto many small pixels can result in a low signal-to-noise ratio (SNR).  By binning the image, you can reduce the impact of camera read noise and thus improve the SNR; and if you are over-sampled,  you won't degrade the accuracy of computing the guide star location.  Choosing a binning factor greater than one will have the following effects:
  1. Star images will have a higher SNR and will be easier to detect above the background noise level.  This is especially helpful if you are limited to using faint stars (i.e. with SNR values below about 10).
  2. The amount of data downloaded from the camera will be reduced by the square of the binning factor.  This can be helpful if you are using a camera that makes heavy use of USB resources even if star brightness and SNR are already reasonable with un-binned images.  Of course, using sub-frames can achieve the same result once a star has been selected.
  3. The resolution (image scale) of your guider image will be reduced by the binning factor.  This is not likely to be a problem if the un-binned image scale is below 1 arc-sec/pixel, but your guiding results may suffer if the un-binned image scale is above 2.5 arc-sec/pixel.  You may need to experiment because the results will also depend on the image scale of your main camera system.
Each binning level requires its own dark frames and bad-pixel map - they are not interchangeable, nor can a transform be done automatically.  If you want the flexibility of switching back and forth between binning settings, you should create separate profiles for each binning value.  Then build a dark library and a bad-pixel map for each of those profiles.  When you want to change binning factors, just switch to the profile that has the setting you want, and a dark library and/or bad-pixel map will be available.   If you want to check that the camera is binning correctly, you can use the Stats window to confirm the frame size and current on-camera bin settings.  Even if you've made a firm decision to change the binning, you should create a new profile using the new-profile-wizard - that will automatically adjust all of the guiding parameters that depend on image scale.  From a guiding perspective, a change in binning is essentially the same as switching to a different camera.

Dithering

In order to reduce fixed-pattern noise and hot pixels, imagers often move the telescope by very small amounts between exposures – this is called dithering. Dithering is always controlled by the imaging app because it is the only one that can suspend exposures with the main camera while the pointing position is being shifted.  PHD2’s only role in this is to issue guide commands that will accomplish the requested shift in position – it is simply doing that it’s told. The small shift in pointing position is accomplished  by PHD2 in two steps:

1.      Change the lock-point of the primary guide star by the amount requested by the imaging app.

2.      Use the normal guiding routines to move the primary guide star to the new lock-point

The size of the dither is controlled by the imaging app, at least indirectly.  The app may let you specify the maximum size of a dither, typically in units of pixels.  In that case, PHD2 interprets this as the upper range of random values between zero and this limit.  The randomizing process is done to insure that dithering doesn't follow a simplistic back-and-forth pattern or shift the frame back to a location where it has previously been.  For some applications that do PHD2 dithering, you can't specify the maximum amount directly - you are perhaps limited to choices like small/medium/large and the max dither amounts will have preset values.  For that reason, PHD2 has a dither scaling parameter in the 'Global' tab of the Advanced Settings dialog.  It is basically a multiplier term that lets you adjust the range of dither amounts that are possible.  So a scale factor of 1 doesn't change the preset value at all, a value of 10 multiplies it by 10X, etc.  If you're using an app that lets you specify the maximum amount directly (e.g. PHD_Dither), you should leave the dither scale set to 1.0.  Otherwise, you can adjust the scale factor if you aren't happy with the overall range of dithering you're getting with one of the small/medium/large choices..

It’s up to the imaging app to determine when the guiding has settled down and it’s time to start the next exposure with the  main camera.  To make this easier for authors of the imaging apps, PHD2 provides some extra measurement information on how the settling process is proceeding.  This information doesn’t need to be used by the imaging app, it is entirely optional.  In order to take advantage of this help, the imaging app specifies what level of stability it wants to see in order to decide that the dithering activity has settled down.  There are three settling parameters for doing this:

1.       The maximum amount of guide star position error that is considered acceptable – call that position tolerance, PT

2.      The length  of time that must elapse during which the guide star position error stays below the position tolerance – call that the evaluation time, ET

3.      The maximum amount of time that can be tolerated before the measurement process is terminated and the dither is declared to be “done” regardless of the guiding stability – call that the time-out period, TO

To state this in a sentence, the settling process is “done” when the guiding error is <= PT for ET seconds or, if that condition is never satisfied, after TO seconds have expired.  When this evaluation process is complete, PHD2 sends a message to the imaging app saying settling is done.  This is all just extra credit for PHD2, normal guiding is being done from the time the lock-point is moved.

Of course, the specification of these parameters, PT, ET, and TO, is up to you and the values have to be chosen intelligently. Your imaging app may not expose all of these parameters in its user interface or it may give them different names.  If you’re dithering by large amounts with a low-performance mount, you have to expect it will take a long time to settle down.  If you specify a PT value that is too large or an ET value that is too small (overly lax parameters), the imaging app may start the next exposure too soon and you could get streaked stars in the image.  The same problem could occur if you specify a TO value that is too short.  Conversely, if you specify a PT value that is too small or an ET value that is too long (overly demanding parameters), then all of your dithers will incur a delay of TO seconds and settling will "fail" – you are asking too much from your mount.  A sensible approach is to look at your past performance to see how well your mount responds under typical seeing conditions with the size of dithering you want to use.  If your mount has a lot of Dec backlash, you should see how long it takes for guiding to settle down when the direction of the Dec guide command is reversed.  The ET and PT values should reflect the guiding performance you normally get with your setup with a little bit of slack to avoid wasting time.

PHD2 also supports different choices for how the star is moved in RA and Dec. With the default settings, the mount will be shifted in RA and Dec by different  random amounts as described earlier.  If you choose “spiral mode”, the guide star will be moved in a pattern that eventually produces a spiral pattern around the original lock-point.  This automatically reduces the number of Dec reversals and can be a good choice if your mount has substantial backlash. In this mode, there is no randomizing process involved, each dither has the size specified by the imaging app.  Alternatively, you can choose the RA-only option and eliminate Dec reversals altogether, but this may not be a good choice if your imaging camera has a lot of fixed-pattern noise.

If your mount has a substantial amount of declination backlash in the mount, you may be guiding in only the north or south Dec direction.  If PHD2 receives a command to dither in declination while you're operating in this mode, it will temporarily allow guiding in both Dec directions until the dither and settling are completed.  It will then revert to the original north/south-only guiding mode.  If you don't want this behavior, you should restrict dithering to 'RA-only'.  All of the PHD2 dither controls are contained on the 'Global' tab of the Advanced Settings dialog.

Common Mount Mechanical Problems

Periodic Error in Right Ascension (PE)

Periodic error is most often caused by very small machining errors in the various components of the RA drive system.  One part of a typical drive system is shown here:

Credit: Mathis Instruments

A high-precision worm gear (arrow 1) is used to drive the much larger worm wheel (arrow 2).  The latter is attached to the RA shaft and when the mount is tracking at the sidereal rate, the worm wheel will complete a rotation in one sidereal day (23.934 hours).  In order for this tracking to be perfect, all the following conditions must be met:

Identical pitch and spacing for every thread in the worm gear

Rigid attachment of the worm gear to the mounting plate with no flexure or movement of the gear or the mounting blocks

Identical shape and spacing of every tooth in the worm wheel

Worm wheel perfectly round and perfectly centered on its axis of rotation

These are actually just a few of the necessary conditions, but it’s obvious that this level of precision is not likely to be present in most amateur mounts.  The machining of the worm gear is usually the biggest challenge so tracking errors often originate there.  The worm gear turns at a constant rate during sidereal tracking and the time it takes to make one full revolution is called the “worm period”. Worm periods vary among different mounts but generally fall in the range of 4 to 10 minutes.  A machining inaccuracy on one of the worm threads will therefore make its presence known once in every worm period. Of course, many of the worm gear threads are likely to have some inaccuracies and each will make its own contribution to tracking error once during the worm period.  When the tracking error is graphed over a single worm period, the result is usually a curve that is roughly sinusoidal with varying slopes, peaks, and valleys – this is what is known as periodic error.  Here’s an example:

Notice the high-frequency movements caused by seeing that are not part of the mechanical periodic error.

There are other gears in the RA system, often a series of gears that lie between the motor and the worm gear.  These are required to convert from the native speed of the motor to the slower rotation speed of the worm gear and also to generate the torque needed to drive the worm gear.  Each of these components will have machining inaccuracies of its own and will contribute to cumulative tracking errors of the mount.  Many of these components will introduce errors on shorter time periods than the worm period.  Some mounts use drive belts to sidestep some of these “upstream” gear inaccuracies but those can introduce errors of their own – incorrect tensioning, lateral movement of the belt on spindles, etc. 

RA Periodic Error Correction

Periodic error correction (PEC) in the mount firmware is beneficial to auto-guiding if the feature is implemented correctly.  Unfortunately, this isn’t always the case.  But when done correctly, periodic error correction handles some tracking errors before they are seen in the guide camera image.  These corrections are predictive, based on a model of the mount’s PE, as opposed to being reactive like normal auto-guiding.  The net result is that PHD2 has less work to do to keep the RA axis on-target.  Even when the implementation in the mount is done well, calculation of a high-quality PEC curve must be done carefully using an application specific to the purpose.  During the measurement process, the app must filter out seeing-induced guide star movements to produce a smooth correction curve that represents samples across multiple worm periods. It must also be aware of the worm period and the various harmonics in the mount drive system in order to apply corrections only for those tracking errors that are harmonic - i.e. errors with frequencies that are integer multiples of the worm frequency.   If the PE correction curve is poorly constructed, the RA tracking can be worse than using no PEC at all.

If PEC isn't available for your mount or is badly implemented, you can use the PPEC guide algorithm in PHD2. PHD2 Predictive PEC

Declination Backlash and Stiction

Backlash can occur when the direction of motion on an axis is reversed. The telescope may not immediately start moving in the reverse direction even though the motor is turning. The usual cause is loose meshing of the gears in the drive train.  For auto-guiding, this problem doesn't affect guiding in RA because the RA drive system is continuously moving the axis west as it tracks the sky - it never reverses direction because of guiding.  But it is a common source of trouble for Declination because the Dec axis is mostly idle during guiding, running only in short bursts in response to guide commands to move the scope north or south..  A simple picture of what causes backlash is shown here:

This diagram shows two spur gears, but the basic principle also applies to worm gear and worm wheel pairs.  In the diagram above, assume the bottom gear is the drive gear currently rotating counter-clockwise.  The teeth on the drive gear are in contact with the teeth on the driven gear above it and the latter is being driven clockwise.  But the arrows show that the surface on the trailing edge of the drive gear tooth is not touching the matching tooth on the driven gear - there is a small gap.  So when the drive gear reverses direction, there will be a short period of time before the gears are fully meshed and the driven gear starts turning in the opposite direction.  The "reversal delay" in this case is caused by simple backlash.  Some amount of gap is generally required to avoid binding in the gear system and to allow room for lubricant and thermal expansion.  When the mesh is too tight, the axis may exhibit stiction (static friction), a situation where the axis will not move smoothly and freely or is difficult to get moving from a stationary state.  

The Guiding Assistant will measure how the Dec axis behaves when it is forced to reverse direction.  It is only capable of measuring the "reversal delay", the amount of time it takes to change direction and get the axis rotating at the expected rate.  It isn't always possible to distinguish whether the problem is backlash, stiction, or both; but the graph produced by the GA can often provide clues.  This behavior can also be seen during normal guiding sessions that don't employ the large guide pulses used by the GA. If the reversal delay is large, say above 3 seconds, it's probably best to try adjusting the Dec drive system.  If the delay is less than that, the PHD2 Dec Backlash Compensation feature will probably be able to handle Dec reversals fairly well.  Note that the amount of delay is inversely proportional to the guide speed in the mount - as the guide speed is increased, the reversal delay decreases.  This is one of the reasons we recommend using guide speeds of at least 0.5x sidereal.

The reversal delay is usually not a constant value for the mount.  Instead, it often depends on the pointing position of the scope and the balance of the scope on the Dec axis.  As mounts age, the gears wear and for Dec, the wear will be greatest where the scope spends most of its time during imaging.  For northern observers, that is probably in the Dec range of 0 to 40 degrees.  With older mounts especially, the reversal delay can be quite different in those pointing positions than, for example, regions closer to the pole.  This is another reason why the PHD2 Backlash Compensation feature is a better choice than any fixed-size compensation that is programmed in the mount controller.

Uni-directional Declination Guiding

As discussed above, some mounts may have too much reveral delay in Dec to support guiding in both north and south directions.  This situation can be mitigated by configuring PHD2 to guide in only one direction, what we call uni-directional Dec guiding.  This is a viable option because declination guiding is only intended to correct for slow drift - errors caused by polar misalignment and to a lesser extent, mechanical flexure.  Ironically, you might want to de-tune your polar alignment a bit to make it easier to see the drift direction and to reduce the likelihood that seeing will interfere with uni-directional guiding.  Remember that polar mis-alignment, within reason, doesn't usually degrade guiding performance.  Instead, it may introduce field rotation if you're imaging near the pole and have a large camera sensor.  A good first step would be to polar align to within 5-10 arc-min of the pole before setting up for uni-directional guiding.  You can always go back later and check for field rotation.  Just take a sample image with your main camera at the highest declination you would expect for imaging - perhaps 70 degrees north.  If you don't see field rotation there, you can leave the polar alignment where it is.  With any amount of polar mis-alignment, the direction of  Dec corrections will change at some point in the sky.  (Technically, it will reverse directions at two points in the sky but one of those is usually below the horizon.)  The sky location for the reversal depends on how you are mis-aligned on the pole - the relative amounts of azimuth and altitude alignment errors.  If most of  the polar alignment error is in altitude, the point of direction reversal should be near the celestial meridian, about the time a meridian flip is required.

To set up for uni-directional guiding, you can follow these steps:
  1. Move to a field with a good guide star and run the Guiding Assistant for several minutes.  Look at the guiding graph and note whether the guide star is drifting north or south.  Once you see this, reset the Dec guide mode to issue corrections in the opposite direction.  For example, if the star is drifting north, set the Guide mode to 'south.'
  2. Try using the 'LowPass2' guiding algorithm for declination and start with a fairly low aggressiveness factor, say 50%.  If the aggressiveness is too high, the correction may push the star to the "wrong" side of the lock position, where it will remain until the slow drift rate moves it back.  It's better to issue a few small corrections rather than one larger one in order to minimize this type of over-shoot.
  3. Watch the guiding graph to be sure the corrections are being issued in the right direction and the star isn't just steadily drifting off-target.  Over the course of minutes or hours, you may notice the amount of drift is decreasing.  This means you are slowly approaching the point of declination reversal and you should be prepared to change the Dec guide mode accordingly.
  4. If you are dithering, you may want to set the dithering parameters to "RA-only" to avoid disrupting the Dec guiding.

High-precision Mounts and Variable-delay Guiding

Mounts with very accurate absolute encoders and detailed pointing models often allow imaging without any guiding at all.  But there are limitations to how long this can be done without needing some guiding corrections.  The goal in this scenario is to provide a “backup” guiding mechanism that won’t conflict with the inputs from encoders and pointing models and will still improve the overall result.  The recommended strategy for accomplishing this is as follows:

1.      Keep the frequency of guide commands as low as possible.  These mounts can actually be quite “busy” with corrections coming from encoders and fine-grained pointing models, none of which are visible to ASCOM applications.  A slow guiding frequency will minimze the potential for creating instabilities in these functions from external guide commands.

2.      Be especially carefully to avoid chasing the seeing – this is most easily done by using moderate-length or long guide camera exposures and generous min-move settings.

In previous PHD2 releases, users have been able to approximate this approach by using exposures in the 4-8 second range, coupled with a non-zero “time lapse” delay.  The latter simply imposes a fixed delay between the completion of the last guide command and the start of the next guide camera exposure.  The downside of this approach is that operations other than steady-state guiding – things like looping, star selection, calibrating, dithering and settling, etc. – are unnecessarily slowed by the time-lapse value.  The “variable delay” feature eliminates this problem by letting the user specify two different delay values:

1.       A “short” delay that will be used for any activity other than steady-state guiding.  This might be zero but at least for some mounts, it should be non-zero to allow time for the encoders to finish their corrections.  Values above 1 second are probably unnecessary.

2.      A “long” delay that will be used for the normal frame-frame guiding that is typical of steady-state,  long-exposure imaging.  This is the value, in addition to the camera exposure time, that controls the “cadence” of the guiding.

 To give an example, you might use camera exposures of 4 seconds, a “short” delay of 1 second, and a “long” delay of 4 seconds.  The 4-second exposure time will provide good suppression of seeing-related effects and the sum of (4+4) seconds results in a steady 8-second guiding cadence for most of the imaging session.  At the same time, the dither settling times will benefit from the short (4+1) second delays between camera exposures.

Differential Flexure

Any telescope/camera combination is going to flex and sag in various ways as it tracks an object in the sky – that’s just a consequence of gravity and physics.  In fact, each individual component is going to exhibit its own unique behavior in this regard depending on its mass and how it’s attached to its neighboring components.  Especially with larger scopes and heavier cameras, the amount of flexure can be significant, keeping in mind that guiding is dealing in units of a small number of microns.  Since we aren’t generally familiar with dimensions this small, it’s useful to remember that a human hair is roughly 50 microns thick, roughly 10x larger than most guiding corrections.

When a separate guide scope is being used in addition to the imaging scope, each unit will flex and shift independently – this is called differential flexure.  If PHD2 is using the separate guide scope, it will only see and correct for the movements of the guide scope/camera, the differential movements of the imaging scope/camera are invisible.  This can lead to a fairly common and frustrating problem where the guiding results are excellent but the stars taken through the main camera are elongated. 

There will always be some amount of differential flexure in a dual-scope system, it’s only a question of how large it is and whether it is large enough to degrade your images.  For imaging scopes with focal lengths of 1800mm or greater, differential flexure is usually a problem unless the main-camera exposures are kept fairly short.  There’s no way to predict this because there are simply too many mechanical interface points that can move around – movable SCT mirrors, all the connectors between the cameras and their focusers, the focusers themselves, all the thumb-screw fasteners in the system, the mounting ring arrangement for the guide scope, etc.   The typical solution is to eliminate the dual-scope setup and use an off-axis-guider (OAG) on the imaging scope.  This allows PHD2 to “see” all the movements, mechanical or otherwise, that will affect the main-camera images.  In the early days, OAGs were often difficult to use because their fields of view were small and usable guide stars were hard to find.  With the current generation of guide cameras and their large, highly sensitive sensors, most of these problems are a thing of the past.

If you have a situation where you frequently have elongated stars but the guiding results show reasonably similar results for both Dec and RA, you should suspect differential flexure.  You can usually verify this fairly easily with a simple test.  Using the main camera, with guiding active, find the largest exposure time that still has acceptably round stars.  Then capture a sequence of perhaps 10-20 images at that exposure time. Using an app that is capable of displaying that image set, “blink” through the images in the order they were captured.  You will usually see a consistent offset of the stars in each image relative to the previous image – the stars will appear to “march” in a particular direction as you cycle through the image set.  Alternatively, you can simply stack all the images without first aligning them to see the star elongation emerge.

Adaptive/Active Optics Devices

Generally speaking, amateur-grade adaptive/active optics (AO) devices can only deal with some of the problems that create imperfect guiding.  AO’s can usually mask or at least improve the behavior of an under-performing mount because most of the guiding adjustments are accomplished by moving a small tip-tilt optical element – not 70 pounds of telescope gear.  Basically, the mount is rarely asked to do anything beyond basic sidereal tracking.  Problems with backlash, stiction, and periodic error are mostly masked with AO use.  In addition, because an AO is inherently an off-axis-guider, it also eliminates differential flexure problems.  These are significant benefits and explain why many serious imagers use AO’s.

What an AO can’t eliminate is guide star movement due to seeing, at least not under normal conditions.  Guide star movement due to upper atmosphere seeing occurs at frequencies of at least 100s/sec and it isn’t usually practical to find guide stars that can be measured that rapidly. If you attempt to run the AO at such high rates you will have two problems: 1) Any available guide stars will probably have low SNR values, and the calculation of their positions will degrade proportionately; and 2) you will under-sample the seeing deflections.  The latter situation results in “aliasing”, resulting in guide commands that are invariably incorrect and likely to make things even worse.  For these reasons, AO users are still advised to use exposure times of no less than 0.5 second to avoid chasing the seeing.  The goal with AO guiding is really to make the mount “look” better than it really is in terms of tracking accuracy and responsiveness.  If your imaging isn't limited by mount performance, an AO is not likely to provide much benefit.

AO guiding usually involves guide commands being directed, at times, to both the AO and the mount.  The commands are sent only to the AO so long as the guide corrections don’t exceed the physical limits of the tip-tilt element.  As this limit is approached, “bump” guide commands are sent to the mount to help restore the primary guide star to a more central position of the tip-tilt element.  This can happen to correct for polar alignment drift, large guiding excursions arising from external problems (e.g. cable snags) or for large dithers.  An explanation of how these guide commands are “blended” is provided in the Advanced Settings/AO Parameters section of the manual.  AO Parameters

Logging and Debug Output

PHD2 automatically creates two types of log files: a debug log and a guiding log.  Both are very useful for different reasons.  The guide log is intentionally formatted to allow easy interpretation by either a human reader or an external application.  For example, the PHDLogView application (not part of the PHD2 release) can produce a variety of graphs and summary statistics based on data in the PHD2 guide log.   But the log can also be easily imported into Excel or other applications for analysis and graphing.  When importing into Excel, just specify a comma as a column separator.  The debug log has a  complete record of everything that was done in the PHD2 session,  so it is very helpful in isolating any problems you  have.  It also employs a human-friendly (albeit verbose) text format, so it's not difficult to examine the debug log to see what happened.  If you need to report a problem with the software, you will almost certainly be asked to provide both log files.  If you have neither log file available, you are unlikely to get any help.  Note that log files are always created when PHD2 is run, regardless of what was done (or not done) during the time that PHD2 was running so you will have log files to support a request for help.

The location for the files is controlled by the 'Log File Location' field in the 'Global' tab of the 'Advanced Settings' dialog.  By default, log files are stored in the OS-specific default directory for user documents.  In Windows, for example, the files will be stored in a 'PHD2' sub-folder in the "Documents" directory.  This may not be a convenient location, so you can specify a different folder using this edit field.  In order to prevent excessive accumulation of log files, PHD2 automatically removes debug logs that are more than 30 days old and guide logs that are more than 60 days old.  If you want to retain the files for longer periods, you should move or copy them to a different folder location, one not used by PHD2.

To simplify the automatic log upload process (see below), log data is grouped by "imaging day", defined to be a 24-hour period beginning at 09:00 am local time.  This means that all the PHD2 executions on the same imaging day will write guiding and debug log data into the two log files for that imaging day.  

In some unusual cases, you may need to capture guide camera images, usually to support debugging and problem resolution.  This can be done by clicking the 'Enable Star Imaging Logging' menu item under the 'Tools' menu.  The resultant image files will be stored in the same location as the other log files and will be written in the 'Fits' format for maximum fidelity.  If you want to capture a single guide camera frame, you can simply use the File/Save Image... menu item.

Automatic Log File Upload

If you need help using PHD2 or improving your guiding results, you can post a request on the Open-PHD-Guiding forum (https://groups.google.com/forum/#!forum/open-phd-guiding).  Your question should be accompanied by the PHD log files associated with the guiding session you're talking about. The debug log files are usually very large so you can't post them as attachments - you should use the Upload tool described below. Please do not edit, trim, or rename the log files. To make uploading easier, PHD2 has a built-in function to select, compress, and automatically upload the relevant log files. That function is located on the 'Help' menu.  You'll see a dialog box that shows all the available log files, including their timestamps and duration:



Just select the files you want and start the upload process by clicking on 'Next'.  Please be careful to look at the 'Night Of' column to be sure the log covers the time period you're interested in.  PHD2 creates guide and debug log files every time it's run, so some of the log files will be nearly empty - don't upload those.   Be selective about the files you choose - just the files for the session you were having trouble with.  When the upload process is complete, you'll see another window that gives you a link to the files:


You need to capture or record that link so it can be included with the question you'll post on the forum.   Log files will be automatically removed on the server after a reasonable amount of time has elapsed, so you won't need to worry about that.  When you post your request for support, please include a full description of what you were doing, whatever problem you saw, and roughly what time period you want us to focus on.

Managing Equipment Profiles

Equipment profiles were introduced in the section on Basic Use where they are used as part of the 'Connect Equipment' dialog.  If you want to manage multiple profiles, you should use the 'Manage Profiles' button in the 'Connect Equipment' dialog.  Using the menu items there, you can create a new profile or edit/rename/delete an existing one.  The most important option and the one you are most likely to use is to launch the New-Profile-Wizard, described in the Basic Use section of the manual. This is the function that will configure the PHD2 settings that are specific to your equipment configuration.  Each profile holds all the settings that were active at the time the profile was last used except for the dark and bad-pixel map files.  To edit the settings in an existing profile, you first select it in the equipment profile drop-down list, then click on 'Settings' under the 'Manage Profiles' pull-down.  This will take you to the Advanced Settings dialog, where you can make whatever changes you want.  Remember that profiles are automatically updated anytime settings are changed during a PHD2 session. Finally, you can import and export profiles for purposes of debugging, backup, or exchange between computers.

Aux-Mount Connection using "Ask for coordinates"

If you can't connect to your mount using either ASCOM or INDI drivers, you still have a better-than-nothing alternative by using the "Ask for coordinates" aux-mount connection.  With this option, you'll be asked to enter or confirm the scope position each time guiding is going to begin::



If you enter your scope's current declination and side-of-pier values,  PHD2 will automatically adjust the calibration to match that pointing position.  You don't need to be precise, a Declination value that's within a few degrees will work.  This means you won't need to recalibrate as you slew to different targets so long as you update these values each time.  For example,  you can do a calibration near Declination=0 then enter new position values when you've slewed to a high declination imaging target.  This is likely to produce a better result than trying to calibrate at a near-pole position.  This dialog will not be displayed if the start of guiding is the result of a dither operation or a server command from an imaging application.  In order for the calibration adjustment to work correctly, your previous calibration must have been completed with correct positioning data available.  

If you're using this option with the Drift Alignment tool, the dialog will look a bit different:



If you enter the additional information for Right Ascension, latitude, and longitude, the Drift Alignment tool can more accurately adjust its magenta target circle.  Otherwise, the circle will show only an upper-bound estimate of the pointing error during the 'adjustment' phases.  

You can connect or disconnect the "Ask for coordinates" aux-mount without affecting the camera or mount connections.  So you might decide to use the option for drift alignment or for an initial slew to your imaging target, then disconnect from it in order to avoid the repetitive dialog displays.  Regardless of how you choose to use it, you're responsible for having the correct values in place, and you should remember that significantly wrong values can result in poor guiding results.

Advanced Settings for the Simulators

The device simulators were introduced in the Basic Use section as useful tools for experimenting with PHD2 and becoming familiar with its features.  Remember that you must choose 'Simulator' as the camera type and 'On-camera' as the mount type in order to do useful simulation.  As you become more interested in the details of the simulation, you can use the 'Camera Settings' button on the main display to adjust the simulation parameters:




You can adjust simulated mount behaviors for declination backlash, drift due to polar mis-alignment, and periodic error.  You can also adjust the 'seeing' level, which will create fairly realistic guide star deflections that look like seeing effects.  If you adjust these parameters one-by-one, you'll see how they affect star deflections and how the different guide algorithms react to those movements.  Of course, you're dealing with a "nearly perfect" mount in these scenarios (except for backlash), so the simulation can't be entirely realistic.  The simulation dialog is primarily used for development purposes so UI controls may change without corresponding changes to tool tips or documentation.

Multiple Program Executions

In some situations, you may want to run multiple instances of PHD2 at the same time.  To start the second instance of PHD2, you need to supply a command-line parameter of -i 2; the third instance would be started with -i 3, etc.  You can accomplish this in Windows by running PHD2 from a command line using the Windows cmd.exe utility.  Or you can create a Windows desktop shortcut by doing the following:

Right-click on your desktop
Select: New/Shortcut
Enter the following string to identify the location of the program: "C:\Program File (x86)\PHDBuiding2\PHD2.exe" -i2
Click Next
Enter a name for the shortcut, e.g. PHD2 #2
Click Finish

Note the quotes around the name in the 3rd line are required by Windows because there are blanks embedded in the directory name.

Keyboard Shortcuts

Keyboard shortcuts are available for many of the more commonly used tools and functions in PHD2.  These are enumerated in the Keyboard Shortcuts section.

Software Update

One of the most common responses to a request for support in the PHD2 Forum is: please upgrade to the latest version and see if the problem still exists. If you are seeing an issue in an older version of PHD2 it is quite likely that you are not the first person to encounter it, and it has already been discovered and fixed in a newer version of PHD2. For this reason, the developers of PHD2 feel that it is important to be running the most up-to-date version of the program.

Updating a program that you rely on for unattended imaging can sometimes be perceived as a risky proposition. The developers of PHD2 recognize this sentiment--we are imagers too! There is a necessary trade-off between maintaining a stable software installation and staying current with the latest bug fixes and other improvements.  In some cases, camera vendors will issue "breaking" changes to their software drivers and SDKs, often because they have introduced a new camera model.  This poses a problem for us because we are forced to update the camera SDK in order to support the new camera.  But this also means that current users may encounter problems with a camera and drivers that have been working well, something that can only be corrected by upgrading to the latest camera drivers and the latest version of PHD2.

PHD2 achieves a balance between these two opposing needs by publishing two series of software releases. The development releases contain the latest ongoing bug fixes and feature improvements and are tested by the developers--usually during actual imaging time--before being released. Users who choose to run the development releases will get the latest bug fixes and newest features. Development releases have names like "2.6.3dev6" indicating, for example, the 6th development release after the 2.6.3 major release.

Periodically, after a development release has received more test time, it will be published as a major release. For example, 2.6.3dev6 could be published as major release 2.6.4.

Checking for updates

PHD2 has an option to automatically check for software updates. We recommend enabling this option to help keep your version of PHD2 up to date. When the automatic check option is enabled, PHD2 will check for updates in the background when PHD2 starts. If new updates are available, PHD2 will give you the option to install the new version. Enabling the automatic check for updates will not interfere with the ordinary operation of PHD2, including automated operation. It is also safe to leave the option enabled if you are imaging in the field without internet connectivity. If PHD2 cannot check for updates, it will wait until the next time it is started before trying to check again.

Regardless of whether you allow PHD2 to automatically check for updates at startup, you can always manually check for updates by clicking "Check for updates" from the Help menu.