bobro

Thanks Neil and Wim - KS clipping is much clearer now. (Neil - FYI - I've ordered an AR0130 sensor module from Amazon. Should be testing in a couple of weeks.) Bob

Thanks Neil - sort of what I thought might happen, though DSS has an iteration count (5 used in my example). Is this just an iterative way of arriving at the final pixel value by discarding the values farthest from the mean? So if an iteration shows that all values are within an acceptable range the iteration stops? Starts to make sense now. Also, because we are presumably talking about individual pixel values, all of the other pixels that aren't affected by the plane trails benefit from the increased number of subs - which means lower noise? So best to keep all subs rather then discard those with problems in small areas? Perhaps I'm being lazy, but with Kappa Sigma clipping also eliminating noisy/dead pixels and the use of dithering, I now don't bother with darks. OK, I know my images are pretty basic, but is this appropriate? Sorry for so many questions, but this seems to be part of this astro imaging journey - working out what works best for your own setup and inclinations! (Until you change things of course.) Bob

Tuesday had a lovely clear night, but Air Traffic Control decided to route every available plane right across my imaging view! From 23 subs, 5 had plane trails, with the 2 worst shown below. So I decided to try DSS with Kappa Sigma clipping, keeping all 23 subs rather than discarding those with trails. The final image didn't show the plane trails, but I don't quite understand how Kappa Sigma clipping works. Anyone care to explain? Was this the best approach? Thanks Bob

Here is the link - a download at US$3.95. https://www.myscienceshop.com/product/digital-download/tmkpdf045

Carried out another test with the CC - this time with the space between the 2 lenses reduced to only the ring that is normally used to hold a filter in its holder. Results in the attached sample images (processed quickly so a bit rough) with 300 second subs. Lens to camera focal plane still at 88mm. My scope tends to make little flying saucer stars towards one corner. Perhaps down to the simple focusser. I will try and test with a different lens to focal plane distance.

Images look fine for 30 second exposures. The lack of flats can probably be got round with processing for images with small galaxies, but could be an issue for nebulae or single galaxies. Flats aren't really that difficult : keep the scope/camera config unchanged, put a piece of paper across the scope, point to an even source of light at least a couple of meters away (don't point a source of light at the scope) and take flats at the same ISO so that a mid-point grey image is the result. For me the single biggest (and easiest) improvement to imaging was flats - really worth doing! I hope this makes sense/helps? Bob

I checked on the lenses I ordered from Eskma - they are 25.4mm dia. Part numbers 111-0222E (bi-convex) and 112-0227E (plano-concave). HTH

Certainly I do wish to test out the CC more, but clouds are doing their best to prevent this! In particular bringing the lenses closer together. I'm also testing out a guiding setup of an Arduino Nano driving simple DC RA/DEC Economy Motors (not steppers), with PHD2 controlling this. Seems to work, but perhaps I need to move to where there are clearer skies - living on a small island means sea mist can scupper efforts even if there are no clouds!

First attempt at a 'proper' image with the new config of Arduino/PHD2 driving the Economy RA/DEC motors. Of course clouds did their best to thwart this : only 6 subs at 5 minutes. Trouble finding guide star so this was a bit away from the image - result was trailing (tried to fix in processing) due to polar alignment not being good enough. Still good to see M58 and the Siamese Twins in the image, plus a few other smaller galaxies.

Yes, there are many questions when deciding on a guiding setup! Each setup is different, so that means there isn't a single correct answer. Anyway, possible responses as follows: Pixel ratios guider:imager - Orion suggest their 50mm guide scope is good for scopes up to 1500mm focal length. Of course that doesn't mean a lot on its own, therefore the pixel ratios make for a good comparison. With a very good guiding setup, a ratio of 10:1 could be possible, with 4:1 being conservative. So both of your suggested image scopes look ok. Flexure - haven't noticed this to be problem (I'm imaging with the Orion 50mm at 650mm fl), though my EQ2 is way below any required stability requirements for imaging. Assuming you are imaging up to 750mm focal length and everything is well tightened, flexure shouldn't be too big an issue. Added weight - best to keep weight down so that the mount is in control and not the scope. Aperture/guide star brightness - depends on the guiding camera. in my case a simple webcam, so a low f ratio means more/brighter stars. If a purpose made CCD camera is used then not so important. Weight & stability - the mount is trying to keep the scope/guide camera under control, so best to keep scope/guide camera weight down. With a good solid mount, such as an EQ5, that will track well (assuming appropriate polar alignment) for many minutes, a guiding system only need gently nudge the mount in the correct direction from time to time. Mount periodic error is perhaps the real issue that guiding is trying to deal with as PE can suddenly appear from nowhere and needs to be corrected quickly. It would be great to see an 'equation' covering the many parameters of a guiding setup. A PhD thesis perhaps? Would be good to hear a few more responses on this often discussed topic!

