What to do When PHD Guiding isn't Push Here
I designed PHD Guiding to
be as simple as "Push Here Dummy". When everything works, it's
great (and quite often that's the case!). But, what do you do when
it doesn't work? What do you do when you've spent night after night
trying to get it going, only to meet frustration at every turn? One
option is to throw in the towel. Let's cross that one off the list.
Another is to turn to Internet groups like the forums
here on Cloudy Nights the
Yahoo Group, or send me an e-mail. Both are solid options. A
third option is to diagnose it yourself. The articles here are
designed to let you do just this. If they don't get you going,
you'll at least know a lot more about your problem making it easier
for others to help. While I can't ensure you'll get sub-arcsecond
accuracy with perfect stars every time, I can say that I've never
tried to help someone that didn't get guiding up and going. I've
helped a lot of people along the way and odds are pretty good that
your solution will be somewhere in here. I should note at the
outset that many of these apply to any of the other excellent guide
packages out there as well. So, let's dive in!
The first thing to know is that there are a number of reasons
why you might not be getting round stars that have nothing to do
with PHD Guiding itself. Before diving into various settings, we
need to make sure that PHD is actually anywhere near the problem.
Having now helped hundreds of people with their guiding, I can say
that the vast majority of the time, the issues don't stem from
various parameters to set in PHD. I know what you're thinking -
"Not me! It must be the parameters!" Do yourself a favor and let's
walk through the other options first as to why you might get poor
performance or calibration issues that have nothing to do with
hysteresis, aggressiveness, etc. Read through each of these to try
to determine which lines up with your issues the best. Only once
you've ruled out any of the options below should you turn to
tweaking with the parameters.
Calibration works but all my stars are oblong
Now if all your stars are oblong and all the non-roundness is in
the same direction, you could very well have guiding issues that
parameters would help with. Before you dive into this, though,
there is a very important check to make and that is to determine
that it's not coming from something in your optical chain or
something mechanical. The first step in this is to make sure that
your collimation is good. If you throw a high power eyepiece (you
know that thing you actually put your eyeball up to!) and look at a
bright star defocused a touch, do you see nice concentric circles
or are they off-center? Rack to the other side, do you get the same
thing or was it oblong one way on one side and now oblong another
way on this other side? Non-concentric circles point to
mis-collimation and different orientations of footballs point to
astigmatism. If you don't have points of light hitting your sensor,
PHD won't help. Work on those optics.
If the optics look good, head on to a bright star but one not
straight up in the sky and take a short exposure with guiding off.
Now rotate your camera 90 or 180 degrees and take another one. In a
second or so worth of exposure, your mount shouldn't have much
error (if it does, it's time to think about a new mount!). If
exposures here are showing oblong stars, you've got an issue with
your sensor not being lined up with the focal plane. Examine the
direction of the problem in one image and then in the one where you
rotated the camera. Does the problem go in the same direction or
did it move? If it moves, it likely means the error is wherever
"down" is, physically. Gravity is doing what it does best and is
pulling on your rig. Any flex in drawtubes, focusers, adapters,
etc. will pull your sensor out of square. If the problem though is
always in the same direction relative to the sensor even though you
rotated the camera, you're looking at your sensor not being square
relative to its mounting (i.e., relative to the camera body, it is
tilted). Again, there's not going to be anything better guiding can
do about this.
My stars are oblong and PHD's graph shows jumps in RA or
On each sample of the star, PHD tries to figure out where the star
is relative to the lock position and it then sends a correction to
the mount to reduce the error. If a big jump happens, it'll be
because the star moved a bunch without PHD doing anything, because
one of PHD's commands made the mount move more than it should, or
because PHD's demonically possessed. For now, let's throw out the
last option. Bugs do happen in code, but this part of the code has
been stable for so long, the odds are it's something else. What
could it be?
It might seem odd to think that the star moved without PHD's
intervention, but that actually does happen to people with some
frequency. How? Slop in the gears is a prime culprit. Gears never
mesh perfectly and the small gap will give the gears space to rock
back and forth. As this happens, the scope moves and thus, to PHD,
the star moves. Remember, one arcsecond is 1/3,600th of a degree or
about 1/7,200th the width of your thumb at arms length. That's not
much! Why would it rock in the gears? Typically, this comes from
people being a bit obsessive about balance. If your scope is
perfectly balanced, it's very easy to push it to one side and then
the other in the gears. Unbalance it a bit and it's biased towards
one side (east is better than west for RA). Now, a light touch or a
light breeze is much less likely to bring on this mechanical
problem. Both axes should be moderately imbalanced.
A second issue that comes up is crud (technical term) in your
gears. This can cause far more rapid motions than are expected,
leading to a clear jump (the bits of metal change the shape of the
gears as you ride over them). Cleaning them out or ignoring these
occasional jumps are your only real fixes. You'll know if you have
them if you generate a periodic error (PE) curve (see below).
I watch PHD's graph and display and all looks great but my
stars are still oblong
So, PHD's graph shows small errors that are routinely fixed. When
you watch it, the star stays in on or very near the crosshairs.
Thus the box (where PHD thinks the star is) is routinely nicely
lined up with the crosshairs (the lock position). Yet your main
image shows issues. One is great, while the other is not.
PHD is doing its job keeping the guide star in place. All your
data - the graph, probably small errors show in the log file, the
display - say that guiding is good. There are two options here to
First, you must consider if you're asking too much of your
guiding. If you're using a very short guide scope and trying to
image on a 14" f/10 primary scope, you're pushing the notion of
"guider focal length doesn't matter" a bit far. A longer focal
length guide scope or a shorter focal length image scope is
probably in order. With that focal length on your main scope,
you're probably even below a half an arcsecond per pixel there.
Unless you've got a very nice mount and steady skies or really know
how to work your gear perfectly, think long and hard about cutting
that focal length down. If you're just starting out at this, get
that focal length down considerably as guiding well below an
arcsecond of error is not trivial. We'll come back to this
There's another real possibility here, though, and that is flex.
Determining if it's flex or poor guiding can be fairly simple. One
way is to just take a 30 minute or so series of fairly short
exposures (1 minute or less) and scroll through them (e.g., using
Nebulosity's Preview tool). Does the drift you see go back and
forth in one direction (RA) only? If so, your mount's periodic
error isn't being taken care of despite the seemingly good behavior
by PHD (are you imaging at very long focal lengths?).
If not, and if the drift all seems to be in one direction, odds
are you've got flex. Remember, all data pointed to PHD controlling
both the RA and Dec error and yet your main image is showing this
steady migration of the stars across frames. The guide star is
stable, but the main image moved. The answer is that they are
moving relative to each other and the only way that's going to be
happening is if something mechanical is causing it. Your focusers,
rings, and even OTAs themselves can be distorting. As the mount
turns, the direction gravity is pulling and the load it's placing
on the gear changes, leading to this differential flex. No matter
how well PHD holds the star in place, you'll get this error and
there is nothing PHD can do about it. You need to work on getting
things more sturdy. (Note, off-axis guiders are very unlikely to
suffer from this problem.)
My stars were great for one target and poor on another in the
PHD works by knowing how the star moves for given amounts of RA and
Dec motor activity. If you slew to a different portion of the sky,
the vectors PHD uses must be updated by running the calibration
again. You'll need to check "Force calibration" in the Advanced,
select your new star and hit "Guide" to have PHD recalibrate. If
you've done that, start thinking about balance and flex again.
Box 1: Interpreting PHD's
If there is any place that will hold all the secrets to your
guiding woes, it's PHD's log file. In there, you can find clues to
the source of most any problem. You still need to do your detective
work, but it has invaluable information to help you. So, what's in
there and how do we decipher it?
The first thing to do is to make the log file. Before you
calibrate on a star, enable logging either via the Advanced panel
or via the Tools menu. Personally, I leave logging enabled at all
times. A small amount of hard drive space is all it will cost you
and the data can be invaluable.
With that out of the way, we can start to look at it. The log
file is a simple text file you can open up in any text editor
(Word, WordPad, NotePad, TextEdit, etc.) The best way to open it
though is in a spreadsheet program (Excel, OpenOffice, etc.) or one
of the various log file analyzers. If you're using a spreadsheet,
tell it that the file is a "CSV" or "txt" file and that it's
"delimited" with commas (CSV = Comma Separated Values).
With the file open now, you'll see a top section that has your
calibration data (see Box 2 for more on this). After that, you'll
see a long list of values. Each row is a separate time point (a
separate guide frame) and its associated error and corrections. At
the top of this list is the name for each column.
- Frame = image number
- Time = Seconds since guiding began
- dx = Number of pixels the star is from the lock location in the
- dy = Corresponding number for the vertical axis
- Theta = Direction of error (radians)
- RADuration = Milliseconds the RA motor was turned on to correct
for this frame
- RADistance = Amount of error specifically in RA (in
- DECDistance = Milliseconds the DEC motor was turned on to
correct for this frame
- DECDistance = Amount of error specifically in DEC (in
- StarMass = Summed brightness of the guide star.
The RADistance / DECDistance and the RADuration / DECDuration
columns are the ones to focus on the most as they show the error
and corrections PHD made that we care about. Are these errors
continually small and yet you have drift in the main image? Think
about flex. Are the errors building up despite PHD sending large
durations? Think about whether the guide signals are getting
through (or whether you're limiting them too much). Are there
sizable errors building up but the distance columns are zero? Check
your minimum motion parameter. Are there lots of Dec corrections in
the same direction? Odds are your polar alignment is off. Did
guiding go bad at some point and the StarMass column showed a real
drop? Think about whether clouds could have obscured the star.
Calibration is failing - why?
PHD's calibration process works by repeating a loop of taking an
exposure, finding the star, and moving the scope a bit, each time
figuring out how far the star moved from the original "lock"
position (where the crosshairs are). It repeats this until the star
has moved "enough" (defined as 5% of the height of the screen).
Calibration fails when the star doesn't move enough. So, we need to
Box 2 will help you understand the calibration portion of PHD's
log file. If you plot the data using a spreadsheet (see Box 1), you
can quickly see if there is something amiss. If you're not
plotting, it really helps to have had your guide camera squared to
RA and Dec so that one lines up with the x-axis and the other lines
up with the y-axis. Ideally, RA- will "unwind" RA+ and end up in
pretty much the same place where it all started. Dec+ will move
perpendicular to the RA motion (e.g., if RA was mainly along the
x-axis, Dec+ is along the y-axis). Dec- will likely end up not
where you started (the result of backlash in the Dec gear), but
should be along the same line that Dec+ formed. What might you see
that doesn't look like this?
Box 2: Interpreting PHD's
The top of your log file, you'll find the calibration data. You'll
see the position of the crosshairs ("lock" followed by two numbers)
and where the star is when the calibration process begins. After
that, you'll see a number of lines showing how the star is moving
when RA+ (west) is applied followed by an equal number of lines
showing how the star is moving when RA- (east) is applied. For each
calibration step, you'll see the position the star was at. Here,
"x" is the horizontal position, "y" is the vertical position, and
"dx" and "dy" show how far it moved in x and y from the lock
position (delta-x and delta-y).
This is the first spot to look not only for calibration errors,
but also for guiding errors. If you were to plot these numbers (see
Box 1), it might look like what's shown here. Here's where to spot
errors. First, is it actually showing motion of the star? Second,
does RA- follow along the same line as RA+? Does the Dec- follow
along the same line as the Dec+? Both should "unwind" the positive
direction. Is there an angle formed between the + and - versions?
Finally, do RA and Dec form something close to a right angle?
(Note, you'll need to make sure your plot box is square and the
range on each axis is the same to really see this.)
If you'd rather not plot the data, you can just look at the
numbers to see things like whether, after the RA- segment, you end
up near the start position. If you're not plotting, it's a lot
easier if you had your guide camera square so that RA and Dec line
up with x and y (or y and x). If RA+ moves mainly in x, does RA-
move the opposite way in x? Does Dec move in y and not x? It
The star doesn't move much at all
PHD is sending guide commands but the star doesn't move much. One
real possibility here is that the guide commands aren't actually
getting to the mount. Check that you've selected the right option
in the "Mount" menu. If you've selected "on camera" but don't have
a cable going from your camera to the mount, you're not setup
right. "On camera" means you're using the ST-4 port on the camera
and that's what PHD is telling to move. At this point, use the
"Manual Guide" tool to send guide commands to the mount. These will
be small, but you should be able to hear your mount's motors change
as you do this (a stethoscope or a rubber tube may help).
Are you using the ST-4 port and nothing gets through? Check that
your mount's controller is setup to actually listen to the guide
port. Some mounts (e.g., the Losmandy Gemini) need to be in "Photo"
mode to listen to this port at all. PHD is sending the guide
commands but the mount is ignoring them.
Are you using the ST-4 port and only South gets through? This
seemingly odd situation comes up more often than you might think.
It's a cable problem. SBIG guiders expect a "crossover" RJ cable
whereas others expect a "straight" cable. If you hold your RJ cable
so that the two ends face the same direction and look at the colors
of the small wires inside, do they go in the same order (straight)
or reversed so that if you tried to plug them into each other, the
colors would line up (crossover)? Unless you're using an SBIG
camera, you most likely want a straight cable. (Note, the Takahashi
adapter to go from their DIN to an RJ plug acts as a crossover
cable and expects to be plugged into an SBIG style camera.) Note,
two crossovers joined form a straight cable.
The star moves, but not nicely back and forth. Dec isn't
PHD is sending commands to speed up and slow down your RA motor but
the star doesn't come back to the same spot. If you plotted it, the
RA lines form a "V". There can really be only one answer to this
problem and it'll go along with having some of that same motion
show up when Dec is calibrating. PHD is going to assume that RA+
and RA- do opposite things. Yet, the calibration is showing that
while they move in opposite directions to some degree, there is
another component to the motion that his happening regardless of
whether RA+, RA-, or even Dec+/- are engaged. That star drifting
because you are not well polar aligned. Being off the pole is what
causes Dec drift and if you're spot on with your alignment, you
don't even need Dec guiding. A small misalignment is fine (and some
do it intentionally to keep the gears loaded), but if you're seeing
a "V" during under a minute of calibration, you've got way too much
drift (drift that PHD thinks is the effect it's having on the star
by turning on the motors!). You need to work on that alignment.
At times, users will insist that their alignment is spot-on and
that they've done a three-star alignment in their GOTO system to
make sure it is. Three-star models are great in that they use
enough data points to figure out not only what error exists in your
"scope down" position (one star needed for this), but also how far
you're off the pole (and what kind of non-orthogonality you have
your mount). These data points are used by the controller to get
your GOTOs to be spot-on despite your polar misalignment. But, once
there, the mount just has the RA motor move at 1x and move along
the RA axis. Yet, to accurately track, you'd need both RA and Dec
to move as, by being off the pole, you've taken a step closer to
being an alt-az mount instead of an equatorial one. Search the web
for drift alignment tutorials or iterative GOTO alignment
tutorials. Once comfortable with them, they won't take long and
your guiding (and shots) will be a lot better.
Calibration works on other nights, but not tonight and my
signals are getting through
Remember, PHD is looking to have the star move by 5% of the screen
size. Did you change guide scopes to something of a shorter focal
length? If so, it's going to take longer to get the star to move
that much. Likewise, are you imaging nearer the celestial pole? If
so, it will take longer guide pulses to get the mount to move. Odds
are that under these circumstances, increasing the "calibration
step size" in the advanced panel will clear things up. This will
lengthen the duration of each pulse during calibration to get more
motion out of each step.
One last note here is to check your guide rate in your mount's
controller. When you're guiding by hand, a 0.5x rate may be nice
(which amounts to the mount tracking at 0.5x or 1.5x). You're not
helping PHD any by this and you're just increasing the calibration
time and correction time by using anything other than full-speed
If the cookbook approach above doesn't solve your issues or if you
want to know more about what's going on, it's time to turn to some
tools of the trade that will help you understand what's going on.
The most useful bit of information you can have is the log file PHD
will generate if you ask it to (Advanced panel or Tools menu). Box
1 goes over the basics of how to read the log file. Let's use it
here to start some diagnoses.
What am I up against? Generating a Periodic Error Curve
A key thing to determine is just what kinds of errors PHD is having
to correct for. To see this, we need to generate a Periodic Error
(PE) curve. Get things going and get PHD calibrated, ideally using
a star on the meridian. If it's off the meridian, note the
Declination angle of the star you're using as this will let you
convert the error into absolute arcseconds. Once all setup, stop
guiding and head into the Advanced panel and check "Disable guide
outputs". What this will do is tell PHD to do everything it would
normally do, but to skip the part where it actually tries to fix
the error. While here, make sure logging is enabled.
Now, start "guiding" on the star as you normally would. You'll
find the box moves as the star moves and that it will drift away
from the lock position. Hopefully, after a bit, it drifts back (if
not, your polar alignment needs work). Let this go for at least 10
minutes - ideally a half hour or so. Then, stop guiding and shut
things down and copy the log file to the machine you'll be
analyzing things on.
There are several excellent log file analyzers out there and you
can feel free to use them. They can automate this process nicely.
If you're using a spreadsheet, though, you can still get great
information by simply plotting the RADistance column in a line
graph. This will show you the error in RA over time. To get a bit
fancier, do an X-Y plot with the X being the Time column and the Y
being the RADistance column. To get fancier still, convert the
RADistance column into arcseconds using the formula:
If your star is on the meridian, you can skip the
cos(StarDeclination) bit as that amplifies the error to
correct for how far you are off the meridian. While you're at it
here, make another plot for the DECDuration column.
Now, have a look at these. Ideally, your DECDuration one will be
centered on 0 and bounce around just a tiny bit. Polar misalignment
will be indicated by a steady drift. If you see jumps in there,
remember it's not PHD's fault (as PHD isn't sending any guide
commands). Something caused the star to move a whole bunch right
then. Did it jump in RA as well? Think about whether the mount
could be rocking in the gears…
Turning back to the RA curve, the ideal curve would be a smooth
sine wave, gradually undulating up and down. Is it just going up
and down or is there a constant drift to the sine wave pattern? If
so, again, your polar alignment is off. Outside of that, are there
big spikes in the curve or areas with very rapid changes? If so,
your worm gears are not smooth. Since guiding works after the fact
(after the error has been made), rapid errors are tough to correct
for as even in one sample, a sizable problem may have built up.
Start thinking about cleaning and re-greasing those gears. How big
is the error overall? Are we talking numbers closer to 10
arcseconds or closer to 100 arcseconds? If the latter, start
thinking about whether trying to image at 0.5"/pixel is really
reasonable on this mount.
At this point, go back to (or generate) a log file with guiding
still enabled and do the same plot. This will show you how much
error remains and comparing the two will show you how much of the
error has PHD eliminated.
You can take PE curve analysis a lot further once you get into
analysis packages like PEAS. These packages will do also do FFT
(Fast Fourier Transform) analyses on the curve to determine what
frequency components are inside your curve. This kind of analysis
can help you determine where the error is coming from. Not only
will your worm gear be a source of error, but any other shafts and
gears along the way will introduce their own error (the worm is
just typically the largest). For example, on my Losmandy G11 mount
is known to have an error with a period of 76 seconds that stems
from issues in the worm block. As we can see in this analysis by
PEAS, my particular mount has this, but not in copious amounts. So,
I can know where I should start looking (and where I can ignore) if
I want to tune things more and give PHD less it has to correct.
Using the log file
Box 1 above showed you how to start looking at the log file (you
did remember to turn on logging, right?). If guiding went amok in
the night, use the datestamps from your main images to figure out
when and then look in the log file. Do you see anything around that
time? Did the star mass drop a bunch? Did PHD lose the star? Was it
sending guide pulses, but they were the max amount allowed
(according to your Advanced settings)?
Using the graph
PHD can plot in real-time the current RA/Dec or dx/dy error to let
you see how things are going. Use this to see if there is constant
drift or if it spikes at times. It will also report the RMS error
(in pixels) and an opaque "Osc-index" term. That term is the
probability that the current RA guide error is in the same
direction as the previous one (it counts the "different" and "same"
side RA pulses). Were there no PE in your mount, the ideal value
would be 0.5. All mounts have PE and so the ideal probability is
less than 0.5. As you move up (or down) the PE curve, you'll keep
making guide corrections in the same direction and it may be quite
some time before you flip to the other direction. Very smooth
mounts will have low ideal Osc-index parameters. Mounts with
rougher PE curves will have higher ideal ones. There is no clear
ideal value here, but values in the 0.25-0.4 range are typically
good. It will at least let you monitor the effects of your changes.
So, what parameters should I adjust?
If you've gotten this far and are still having issues, it's time to
think about adjusting parameters. OK, fine, even before this point,
you might want to adjust some paramters. Which ones and what do
Parameters everyone should think about
The defaults are there for a reason and they work well for most,
but there are some parameters that all users should think about a
- Calibration step size: This parameter controls how long a pulse
PHD sends during calibration. The exact value here does not matter.
You just want something that will make calibration take a
reasonable amount of time. Here, I define "reasonable" as more than
about 7 steps and fewer than 40. If it is taking a long time to
calibrate, increase this parameter. If it's taking 2 steps, or
something very small, decrease it. If yo don't mind it taking 50
steps, so be it. It's only when it takes a very small number of
steps that it might affect guiding accuracy. But, if you're guiding
with an off-axis rig at 3000 mm of focal length, the stock setting
will make the star shoot off the chip so fast you'll want to drop
- Min motion: This parameter controls how many pixels of motion
PHD must see before a guide command is sent. If you're imaging with
a finderscope you'll want to send things with a small fraction of a
pixel worth of error. If you're on that 3 meter rig, you will have
to tolerate a lot more and probably won't want to send a guide
command unless it's at least a half pixel worth of error. Figuring
out the sampling on your main scope and on your guide scope using
the equation above will help you dial this in.
OK, what's after those?
After these, the next ones to consider are the Dec guide mode /
algorithm and the RA aggressiveness and hysteresis.
- Dec guiding: If you're perfectly on the pole, you won't need to
guide in Dec. If you are off, you'll likely need it. If you're sure
of the direction, you might as well tell PHD this. It will only
send Dec guide commands in that direction and will veto any in the
other. Assuming you don't know the direction and it's set to
"Auto", you have two algorithms to try. "Resist switch" will try to
guess the drift direction and only send guide commands in that
direction. If enough evidence builds up that it's wrong, it'll
change it's assumed drift direction. "Lowpass filter" won't do this
guessing, but smooths the Dec guide commands out over time, sending
a running average guide rate rather than the current error.
- RA guiding: In RA, we need to correct in both directions
routinely (unlike Dec). If you want to smooth out the guide
commands more, you can increase the hysteresis (amount of the last
guide command factored in) and/or decrease the aggressiveness
(amount of the current error factored in).
Well, there you have it. That's quite a bit of troubleshooting for
something that's supposed to be "Push Here Dummy". Very little of
it, though, is in PHD's or any other guiding program's control.
Balance, flex, etc. can all wreak havoc on your guiding accuracy.
If you don't get those under control, you'll be fighting guiding at
every turn. If your guide commands aren't getting to the mount,
you'll be fighting things (and losing every time). If your polar
alignment isn't decent, you're asking guiding to constantly pull
out substantial errors. If you can get your mount physically in
good shape, your guiding package, be it PHD or something else, is
going to have a much easier time getting those stars round.
Hopefully, this has helped you understand both a bit about how PHD
works and about how to get it working when all seems lost.