What's Wrong with the Celestron CGEM Mount?

Greg Marshall, 9/12/11

Figure 1.

When I first bought a CGEM in the summer of 2009 I started writing a review immediately, but soon ran into problems that prevented me from doing a complete review. 18 months and several round trips to Celestron Tech Support later, I finally knew exactly what the problem was. This is not so much a review of the CGEM as a detailed analysis of that problem. Little else about the CGEM is surprising – its performance is very similar to other modern mounts in the same price range, such as the Orion Atlas.

First, let me tell you that I got into astronomy specifically to do astro-photography starting in 2005, having been an avid photographer for decades. I am also an electronics engineer (now retired) with experience in electronic imaging and image processing. I have no connection with Celestron or any other manufacturer or vendor of astronomy equipment. Prior to the CGEM I used a Losmandy GM-8, which I liked fairly well, but it didn't have the load capacity I needed. I also used an Atlas mount for several months while the CGEM was being studied and repaired. I have owned a half dozen different scopes, mostly small refractors, and currently use an AT111EDT. My home is near Portland, Oregon, where it is cloudy much of the time, but fellow astronomers are very friendly because misery loves company.

My initial problems with the CGEM were all about DEC guiding. Using the popular “PHD Guiding” software, DEC guiding was often erratic and sometimes it seemed that the mount was simply not responding to DEC guiding commands at all, even though RA guiding worked fine. After eliminating the possibility of software and electrical connection issues, I reasoned that the problem must be due to backlash. However, since drift from mis-alignment is constant, the backlash should eventually be taken up and guiding should then proceed correctly as long as the direction doesn't change. The CGEM has an anti-backlash feature , but it only comes into play when the direction changes, which is almost always due to spurious errors such as seeing or wind pushing the scope.

Figure 2.

Because my CGEM had a great deal of backlash in DEC (resulting from very loose meshing of the worm gear and worm wheel) and because I had not adequately quantified the problem at that time, I sent the mount back to Celestron for adjustment. It is possible (and fairly easy) to adjust this gear mesh yourself, but Celestron discourages users from doing so and since I was less than thrilled with the performance of the mount I did not want to risk voiding the warranty.

When the mount came back there was no improvement in the guiding performance, but there were some new issues. To keep this short I'll skip over the irrelevant trips to Celestron Tech Support and simply tell you that they never did fix it. After 3 returns they replaced the mount head, but the new one had exactly the same problem. After struggling with it for 18 months I finally opened the thing up and started studying how it works. One of the reasons that I chose the CGEM over its cousin, the Orion Atlas, is that it uses servo motors rather than steppers. In theory, a servo should provide more precise control of position because it is dependent on the precision of an optical encoder rather than the mechanical characteristics of a motor. The Atlas, like other stepper-based mounts, uses “micro-stepping” to get finer increments of motion. However, dividing a single step of the motor into 64 micro-steps only works as well as the windings of the motor are matched – typically far less than 1/64^th of a full step. Ironically, the problem with the CGEM turned out to be directly related to the servo motors and you don't even have to look inside the mount to see it. Using the hand controller, select “GET RA & DEC” from the main menu or “GET AXIS POSITION” under the “UTILITIES” menu. Set the slew rate to 1 or 2 (0.5X or 1X sidereal rate, the kind of rate you would use in guiding) and press the north or south button for about half a second. Normally, the DEC position will change by a few arcseconds. But if you continue short steps in the same direction, you may find a point at which it will no longer advance. The numbers might change a bit in response to pressing the button, but then come back to about the same value. The same thing happens when you are trying to guide. The result is that if you limit the pulse to half a second (500 milliseconds) and keep going in the same direction it will never get past this “bad spot”. I looked at the drive signals to the DEC motor and saw that each time I pressed the button the motor would be driven, but then the voltage would go to zero, even though the position slipped back. This is not how a traditional servo system works and for a while I was very annoyed that my problems seemed to be the result of faulty firmware.

There are two different mechanical problems that could cause this behavior. The first is simply binding of gears: Some gear downstream of the motor could have a rough spot that causes it to bind – or just have a bit more friction at a certain angle. The other possibility is “cogging”, the tendency of some electric motors to magnetically favor certain positions over others. Celestron claims to use “low cog” motors in the CGEM, so I was inclined to think it was the gears, but recently, another CGEM user took apart a motor/gearbox and found that the motor has quite visible cogging.

This is (potentially) good news because fixing the firmware to drive the motor with just enough current to maintain the position as indicated by the encoder would likely make a vast improvement in the case of cogging, but it wouldn't help much with bad gears. With either of these mechanical problems the result is the same: The controller thinks it has moved the mount on each pulse, but the telescope doesn't actually move at all. Eventually, the error is large enough (the motor is driven hard enough) that it gets past the bad spot and the telescope can move again. PHD has a parameter to limit the maximum duration of guide pulses and the default value is too small to allow the CGEM to overcome the cogging. You can increase the parameter (2000 milliseconds should do it) to avoid getting completely stuck, but that just means that it will drift until the error gets large, then correct all at once. For anything more than a wide angle camera lens, this jump in position is too great and will ruin the exposure.

Figure 3.

I have tested several CGEM mounts as described above and found that the problem is quite common, but not universal - some CGEMs work just fine. In my case I found that the motor on the RA axis worked fine. Since the motors are identical and the problem only affects the DEC axis, I swapped the motors and finally got a mount that worked well for astro-photography.

Please note that the problem described above relates ONLY to guided astro-photography and only to some samples of the CGEM. A visual user would never encounter this problem at all.