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

298 Excellent


About kens

  • Rank
    Proto Star

Profile Information

  • Gender
  • Interests
    Deep sky, fly fishing, cycling
  • Location
    Melbourne, Australia
  1. The main issue from poor polar alignment when guiding is field rotation causing elongation of stars If you plug in the details of your specific imaging situation into the field rotation calculator at http://celestialwonders.com/tools/rotationMaxErrorCalc.html you can se if field rotation is an issue. It gets worse the closer you are to the celestial pole but for the vast majority of likely situations, 5 arcmin is indeed good enough.
  2. kens

    CCD v CMOS

    60dB gain (gain 600) is way too high. You have less than 4 stops of dynamic range there. I keep the gain at 200 (20dB) or lower where the dynamic range is a bit less than 10 stops. Typically I use gain 75 for luminance, 139 (unity) for RGB and 200 for narrowband unless I an get a reasonable exposure at 139.
  3. The minmo values recommended are quite high - more than 1" on both axes. That is limiting your guiding. Were the conditions particularly poor when you ran the GA? Looks like some cloud came over near the end Dec backlash is also evident. Did you measure it with the GA?
  4. At face value the numbers look ok on the screen shot but really need to see the guide log. Note that the belt mod does not fix the major source of backlash which the worm/ring gear interface
  5. Start with the OAG. I suspect the eggy stars are the result of differential flexure with the finder guider. Your guiding RMS is not hugely different in RA and Dec so you would not expect eggy stars from that. The guiding RMS vaues could be down to poor seeing.
  6. You could try asking on the INDI forum. Jasem is very helpful. https://indilib.org/forum.html
  7. You don't need to sweat over offset. I just set it to 50 on the ASI1600 and leave it at that. The reduction of dynamic range at low gain is insignificant but leaving it constant saves mistakes. That is unless you are using the presets in the ASCOM driver which for some models also adjusts the offset. In that case its easier to use the defaults. Also, the gain and read noise numbers provided by ZWO are near enough to what you measure so no need to re-measure them. Your graph is ok - what might be confusing you is that gain is given in e-/ADU by convention but it is more intuitive for it to be in ADU/e- These numbers don't quite match what I'd expect from the Shiraz tables on CN. e.g. At Gain 0 Offset 10 he says 420 ADU above offset which would be 420+16x10 = 580. You've got 400 ADU with offset which is just 240 above offset so only about half the exposure. One of the problems with the tables is that it depends a bit on getting a reasonable estimate of your sky background. I prefer to calculate (or look up) the target ADU then take a sample sub to see if the median is near enough to that target. Its not a precise science - targets of 3xRN^2 to 10xRN^2 are ok. More than 10xRN^2 is also ok if you are not saturating. I'm wondering if your stacking problems are more related to the SNR of the individual subs. I've found the recommended ADU values under strong LP, less than ideal seeing and faint stars leads to very few alignment stars being found due to poor SNR per sub. In that case the only answer is to expose longer per sub than recommended.
  8. Hi Eric - I see you are using the Z-filter algorithm this time. Overall the results are as good as you could expect with RMS of 0.11 pixels on both axes. That is at the limit of what PHD2 can do so too improve you would need a smaller pixel scale for guiding. The RA result could be optimistic because you were guiding at around 70 deg declination where any RA errors (e.g. from PE) would be greatly reduced. Your exposure times are 3s and on the Z-filter you have an X-fac of 2. This gives a "virtual" exposure time of 6s which is quite sensible. The Z-filter is primarily designed to allow shorter exposure times (e.g 0.5s to 1.0s) but still works at longer exposures - its just the benefits are not as evident compared to the other algorithms. When using the Z-filter the MinMo values operate differently from the other algos in that it applies to the correction rather than the measured deviation of the guide star. This is because it can give small corrections that are less than the smallest movement possible in some mounts. Your MinMo values are quite high given your pixel scale - equivalent to around 0.7". This sets a floor for your RMS values. For RA I would recommend starting at MinMo of 0 with the Z-filter. But you'd also need a session closer to Dec 0 to see what else may be needed. On the Dec axis the MinMo value depends on your level of backlash. Your backlash seems to be under control with the settings you have so I would leave them as-is.
  9. Hi Eric, can you post the guide log from that session. Under the Help menu is an option to Open Log Folder. You can find the Guide Logs there with the Date/time of the session in the file name. The Guide Logs show a lot more about what was happening than you can get from a screen shot.
  10. In line with Michael's comments, it's possible the program crashed and you got the prompt when you restarted it. The debug log will explain what happened. Unlike Windows you can turn off automatic updates in the brain on the General tab or restrict it to major updates only.
  11. Glad it worked for you but it sounds very odd. The only things I can think of that would cause that are some sort of mirroring of the image or the mount not tracking. The lens (I assume you mean a camera lens) should not do that but it is possibility. Also, since you are using a knock-off camera there is the possibility that it is producing mirrored images (e.g. by returning the rows in reverse order). Can you provide a screenshot or saved image from PHD2 centred around the pole? The asterism formed by BQ Oct, HD99685 and HD98784 is quite distinctive and will show me if the image is inverted. If so there's more reason to add an option to PDA to allow for an image mirrored by either the lens, the driver or an OAG.
  12. Yours is a different problem. Were you pointing at the South Celestial Pole? According to the log you were pointing near the Celestial Equator (declination zero). If that's the case then PDA won't work as you need to be pointing within 5 degrees of the pole.
  13. I can make the red line go anywhere I want But I do need to verify some things first. One is that the scope was tracking during he polar drift (at face value this would appear to be the case) and the other is that the PA error from an alternative method is consistent with the PDA result. Tracking is important because near the pole the RA drift when tracking is off is very small and mimics the PA drift very closely. That fact that you slewed from your calibration point to the pole would normally cause EQMOD to start tracking so that looks promising. Also, measuring the PA drift on your guided runs shows the drift was much less after your PDA run. This is not conclusive as it depends on where you are pointing in the sky but promising nevertheless.. A Sharpcap, KStars or SPA alignment would confirm the result. Getting the direction right is mind bogglingly difficult due to the multitude of coordinate systems one has to deal with in the calculations. So its quite possible that the northern hemisphere direction is wrong. I'm confident about the southern hemisphere result is correct since I was able to confirm that myself. Another possible problem is the use of an OAG. The prism reverses the image orientation which might affect the calculations. Basically, the speed of the drift determines how far out the PA is and the direction to the pole is at right angles to the drift. In the NH the drift is counterclockwise and in the SH it is clockwise (or maybe the other way - I can't recall). But in the mirror image caused by an OAG the direction could be reversed. I'll need to go over the maths and also try it out myself with an OAG if the clouds ever clear. If it turns out to be due to the OAG then I'll need to include an option for the user to indicate the image is reversed. If you could verify the PA error after PDA that would be useful. Thanks for the data - it was quite clean
  • Create New...

Important Information

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