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



Advanced Members
  • Content count

  • Joined

  • Last visited

Community Reputation

168 Excellent

About derrickf

  • Rank
    Star Forming
  • Birthday

Contact Methods

  • Website URL

Profile Information

  • Location
    West Berkshire
  1. You don't need the hand controller to be plugged in if you are controlling the mount through sitch.exe. My hand controller has been dodgy since day 1 and now lives in a box far away from the mount. HTH Derrick
  2. I like the choices you have made in working on this data - it's good to see an image that is processed just far enough to exploit the available data; as others have said you can process more aggressively to minimise noise when you have more data. Derrick
  3. I noticed this in a thread on the PI forum about a different topic here. About halfway down the first page Vicent Pieris indicates that PI will have a process for correcting amp glow; this may be of use to owners of the ASI 1600 : Quote from: IanL on 2017 January 09 10:17:16 - If your CMOS camera suffers from repeatable banding, amp glow or fixed pattern noise, then you should turn off PI's dark frame optimisation and use a time and temperature matched master dark. Otherwise it will likely over or under-correct and those artifacts will only be partially corrected (or indeed made more visible). This is certainly the case for my CMOS-based ZWO ASI1600MM-cool. A temperature and time-matched master dark without optimisation works very well and deals with the amp-glow that becomes visible and increases after about 60 seconds of exposure. With optimisation turned on, PI under-corrects by applying a scaling factor of about 0.45 despite a matched dark frame. This is unsurprising since the optimisation process is global and I expect it is being thrown by the significant variation across the frame. Hi, We're designing an amp glow correction right now, so in the future you'll be able to optimize the amp glow subtraction. HTH Derrick
  4. Is this with no PC connection whatsoever to the mount? If so it would point to this being either a mechanical problem with the mount (faulty encoder?) or a firmware problem. Maybe Lucas can shed some light on possible solutions now that the mount control software is demonstrably not the culprit. One step closer to a solution ... BTW there is no reason to assume that this is the cause of the aberrant behaviour of the mounts owned by other people.
  5. I would share your trepidation but, as Ray D suggests, no need to be quite that radical - just hook up a camera without connecting Sitech.exe to the mount
  6. I certainly wasn't suggesting that running it as a "dumb mount" should be anything other than a diagnostic exercise. You have been rigorous in your diagnosis to date with this one exception; again I'm not advocating that you do this - I was just asking if you had.
  7. I almost agree with your conclusion: if I understand your setup correctly, the problem, based on your observation, would seem to be in either the mount (including the Sitech controller) or in Sitech.exe. Have you tried doing an animation run using just the handset (a PITA I know - the handset is the weakest part of the whole mount hardware IMHO and I dislike it intensely). Clearly if the behaviour persists then it is the mount at fault; if it doesn't then that would be pretty incontrovertible proof that the issue lies with Sitech.exe. FWIW when I first got my mount, I had some seemingly random RA jumps but I chased that down to a PXP model gone bad after making some (what I thought were) minor changes to the mechanical configuration. I built a new PXP model and the jumps went away - probably un-related to the current problems people are seeing but I thought I would mention it.
  8. I have great respect for Dan and he may well be right - however he appears in this case to have based his solution on reviewing logs from only 1 or possibly 2 systems that exhibit this issue. Anyhow it looks like those users who are suffering with this are content that a fix is on the way so there's little point in further conjecture; I'll keep quiet
  9. Has anybody considered whether the guiding software used has any bearing on this - I use MaximDL and I recall Steve indicating that he also does - neither of us has (yet) been afflicted by jumps in RA. It seems that some others who use PHD do experience the RA jumps.
  10. I agree, it is unlikely to be an OS related issue per se (it could though conceivably be related to some combination of OS settings). ISTR from another thread that you are using win 10 pro as am I. I have not had any issues with jumps in RA, indeed imaging at around 0.5 arcseconds / pixel RA jumps of the magnitude others have observed would be a huge issue for me.
  11. Thanks Gnomus
  12. Thanks Chris
  13. Narrow band filters enable you to capture detail which is difficult to perceive in a wide band image but there is still quite a detailed structure that can be captured in LRGB. See my LRGB image from last year I think you are on the right path - refining your focus and guiding before leaping into the added challenges presented by narrow band imaging is IMHO your best option. Regards Derrick
  14. Magnus, you might want to read about sampling theory: a system that can sample at roughly 0.33 arcseconds is indeed required to properly reconstruct 2D features separated by 1 arcsecond - it is not resolving features at 0.33 arcseconds. Clearly one cannot capture more detail than permitted by local environmental and atmospheric effects otherwise NASA would not have invested billions of dollars sending telescopes into space. Earth based imaging will always be limited by the seeing which we often evaluate using the FWHM of star images. So if a star is blurred by atmospheric conditions into a disk with a FWHM of 1 arcsecond , we need a system capable of collecting 3.3 samples across the disc at full width half maximum intensity.
  15. It depends on your imaging preferences - if widefield nebulae, galaxy fields etc. are what float your boat you probably don't care much about critical sampling - FOV is king. OTOH if your interest is in imaging PNebs, galaxies and other small objects and extracting the maximum detail for seeing conditions (as mine primarily is) than critical sampling is ... well, critical :-)