Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

Welcome to Stargazers Lounge

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customise your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    sgl_imaging_challenge_banner_satellites_v2.jpg

bobro

Advanced Members
  • Content count

    92
  • Joined

  • Last visited

Community Reputation

95 Excellent

About bobro

  • Rank
    Nebula
  • Birthday

Profile Information

  • Gender
  • Location
    Isle of Wight
  1. 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.
  2. 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.
  3. 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).
  4. 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
  5. 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.
  6. Well, I did have a go with the image (helps improve my basic skills in GIMP 16 bit). It wasn't really blown out (Orion nebula aside), just very bright. Bringing the brightness down helped with that, plus a small amount of stretching and basic flattening to try and remove the vignetting. There's a lot to like about the image - Orion, Running Man, Flame and HorseHead (just!) nebulas, plus NGC2264. The colour of Betelgeuse is lovely. A few more subs and it could be a cracker.
  7. Nice capture of the Flame and HH - great targets. If you aren't taking flats, they are straightforward to do and will really improve final images - below is a flattened version of your jpeg to give an idea - hope you don't mind me using it.
  8. 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.
  9. Whilst I don't know anything about Arduinos, I've written enough interrupt service routines to be able to answer your general question. Yes, you can OR together multiple interrupts to present to a processor's interrupt pin. A key thing to ensure is that all combinations of interrupt timing are supported. For example, using a level triggered processor interrupt (rather than edge triggered), allows a 2nd interrupt source to activate whist a 1st interrupt is being serviced. If the interrupt service routine does not see the 2nd interrupt whilst it is servicing the first interrupt, the 2nd interrupt will kick off the interrupt service routine again when the 1st interrupt is exited. Obviously the interrupt service routine must service and clear interrupts.
  10. An autoguiding setup will ensure the guide star remains central. However, depending on the relationship in the setup between the guide star and the imaging view, field rotation can happen, resulting in star trailing. If polar alignment is very good it will reduce/eliminate field rotation and produce less/no star trailing. So yes, polar alignment is important - especially as exposure length increases. Drift alignment is a very good way of polar aligning. PEC, being a predictive method of correcting errors before they happen, helps reduce star trailing and is particularly applicable to a non-guided configuration. Autoguiding also reduces star trailing by correcting errors as they happen. Arguably, PEC is less important when autoguiding as errors will be automatically corrected anyway.
  11. 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.
  12. 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
  13. The blower may have done the trick, but I don't think the light from the panel will show this - I've previously tried taking flats with just the camera and found the unfocussed light doesn't show the dust as well. Light from the telescope will show dust as the light is focussed and will show up anything in its path. Light from the panel is not focussed. Following our previous exchange of messages, I've had a closer look at flats taken after modification of my camera. There is dust! See a stretched part of a flat below. The effect of the dust is visible on a raw image but is not evident on a stacked image using flats, showing the flats are doing their job. I think that is what you need to work towards - getting flats to work. That means obtaining even illumination, although dust can (and will) move around, so there may still be a bit of fixing to do manually.
  14. alt plus left click moves the on-screen rectangle to where the cursor is.
  15. 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!