Using CCDOPS with the LX200 by Bruce Johnston

Using CCDOPS (With the LX200)

by Bruce Johnston

Please keep in mind that in the following discussion, what is said was specifically aimed at a permanently mounted LX200, being used with an ST-7/ST-8/ST-9, with CCDOPS software.

Most of what is said, however, will apply to other cameras, other scopes .... and even other image acquisition software .... by modifying the information accordingly.

The Preparing of the scope

Over time, I've been investigating the R.A. drive system of the LX200 as well as doing quite a bit of experimenting with CCDOPS. I still have more information to gather about the R.A. drive.... to be discussed in detail at another time and place ... but I've discovered enough about it to come to some reasonable conclusions as applies to CCD guiding of the scope. Here, however, I'll explain enough so that the techniques I use make sense.

I've come to the conclusion that the weakest point for accurate tracking on the scope is in the gearbox. Naturally, the worm and worm wheel could use improvement and are factors in PEC training and guiding, but I believe that the weakest spot is in that small gearbox. Now, YOUR scope may be just fine. If so, you probably don't need the information given here.

That having been said, one of the things I've confirmed is that loading the fork with weights to make the scope want to rotate in an Easterly direction will aid in the drive operation and guiding, primarily due to `gear slack' between the gears in the box. The only modification I'd make to the suggestion is, use more weight than is usually recommended. General wisdom suggests that the weight be added to the Eastern fork; just enough to make it barely try to fall to the East when the R.A. lock is loosened. I recommend that the weight be enough to make it significantly want to rotate East.

Because of `gear slack' of the gears, on a well-balanced scope, the gears in the gear box can and will, quite literally, stop for brief periods of time, then race to catch up! Needless to say, this has a very bad effect on the accuracy of the drive system overall. By weighing the scope to the East, you are adding some extra friction to the worm/worm gear mating surfaces. This friction adds load to the gearbox, to help keep the gears from developing the slack mentioned. (This is a poor method of loading down the gearbox, but at the present time, it's about the only method available.

Now, don't think that this pausing of the gears is the only problem with the gears in the gear box. Far from it.

As a rough guide, I have a weight of about three pounds attached to my East fork. Much more and you begin to possibly overwork the scope drive if the scope has a lot of accessories on it. Much less and you won't create enough friction in the worm/worm gear combination.

Even when the scope is weighted to the East, the benefits of the weight offset become almost negligible when the scope is aimed down to within 45 degrees of either horizon.

DO, however, balance the scope in DEC. The same gearbox problems exist there, but little can be done to compensate for it here. In DEC, the scope may have to correct in both directions, so if you weigh it down to help in one direction, you make it worse in the other direction.

Next item, do your best to polar align. There is more involved here than field rotation, as you'll see.

Mount the camera to the scope in such a way that the camera is truly parallel to the RA axis of the scope. In spite of what SBIG says about being able to just be `close'... within 30 degrees or so... get it PARALLEL! `Close' is pretty good, but it also results in `pretty good' tracking. Certainly not GREAT tracking.

At this point, I'll side step and describe the method I use for quickly mounting my camera to my scope and getting it parallel. You may not want to do this, but I'll describe it anyway.

I went to a local hardware and bought a very inexpensive, plastic level about six inches long. The three `bubbles' in the level just pop out if they're pushed. Each `bubble' is about one inch long. I then glued one to the top of my camera on a nice flat side. Then I ignored it.

I mounted the camera to the scope in the usual way, found a reasonably bright star nearly anywhere in the sky, centered it on the imaging chip, and focused it. Next, I just moved the scope in RA in both directions. I watched to see if the track of the star appeared to be parallel to the display window in `Dim' mode. If not, I tweaked it until it seemed to travel across the box in a nice, parallel fashion.

Once it appeared to be okay, I made sure I was in unbinned mode and I selected to do a `Calibrate' of the camera, using the imaging chip. I set the calibration time for around 15 seconds. When the first move was done, it told me if I had moved downward or upward on the image. If I had, I tweaked the camera position slightly and did another calibrate.

When I finally reached the point where I could traverse the ENTIRE chip and only go down or up no more than two pixels, I knew I had the camera as square as I could get it.

Using the hand control, I then swung the scope around to where the scope was pointing at zero degrees in DEC, and slowly moved it in RA until the bubble in the `level' on the camera was dead center between its two lines. I immediately turned the scope off. With the `bubble' on the camera dead-center, I took another `level-bulb', put some glue on it, pressed it up against the BACK of the OTA, centered the `bubble' between its lines, and held it in place until the glue dried.

