Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by kens

  1. 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.
  2. 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?
  3. 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
  4. 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.
  5. You could try asking on the INDI forum. Jasem is very helpful. https://indilib.org/forum.html
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. Thanks. At first I thought the problem was the hemisphere setting till I realised you are in Melbourne like me So I know the tool is thoroughly tested in the southern hemisphere. What is odd is that when you were ding the polar drift the mount was reporting a declination of close to zero rather than close to -90. That is not necessarily a problem as it could just be a sync issue but you do need to be pointing towards the pole. Also make sure the mount is tracking (not parked). The video tutorials here should be relevant since I made them from Melbourne. The star pattern near the pole is quite distinctive.
  14. Make sure your mount is tracking when you do the alignment. This is the most common problem with PDA. I'd like to get to the bottom of these issues so if you can upload your Debug log that would be helpful.
  15. Hi ZiHao In the only run of any usable length your hysteresis is set to 0.1 which is very low and the MinMo is set to 0.2 which is quite high. The net result is that the PE of the RA axis is not being guided out. You need to stop fiddling with the settings unless you really know what you are doing. Otherwise use the default settings an/or the recommendations of the Guiding Assistant. When you run the guiding assistant, enable the backlash measurement as there are signs of backlash in your mount.
  16. For dithering you need to know both your imaging scale as well as your guiding scale. That’s because you want to dither , say, 10 pixels on your imaging camera and need to convert that to guiding pixels for PHD2 to do the dither. I don’t use APT so I just had a look at the documentation and it is indeed confusing. I’m not sure what it sends to PHD2 Can you post your debug log? That will tell me what APT sends to PHD2
  17. Don’t forget that to dither 10 pixels on your imaging camera you only need to dither around 3 or 4 pixels on your guide camera at 650mm FL, and 2 or 3 pixels at 1000mm FL.
  18. Having a closer look at the log, PemPro log viewer appears to be miscalculating the arcsecond values so both the dithers and drift are not as large as I first thought. Normally it does not show up but as you were guiding at 70deg declination the calculation error is magnified. I'll need to do some manual calculations now as you may not have any major issues at all. The performance between dithers looks pretty good,. I need to see if the drift is consistent with refraction ordue to flexure. Your dithers are averaging around 5 pixels and the largest was 7 pixels. A 5 pixel dither should equate to 30 arcseconds or so. Depending on your imaging scale that sounds reasonable if a little on the high side. I understand that 10-20 pixels is the usual.
  19. Most likely yes. Due to not being anchored securely enough. The following show the amount of drift on both axes (RA then DEC) You can also see the size of the dithers. Given the short focal length you could reduce the size of the dithers. At 3 seconds the Z-filter offers no real advantage over Hysteresis. But it should not do any real harm. It can make recovery from dithers slow but does not look like an issue here.
  20. I had a look using Pempro log viewer. Its a bit hard to analyse due to the dithering but there are signs of quite severe flexure (hundreds of arc seconds)
  21. You still need a way to power the Arduino.
  22. Under the Help menu you should have an option to Open Log Folder. You ill find your logs there. Find the one with the right date and named as a Guide log (not Debug log). If it is large you might need to Zip it first to attach it.
  23. The OP would be best off creating a new profile with the wizard to get all the right settings
  24. For continuous waveforms a Fourier transform is used to convert from time domain to frequency domain. For a discrete, that is sampled, waveform the equivalent transform is known as the Z transform and the discretised frequency domain as the Z domain. The Z filter algorithm is designed using the Z transform and operates in the Z domain. It is the digital equivalent of capacitors and inductors used to filter audio signals so I would not characterise it as adaptive. Bessel and Butterworth filters are often used in audio systems e.g for crossovers due to their characteristics. These same characteristics are useful for guiding.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.