Anyone know why the global Sky-Watcher site shows the EQ3 with a steel tube tripod http://www.skywatcher.com/product/eq3-synscan/ , yet (in the UK at least), it is sold with the aluminium tripod that doesn't seem great for stability?

The ratio based simply on focal length is a rough starting point. However, a guiding setup works by monitoring pixels on the guide camera and will try and guide to this. The movement between the guide camera's and the imaging camera's images is based on focal length and pixel size - this is measured in arcseconds per pixel (aps). Your imaging scope has a focal length of 750mm and the imaging camera a pixel size of 4.3um. aps_imaging = pixelsize * 206 / focal_length = 4.3 * 206 / 750 = 1.18 arcseconds per pixel (each pixel of the imaging camera covers 1.18 arcseconds of the sky) An Orion mini guide scope has a focal length of 162mm. Although the guide camera has not been specified, assuming a QHY5-II Mono with a 3.75um pixel size : aps_guiding = 3.75 * 206 / 162 = 4.77 arcseconds per pixel For good guiding, a maximim ratio of around 4:1 between aps_guiding and aps_imaging is often suggested. This is based on modern guiding software being able to guide to sub-pixel accuracy. The above guiding/imaging setup gives : aps_guiding / aps_imaging = 4.77 / 1.18 = 4.04 So the above system is at the bounds of the typical match between the guiding and imaging parts of the setup and should be ok to go ahead with (other factors such as mount stability and seeing can make for much bigger variation). HTH.

Must get an upgrade for my camera!

Somehow the Moon always seems to be out when it's time to test something......this time my Raspberry PI/Lin_guider dual axis autoguiding config has been replaced by PHD2 running on the image capture laptop. The main reason for this was to simpify the setup with the laptop now running guiding and image capture. It also makes for a simpler battery powered dual axis guided setup : camera battery, RA motor battery (PP3) and laptop battery. The laptop is actually an eebook, but seems to handle guiding and image capture without issue. The eebook very long battery life of 8-10 hours is excellent, though it will be reduced a bit due to driving the DEC motor and the Arduino. The first image (Jupiter - below) with the new setup is 14 subs each of 180 seconds, 100ISO due to the Moon. Guiding seemed to work ok - not much different from Lin_guider except for guiding corrections issued less frequently. This could be an issue when the wind gets up a bit. Looking forward to a better imaging test when there isn't a moon!

Yes - didn't spend more than 15 minutes processing, so more should be possible. I tried dithering for the first (APT to Lin_guider) - failed as Lin_guider control seemed to go into DEC oscillation. So I turned dithering off for the above image. There seems to be something going on with DEC guiding (oscillation) - it looks like backlash, although it didn't show in earlier guiding. RA is fine. Needs investigation.....this stuff keeps us busy!

Here's my Leo Triplet from last night - 20 subs @ 4min, 800ISO.

A gap in the clouds appeared - long enough for a with/without CC test. Almost full moon too. Images below show the results. There is some additional vignetting and loss of light when the CC is used. The camera needs to be moved away from the scope by about an additional 10mm to achieve focus- unexpected. Possibly the CC position in the focus tube needs to be adjusted. The CC seems to be doing what it's meant to do though.

The design came from a 1991 magazine - I can't advise on specifics as I'm not an optical designer, though it was described with an f4.5 scope. The spacing between the two lenses was described as not critical. The approx distance to the camera focal plane and the lens specs are in the diagram at the start of this topic. I purchased the lenses from Eksma Optics. So far there hasn't been an opportunity to test the CC - waiting for a gap in the clouds.

Possibly not a good idea for use with a small sensor. This type of corrector, whilst improving coma as distance from the image centre increases, actually makes spot sources (such as stars) larger near the image centre. If a small sensor is used with a fast Newtonian, it shouldn't suffer too much coma as coma increases linearly with distance from the image centre in an uncorrected Newtonian (parabolic mirror).

Not much opportunity for imaging recently, so I've been putting together a DIY 1.25" Coma Corrector. See : Hope to be posting images here with it before too long! (If it works .) Bob

Those comet shaped stars towards the edge of images taken with my Newtonian f5 scope were starting to annoy me, so it was time to look for a coma corrector. Probably due to lack of demand, there didn't seem to be much available in the way of CCs for 1.25" focusers. So, after a bit of internet searching, a magazine article dating back to 1991 with an optical design for CCs was found. After a couple of minor design changes to suit stock lenses I could find, lenses were ordered plus the other metal parts to construct a housing with. The optical design is a Ross type two element corrector, producing no change to the focal length nor focusing of the telescope. It's not the best type of corrector design, but stock lenses are easy to obtain for it and it's not a critical design. As the lenses are 25mm diameter, they fit nicely into a 1.25" filter housing - one for each lens as the lens spacing isn't supposed to be critical. The remainder of the CC is made from a 1.25" eyepiece barrel with a filter extension tube between the barrel and the two filter housings. Sitting inside the telescope focuser tube, eyepiece screws hold the CC in place, allowing for a bit of fine tuning of the distance between the camera focal plane and the CC lens. It's strange to look through the CC - seems like looking through a piece of plain glass as the two lenses cancel each other out. Hopefully it will do more than plain glass for imaging! Next step, of course, is testing. I'll post results when clouds allow.......... If anyone has experience or thoughts on this type of design, please comment.