Thereafter, to make sure my camera is mounted correctly, before I turn the scope on, I simply aim the scope manually until the bubble on the back of the scope is level. Then I mount the camera, adjust it until it's `bubble' reads level, and I'm all set!

The reason you want to be as well polar aligned as possible and have your camera as parallel to the R.A. axis as possible, is to allow you to minimize or possibly eliminate any DEC corrections. This, of course, is obvious, but you may not have considered one way of looking at it... or perhaps you have.

Assume you are perfectly polar aligned, but that you have your camera mounted at an angle. This would mean that a truly R.A.-only shift in the guide star would not only be seen as a left/right movement on the guide chip, but would also be seen as up/down to some degree. At least, that's the way CCDOPS would see it. That means that the correction would not only be in R.A... which is all it really needs... but in DEC as well. After all, if the star is moving at a diagonal on the chip, it means that both movements would be detected.

Now, there is just NO WAY that movement on both axes can result in as good of a correction as the single, true, R.A. correction needed. Yet, if you were not well polar aligned, there's also no way of taking an image for any length of time with the DEC corrections turned off. Therefore, the best situation.. in my opinion.. is good polar alignment, a squared up camera, and DEC corrections turned OFF!

On my particular scope, when there is a DEC movement, it causes a slight R.A. shift of the OTA. I think my nylon `bearing' on the DEC drive side is either slightly compressing, or there is front-back wear in it. Therefore, I try to eliminate any DEC corrections if possible. (I need the DEC bearing mod, scheduled for this winter.)

P.E.C. training the scope

I'm assuming that you have trained the P.E.C. for your scope before we move on to the next phase. Use whatever method of training that you prefer; manually or using your camera to do the work. If you'd like to see the method I use for training with the camera, you can check the MAPUG archives under `LX200'.

However, there are two little tidbits as regards PEC training that you might want to know if you didn't already.

First, a person quite often would like to see how the scope is operating before and after training. The standard way to do this is to throw the Polar alignment way off, so as to introduce significant DEC drift, and take an image of a star for at least eight minutes. A sine wave, or even multi-sine wave, image will be drawn by the star as it shifts back and forth in R.A., while slowly traveling down in DEC.

I suggest a method that doesn't require making any maladjustments. Make sure your camera is in the high-resolution mode for this. Locate a fairly dim star on your imaging chip. Move the scope until the selected star is near the top of the chip. Then, start a `grab' of an image for at least eight minutes. As the exposure takes place, once every second, just tap the `down' DEC button briefly. You can use the timer that runs during the grab, to time each second. This will result in a similar type of image, but no adjustments are lost. After PEC training, you can repeat the process to get an image that shows the improvement you've made.

The second point I'd like to make has to do with a question I've been hearing for several years now. "Is it better to guide with P.E.C. turned off (untrained)? Do P.E.C. and the guide camera `fight' against each other?" You can try it and decide for yourself, but I did quite a bit of comparing the two situations, and in every case, having P.E.C. on (trained) always gave a better guide than when it wasn't trained, even when the training wasn't very well done. Sometimes, such as when the technique I'll be recommending is used, the difference wasn't as great, but it still was always better when trained. For what it's worth.

The CCDOPS variables

Actually, there only a very few variables used in CCDOPS. It's a wonder that so few values can cause so much mystery. But I can say for certain that they truly had ME going! I think it's because I was trying to give them much more power and complexity than they actually have.

Let's cover them in order and see what they do... and if we even ever NEED them. To access them, you'd select the `Track' menu and then `Auto guide Parameters'. These parameters are listed as for the `Auto guide' operation, but the program makes use of them during self guide, as well.

Active Directions: These choices are probably well known to all CCDOPS users. They simply specify which directions, if any, will be allowed to move the scope. As I said earlier, if possible, use ONLY the one that represents the R.A. drive. For a camera that is mounted `normally', this would be the `X' direction. If the camera is rotated 90 degrees either way, R.A. is controlled by the `Y' direction.

