Please find my general notes on webcam autoguiding here.
I am fundamentally lazy. Well, maybe thats putting it a little too succinctly. One of my principles of astrophotography as a hobby is about time. Clear, transparent and moonless nights are so infrequent these days that any telescope time during favorable conditions should be spent doing one thing, and one thing only - imaging. Time frittered away at the telescope doing battle with focus, dew, finding objects, adjusting this and that, etc etc is time wasted. Time which would be far better spent gathering photons with our ccd cameras, or, on that rare occasion, our eyeballs.
Great swathes of time for do exist. When its cloudy and raining, or, during the summer when proper darkness is just a memory, hours tick by - and its these hours we have to put to good use to keep decent telescope time allocated firmly to imaging.
Anyhow, I digress.
I have a second hand LXD55 mount. On this is mounted my 200mm F5 Newtonian. The LXD55 mount is not great for long exposure work. It has a nasty amount of periodic error, and needs guiding for good results. Being lazy, I prefer autoguiding. Piggy-backed on this is a 400mm F5 short refractor. This has a 2x barlow and an Sc1 toucam on the end to act as a guide camera. The output of the guidecamera is fed via a USB hub to a computer indoors. This computer is running Guidedog. This wonderful piece of free software monitors a guidestar and makes adjustments via an RS232 cable to the Autostar hand controller, and then onto the mount. Using this setup I can sometimes manage over 5 minute exposures with an SC3 camera.
The whole affair has, until now, been crudely mounted on the back of the newtonian with a couple of bits of aluminum that allow me to undo a nut and tweak it a couple of degrees from side to side.
The key with good guiding is to find the brightest guidestar available. This gives a better signal to noise ratio - and the brighter the guidestar the shorter the exposures and the better the guiding.
During imaging the follow was typical
1. Turn on Guidescope camera at 2sec exposures. Note lack of guidestar on screen.
2. Swear. Turn on obs light.
3. Go outside, loosen bolt, slide guidescope a bit to the left. Tighten bolt.
4. Go inside. Turn off light. Wait a few seconds.
5. Note lack of decent guidestar on screen.
6. Repeat until you chance upon a bright enough star.
Now, when imaging in the Milky Way, more often than not, a star is in the guidescope first time. However, when imaging in less star rich regions eg Virgo Cluster, nearly 30mins could be wasted running back and forth. This made for a very stressed astronomer. Stressed astronomers do not take good images.
In addition to all this, my guidescope mount was not the most stable affair. It needed improving. The wobble when slewing could be quite alarming.
Simple. A motorised version of the above process that I could control from the computer indoors. This would reduce steps 2,3 and 4 above to the brief click of a button. In addition to this, I would be able to search back and forth for the best prospective guidestar instead of settling for the first one I find, not knowing if I was going to find another, or return to a good one with the previous setup. A further extension would be the ability to use a more powerful barlow lens, giving a smaller field of view but better guiding. Doubling the barlow with the old setup would have mean it taking at least 4 times longer to find a guidestar!
With the current setup I had about 3 degrees of travel in one plane. I could go left and right, but not up and down (at least, not without fetching a spanner). I would almost always find a star eventually. So I decided I only needed to move in one dimension.
The computer control is not vital - but I am a geek, so I like to do these things. Also, my guiding PC has 3 LPT ports, two of which are sitting around not doing anything.
To start off with I googled around a bit. Somebody was bound to have solved this problem before. I did find one chap who had made some kind of guidescope field de-rotater, but little information on my problem.
After some discussions with Arthur Edwards on the matter, I decided on a rough plan of two sliding aluminum plates, driven by a motor. First up was a visit to that most hallowed of Southampton's shops - The Metal Supermarket. This produced two bits of 5mm aluminum plate. 400mm x 75mm and 400mm x 60mm. These only cost a couple of quid.
With aluminum, its vital to get the best compromise between rigidity and weight. The Metal Supermarket will cut up more or less any type of metal to roughly the size you need - my DIY astronomy has taken me there on several occasions. Lovely people.
These were bolted together at one end to provide a pivot. Mounting holes were made for the guidescope rings, and a slot cut at the other end to allow one to move with respect to the other.
The two plates were sandwiched with 1mm PTFE sheet to minimise friction.
A motor was donated by Arthur. It came with its own gearbox and thread/slider contraption. This was mounted at one end. On applying some volts to the motor, the guidescope moved left and right! Success!
Next I devised a control box. This needed the following features.
1)Two buttons to allow manual "at the scope" control.
2)Microswitches to stop the motor when it reached the "end".
3)Reversing power to the motors via a relay or three.
4)Connection to the computer to allow remote operation.
After much pondering and some blowing up of relays, I arrived at the following circuit:-
There are two relays. One for direction and one for on/off. Putting Pin2/manual left high will fire both relays. Putting pin 3/manual right high will fire only the on/off relay. The Normally Closed connection of the microswitch allows the relay control current to flow - if the MS is pressed, then the current is broken. The Normally Open connection of the MS then puts the correct LPT control to ground giving a signal at the computer. There are a few more diodes and pull ups in there to protect the LPT port but have been omitted for clarity. My circuit drawing skills are hopeless, but you get the idea. I may have made an error in the diagram - but rest assured it does work. Doubtless somebody has a far more elegant way of doing this - if you do, please tell me, as I had a lot of trouble working out how to do this!
Then I devised a small computer program to allow me to switch on the motors in either direction for a certain number of milliseconds, and give me a visual warning of the motor reaching the "end stops".
The numbers on the right give information on the inputs of the LPT port. When the end stops are reached on of these bits goes low and a warning icon appears.
Now follows a few snapshots of the setup mounted on the scope:-
Here you can see everything attached to the scope and plugged in. The black control box is simply attached to one of the main tube rings with a small bolt. The computer power connector supplies 12v for the control circuit, the usb connector is actually connected to my parallel port for computer control. The grey serial lead connects to the microswitches and the thin red and white cable is power to the motor. It all looks very untidy, but I was just using whatever connectors I had to hand. Now its all working I will look at some ways a tidying it up.
View from the side. The black push putton on the top of the box is for manual control (there is another button on the other side.) You can clearly see the aluminum/PTFE sandwich. Note that the guide camera is not attached.
With the guidescope itself removed. The pivot bolt is on the right and the left and end moves "up and down" by the motor.
Close up shot of the "business end". The bolt at the top passes through the slot in the top sheet of aluminum. The Motor on the right turns the screw, and the block moves along the thread. The two pronged widget is used to communicate the block's motion to the top aluminum plate. Obviously this needs to be able to turn slightly. The two microswitches at each end detect the "end points" of the travel. The white stuff is lithium grease.
Another shot from a slightly different angle.
Looking from the camera end.
Also a short AVI showing the motion. And no, thats not going to win anyone an Oscar.
Obviously when the motor is pulling against gravity it goes a little slower than when its going "downhill", but with between 20ms and 50ms pulses I was able to move the guidescope about 1 field of view... about 12 arc minutes.
The only problem came when the guidescope is "sideways" ie when its pointing low in the south. In this position it had a tendency to slip after a period of guiding.
This highlights the main weakness. The guidescope mount is not locked in position. The transmission components cannot be tight - they have to be able to move with the motor, and rotate to a certain extent, due to the end of the pivot prescribing a circle. Any tracking passed the meridian is going to be a nightmere, but I can live with that. I must think of a better way of arranging this. Another option is to install a small relay driven electromagnet to clamp the scope when the motor is not driving.
Overall, a wonderful improvement to my imaging experience, and time well spent.
I use an SC1 modified webcam as an autoguiding camera. Recently I have upgraded this camera. I have removed the colour ICX098 CCD sensor and replaced it with an ICX098 BLACK AND WHITE sensor. This is not the "SC3" upgrade - that involves a chip with bigger pixels. This upgrade is a simple swap of the colour chip for the black and white equivalent.
The modification was a fairly easy bit of soldering. The new ccd is an exact pin for pin replacement for the old colour CCD chip. It was not expensive either - perhaps as expensive as a very cheap eyepeice.
The advantage of using the black and white chip is a large increase in sensitivity. With no built in colour filters, I can see fainter guidestars, with less exposure, and better signal to noise. Running the camera in RAW Mode gives, in theory, better resolution.
I strongly recommend this modification to anyone using a toucam webcam for autoguiding. Suitable CCDs and more details can be obtained from Artemis.
The next modification I made was adding a fan to the case holding the toucam. This made a visible reduction in the background noise. This can only improve guiding by offering a better signal to noise ratio. Every little helps!
The final tweak I have made is to swap my 2x barlow in the guidescope for a 3x barlow. After the above improvements I felt brave enough to reduce the field of view and increase the resolution a bit. This gives me guiding at aprox 1200mm with 5.6um pixels. This works out at an image scale of just under one arc second per pixel. My normal imaging setup (200mm/1000mm newtonian telescope and SC3 modified toucam webcam) has an imaging scale of about 1.5 arc seconds per pixel.
My main autoguiding problem is related to autostar. The tracking is running slow, and I have yet to get custom tracking rates to work. This makes one part of the PEC graph rather steep.
See some of my other projects - Homemade DIY telescope parts with a mini lathe
By request I have put some snippets and fragments and examples of the visual basic .net (VB .net) code I used. I used IO.DLL available on the web to communicate with the port.
The functions in IO.DLL need to be declared:
Private Declare Sub PortOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Byte)
Private Declare Sub PortWordOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Integer)
Private Declare Sub PortDWordOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Long)
Private Declare Function PortIn Lib "IO.DLL" (ByVal Port As Integer) As Byte
Private Declare Function PortWordIn Lib "IO.DLL" (ByVal Port As Integer) As Integer
Private Declare Function PortDWordIn Lib "IO.DLL" (ByVal Port As Integer) As Long
Private Declare Sub SetPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Sub ClrPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Sub NotPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Function GetPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte) As Boolean
Private Declare Function RightPortShift Lib "IO.DLL" (ByVal Port As Integer, ByVal Val As Boolean) As Boolean
Private Declare Function LeftPortShift Lib "IO.DLL" (ByVal Port As Integer, ByVal Val As Boolean) As Boolean
Private Declare Function IsDriverInstalled Lib "IO.DLL" () As Boolean
The code to check the state of the LPT parallel port
Dim bReturn As Boolean
Dim output As Byte
'bReturn = IsDriverInstalled()
output = PortIn(PortRef + 1)
Me.TextBox1.Text = output
Me.textboxbit0.Text = output And 1
Me.textboxbit1.Text = output And 2
Me.textboxbit2.Text = output And 4
Me.textboxbit3.Text = output And 8
Me.textboxbit4.Text = output And 16
Me.textboxbit5.Text = output And 32
Me.textboxbit6.Text = output And 64
Me.textboxbit7.Text = output And 128
Dim rightstop As Byte
Dim leftstop As Byte
rightstop = output And 16
leftstop = output And 32
If leftstop = 0 Then
Me.ButtonLeftStop.Visible = True
Else
Me.ButtonLeftStop.Visible = False
End If
If rightstop = 0 Then
Me.ButtonRightStop.Visible = True
Else
Me.ButtonRightStop.Visible = False
End If
And the clicking code
Dim bReturn As Boolean
Dim defcol As Color
defcol = Me.ButtonRight.BackColor
' bReturn = IsDriverInstalled()
Me.ButtonRight.BackColor = Color.Green
Me.ButtonRight.Refresh()
SetPortBit(PortRef, AppSettings("rightbit"))
Thread.Sleep(Me.NumericRight.Value)
ClrPortBit(PortRef, AppSettings("rightbit"))
Me.ButtonRight.BackColor = defcol
Me.ButtonRight.Refresh()
Hope that helps. Contact me on the email address on the homepage for more details.
