Auto focus received a bad HFR value 2 times in a row!

Description

Auto focus failure, generation of negative HFR values. Do not see any obvious issue with the provided parameters in the interface. Each time, if and when the SGP autofocusing pulls the focus in, and at the initial center value, the HFR is very different from when ideal focus was attained. This is particularly strange.

Aprox time of issue: 10:17 PM

Link to Logs

Useful Info

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.457
.NET: 4.7.2

I have the same issue and posted my question yesterday, then I saw your post. I have no input so far from anyone regarding a solution. Have you heard anything?

No, I haven’t. But I keep realizing the only reason I updated my feather touch to something motorized was for convenience of motorizing it and not necessarily for relying on SGP to keep focus for me when system is unattended at night and every time a filter change is done, etc. I know that I can’t leave the system unattended for many other reasons. So sometimes I give up on this and sometimes I feel like I need to find the solution.

I don’t think SGP is working as it should. Nothing personal, SGP, but it would be nice if it would work.

Farzad

I’m also getting this happen at the start of every night. Did anyone find a solution?

@PeterGoodhew

Looking at the logfile posted by Farzad-k, I would say the problem he was having was due to uncorrected backlash:

AF Result Position #Stars HFR Quality
1 15080 6 5.29 na
2 15060 7 5.34 na
3 15040 7 5.35 na
4 15020 8 4.81 94
5 15000 8 3.67 98
6 14980 10 3.15 97
7 14960 8 3.30 88
8 14940 8 3.96 100
9 14920 3 5.77 56

The first non-trivial HFR change occurs at the 4th AF point at FocPos 15020: the first 3 AF measurements are wasted as the focuser movement has not removed the latent backlash. After this the AF curve follows the expected AF curve shape. Unfortunately, the first three AF results are included in the overall AF quality calculation that comes out at 56% which is below the necessary threshold and thereby causing an AF re-run. As the uncorrected backlash is still present, AF continues to fail.

I assume Farzad managed to resolve his problem but if not I suggest he change his Backlash correction to > 80 steps. Also I think 9 AF points per run does not give any quality improvement versus say 7 AF points and is unnecessarily time consuming.

Hope this helps

Mike

@PeterGoodhew

Looking at the logfile posted by Farzad-k, I would say the problem he was having was due to uncorrected backlash:

AF Result Position #Stars HFR Quality
1 15080 6 5.29 na
2 15060 7 5.34 na
3 15040 7 5.35 na
4 15020 8 4.81 94
5 15000 8 3.67 98
6 14980 10 3.15 97
7 14960 8 3.30 88
8 14940 8 3.96 100
9 14920 3 5.77 56

The first non-trivial HFR change occurs at the 4th AF point at FocPos 15020: the first 3 AF measurements are wasted as the focuser movement has not removed the latent backlash. After this the AF curve follows the expected AF curve shape. Unfortunately, the first three AF results are included in the overall AF quality calculation that comes out at 56% which is below the necessary threshold and thereby causing an AF re-run. As the uncorrected backlash is still present, AF continues to fail.

I assume Farzad managed to resolve his problem but if not I suggest he change his Backlash correction to > 80 steps. Also I think 9 AF points per run does not give any quality improvement versus say 7 AF points and is unnecessarily time consuming.

Hope this helps

Mike