SUMMARY With stable ~1 arcsec guiding and the capture module set to abort at > 2" Total RMS, EKOS will repeatedly abort capture because it calculates Total RMS" wrong after dithering (sometimes getting a value of 15"). For larger Total RMS, the guide process itself can sometimes lose its guide star and be aborted (this seems worse in 3.5.0). STEPS TO REPRODUCE 1. Begin guiding, with the configuration set to dither every 5 frames. 2. Begin capturing. Set the module to short capture when guiding deviation is > 2 3. Wait for the dither to happen. OBSERVED RESULT Total RMS climbs very high in the capture module, and it aborts. In the guiding module, it never seems to get that bad (though I will try to verify this the next time out). EXPECTED RESULT Total RMS" should not significantly change Total RMS, as the positional change is intended. Find a way to exclude dithers from the calculation. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
FYI, we just added an option to only start capturing once guiding deviation is below a certain threshold. Maybe that would help in your situation?
It's not a problem that the capture module doesn't start while Total RMS is high. The problem is that the error calculation seems to INCLUDE the intentional dither event. This causes artificially high error -- instead of the <1" Total RMS, it climbs above 10" where the guiding module is configured to abort. I've seen as high as 15. Even if the guiding module continues, it would take a long time to get back down to <2" where the capture module will continue imaging. It basically breaks my session. As soon as I turn dithering off, everything works beautifully with < 1" error. Unfortunately the weather has been just horrible lately so I can't test this further, but it did seem to happen in 3.5.0 during my one night outside. It could be related to another issue that seems new in 3.5.0: SEP Multistar will lose the guide star even with an SNR of 700 to 1100. It sometimes takes a few tries to get a good guiding session, then it's fine. I can easily reproduce this with the simulators. Click guide, it picks its primary and additional starts, gets to the point where it clears DEC backlash and then it loses the guide star and aborts. And yes, the stars are outside of the tracking square/circle. I run a RASA, so I take lots of short-exposure images. I definitely need dithering.
Regarding the second issue I mentioned about not being able to retain the simulator guide star... I noticed that I also could not plate-solve. No location on the sky would work. I even tried building a mount model with 5 points and they all failed. I quit and re-launched KStars and now the simulator seems to align and guide just fine. I changed no settings either time. Inconsistent. If I see this again, either for real or in the sim, I'll capture the logs.
Makes sense. The RMS measure inside the guider module, which is what capture uses, includes samples from outside the capture. I added something in Analyze to graph the RMS only in capture, but this is not what that checkbox uses (nor would it be available to capture). I'll try and include a fix in time for the next release. Could I see a log with debug logging turned on for (at least) guider and capture? Of course, you can workaround by disabling the checkbox to abort capture with large error. FWIW, this has not changed recently AFAIK. Has this been working better in the past, or is this something new you just noticed?
(In reply to MountainAirCA from comment #3) > Regarding the second issue I mentioned about not being able to retain the > simulator guide star... I noticed that I also could not plate-solve. No > location on the sky would work. I even tried building a mount model with 5 > points and they all failed. > > I quit and re-launched KStars and now the simulator seems to align and guide > just fine. I changed no settings either time. Inconsistent. If I see this > again, either for real or in the sim, I'll capture the logs. Guiding with the simulator is tricky in two respects. 1. You need to make sure you move the telescope away from the pole. You can't guide pointing at the north star, for instance. Move it at least 20 degrees away in DEC. 2. The simulator comes up defocused. I believe it starts at around 50000, and the focus point is around 40000. Move it there there before attempting to plate solve or guide.
#1 I knew about (I was always slewing to M31) but is a great tip. #2 is a good point, I'll try it out!(In reply to Hy from comment #4) > Makes sense. The RMS measure inside the guider module, which is what capture > uses, includes samples from outside the capture. I added something in > Analyze to graph the RMS only in capture, but this is not what that checkbox > uses (nor would it be available to capture). I'll try and include a fix in > time for the next release. > > Could I see a log with debug logging turned on for (at least) guider and > capture? > > Of course, you can workaround by disabling the checkbox to abort capture > with large error. > > FWIW, this has not changed recently AFAIK. Has this been working better in > the past, or is this something new you just noticed? Sure, I will capture logs for you as soon as I can. AFAIK this has always been an issue. I actually emailed with you about it several months ago, but didn't open a ticket until now. I waited because the issue seemed to go away, but I later discovered that it was because I had somehow set my guider to use the main scope instead of the guide scope. All my error reporting was way, way smaller than it actually was.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I am re-opening this ticket because I ran into this issue last night and was able to capture some guide logs. In short, my rig was guiding well and dithering every 5 frames. When it dithered, it would trigger one, two, sometimes 3 aborts of the image capture because it thought the RMS was too high (> 2"). However, on the guiding screen, the total RMS was still about 1" and I saw no bad spikes. I believe at some point Jasem mentioned fixing the calculation so we wouldn't see it jump to 5, 10" RMS after a dither... so the guiding screen doesn't show that artificially-high RMS value, but the capture module still aborts like it still sees it. I hope this log captures a couple instances of it.
Created attachment 134986 [details] Log The attached log should show a couple instances of this happening. It basically makes the "abort capture when guiding deviation exceeds 2s" feature problematic when using dithering.
I was not able to reproduce this, however I did look through the code and tightened up a couple things and am submitting merge request https://invent.kde.org/education/kstars/-/merge_requests/430 that will hopefully improve the situation. - The previous code suspended capture if there were 2 or more guide iterations that exceeded the stated guide drift value, even if they were separated by hours (in a single capture sequence). This now requires 3 consecutive guide iterations to exceed the value in order to suspend capture. - The current code exempted the states GUIDE_DITHERING and GUIDE_MANUAL_DITHERING from broadcasting its drift to capture, but didn't exempt GUIDE_DITHERING_ERROR, GUIDE_DITHERING_SUCCESS, and GUIDE_DITHERING_SETTLE. It's possible that some drift computed in one of the latter states found its way to capture, and caused capture to suspend. BTW, the current code doesn't check the RMS value. That is, it isn't looking at an average over past N samples. It considers the most recent guide deviation and makes its decision based on that one or two samples (or now, based on 3 consecutive samples).