Potential Auto Focusing Bug

I wanted to start a new thread to let the folks here on the forum know of two (2) potential issues that been discovered with SGP autofocusing and a feature request to be added. Gene and Jared have been in contact with each other on this but I thought I would update the forum. I hope that is OK.

Gene is the ASCOM developer for the GCUSB_ nSTEP ASCOM Driver. We’ve been testing SGP’s Autofocusing to try to figure out why the delay Gene has programed into his ASCOM driver does not appear to work. The delay was added to help those of us that are using SGP’s autofocusing with the primary mirror and to see if a delay after moving to position would allow the system to settle, I call it “Ring out”, before the autofocus image would kickoff. What we discovered were two potential issues.

Issue 1 - Backlash Timeout – This timeout throws some type of error. Jared is aware of this and has identified the problem with a possible fix for the next release.

Issue 2 – Not honoring “IsMoving” on second and subsequent moves during autofocusing. In fact we’ve seen times were the image was kicking off while the focuser was still moving to position. Gene Sent Jared logs and a simulator. I believe Jared has seen this as well. Not sure if or when this might get addressed.

Both issues if authenticated might explain why some with primary mirror focusers are have difficulties with getting good V-curves and/or repeatable curves. I use both crayford and primary mirror focusers and seem to notice the issue more with primary mirror focusing. It might be because focusing with a moving mirror is more sensitive to small movements.

Now for my request – I would like to see a user selectable time delay be added to the Autofocusing process. I think something like is done today with mount settling option that allows the mount to ring-out. Anyway, I just wanted to get this out there and to see what other folks might think about adding in a user selectable delay to the Autofocus process.

Kind Regards,

I don’t believe this was an issue until Gene implemented the wait. We were checking that the current position equaled the requested position and in the absense of a “Wait” at the end of the move those things should be the same. Granted, we should have been looking for “IsMoving” but that has been problematic in the past as some, badly behaving, focusers would report False when the focuser was in fact moving.

This has been addressed and will be in the next beta.

This may be less of an issue based on the above fix. Need to validate that assumption. But as I type, it has not been fixed. Only noted that a timeout issue is likely possible for a long running focus move and it’s backlash counterpart.

If implemented it would likely be a per move delay similar to the telescope. So how you got there would not matter. It would be invoked each time a move of the focuser was requested, not just for AF.


I have been battling both issues ever since I started using SGP - but I didn’t know they might be related.

There are many aspects of SGP that seem to assume that autofocus and backlash removal will be very fast - but in my setups the backlash unwind can take 1-2 minutes - depending on the setup. My logs would often indicate a Timeout error - but the autofocus process would proceed normally.

In addition - once focus is found - SGP will display that autofocus is complete on the main dialog - but meanwhile backlash compensation is being applied and it will be some time before it is actually complete. One window says complete and the other says things are happening.

But for diagnosing the issue I can report that I have used multiple cameras and two different focuser drivers - and both the RoboFocus driver and the Rigel driver will create bad autofocus images - but only for certain cameras.

I had the problem with RoboFocus and SX, and I had the problem with Rigel and QHY174. I did not have the problem with RoboFocus and Atik, and I did not have the problem with Rigel and ASI 1600. Atik has a shutter and the ASI does not.

So I would greatly appreciate a user-settable delay after every focus move. I think there should be settable delay after anything moves: Mount, FilterWheel, Focuser, and Rotator. The Rotator delay probably isn’t needed - but it may be for some people.

Also I would avoid displaying “complete” messages when the process really isn’t complete yet.

Thanks for looking into this-

A little background first - Gene is the ASCOM developer for the GCUSB_ nSTEP ASCOM Driver. He programmed in a user selectiable time delay into a alpha GCUSB_NSTEP ASCOM driver to see if a small delay would help improve focusing for folks using the primary mirror to focus with. We’ve been testing SGP and the autofocus routine still seems to be ignoring ASCOM IsMoving. It appears as soon as the position during autofocusing is reached instead of waiting for the IsMioving to return false, it takes the image. I have several logs (both SGP and nSTEP attached), with different time delays and with and without backlash that I hope will help isolate the issue.

While doing more testing tonight I found another potential new issue.It appears that no matter what I set the OSC exposure time in the Auto Focus Settings Options box to, it only takes a 1 second exposure during Autofocusing.