There actually is a purpose for selecting the `none', by the way. If you wanted to plot out a graph of what the camera controls would do if they were active, you'd select this. An example would be if you wanted to create a `Track Log" of what the scope is actually doing on it's own with no help from the program. You could `pretend' that the program is controlling the scope and save a record of what it would have done. The log, when converted to text file and loaded into a program such as Excel, can provide a graph of the moves the camera would have had to make. It tells a person a lot about how the scope is performing. I've used this feature a lot of times in my studies of how things work, and I used the feature to create the graphs used in this discussion.

Aggressiveness: The most confusing, and the most useless, of all of them! (I bet this statement gets a LOT of peoples' dander up when they see it!) To quote what someone at SBIG once told me, "That was the biggest mistake we ever made with CCDOPS; putting in `aggressiveness'". And I fully agree with that statement.

What this is supposed to do is to allow a person to change the values of some of the other parameters by changing only this one value. And that's about as clear as the manual also says it. Unfortunately, what is being changed, by how much, and why, has remained the big mystery. My solution? Learn what the other variables do, set this value to 10.... then forget it even exists!

Relay +X: This is the value that was calculated during your last `Calibrate' operation. It's the result of having had the Calibrate routine detect where the brightest star in the image is, then moving the scope for the time you specify, and seeing where the star ends up. From that figure, it can calculate just how long it takes to move a particular distance. The time it takes to move this particular distance is the value stored in this field when the star moves to the left.

For instance, let's assume you used the guide chip for doing your Calibrate. Let's also assume that you told the program to move the telescope for 8 seconds. First, it detects the centroid of the brightest star in the star field. Then the program moves the scope for 8 seconds. At the end of the 8 seconds, it again finds the brightest star in the star field on the guide chip. In this hypothetical example, we'll say the movement in those 8 seconds was 72.7 pixels. A quick calculation of the movement time divided by the number of pixels, and presto! You'd have the rate of movement of the scope, which is roughly .11 seconds per pixel. But rather than store this figure, instead store the time it took to move, say, 50 pixels. In that case, the answer can be stored more accurately with fewer digits and the answer would be 5.50 seconds. So long as the program always uses the number of pixels as 50 for its calculations, there's no problem. It can easily calculate the movement time down to hundredths of a pixel.

Actually, I believe that a larger number was used, simply so that the user could deal with changing the values easier (And by golly, you just may want to do that!). Otherwise, it could just store the value of .110041265 .. the more accurate time for one pixel movement ... and let it go at that.

Relay -X: Same thing as the +X time, but calculated when moving in the opposite direction.

Relay +Y: Relay -Y: Once again, the same thing as the `X' movements, but in the DEC direction, assuming you don't have the camera rotated 90 degrees.

Minimum move: The manual says that this should be set to the shortest amount of time that you ever push the correction button when guiding. They all recommend a value of 50 be entered (50 milliseconds) and leave it at that .

A quick calculation shows that 50 milliseconds of movement would result in approximately .75 arc-seconds of DISTANCE. (FINALLY, a mention of DISTANCE!) The calculation is based on the fact that there are approximately 15 arc-seconds of distance covered in one second of time at Sidereal rate.

Sounds good, but not necessarily good enough, as we'll see.

Maximum move: The manual says to set it for the longest time you would hold a correction button down. There is also a general recommendation of entering somewhere around 500 to 1000 milliseconds. That's a lot of movement! We're talking about moving up to 7.5 to 15 arc-seconds as a maximum move! Maybe, just maybe, we can come up with a more personalized value for this variable.

Track time: This variable isn't really one of the `Auto guide parameters', but is in the `Self Guide' option itself. It plays an important part in acquiring a self-guided image, so I added it to the list.

One very important fact about this option should be understood. It may be quite obvious to most people, but I want to emphasize it nonetheless. When a particular time is selected, it is assumed that the guide chip is read out on these intervals and the new centroid calculated. If you have a fairly long track time selected, you can pretty much use that idea. But if your track time is very short, the difference becomes significant.

For instance, assume that you have the camera set up to update every .25 seconds. Then, assume that it takes, for instance, .2 seconds to make a correction that it just detected was necessary. The next update of the tracking chip won't be .25 seconds after the last one began, but .25 seconds + .2 seconds later. The point here is that the program won't look for a new position of the guide star until it finishes actually making the correction that it detected as being needed. This extra time can become very important under the right circumstances.

The LX200 drive revisited

Before getting into gears and graphs and things, I suggest using a very good way of watching what's going on with your scope and what it is that you're fighting when you're doing a self-guide.

Aim your scope at some pretty bright star and center in on your imaging chip, using the `Focus' option. Make sure your camera setup shows that you're not operating in any binning mode.
While still in `Focus' mode, select the `Planet' mode of display and be sure that you have `Auto contrast' turned on. Also, have the update time set for as fast as possible (.11 seconds).
After the full screen displays, use the selection box to just surround the star you've selected. Make the box is as small as possible and still enclose the star.
Select to run.

Now just sit there and watch the movement of the star. It will hop around, for sure. Some of it might be because of the seeing, but much of it is because of the drive mechanics of the scope. Just watch it for a while. See how the star will hop left, then right. It goes up, then down. (That part is most likely due to the seeing, because we're not driving the scope in Declination. It's therefore, a pretty good indicator of your seeing at that particular time.) You may see the star hop by several pixels at one moment, and by a small portion of a pixel the next. Notice that in many cases, the `hop' to the left is followed by a `hop' to the right, bringing it back where it belongs, and other times it just stays off. That's what your camera and software are fighting when self-guiding!

An extra side point to what you're watching: If the star has a general tendency to slowly work its way to the left or right, your scope is NOT running at the Sidereal rate. This can be caused by the training of the P.E.C. or even by where you're located on the R.A. worm gear.

You should watch the star quite a long period of time, however, before you decide that this is the case. There are some much slower variations taking place that might not be apparent except over a period of minutes. Again, these gradual variations could be the result of either the worm/worm gear, or a periodic error from gears in the gear box drive. (Yes, there CAN be periodic error from spur gears, especially the way that the ones in the gear box are used.)

If it's caused by where on the worm gear you're operating, you may wish to go to my discussion on how to make sure you're on the `sweet spot' of the gear. For that, you can visit:

<http//www.mapug-astronomy.net/ccdastro/goto.htm>

If it's drifting because of the P.E.C. training, it means that it required more `left' than `right' corrections or vice-versa. In that case, you can get the star to stabilize on the screen by going to the `Clock' setting and changing it from the `60.1 Quartz' mode to slightly faster or slower, whichever is needed.

Watch the movement of the star for a period of time, until you have this erratic `hopping' of the star fixed in your memory. It'll make the rest of the discussion much more meaningful.

If you don't see the `hopping', you're one of those rare people that has an LX200 with an exceptional drive system, and you don't NEED this discussion!

This is a typical graph of the movement of a star in R.A. as seen by CCDOPS when tracking on a typical LX-200. It's basically a graph of what you saw the star doing if you watched the star as suggested, after having P.E.C. trained the scope. Notice that it hops up and down (left and right in R.A.) on a semi-regular basis. Sometimes you see what appears to be an over-correction or under-correction, and other times it seems to correct itself nicely from the erratic spikes. Actually, you'd see a similar spiking and peaking on an untrained and unguided star, so that would eliminate the likelihood that it's due to camera over-correction. Nonetheless, regardless of where the spikes come from, they certainly would cause a star to be oval or streaked shape in the R.A. direction if it isn't corrected somehow.

Next is a section of the graph for R.A. movement over a much shorter period of time. Once again, you can see that there are areas of swing in one direction, followed by swings in the opposite direction. In some cases, the swing is back toward zero, and in others, it swings beyond zero and overshoots. If this represents an area of time on a scope that has not been P.E.C. trained, then it represents mechanical movement only. If it's from a P.E.C. trained scope, it's a combination of both mechanical movement and training. Either way, this is typical of what you might see by watching a star move when doing unguided exposures.

This may or may not be bad, since there is neither time nor distance representation on the graph. It might represent a total swing peak-to-peak, of only a small fraction of a pixel and a time of one revolution of the worm. If so, the scope is operating nicely. One thing is almost guaranteed, however. If you wait until this section of the drive repeats, it will GENERALLY have this shape, but it won't be anywhere near to being exactly the same.

This graph is similar, except some arbitrary values have been assigned. The up/down values now represent a movement of .5 pixels for every division and the left/right major marks represent that the image was sampled each second, and at these times.

Two things should be apparent when the graph is examined. First, the errors between the sample times are going to be there whether or not we sample the image and correct it. Since these peaks and valleys aren't being sampled and corrections taking place, they won't be affected.

The second thing to notice is that the first two samples read the fact that the centroid is quite `minus' in location (meaning that the star is either off to the left or right, depending on the orientation of the camera), and if we were to correct for their location, we'd be correcting in the SAME direction that the scope is going to move on its own! That means that we'd end up in an OVER correction, since both the mechanics of the scope and the correction by CCDOPS are going to work together.

Now, this still may or may not be significant. After all, we still don't know how much movement a `pixel' amounts to. It may be fine or it may be disaster!

Finally, here's an approximation of the resulting movement of the scope. Actually, it's off by even more than indicated because the first correction isn't shown in the chart. Naturally, the corrections wouldn't look this extreme, but it's just meant to show the correction of the program ... in concept ... and how much it would add to the swing.

Still, you can see that because of the fact that the camera correction and the scope itself, were both moving the scope in the same direction, the error created a worse condition than if it hadn't been corrected at all.... at least for a period of time.

Once the first correction took place, all other corrections would be based on where the centroid of the star would be, AFTER the correction. The graph previous to this one can not be used because the star will have been moved to a new location.

Modifying the variables

Now it's time to see how to modify the various settings in CCDOPS and when to do so. However, as we look at the variables it is VERY important that you keep one fundamental fact in mind. The camera and software .. or the person doing manual guiding ... do NOT cause the scope to run FASTER nor SLOWER! The LX200 corrects at 2X sidereal speed. More accurately, it causes the SCOPE to run at 2X sidereal speed. The corrections themselves are AT Sidereal speed. What the program or human does, is to CAUSE a correction, and make the corrections SHORTER or LONGER in TIME!!

Relay +/-X, +/Y: You went through the typical training session of the scope, calibrated the camera, and now you're about to do a self-guide of an image. You're watching the corrections take place before you actually begin the exposure session. (An excellent way to see how the camera and scope are working together, by the way.) After a period of time watching the values go between a plus and minus value, you come to the conclusion that the camera is over-correcting. You see that most of the time when it corrects, it seems to end up significantly beyond zero pixels and is off in the opposite direction. But how to correct for over-correction?

Remember that earlier we said the function of the calibrate routine was to establish how the camera controls scope movement. It moves the scope for a certain time, and then it looks to see how far it moves the scope. It then stores a `time' value for the program to use when calculation how long to move the scope for ANY distance. Time and distance. Time in seconds, distance in total pixels moved. All it needs to know is, time in seconds, and pixels or fractions of pixels moved or to be moved.

If the camera and program are truly causing the scope to overshoot, that means that the calculation was wrong. This can happen for various reasons, but the real question is, what can be done to correct the condition?

We'll assume that the calibration routine decided that it took 10 seconds to move `X' number of pixels, and that's the time value that was stored. But we just decided that the scope is being over-corrected, so the number is wrong. Furthermore, we know that it's moving the scope LONGER in time than it should. The calculated value is too LONG in time! We can correct it by changing the +/- X values to a SHORTER time, effectively telling the program that it can move the distance of `X' pixels in less time.... which it can! Now the program will move the scope for a shorter period of time, which will reduce or eliminate the overshoot. How MUCH do we change the value? It's a matter of some experimentation. Probably a good starting point would be to reduce it by 20% in each of the two directions, which means changing our hypothetical time of 10 seconds down to 8 seconds and see if we like the results.

Naturally, if it appears that the corrections are under-shooting, you would have the reverse condition, and you'd LENGTHEN the correction time. In this case, to perhaps 12 seconds.

The real benefit of applying the corrections at this level is, you can modify an over or under correction that's happening in only one of the two directions, or if it's happening by different amounts in each direction. Any combination of over or under correction for EITHER direction can be modified by changing these variables accordingly.

Likewise for DEC over or under corrections, except you'd change the +/- Y relay values.

Personally, I'd prefer to have an under correction than an over correction as a beginning point, but it's rather difficult to be sure you're truly over or under correcting when you first begin playing with the variables. Therefore, when in doubt, I'd recommend you assume that the time values are correct. The fact is, the values calculated aren't usually very far off from optimum.

Minimum move: There's another fact about this variable you should be made aware of. Whatever value that's used here, if the correction calculates out to be less than this value by the program, NO correction will take place for it. What you'd see, however, is simply the amount of pixel size, rather than the time, and there just would be no correction taking place. It would show "integrating" and wouldn't show "correcting" for that value. This may help clear up why it is that you'll see values showing up without being corrected. I always wondered what was going on when I saw that, and I know. You also now know, if you didn't before.

My experiences with this variable have shown me that, for my particular case, it was better to use a somewhat longer time than the default 50 milliseconds. I found that at the lower figure, I wasn't getting optimum correction. Very possibly it was because the scope didn't respond well for this short of a time. It also could be that for my typical `seeing', I was chasing the star too much. I found that if I used a value of 80 to 90 milliseconds, there was a significant improvement in the resulting correction. Any value much greater than this, and too much error got `bypassed'.

This, of course, means that any error that was less than around 1.2 arc seconds wasn't corrected for.

You may well find that for your scope and seeing conditions, you should increase or decrease the value somewhat, but I'd say that my values are a very good starting point.

Maximum move: What this variable does, is to put a time limit on how long a correction is allowed to take place. If, for instance, the program determines that a correction of 200 milliseconds is needed, but you've entered a value of, say, 120 milliseconds, the correction will stop after the first 120 milliseconds of correction time.

But an allowed correction of .5 seconds to a second, as the default settings are recommended??? WOW! That's expecting that your scope is in REALLY bad shape, I think! 7.5 to 15 arc second corrections?? If you need to make corrections of that amount, you've got SERIOUS problems!

My experiences have shown me that if I use just slightly less than TWICE the minimum move time, it's pretty close to the ideal compromise. That way, when a condition exists as in the previous graphs, where a major swing from one extreme to another happens, you don't allow the camera/program to swing nearly that far. You therefore aren't so likely to be adding a lot of correction to a swing that's going to correct itself. But you still make reasonable corrections for reasonable values.

This means that my typical settings are for 80 millisecond minimum moves and around 140 millisecond maximum moves. (Actually, I rather prefer 80 and 120 milliseconds for average sky conditions.)

Track time: For this variable, I use a very simple rule, and it always seems to work. USE THE MINIMUM TIME POSSIBLE! If I find that I can get my object on the Imaging chip nicely and still find a decent star on which to guide, I'll go as short in time as I possibly can! Quite often, I'll have the setting down to as low as 20 or 30 milliseconds!

The way I try to do this is as follows:

Using `Focus' mode, `Dim' setting, center the object to be imaged on the imaging chip..
Switch the settings to `Guide chip', `Full'.
Using `Focus' full size and a time of .11 seconds, locate a decent guide star. If necessary, move around a bit until a decent one is found. (I will have a tip on this, later.)
Switch back to the imaging chip and make sure that the image still looks okay.

I then go to `Self Guide' and after having selected the exposure time, I select a guide time of .11 seconds and see what the brightest star on the guide chip looks like. If I can see it plainly, I restart with an even lower guide time. I keep repeating this, lowering the guide time, until I can't see even a hint of the guide star, then I move back up until I can barely see a hint of it. That's the time I use.

You'll find that the program can do a very good job of tracking on a star that you can hardly see at all. I'm very impressed with the program in this area.

By using that basic technique, I can get guide times.. and therefore, update times.. down to extremely small values more often than not.

At that point, I shoot my shots. Simple as that.

Do these values really work? Is it worth messing with? Before experimenting with the variables, on an excellent night I would typically end up with images that had a `FWHM' of about 5.5 arc seconds. Now, on an average night, I can get images with a `FWHM' of about 3.5 arc seconds, and on a really good night, as low as 2.5 arc seconds!! For me, yes, it's worth the effort. (Obviously, I don't live in the ideal imaging environmant!)

My primary goal when I began looking into the mechanics of the scope and also how CCDOPS really worked, was to try to get images with ROUND stars, instead of the typical oval ones that I usually saw. For most of my images now, I get round ones. My belief was, and still is, if you have anything but round stars, then the rest of the image is also suffering significantly in detail, even if it isn't very evident immediately.

Supplemental notes and tips

Pixel size

One of the things not specified earlier on, was exactly how big the pixels are on the guide chip, in arc-seconds. That, I'm sure you would want to know when you see that you're correcting down to a portion of a pixel.

A little bit of trigonometry can tell you, but I'll give you a rule of thumb that will get you close enough for what you'd need to know. The pixel width on the TC-211 chip is 13.8 microns wide and 16 microns tall, so we can use a general guide of saying that for a focal length of 100 inches (2540 mm), a pixel is 1.12 arc seconds wide, and approximately 1.3 arc seconds tall. Thus, to figure the angular size of a pixel for your scope, you can divide 100 by the focal length in inches of your scope, then multiply that number by the width or height in arc seconds just given.

For instance, my scope is a 10", F6.3 scope, which of course, has a focal length of 63 inches. 100/63 = 1.5873. That number multiplied by 1.12, tells me that the pixel width for me is 1.77 arc seconds (1.5873 x 1.12) and has a height of 2.06 arc seconds. ( 1.5873 x 1.3). Expressed as a formula, if you like, it's:

X= (100/F.L.) x 1.12, where:

X= Pixel width in arc seconds for your scope

F.L. = Focal length in inches of your scope.

and

Y= (100/F.L.) x 1.3, where:

Y= Pixel height in arc seconds for your scope

F.L. = Focal length in inches of your scope.

Just so you know how much is or is not being corrected as you see the pixel sizes flying by during a self-guide.

Finding a guide star

This little tip just may save you headaches in the future when you're trying to find that elusive guide star that's just out of sight when you display the imaging chip with the `Focus' mode:

Some night, before you actually begin imaging, but the camera is all set up and the scope is ready, do a `Go To' some bright star. I used Altair.
Center the star on the imaging chip and sync on it.
Switch the display on the scope to the present R.A. and Dec of the scope. (I had to move the scope North to get it down to the guide chip.)
Note the DIFFERENCE in R.A. and Dec between this reading and the one you had for the imaging chip.
This reading is the amount you must move the scope in the OPPOSITE direction in the future, to allow you to see the field of view available for the GUIDE chip, but on the IMAGING chip!

Next time you center an object to be imaged on the guide chip, you can look at the field available for the imaging chip, on the GUIDE chip, plus the area around it when you move the scope by this amount. This will help you to find that elusive guide star that's JUST outside the field of view for the guide chip, plus a significant amount more. Try it! It works!

Extra, extra point: If you're really ambitious, you could do this same thing for ALL of the four camera orientations, and in the future, you could look at the area around the desired object to see which way to turn the camera, in order to be sure to be able to have a guide star. Sure beats having to rotate the camera every time, then try to see of you'll be able to use the new orientation.

Aligning the camera to the scope

Earlier in the discussion, I explained about using an inexpensive bubble level for aligning the camera to the scope. It just may be that you also often rotate the camera on the scope, to get a better field for taking images that won't fit when the camera is in its `normal' orientation. In that case, use that third `bubble' that came with the level. Here's the order you'd glue the `bubbles' into place.

Glue the first bubble to the camera, just as explained earlier.
Do the alignment as described.
Rotate the scope until the bubble on the camera reads level, just as before.
Shut the scope off, as before.
Glue the bubble to the scope, just as before.
Rotate the camera to the desired new angle, 90 degrees from what it was. This can be done on a future night if you like.
Go through the same alignment procedure as earlier explained.
Rotate the scope until the `bubble' on the SCOPE reads level, then immediately shut the scope off.
Glue the third bubble on the CAMERA, and hold it in place, with the bubble reading `level'.

Now you're set for quick-aligning the camera to the scope for two different orientations. Quick and easy.

Running `Calibrate' for the scope

There seem to be a lot of problems for running the `Calibrate' command for many people. I have a couple of tips that may help, if you haven't already considered them.

1. If you've done a calibrate already, and if you're using the settings that I've recommended, if the object you want to image is with 30 degrees Dec of where you last calibrated it....... leave it!!! Don't calibrate it again! The difference is negligible!

2. If you ARE going to do a Calibrate, use the IMAGING chip to do it, rather than the guide chip. You'll get just as good of a calibration with it, and it's a lot easier to find a calibration star somewhere near where you want to be, with the imaging chip. You can even find one by just finding a reasonable star in your finder scope and centering it on the imaging chip.

3. If you DO use the imaging chip, you can use a pretty bright star, so it's not so hard to keep other stars that are bright around it from coming into the field of view. Just use a lone, fairly bright star.

4. As a general guideline, on my 63" focal length scope, I tell the program to move for 15 seconds in all directions while doing the calibrate. That's plenty of time, the star doesn't leave the field of view in that length of time, and it's a good number. If your scope is significantly longer or shorter in focal length, you may have to make the times somewhat shorter or longer, respectively, to get a good reading.

5. Contrary to popular opinion, you CAN use a bright star for the calibration. I've often used Arcturus or even Sirius! All you need do is tell the calibrate routine to expose for a VERY short time, but MOVE for a very LONG time (my 15 seconds) and it calibrates just fine.

6. If you DO want to calibrate near where you're going to image, use the `Go To' function of the LX200 to help you find a nice, fairly bright, isolated star to use for the calibration.

A. Do the `Go To', and note which star number the scope uses for helping to locate your object. Then CANCEL the `Go To'!

B. Do a separate `Go To' to this star number.

C. Center this star on the imaging chip, use a short exposure time but the longer calibration time, and presto! Easy calibration!

Taking an unguided image

Earlier, I suggested that you watch the star on the imaging chip before going on with the rest of the information. I also said that it just might be that you'd have to change your scope drive rate to keep the star from drifting out of the field of view over time. If you're going to take unguided images using the `Grab' option, you should also use the idea of watching the star for drift before you do. This just may allow your unguided shot to be better, because you'll have minimized time drift. You'll still have the `hopping' of the star during the shot, but at least you'll have minimized the long-term drift.

Once again I want to say that the long term drift may well be to periodic error of the worm/worm wheel, or drive problems within the gear box. These can all add together to create a back-and-fourth drift that can't be eliminated by increasing or decreasing the drive time. If that's the case, your unguided shots are going to be limited in time, indeed. I've found that self guide, even for relatively short periods of time, is better than unguided shots, even under great conditions. An occasional `bump' back to the proper place during self-guide, can fix the various drifts that you find during unguided shots.

Drift method, Polar alignment test

I'm fairly sure that a lot of people know about this simple idea, but I'll pass it along, just in case. If you want to check how much drift you're getting after having made one of the alignments for the drift method, don't spend your time looking through a Barlow at a crosshair eyepiece to see how you've done. Instead, put your camera/scope into `Self guide' on a star near where you wish to check. Select to correct in R.A. only. Then, having selected any time you'd like, for an exposure time, start guiding. Don't at any time, let the image begin to be taken.

When you begin, note how much your Dec correction is off. It should be pretty close to zero pixels. Later, come back and see how much you're off in pixels, on the Dec reading. This will tell you how much drift you have North or South, down to arc seconds!! That's a lot more accurate than just thinking to yourself that `the star was still near the crosshair' or something like that.

No big deal, but I thought I'd pass it along.

A Closing thought

One experiment I've just begun, is to see just how beneficial it might be to use the camera and do a `P.E.C. train' on a star nearby where I'm going to image. Actually, just doing an `Update' is what I've begun to try. Furthermore, I've begun doing this update at a VERY fast rate, similar to what I use for guiding when I can. I then follow it up with a `Calibrate' on the same star. Finally, I begin my exposures. The results of this experiment are far from in as yet, but I will say, the result so far, is.... interesting.

I'm sure that there are many more tips that will come to mind at a later time. If so, I'll do my best to add them to the list. This is a good start, I think.

Supplemental notes as of December, 2001:

Long after I completed this writeup, I continued to do a lot more investigating of the various subjects. One thing that I've discovered over time, is that if a person uses the various settings as I suggest, there is only one reason for having to do a 'Calibrate' operation after the first one! That reason would be, if you change the camera orientation by 90 or 180 degrees, so that the program can determine the directions the camera will move when given a '+X', '-X', '+Y' and '-Y' direction-move command.

I've also found that, for me, when I image, the ONLY variable I've needed to change is the 'Maximum Move' variable. I may slightly modify this value from night to night, depending on various environmental conditions I have, such as 'seeing', etc. Even then, however, any value changes are quite small.

Even if I switch to a focal reducer or a Barlow, I end up using all of the same values as I listed earlier. After all, 50 milliseconds still represents about .75 arc seconds, and that's a nice lower limit to tell the LX200 to correct for. Likewise, 120 milliseconds for a MAXIMUM move, is still about 1.8 arc seconds, Barlow or focal reducer installed or not, and it seems to be a pretty good value to keep the scope from over-correcting when the quick 'hops' happen to manifest themselves.

These statements fly in the face of many, that recommend doing a Calibrate operation, on a star near the image to be acquired.

In short, once you understand how the various variables will effect the guiding, you can pretty much select your optimum settings in a matter of minutes, worst case, no matter where in the sky you're getting the image. That certainly makes CCD imaging a lot less painless, compared to what it probably was before you read this article!

I hope this discussion helps someone to get a better handle on their LX200 and ST-7/ST-8/ST-9 when using CCDOPS. Clear skies, and....

ENJOY ASTRONOMY!!!

Bruce Johnston

Return to homepage