I’ve been having trouble with SGPro’s autofocus on one of my scopes, on another of my scopes there is not this same problem. This problem doesn’t happen every time, sometimes autofocus goes as expected. What happens is SGPro goes through all the autofocus images and moves the focuser’s position the number of steps as it should, and plots the data points. But once it finishes the final data point and draws the green lines on each leg of the V-curve, it’s clear that the green lines intersect off to the side indicating that the focuser needs to be adjusted from where it started. However, when SGPro takes the validation frame, it moves the focuser back to the position that it started at. So its like SGPro has no problem talking to and operating the focuser, and it figures out the best fit for focused, but then it just moves the focuser right back to the original position which it clearly just figured out is not focused. Like I said, with this particular scope, when focus clearly needs to be adjusted, sometimes it will adjust the focuser, but most of the time it doesn’t. This never happens with my other scope.
The scope that this is happening with is my SCT which has a Rigel nStep focuser motor controlled by a MoonLite controller. My other scope which has never had this problem is controlled by the same MoonLite controller, but has a MoonLite stepper. My mount is an iOptron CEM60 which has a hub on the DEC saddle to help with cable management, and that hub has a RJ12 socket which I use to connect the focuser motor to the controller (I had to use a DB9 to RJ12 adapter on the MoonLite controller). I’m using SGPro version 2.5.1.17.
Heres a screenshot showing the autofocus graph and the starting and final focuser positions being the same. Dropbox - File Deleted
Has this happened to anyone else? What might be responsible for causing this?
The algorithm that SGP uses doesn’t necessarily put the focus at the intersection of the green lines. Ken or Jared can explain this way better than I can but I think there is also some weighting of the HFR values going on as well. You will get a validation HFR value at the end and for me it’s usually close enough that it doesn’t make a difference. If you are watching you can always hit the run again button.
For the validation frame I seem to never get as good of an HFR that was plotted at the bottom of the V-curve during the autofocus run (its usually ~.5 higher than the best data point). 1 out of 3 times I get that warning message that says something like the HFR is above the calculated HFR. This autofocusing has been a pain to get working reliably with good results with my SCT, but it works very good every time with my ES ED102.
I don’t see a problem, looking at your screen shot the best focus position in the focus graph is 22906, this is reported as the best focus position, and the focus position is 22906. The focuser has determined the best focus position and moved to it. Where did you expect the focus to be?
The focuser started at 22906. Looking at the results of the V-curve it seems like the focuser needed to be adjusted but it ended up right back at 22906. I thought it needed to be adjusted to about 22850.
I have had less out of focus V-curves with my other scope and it still adjusted the focuser a few steps. Heres that screenshot (notice how the starting position is 23119 and it found best focus at 23117, so you can see the starting position is still displayed when autofocus is complete, but in the other screenshot the best focus position is the same as the starting position).
We have 2 different ways to determine what is best focus. “Weighted Average” and “Slope Intersection”. We default to slope intersection but if that fails (for a number of reasons) we fall back on weighted average. Slope Intersection does what you’re assuming and places focus where the two green lines intersect. Weighted average requires a good deal more math and assumptions but it generally does a very good job as well.
I don’t really see anything wrong with either of these graphs. On the first instance “Slope Intersection” failed, I’m not sure why. It could have been because the slopes too different or because the calculated point is too far away from where it’s expected…or some other reasons I can’t immediately recall.
With the new focus routine you want to enable smart focus (uncheck the box), otherwise it will use the weighted average method and not the intersection of the curves. That may be why it put it right back where it was. The new focus routine is quite good at detecting out of focus stars now and the central obstruction is much less of a problem.
Hmmm. I’m not sure this is correct. Hopefully Ken or Jared can clarify. I thought what Smart Focus did was monitor the curve and if it is lopsided, restart the routine with new start points in the right direction. I didn’t think it forced a weighted average fit. I could be wrong though. I always leave Smart Focus enabled.
I also thought that SGP indicated that it got a good “intersection” fit by coloring the lines green. If one or both lines are red, I thought that meant that it picked a weighted average.
Last night I went back to the default setting of having smart focus enabled. A couple times when smart focus took over and it kept adding exposures on top of the 7 I had set, the stars were so far out of focus that none of them were being detected, yet smart focus would keep going another 300 steps out of focus for another exposure. Each time that happened I canceled the auto focus run after 3-4 exposures that SGP didn’t detect any stars. How many times will smart focus add an exposure when the previous didn’t have any stars detected?
Even though SGP wasn’t detecting any stars, I was still seeing a lot of them that I thought should’ve been detected. Is there a setting that will allow SGP to use those stars that were more out of focus?
SGPro does not anlyze previous frames in order to determine what to do next, but the AF routine does have a notion of “runaway focus” using ((2 * data points) + 1).
In order for us to better analyze what is happening to you, we would need logs showing the AF run and a full AFPack.
Possibly, but maybe not. If the stars were rejected due to size (too big or too small), you have some control over this. If the stars were rejected because the flux signal did not deviate from background sufficiently, then no, we don’t offer control over that.
I watched an autofocus run last night and noticed the same thing as Jamee. Autofocus completed and I had two green lines that intersected just to the left of the lowest point in the curve. SGP did not put the focus point at the intersection and just put it at the lowest point in the curve. The curve on the right had a lesser slope so I don’t know if that made a difference. Other times I notice that it uses the intersection.
I’ll run it tonight and save a couple of focus packs.
Here is a couple of autofocus runs I just did. The first set the focus well to the right of the intersection of the two green lines but the second run seemed to use the intersection. I will say that the focus point for both runs was about the same though. Maybe I just don’t understand how the autofocus routine works.