I played around with different settings time and when I run the Autofocus, it only takes a 1 second exposure. See log with title “New Bug Found Today”. I looked in the SGP log for this run and it says 1 second exposure, even though I had it set for 5. So it looks like for some reason it is ignoring the exposure time. I’m now wondering if this might be related with what is causing the issue with not waiting for the IsMoving to timeout as well.

Would be interested in knowing if anyone else has noticed this issue with the Auto Focus time setting…

One other note, When I found this timing issue tonight I was not using the Alpha ASCOM driver.

I hope I didn’t overdue it with the logs but I thought comparing them might help.


<a class=“attachment"href=”/uploads/db2508/original/2X/3/341224cfbe35fcfcc16eb10e5cd3a3ce9ac81bec.txt">nsteplog174027123099 (Zero Delay).txt (64.8 KB)
sg_logfile_20170307173932 (Zero Delay).txt (44.2 KB)
sg_logfile_20170307174625 (10 Sec Delay).txt (41.4 KB)
nsteplog183141123099 (2 Sec Delay).txt (89.0 KB)
nsteplog185501123099 (4 sec Delay No BL).txt (48.7 KB)
sg_logfile_20170307183718 (4 Sec Delay).txt (52.3 KB)
sg_logfile_20170307183104 (2 Sec Delay).txt (54.7 KB)
nsteplog174723123099 (10 Sec Delay).txt (143.2 KB)
sg_logfile_20170307185257 (4 Sec Delay No BL).txt (59.8 KB)
sg_logfile_20170308193935 (New Bug found today).txt (57.2 KB)
nsteplog183758123099 (4 Sec Delay).txt (101.6 KB)

Hi @Jared

One more thought. The logs with the 10 second delay is very much different from the other in the fact that after the autofocus exposure is done, there’s like a 1-minute delay before SGP decides to move to the next focusing position.

I hope the logs help,



I have been using my asi-1600, which didn’t have a problem with the rigel focuser - but I still want to use my qhy5iii-174 - which had problems with autofocus.

Is the problem resolved yet? It seems like there was an issue with backlash compensation causing a timeout - and separately the focus exposures may have been happening without first checking if the focuser is moving.

Are the problems identified now - or are there still mysteries? I would like to know in case I have a project that requires autofocus with the 174.

Oh and I checked my logs and it does look like autofocus exposures take 2s for me - which is what I want. I will study it more carefully - but that part seems ok.


Hi Frank,

Have you tried to run the autofocus with something other then 2s? No matter what I set the autofocus control Exposure time to, it will only take a 2 second exposure. It would be interested to see if anyone else is experiencing this issue or is it something with my setup.

Also, I’m surprised other folks using the primary mirror for focusing have not mentioned or noticed these artifacts, blurred or trailing stars, during autofocuing. I firmly believe if Jared can allow for a small user delay before taking the focusing image it would be a huge benefit by allowing the mirror and the connecting parts to settle, ring out, before taking the focusing image.

I have not heard anything on this so I’m not sure if Jared is looking into this and/or considering if a fix is needed.


I only have the problem with streaked stars when I use an sx or qhy camera. I have no idea why it would be camera related unless there is some additional delay that helps.

The autofocus works very well with ASI-1600mm and with Atik383L+ - but it is pretty much useless with qhy5iii-174 due to streaked stars.

So that might explain why others aren’t having this problem.

As for the wrong exposure - I thought you were only getting 1s exposures - and my point was that my logs show 2s, which is what I’m requesting. There may be multiple places to specify the autofocus exposure - so maybe there is some confusion there. I’ll try to remember to test that next time.


I’m still not sure what people know and don’t know about this problem - but one thing occurred to me. Maybe the cameras that fail are the ones that are using too long an exposure - and it bumps into the subsequent focuser move? This is very different from having the exposure happen too quickly after the previous move.

I’m not sure if these things can be distinguished from the timing logs.


Hi Frank,

You are correct, I meant to say 1 second. The autofocus counts starts at 1 then to 0 so for some reason I got 2 stuck in my head. But yes, 1 second is correct. Anyway, it really doesn’t matter much because no matter what I set the Autofocus Exposure times to I get the same exposure time of 1 second.

Anyway, I hope Jared can take a look and maybe figure it out.


Hi Jared,

I wanted to ping this again to see if you thought much more about trying to fix the IsMoving bug/issue? If we can get the IsMoving thing worked out, Gene has an updated driver that will allow the user to select a delay so the system can settle in before SGP kicks the image request off during autofocusing.

