I use a Celestron CGEM for my mount. It suffers from roughly 50 arc-seconds of declination backlash…which is big. This causes big headaches when trying to autoguide. I have invented a program I call “Backlash Assistant” which dramatically reduces the effect of declination backlash while autoguiding. The program is synchronized with PHD2 Guiding and operates in parallel with PHD2 to quickly move my declination axis thru its backlash such that my autoguiding barely notices what is happening. So…
What is declination backlash?
Most mounts use motors coupled to multiple sets of gears to control the position of the Alt/Azm or RA/DEC axis.
This graphic illustrates the motor/gearbox arrangement in my Celestron CGEM mount. The worm gear is used to drive the king gear which is what rotates the RA or DEC axis. This gearing is identical for both the RA and DEC axis. A lot of mounts use a similar combination of motor and gearbox. The important detail here is that there are several gears involved and each set of gears has a small amount of backlash. This is because these sets of gears need to have a small amount of spacing so that the gears do not bind or wear excessively. These small backlashes all add up and, in my case, results is approximately 50 arc-seconds of backlash.
DEC Backlash Events
What we notice is that, while autoguiding, when the declination axis needs to change direction nothing seems to happen initially. This is because the declination motor needs to rotate roughly ½ rotation before all of the backlashes in all of these gears have been taken up in the opposite direction. Only then can the declination motor turn the declination axis causing the telescope to rotate. These reversal events are typically called DEC backlash events.
The RA motor + gearbox probably has a similar amount of backlash but, when autoguiding, the RA motor typically turns in one direction. This means that the RA backlash is always taken up in one direction so we don’t experience RA backlash events while imaging.
DEC backlash events can happen far too often. Autoguiding requires very small adjustments in both RA and DEC. Small adjustments in RA translate into momentary increases or decreases in the RA motor RPM as it slowly turns to track the sky. Most of the time the DEC motor is stopped. Small adjustments in DEC require small rotations of the DEC motor. A typical autoguiding adjustment can be 1 arc-second which, for the DEC axis, would be 1/80th of a revolution of the motor.
If the direction of a DEC axis adjustment requires the motor to rotate in the opposition direction one of four things happens depending on how much DEC backlash the mount has.
1)If the mount has no backlash the adjustment will rotate the DEC axis and the autoguiding error will be corrected.
2)If the mount has a small amount of backlash PHD2 can be configured to use it’s Declination Backlash Compensation. This will cause the DEC axis to rotate close to the full amount of its backlash whenever a reversal is required. This requires the DEC motor to make a large rotation using it’s autoguiding speed. 30 arc-seconds at 100% autoguiding rate[15a-s/sec] requires two seconds…4 seconds at 50% autoguiding rate[7.5a-s/sec] During this time there are no corrections made to the RA axis and no guide camera updates.
3)For larger amounts of backlash you can still try using the Declination Backlash Compensation. There is a maximum of 8 seconds placed on this feature. At 50% autoguiding rate this would result in a 60 arc-second movement with no control of the RA axis or guide camera updates for 8 seconds.
4)You decide to not use the PHD2 Declination Backlash Compensation. You will notice that your DEC guiding error can persist for over a minute as your DEC motor slowly rotates and takes up the backlash in the gearing. Basically the DEC axis is uncontrollable during this time. The DEC guiding error can become quite large. When the DEC motor finally takes up the backlash it is possible for there to be a dramatic correction which could result in oscillations.
How to deal with Backlash Events
The easiest way to reduce backlash events is to avoid perfectly polar aligning your mount. Polar alignment means that your RA axis is precisely aligned with the celestial pole of the earth. Perfect polar alignment tends to be a bragging point amongst astrophotographers but perfect polar alignment tends to also result in a perfect storm for DEC backlash events. If you can introduce a small error (<5 arc-minutes) into your polar alignment this will cause the DEC axis to always require small adjustments in the same direction while autoguiding. Unfortunately these small adjustments can tend to become smaller and eventually change their direction over the course of the evening. When that happens you will experience DEC backlash events until the small adjustments grow again.
You can try to reduce the size of your mount’s DEC backlash by making mechanical adjustments. These types of adjustments are typically documented on user forums for your mount. The ultimate solution is to buy a better mount.
My solution Backlash Assistant
I decided that I could start by writing a program to study this issue. This eventually grew into a program that dynamically corrected my mount’s DEC axis in tandem with PHD2 autoguiding. I call my program “Backlash Assistant” and I have been using it for over three years. It is always active when I am imaging.
PHD2 Guiding performs autoguiding by taking photos using your guide camera and then issuing what are called guide pulses to your mount’s RA and DEC motors. These pulses vary in length between a few milliseconds to 1,000s of mS. PHD2 Guiding also has a server feature which allows me to aquire guiding information and time synchronization. After a few E-mails between myself and Andy & Bruce (the folks who maintain PHD2 Guiding) I was able to determine the timing of PHD2. It functions as follows:
1)Tell the guide camera to take a photo and wait until the photo is complete.
2)Analyse the photo and determine the exact position of the selected guide star(s).
3)Send out guide pulses as required to the RA and/or DEC axis and wait until these guide pulses are done.
4)Broadcast a GuideStep message on the PHD server and go back to step 1).
I would expect that most people reading this would say “you don’t need to be a rocket scientist to understand that!”. But when I documented this order of operations I realized that PHD2 is doing nothing while the guide camera is taking a picture. Via the PHD2 server I can tell what these exposure times are. I also knew that, whenever PHD2 sent a GuideStep server message, PHD2 was about to start a new exposure and would be waiting for it to finish.
After a little experimenting I discovered that I could have my program send DEC guide pulses to my mount while PHD2 is waiting for a new picture to finish exposing. This is the beauty of the ASCOM architecture…multiple programs can communicate to the same ASCOM device at the same time. PHD2 doesn’t know, or care, that I am sending out guide pulses during this time interval.
I had already developed a generic mathematical model for DEC backlash. You specify the backlash size and the maximum allowable guide pulse. I also included a “wait until” deadband which causes my program to wait until PHD2 has sent out enough guide pulses to verify that a real DEC backlash event is occurring. The backlash size and “wait until” deadband are specified in arc-seconds. The model keeps track of all of the DEC guide pulses sent by PHD2 and by my Backlash Assistant.
My model knows exactly when a DEC backlash event is occurring and exactly how far thru the DEC backlash the motor has rotated at any given time. With every DEC guide pulse issued by PHD2 my model will determine when PHD2 needs help. My program will then send additional DEC guide pulses and track how much further to move. Once the model determines that we are getting near to the end of the backlash zone the extra guide pulses will become smaller and stop allowing PHD2 to smoothly finish the DEC movement.
The coolest thing about this approach is that PHD2 doesn’t know that my program is doing this. PHD2 ends up sending DEC guide pulses that would be appropriate for a mount have roughly 10 arc-seconds of backlash. My program ends up issuing the missing 40 arc-seconds of guide pulses. The other benefit is that my PHD2 guiding graphs look as if there were no DEC backlash events even though there were several. I have seen situations where the DEC axis made it half way thru it’s backlash and then it dithered back and forth a few times before moving all the way and settled down…all the while the PHD2 DEC guiding error remained very small.
Let’s see the results!
Hopefully you can zoom in on this graph. PHD2 Guiding was taking 2 second exposures during this backlash event. The green pen is the output from the Backlash Model. For this event I was using a backlash size of 56 arc-seconds (+/-28 arc-seconds). The red pen is the DEC Guiding Error calculated by PHD2 and acquired via the PHD2 server. The dark blue pen is the DEC Position feedback provide by the ASCOM connection to my CGEM mount. The light blue pen is what I call the Culmulative DEC movement which is a visualization tool I use to keep track of the DEC axis positioning caused by PHD2 Guiding. This signal needs further explaining…
The DEC Position feedback provided by my Celestron CGEM is generating by the pointing model in the CGEM firmware. Every mount utilizes a pointing model to position the mount. There are always small errors in these pointing models and, when studying movements at the arc-second level, it is common for the DEC axis feedback value to slowly drift upwards or downwards even though the DEC motor is not turning.
Because of this drift I chose to focus on the DEC guide pulses being used. I use a DEC Guide speed of 50%. This means that whenever a DEC guide pulse is active the DEC motor will be rotating at 7.5 arc-seconds/second. The Backlash model generates it’s output by tallying up all of the guide pulses(from PHD2 and from my program) and rescales them so that one second (1000mS) of guide pulses equals 7.5 arc-seconds of DEC axis movement. If you compare the DEC Position feedback(dark blue) with the Backlash Model(green) you can see that the backlash movements are very close to the same magnitude. This gives me the confidence to say that using guide pulses to determine position movements is a useful method.
The Culmulative DEC movement signal(light blue) is derived solely from the DEC guide pulses generated by PHD2 Guiding. It’s a very convenient way to visualize how much DEC movement is being caused by PHD2 Guiding. For this specific example: At 20:32:00 the Culmulative DEC movement started off at -11 arc-seconds and lowered to roughly -17 arc-seconds during the initial DEC backlash event. The Backlash Model Output indicates a total DEC movement of roughly 55 arc-seconds. This means that the DEC axis moved 55 arc-seconds but PHD2 only had to issue approx. 7 arc-seconds of DEC guide pulses. The DEC Guiding error barely reached 1 arc-second. At 20:40:00 the DEC axis experiences a Backlash event in the opposite direction. A more significant DEC Guiding error occurred which explains why this recovery is much faster acting.
Just before 20:46:00 there was a DEC Guiding Error spike of 2.5 arc-seconds. The Backlash Model signal indicates that the backlash is fully taken up so it did not permit any additional guide pulses. The Culmulative DEC movement signal shows a 2.5 arc-second correction which indicates that PHD2 was able to take care of this small event without any assistance from my program.
Here I show the DEC Guiding Error as recorded by PHD2. The three events discussed here are indicated by the red arrows.
I use my Backlash Assistant program whenever I am imaging. I have yet to invent an automatic adaption function for my backlash model which could increase or decrease the backlash size if needed. I suspect that the backlash size does change over time. I have also seen large changes in the backlash size whenever I have made mechanical adjustments to reduce DEC backlash.
Peter