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.



Advanced Members
  • Content count

  • Joined

  • Last visited

Community Reputation

263 Excellent

About themos

  • Rank
    Main Sequence

Profile Information

  • Gender
  • Location
  1. Hello, If you have a camera and a laptop, you can use my PhotoPolarAlign method described here, it's been tested in Southern Hemisphere and can give Polar Alignment accurate to a few arcminutes in about 15 minutes.
  2. Sorry Olly, as I understand it it's not about saturating your chip with orange glow. The general rule for a single exposure is expose until your read noise is not the limiting factor. That happens earlier in the exposure for low-read-noise cameras (modern CMOS, for instance). So what other noise sources are there that we should think about? There's dark noise which is what you get even with the shutter closed. And there's shot noise, which is the uneven dribble of photons from light polluted "background" sky. The more light pollution there is, the more photons come from it and the associated noise is the square root of the average number of photons. So that increases as we expose and at some point becomes much larger than the one-time penalty of read noise we pay at the end of the exposure (the "sub" some people call it). At that point, there's little point in carrying on with that exposure and we might as well start a new one. Starting a new one has advantages because our tracking/guiding could fail at any moment and you don't want to ruin a half-hour exposure because of stray photons in the last minute. Also, we don't want to saturate the bright interesting objects! So, dark skies means longer exposures are optimal than bright skies.
  3. I should add that the method I used in PPA also appears in SharpCap http://www.sharpcap.co.uk/sharpcap/features/polar-alignment so if you like the extra bells and whistles you might like to give that a try.
  4. I think it would be great for someone to add this, but I wouldn't be using it myself. Given that hardly anybody has a mount with motorised elevation/azimuth controls of the polar axis, the PPA process will always involve a human being iterating moves and closing in on the error. People with observatories can take their time and people that set up every night can use a piggy-back camera (even a compact camera will produce good enough stars in 10 seconds or so).
  5. I am sorry, that's not it! The first couple of images will fix the pixel position of the polar axis no matter what orientations you used. The requirement for the second image to be horizontal is to translate the x/y correction that is calculated (which is merely along the long side and short side of the sensor) to the left/right and up/down instructions needed for the person doing the mount correction.
  6. Hello Steve, I've avoided using the reflector at prime focus because 1) the image scale is a bit excessive for the purpose ,2) reflector images have the wrong parity which messes up the move instructions and 3) it's more tricky to know what horizontal is. Best way of making the mapping from arcminutes to screw turns is to solve images (with PPA!). I guess I would do the first couple to get the polar axis, then give a full turn to raise the polar axis and do an improvement solve, then note the new error (the Up/Down move instruction). Repeat for Left/Right. For this to work, you must make sure your horizontal image is really that. I used to do it with a spreadsheet and just the positions of Polaris and Lambda UMi (like David Rowe had suggested) doing the geometry you described. Then I realized that the NCP is quite near the line connecting the two and that magnifies errors. The next idea was to use more stars and take an average of the geometric solutions. I finally settled on a numerical method to find the fixed point of the transformation implied by the two solved images. The mapping is (pixel x, pixel y) -> (ra,dec from 1st solve) -> (pixel x, pixel y from 2nd solve). The axis of rotation is the pixel that gets mapped to itself. When I do the Improvement step, I already know the pixel position of the axis of rotation. That will not change, no more RA/DEC moves allowed. I also know that my camera is horizontal. Any moves with the screws of the mount would just shift the sky in the field of view, so I just move to bring the NCP onto the known pixel position. Themos
  7. It should be ok, I guess you will need to experiment. But you don't have to slew, you can just undo the RA clutch and swing the axis manually. Atsrotracs can't do that but your CG-5 should be able to do it.
  8. My Stellarium (0.17.0) says, when I click on Polaris, RA/Dec (on date): 2h55m07.03s/+89d20m23.7s. So that is nearly 40mins off the current NCP.
  9. Hello, I've added your ideas in the GitHub Issues. I am not sure when I will find time to add these but they are there in case anyone is tempted to implement them and do a pull request. Polaris was at ~44 minutes in J2000 but not now! PPA does adjust for the wandering of the Earth's axis (precession).
  10. Thanks! I will message you! Themos
  11. Hello, After trying to make USB shutter control cable for an EOS 20D and failing (soldering skills and eyesight failing) I am asking the community to help me finish this. I already have an FTDI USB to TTL cable for the job and I have converted the 20D shutter control to 2.5mm female audio jack. The circuit needed is like this one except it will be driven by the GREEN/BLACK wires of the FTDI cable instead of the pin-7/pin-5 of the serial port in the diagram. If you can help, please get in touch. Themos
  12. themos

    Heads-up: Apollo 15x70 on Astroboot

    They second one has just disappeared from the website!
  13. themos

    Heads-up: Apollo 15x70 on Astroboot

    They've arrived! I got the one advertised as damaged case but I can't see any damage! I will give a further report later.
  14. themos

    Heads-up: Apollo 15x70 on Astroboot

    Cheers! there's only one left now.
  15. themos

    SharpCap 2.9 - Polar Alignment

    Hello, whenever I have verified the PHD GuideLogs after a session, I find an estimated PA error that's quite similar to what PhotoPolarAlign (same method that Robin has put in SharpCap) measured. I use PHDLab for analysing PHD GuideLog files. A couple of things to check: It could be that PHD's Drift Align procedure is not as robust as PHDLab's analysis (remember that PHDLab can see the entire session, not just 10 minutes, and tell how much Dec correction was applied). The other thing is refraction. If you are imaging fairly low in the sky, there will be significant and varying refraction. The path of the star will not be a perfect circle and you will get apparent drift no matter how perfectly polar aligned you are. I image at up to a metre focal length and up to 10 minute subs and consider any polar error under 5 arcmin as good enough.

Important Information

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