I just introduced a new feature in 3.5.1-beta (nightlies) that you may be interested in testing.

This attempts to improve an issue I've been having, and I've heard others have seen, where guiding drift "spikes" can occur, e.g. right after autofocus sessions. For instance, see this Analyze screenshot .

What's happening is an interaction between capture, guiding and autofocus. When I image, I enable autofocus on filter change, and I also suspend guiding during autofocus. [The bottom checkbox on the focus tab in the settings sub-tab says "suspend guiding", and using that makes sense to me, as guiding and autofocus would seem to interact poorly with each other]. Unfortunately, though, without guiding, and with the focuser pumping in and out, the guide star can wander away from its target position during the minute or two of an autofocus session.

Thus, occasionally during my imaging sessions, my capture sequence changes filters, then autofocuses, and when capture restarts, the guide error is significant and it can take several guiding iterations to correct, during which the image is being captured. Further, if the target is sufficiently offset, or if the guide star wandered out of the reticle, the guider might fail to even find the guide star, and would then be restarted by the scheduler. A new guide star will be found, possibly with a significant positional offset from the origin image coordinates (and likely doubled stars). This happens shortly after the red and green focus sessions in the above screenshot link, and is the cause of the red RMS line spiking up.

I have attempted to fix this with a new capture control, and you can see the improvement in this screenshot .

The main change is this new capture-tab checkbox that, when enabled, causes the capture process to wait for a low guider offset before starting up a new image capture. This might be, for example, 2 arc-seconds (the default) as in the screenshot. Thus, if after focus is completed and the guider restarts, if the guide star is offset by 15 arc-seconds, and requires 4 guider iterations to get back to a < 2 arc-second offset, capture will wait until those guide iterations are complete.

In addition, Analyze now has a new graph. In the capture line below the Statistics graphs, there's a capture RMS graph, which plots the guider drift, but only uses samples when an image is being captured -- so it more properly reflects the "important RMS" that will be baked in to the captured image. You can see that in the 2nd screenshot above . I may ultimately remove the above rms (on the Guide line) which reflects ALL guide iterations (even when no image is being captured). For now I left them both in. I'd recommend using the new capture-only rms--which I believe measures what you want to see.

As always, please feel free to send bugs/suggestions.
Hy

Hy, that's terrific news! Thanks an awful lot for fixing a long standing issue that can also occur after dithering. At least it does here occasionally. I'm looking forward to using the new feature.

Ah, that's a very nice one, too. I had not noticed the new menu tab in the capture tab, but just activated it when reading this. It's nicely working. It doesn't report anything (in standard mode), but indeed waits until the guide deviation is lower than the threshold. Cool.

Won't rescue my night though, I'm afraid. The wind is really bad, strong with hefty gusts. Even at 30s I'll have to nuke most subs.
Ah well, at least no clouds

Is there a way to Analyze past sessions? I just upgraded to Kstars 3.5.0 (in the last week) and I did notice the new tab in the capture settings, the default was set at 2 arc sec, but I don't think I checked it when imaging. I am running a lot of verbose logs, because of both the new Kstars version and a new Rpi 4, so my question is can I run past sessions of the logs thru the analyzer? I admit I have not looked at that new Analyze feature at all, so I may be asking a question that has an obvious answer.

thanks,
Ron

Ron,

Yes, no problem. Take a look at this thread: indilib.org/forum/general/7597-new-kstar...analyze.html?start=0
Bottom line, you just click on 'Read from File' at the top, and navigate to the directory where .analyze logs are stored and select the one you want.

Some points:

• It does not read standard logs, it reads a new kind of log file ending with .analyze, which is stored in a sister directory to the standard log.
• The menu defaults to that location.
• The first post in the above thread documents usage as of August, which is very similar to today's version.

Hy

thanks, I will look next time I turn the system on. I assume I had to enable the analyze log at the beginning, or is that a default. Anyway I will look to see if I have an analyze log.

Ron

You do not need to enable anything. The .analyze files should be there already.
The 'Read from File' menu should find them, and you can see them too
if (on Linux) you look in ~/.local/share/kstars/analyze/

Hy

Yes, i was able to open up the analyze panel and load the other nights log. Great Stuff! Not knowing much about this panel I never set the Calculate HFR in the Kstars Fits option page. Is there a way to calculate hfr on past stored images? What I am actually looking for is a way to determine (quantitatively if possible) what kind of seeing I have on any one night. Can this be gleamed from data taken or perhaps set up a special imaging session (range of exposures?) that could be used to quantify seeing?

thanks,
Ron

There is no way at this point to calculate HFR for past analyze logs that don't have it.

Don't really know what to say about the seeing question. HFR is certainly related to seeing, but has other factors, e.g. guiding/tracking, focus, the altitude of the target. It is also an average of the HFR of many stars, some brighter, and hence, at least for most telescopes & cameras, larger than others. Perhaps the HFR of a particular star at the same or similar altitude on a short (e.g. 1s) exposure might correlate with seeing? Or let's say, the same altitude, and same magnitude, but doesn't have to be the same star? I'd say it would be a worthwhile research project for you to find a good way to measure seeing! Do you know how it's done professionally?

Hy,
thanks, you must be in management, you know how to deflect a question back at the questioner!

I was really asking if there is a way to measure HFR from past images, not the logs. Can I load an image into the Fits viewer and have it calculate the HFR in that image?

No I don't really know, people use the Bortle scale, but I feel that is pretty subjective. I guess I am looking for a quick way to determine whether I am wasting my time on any particular night. Usually twinkling stars says there is too much upper atmospheric motion. My mount is old, so I don't really know if poor guiding is do to my mount or the conditions. I try to image high in the sky as I have a lot of trees around anyway. I am thinking of a routine that says image nearly vertical, take some images, measure star size over a few extended exposures (with the main imaging camera) and determine if the your seeing the kind of star size and eccentricity that is conducive to 'better' images?

thanks,
Ron

Yes, you can use fitsviewer to see the HFR in fits files.

Just open up a fitsviewer (e.g. from the kstars file menu, just click 'Open Image').
That would give you the HFR on the status line below the image if you've configured KStars/FITS to do that.
To configure that, open the FITS settings (e.g. in Kstars' settings menu, click configure KStars, then go to the FITS tab on the side, and make sure 'Auto Compute HFR' is checked.
You might want to also select 'Quick HFR' which will speed things up by only using the center 25% of the image to compute the HFR.

Please let me know if that doesn't do the trick.
Hy

What needs to be done to see the HFR plot? I have enabled the options in FITS settings, but the values are not loaded, not plotted. There is a value -1.