Will give it a shot tonight if the wx holds.

My roll-away should be...rolling beginning of April, so for sure I'll be giving this a try. I hope it will properly recognize galaxy cores as what they are

-Eric

Hey sounds great !
I'll give a try to this new module as soon as the weather is good.

Davy

I haven't check that part yet, but I should test it soon enough. I integrated yesterday to Guide module as well.

Are you planning to expand this to the point where it can be used for detecting exoplanet transits?
That would be cool! Can't wait!

I'll check it out next time we have good weather here. According to the weather frogs, that's not going to happen for another week, though.

That's a long way off... I'm not sure if SEP is suitable for that.

Finally, after spring break (kids), work travel, and terrible weather I got a clear night and a bit of time. I did some basic testing of SEP in the focus module that comprised of running the focus module both with the default of gradient detection and SEP. Gradient worked and selected a star. SEP did not. Instead it either found a hot pixel or a blank area and the focus module continued with attempting to focus. Obviously it failed.

Looking at the red circles in the focus module I see that SEP does find a couple of stars but also hot pixels.

Logs and a full-frame fits image, logs, and a couple of screen shots here:

www.dropbox.com/sh/btcc25a8gfl0xes/AAAbU...5ssa2dOYViq_Jca?dl=0

Right, I already found issues with SEP and fixed them in KStars GIT. I will use your frames to see if it still holds, thanks for providing the frames that's a tremendous help!!

So in KStars GIT, it detected all stars fine, and I didn't see any hot pixels gets picked up. Would be great if you can test that from the nightly PPA.

I am not sure if this is relevant for your SEP testing, because I experienced this issue also with the Centroid or Iterative method, but a frequent reason why the scheduler gives up and aborts is failure to reach proper focus.



In this case, I was imaging M101 (under adverse conditions, like a full moon, yes, I know that's crazy!) and that is a region of the sky that has relatively few brighter stars around for the focuser to latch on to. From the attached screenshot one can see that there was one aberrant reading (HFR 0.842) which the focuser, of course, never could reach again, resulting in failure and aborted schedule.
Would it be possible for the focuser to compute a more realistic HFR value from the aggregate of measurements and then use that as the basis to reach? As you can see, I already had set a pretty high tolerance, but if one erroneous minimal HFR value is too great an outlier that doesn't help either.

One other thing I just noticed is that in its many unsuccessful attempts to reach focus, the module dumped so many image files into the ~/.local/share/kstars/autofocus folder that the 32GB eMMC on my Zotac 332pico was close to being maxed out. The last unsuccessful focuser attempt alone had generated 4.7GB! As is, I have set up a script to clean out that folder every time at startup, but it would be advantageous to have the option to do so every time the focuser has completed a - successful or unsuccessful - autofocus run. The image files would not be required any more under normal circumstances after that.

I think I will disable the image logging in the next version completely. Since you're doing full-field, it already takes the average in the frames. You could increase number of frames so that it averages it even further. If you have a better statistical approach, checkout out ekos/focus/focus.cpp file and the function setCaptureComplete() where all the calculations for this are done. Any improvements are appreciated!