I truly believe the best solution is to build a delay into the SGP autofocusing process, either fixed or user settable (much like the mount does), to allow for a very small delay, maybe 1 second, between focusing moves to allow the system to settle before kicking off the image. This isn’t important for folks using crayford focuser but I believe it is very important to have a delay for the folks using a primary mirror focuser.

Also, I haven’t had any clear skies so I have not be able to see what’s going on with why I cannot get the autofocusing to take anything longer then a 1 second exposure. If needed, see my previous logs I posted last week.

Kind Regards,

I was able to do a little more testing last night to find out why the autofocusing imaging time is stuck at 1 second. It appears when I have the manual rotator active in the sequence the autofocusing imaging is fixed to 1 second. Even if I have the autofocusing imaging time set to some other value it will always take a 1 second exposure. However, if I deactivate the manual rotator and run the autofocusing, the imaging time is obeyed during autofocusing.

I’m sure it is something I don’t understand with how the manual rotator interacts with the autofocusing process. I was always under the belief that I need the manual rotator active in my sequences so I can take flats as part of the sequence. I use the Alnitak driver so SGP can set the brightness and turn on/off the flat panel.

Anyway, any help on this would be helpful. Maybe I don’t need to have the manual rotator as part of my equipment profile to use the flat panel?


Hmm… that sounds all wrong to me. Can you post a sgf that shows this issue? I can’t think of any good reason that the rotator would affect AF.

Hi Ken,

As requested below is the Dropbox link to the Sequence Files. I included the sequence file as well as the equipment profile file. The file(s) were to big to upload here, exceeded the 1,024kb limit by 200kb.

Thanks for taking a look.

Kind Regards,

Not sure if related but in the log based on your sequence ‘Filter 1’ has an AF time of 1 second versus Filter 2 which is 4 seconds.

[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] >> FILTER 1:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] bActive: True
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] sName: None
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] nAfExposureTime: 1

And then this:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] >> FILTER 2:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] bActive: True
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] sName:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] nAfExposureTime: 4

All other ‘filters’ have bActive=False

Is it picking up AF time for ‘filter 1’ ?


I did some additional testing this morning on this AF issue.

  1. I simply did the following. (No eqipment profile was used and No Sequence was loaded)
    Camera = Simulator
    No Filter Wheel
    Focuser = Simulator
    When I run the AF this way the AF time is honored.


  1. When I run this way
    Camera = Simulator
    Manual Filter Wheel
    Focuser = Simulator
    The AF only takes a 1 second exposure.
    Even if I change the AF exposure time in the Filter Setup window, when I run AF with the Manual Filter Wheel active it still only takes a one second exposure.

When I either have No Filter Wheel or have the Manual Filter Wheel deactivated the AF works fine. There seems to some link between the AF and the Manual Filter Wheel.

Hope this helps isolate the problem.



Before I go deep diving through logs here, I just want to make sure the issue you are seeing is beyond this concept.

When you have no filter wheel selected, your AF exposure time is set here:

When you are using a filter wheel (manual or otherwise), you set AF exposure times individually, per filter, as seen here:

If this is old news to you, we can dig further.

Yep, Old news,

This first image below is showing the Camera and focuser connected, (Both Simulators) and in this configuration I have the AF exposure time set to 4 seconds. AF kicks off and runs the 4 second exposure.

This second image below I included the manual filter wheel connect and connected. I also have the AF exposure time set to 4 seconds. AF kicks off but only runs the exposure for 1 second.

It is very easy to reproduce and very repeatable. You don’t need any equipment profile or sequence loaded. Simply select the camera and focuser simulator, select whatever AF time you want and run the AF. it will obey the imaging time. Next add in the Manual focuser wheel, set the filters to whatever value you want. Run the AF and you’ll see that the AF image only takes a 1 second exposure. I’ve run the test on two different PC as well as the previous SGP Beta as well as this newest release, beta x.20, and in every case the AF behaves the same.

Hope this helps.


I think you mean you have it set for 3 seconds? Not being nit-picky, just making sure we aren’t talking past each other. Either way, 1s is not part of this equation. I’ll take a look.

Hi Ken,

Sorry, I should had been a little clearer, meaning the AF exposures were set to 4 seconds and the Filter was set to 3 seconds. I believe if you follow the way I tested it, it should be easy to verify on your end.

Thanks again,