As I'm hoping to soon start testing out PHD via an Arduino, I spent a bit of time today looking at your guiding graph. Initially I didn't think I could offer anything in the way of help as my current setup is Lin_guider. Nevertheless there are obvious similarities, so here goes..... My comments assume that a good guide star was used and so wasn't a source of the instability - I don't know enough about PHD to tell from the graph. RA guiding continually oscillating about zero is often a sign of overguiding. I can see this with my setup if the gain (Aggressiveness) is set too high, so this is something to look at. I'm not convinced this is the real reason for the oscillation though. Your setup is using a 3 second guiding exposure. This seems quite high and will limit the responsiveness of the guiding, possibly resulting in guiding corrections being large. As a comparison, my guide camera cannot do long exposures, which results in Lin_guider issuing guide corrections of up to about 8 guide corrections each second. Due to the frequent guide corrections I need to set the RA Aggressiveness to a low value. The end result is guiding that is relatively responsive. I note that your setup typically issues a guide correction each 3 seconds - this is also a sign of an overguided system as there should be periods where guide corrections are not required, especially with a stepper motor driver (my setup is a simple dc motor so underlying accuracy isn't great). Some suggestions - 1) capture a guide graph with RA guiding disabled to see the underlying accuracy of the setup 2) shorten the guide camera exposure to allow more frequent guide calculations 3) try reducing the RA aggressiveness Hope this helps - perhaps someone with more experience of PHD will come along and offer better advice.

Lin_guider's settings are in time duration (msec). This determines the period during which the relay contacts are active in my setup. PHD may be different. Correction time for your setup may be quite different from mine - only testing will tell. The text file corrections could be useful in drawing a graph.

Congratulations Steve on getting this far with guiding. It's very likely that many will be using PHD for guiding. If you haven't seen it, here is a link to a PHD tutorial: As I use Lin_guider I can give you an overview of how I 'tuned' it for my setup by trial and error setting of the guide parameters. The setup is unusual in its use of DC motors rather than stepper motors, so it will likely respond in a different way to a stepper motor system. Nevertheless, the basic principles should still hold. Following Lin_ guider calibration, guiding was started on a star chosen by Lin_guider. The guiding graph shows the error in guiding and, of course, the aim is to make this as small as possible and correct guiding errors as quickly as possible. If the Python guiding program doesn't produce a graph it may be possible to observe the central star to see how guiding is performing. Proportional Gain setting (RA Aggressiveness) - this is set to a value that corrects a largish error with some dampened oscillation about the mid-line. If this value is too high oscillations may grow and guiding will fail. If this value is too small (no dampened oscillation) it will take too long to correct an error. Set to 10 for my setup. Integral setting (RA Hysteresis) - if guiding continually swings backwards and forwards, this can be reduced by adding together calculated guiding corrections, so smoothing out the calculated guide error. I didn't use this setting as stability wasn't an issue. Minimum correction - this helps to stop tiny corrections that may not be useful (guiding noise). In my setup a value of 50msec still seemed to provide useful correction. Maximum correction - large guiding corrections shouldn't be necessary, though may be calculated due to wind on the mount. Limiting the maximum correction helps stop sending the scope too far off course (it should come back as the wind effect disappears). 500msec is a good starting value for this. DEC settings - luckily my setup doesn't suffer from DEC backlash, so I was able to tune the DEC parameters in the same way, with final values being not too different to RA. If backlash is an issue it may be better to guide DEC in only one direction. One area I don't really understand with Lin_guider is the frequency of guiding. I think it may be down to the webcam I use which doesn't support long exposures. The result seems to be that Lin_guider can issue multiple (perhaps 5 or 6) guiding corrections each second. This is perhaps a good thing as it helps with a fast guiding response. Hope the above is useful to you and good luck with 'tuning' your setup. Bob

Thanks for the info on your excellent project. Coincidentally, I've just ordered an Arduino Nano to allow my mount tracking to be driven by PHD2. The Arduino to be loaded with Kevin Ferrare's code https://github.com/kevinferrare/arduino-st4/ and a modified relay board to interface to the motors. With APT loaded on the PC it should make for an integrated imaging and guiding system - if my eeebook is powerful enough to drive everything! Use of a stepper motor may give better tracking (less jitter) than the simple DC motor used in the Economy Motor Drive, though I find the biggest sources of trailing in my setup are the wind and accuracy of polar aligment (with longer exposures). Good luck with your project - I look forward to seeing some images!