Hi Fred,

For 20 contiguous pixels you'd need say a grouping of 4 x 5 pixels above the background cutoff. This is a "radius" of 2.25 pixels. That would make the HFR around a pixel so its certainly possible to get some hits with an HFR < 1.

On the other hand with Thresh Multiple set to 2.0 you'll be extracting above the background noise about 95% of the time (2 sigma) so 5% of the time pixels above the background cutoff will actually be background noise (assuming the noise is gaussian). So its certainly possible to get a grouping of 20 pixels > background cutoff that are just noise.

If you zoom is on a star with an HFR < 1 so that you see individual pixels you'll be able to see whether it looks like a real star or not. If its just noise then there are several options:
1. You could increase Min Area.
2. You could increase Thresh Multiple.
3. You could specify a Min Size > 1 so stars with an HFR < 1 will be ignored.

The MacOSX nightly is broke again. May27th works, but the 28th has failed to build again.

I downloaded the OSX build dates 27 May and notes two issues before I quit it.

1. Immediately after selecting Capture and Solve, EKOS set my rotator to 360. This was unexpected, as normally it only rotates with LOAD and slew. I had never seen this action before.

2. Once it did the above, It no longer saw any of my plate solving index files. I assume it just lost the link to their location, but I don’t know why. No other previous version of KStars OSX did that.

As the night was clear and I needed to finish a target, I quit this version and launched one from May 11, which worked perfectly.

I’ll go back in and see if I can figure out what happened to the solver index files later today.

1. That's correct behavior for "Load & Slew" if "Automatic & Manual Rotator Control" was toggled.
2. Completely unrelated issue, did you check the index files settings? what makes you think it cannot see them?

Hi Peter,

It would probably be better to start a new thread for this. I don't think its likely that this is related to Focus changes, and I'm afraid I don't know much about the rotator code. A new item on the forum would attract the attention of a wider group of developers that may be able to help.

Also, can you clarify what you mean by "Calculate and Slew" - did you mean "Capture and Solve" or something else?

John.

Ok, I'll add a new thread after I do some more investigation.
Yes, I made a mistake with my description, which is why Jasem made his comment. I meant "Capture and Solve", which is NOT supposed to move the rotator as far as I know. It never did before, only "Load and slew" did. I have edited my original post.

Pit,

I've merged a fix for focus options not getting saved properly.

Great! Will test it ASAP (but we are plagued by a low-pressure system at the azores, and the mountain is in clouds since almost a week (

I also saw some changes regarding the fit ("long tail" whe the fit isn't good) As I also experienced those I'm curious if that helped...

The "long tail" change isn't merged yet as I'm still testing it. Its definitely an improvement but may need some further tweaking when folks with different equipment get to use it.

FYI, the macOS nightly build worked last night, but the win64 failed.

The fix for "long tails" is merged.

Played with all the toys last night...
FWHM...

Number of Stars works well for my setup...


Fourier Power...


Adaptive focus tracked the temperature changes through the night...

The new focus system works well, but I did find an issue where it would have the one side of the curve ended much farther than the other when I used filters with an offset.
For example my OIII filter uses a 250 offset. So when I use that filter, I notice that every focus session (which switches to LUM) has funky curve. The inside of the curve is almost soube the outside. If I don't use any offsets, this does not happen.