Jump to content

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.



  • Content Count

  • Joined

  • Last visited

Community Reputation

173 Excellent

About derrickf

  • Rank
    Star Forming

Contact Methods

  • Website URL

Profile Information

  • Location
    West Berkshire
  1. I would really appreciate the link to the .STP files too. You have done a fantastic job with this design Derrick
  2. Autodesk Fusion 3D is free for personal use and use by small businesses. It is a fully featured 3D modelling system with integrated complex surfacing, FEA, CAM, sheet metal design and development, rendering etc. It is ideal for designing the kind of widgets we need from time to time in pursuit of this hobby. It is very well supported on Youtube by Autodesk and many third parties. HTH Derrick
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.