This post is a follow-on from my previous one, which talked about the basics when upgrading your mount from a Start Adventurer (SA) to an AZ-GTI running in equatorial mode. This one covers the whole business of autoguiding. To put this article in context:
- You have come from
- a simple single-axis mount relying entirely on physical polar alignment for its unguided tracking accuracy, enacted via a polar scope, and which uses ST4 guiding, to:
- a dual axis GOTO mount with no polar scope and no ST4 port.
As a result, there are two concepts you need to get to grips with. First, drift alignment, using one or more of the several tools available, and second, the wonderful world of pulse guiding. Let’s start with pulse guiding; I’ll come back to polar alignment later. A fundamental difference from ST4 guiding is that with pulse guiding you can calibrate once, at an optimum place in the sky, and then guide elsewhere, at your target. This means that the mount control system needs to communicate with the guider, in order to adjust the calibration for different Declination values. Right away, that rules out Synscan running on a mobile device (unless someone can tell me otherwise), which is a shame because I love the Synscan app!
With pulse guiding you will need a mount control system that uses an INDI or ASCOM (Windows-only) driver. NINA is perhaps the best known ASCOM-based system and Kstars/Ekos the best-known ‘other’. Kstars is the planetarium/GOTO part and Ekos the underlying controller for connecting equipment, aligning, focusing, guiding, image capture and scheduling, but you don’t have to use all of it. I use a Raspberry Pi as the mount controller and Pi OS (formerly Raspbian) is a Linux variant, so for me it’s got to be KStars/Ekos. If you are using an ASCOM-based system, don’t stop reading, because I’m not going to get into too much detail and much of my journey will still be relevant to you.
This is not going to be a tutorial on setting up and operating Kstars/Ekos, because there are plenty of those online. The key thing is that you need the EQMOD driver, and when creating your profile, select ‘AZ-GTI Equatorial’; EMOD supports many Skywatcher mounts. You’ll need to have Ekos running before you start PHD2, otherwise PHD2 will not be able to connect to the mount. Ekos has its own internal guider too, but I have not used that. To enable Ekos to communicate with PHD2, you’ll need to activate the server in PHD2.
The guide scope needs to be pointed roughly in the same direction as the camera. You can then calibrate at a point close to the N-S meridian, at an elevation of 90o minus your latitude, which gives maximum start movement in both RA and Dec. PHD2 then allows you to inspect your calibration data, so you can redo it if no good. You may then slew to your target, restore that calibration and start guiding. You only really need to redo calibration if you move the guide camera. In my early attempts I was getting a lot of guiding problems, with generally poor calibrations and then sudden guding aberrations every 30 seconds or so. This turned out to be for a combination of reasons:
- Poor guide scope fitting – there must be no flex between it and the mount.
- Various mechanical wobbles on the tripod – mainly with me trying to be too clever.
- Mount backlash.
- Sub optimal guiding settings.
- Poor polar alignment, which meant that the guiding system had to work harder.
Guidescope fitting. If you are using a telescope, you will have a nice guide scope of finder mount on it, and that’s undoubtedly the best place for your guidescope. However, if you are using a long camera lens like me, no such bracket exists. The attached photo shows my current setup. You can see my two finders, on a homemade bracket attached to the camera’s hot shoe. I’ll come to why I still use those later, when talking about polar alignment. My first attempt had the guidescope replacing the optical finder, which arguably is a bit of a luxury anyway. This was a bit of a disaster; that flimsy mounting arrangement might be ok for finders, but definitely not guidescopes. You can see from the photo that it’s now mounted upside down on the dovetail bar mounting the camera. This works fine, but does have the disadvantage that I can’t get to targets with a Dec lower than about -10o. From my location, that’s not actually too problematic. Imaginative readers will I’m sure be able to come up with alternatives. You can see a small bracket on the counterweight bar, above the weights. At one point I tried fixing the guidescope there, but with the mount tilted over with the counterweight bar close to the horizontal, the guidescope’s weight did have a tendency to unscrew the counterweight bar!
Regarding tripods, just make sure you have a good one. I quite like vintage ones, which are often built like rocks. Mine is a Japanese Velbon VGB3 (I think sold as a VS3 in the US) from the 1970s or 80s. In particular, if you are using a photographic tripod, get one with a pan-tilt head rather than a ball head if possible. My ‘too clever’ moment was adding a tripod leveller below the wedge, for finer altitude adjustment when polar-aligning. It was great at that, but significantly reduced the firmness of the overall setup (it was quite cheap!). Now removed.
Backlash. The AZ-GTI is a budget GOTO mount, which suffers from quite poor backlash in both axes, but this can be coped with. If it is so bad that you can physically wobble one or both axes with the clutches tight, then there are videos on Youtube showing you how to fix that. However, even if that’s not the case, the backlash (mainly Dec) may still pose a potential problem if you are aiming for guiding errors in the region of 1 arc second. The best solution is simply to put the mount slightly out of balance on both axes. Conventionally this is camera-heavy in RA and camera-end-heavy in Dec.
On to guide settings then. A great discovery was the PHD2 guiding assistant, under the Tools menu. This actually enables you to measure Dec backlash amongst, other things. It also suggests values for some of the guiding parameters. You are then free to experiment around those values. With a little trial and error you can get some good guiding results. One key setting is the direction of Dec guiding – you have a choice of Off, North, South and Auto. The reason why you might not just leave it on auto, pushing south when Dec has strayed a little North, and vice versa,is backlash. If Dec guiding is set to Auto, it can just hunt within the backlash of the gears, which can leave you with a constant deviation from zero, which never seems to be corrected. If you temporarily set Dec guiding to ‘Off’, you will quickly see which way the Dec axis is drifting and you can set guiding as unidirectional in the opposite direction. This is akin to a car pulling to the right, so you should only ever need to steer left. Personally I haven’t found ‘auto’ to be particularly problematic, but sometimes unidirectional guiding seems to help.
And finally – on to polar alignment, which I promised to come back to right at the start of this article. The worse the PA error, the more work the guider will have to do to keep up, and the worse the guiding accuracy will generally be as a result. The guiding assistant will tell you what your polar alignment error is, and you should aim for something less than 10 arcminutes. With Synscan, Ekos and PHD2, there are no less than five methods of polar alignment available – PHD2 alone offers three of them. Ekos uses a plate solving method, similar to how it does its logical or GOTO alignment. However, whilst the latter is great with a DSLR, the download and processing times of large DSLR images on a small computer (eg my Pi) means that polar alignment using this method is pretty painful. Probably worth a try with a guidescope, but I haven’t gone down that route.
This is what I have found to be both expedient and effective, and yields PA errors of less than 10 arcminutes. As I said in my previous post, polar alignment using Synscan is a joy, so even before switching on the computer running Kstars/Ekos, I do that using Synscan on my mobile phone: a quick 2-star alignment followed by polar alignment on the second alignment star. I suspect that a 3-star alignment with well-chosen stars would probably make this more accurate, but I follow this up with a second method, so that doesn’t really matter. After polar aligning, hibernate the mount in its park position (towards the celestialpole with the counterweight bar vertically downwards) and then switch it off. Why switch it off? Put simply (unless someone can show me otherwise) Synscan and Kstars don’t mix. If both are connected and you execute a GOTO using one, followed by the other, the mount will behave very strangely and certainly not point where you want it to. After restarting the mount, you can now start up Kstars/Ekos and PHD2, and connect everything. I then use the simplest of the available polar alignment methods in PHD2 – the Polar Drift Alignment Tool (under the Tools menu). Unpark the mount and start it tracking and it’s already pointing roughly towards the pole from Synscan hibernate event, which is where it needs to be. Select a star in PHD2, run the tool for a minute or so, and you’ll see a red line connecting the selected star to where it should be if polar alignment was perfect. Stop the tool running and then simply move the star to that location using your wedge controls. You can then re-run to check your accuracy and go round again if necessary. There are several videos on Youtube showing how this works.
You can then slew to your target, run Ekos plate solving and start your test shots. I now achieve guiding errors or between 1-2 arcsec and with a little more practice am fairly confident that it’ll gradually get closer to a consistent 1.0, which is probably about as good as you’ll get out an AZ-GTI. To put that in context, one pixel on my EOS 800D subtends 2.5 arcsec with a 300mm lens.
One final word, on focusing – with DSLR lenses, the INDI Gphoto driver (the driver for DSLRs) can control your lens’s electronic focuser. This may well also be true for the equivalent ASCOM driver, but I don’t know that for sure. This means that in theory autofocusing will work, driven from the Ekos focusing tab. However, I find it a bit slow with large DSLR images and a small computer (Pi) and it’s much quicker to use the manual focus in/out buttons on the Ekos focus tab in combination with a Bahtinov mask, with the camera live-feed set to x10. That way you can get perfect focus without actually touching the lens,and it's pretty quick.
I hope that at least some readers will have found these two posts useful. If you have been on a similar journey, please comment away if you came up with alternative solutions, or even hit problems that I didn’t. Or if you have undertaken the same journey but with an ASCOM-based system.
Clear skies y’all!
Chris
