The last two nights have been clear and that does not happen very often where I live. I may even get a third. That have left me 20 hours to play with SGP. Below are my experience and a description of the problems I encountered. Some of this may be related to settings or lack of understanding from my side of how things should work/be set up.

  1. Autofocus
    When it works, it works fine. But all to often it don’t. Most common cause it that it is waiting for the autoguider to settle. It may be waiting for minutes and at the end I have to abort. If the settling criteria is the same as I have set for starting a new frame, this is a bug. Not one single frame over these two nights has been delayed due to the guider not settling. The criteria is quite generous.
    In one instance the autufocus routine just kept going taking more and more frames. It made me hungry because in the end the screen were full of donuts. I had to abort.
  2. After aborting anything, autofocus or anything else, the first frame thereafter is empty. I mean really empty. Not even noise is recorded and all image statistics reads zero. The next frame though is OK. This happened several times over the night. I wrote about this in a post a few days ago regarding my ASI1600. This is a different camera, but symptoms are the same. So I think this is SGP related.
  3. Camera temperature
    While talking about camera, I was not able to set the temperature to -15 deg how much I tried. I tried numerous times, but no matter what, SGP showed that the temperature was set to -11,9 in the docking window. So I imaged at this temperature. But every time I restarted a sequence, the warning window appeared telling me that the temperature was not -15. If I had told SGP to wait, I’d still be waiting.
  4. Meridian flips
    They work fine actually, but centering there after not equally good in my opinion. It does its stuff, but if the PS2 solve is not within the 50 pixels I have specified it stops. I have to manually press Run again to get it into position. It never failed the second time. But if I did not babysit SGP at the time, that would have been the end of that sequence. This may be by design, but I would like the solve to automatically go on for as many attempts as required (user specified?).
  5. End of sequence
    I had checked the Park telescope when sequence completes check box. I went to bed after midnight seeing that everything was running smoothly. I disabled autofocus due to the problems above. Set the alarm to 6 in the morning, but something woke me up after a couple of hours. I found the the scope was parked, but the sequence was incomplete. There was still 49 frames remaining in the last event.
    PHD2 reported that the star was lost and the sequence was aborted. (Not blaming SGP for that!) Probably I had not opened the shutter wide enough, what ever. My point being: An aborted sequence is not the same as a completed sequence. The scope should not have been parked in my opinion.
    Some might disagree on this and maybe there should have been two check boxes, one for sequence end (for whatever reason) and one for sequence completed.
  6. Parking the dome
    In this version of SGP the dome will not park properly. I overshoots its home position by about 15 deg. This never happend with the production version of SGP and since I have not changed anything else it seem to be SGP related. I will look into this further, but synchronization between mount and dome is close to perfect except for parking. I’m using POTH to sync mount and dome. The dome driver is LesveDomeNet.

This became a lengthy report and it is mostly ment for the SGP progrmmers. But feel free to leave your comments.

Thx for your thought. Please provide logs.

It is the same. What led you to turn this on? That option is typically not needed unless you are a long focal length. If you provide logs, I can look. Testing here there is no problem.

This will be one of the areas in 4.0 where we take a better look.

This is literally the only report of this… I can’t say for sure, but it seems like there would be others. I cannot reproduce this. What is the other camera?

Showed that the temperature was SET to 11.9 or was reporting it was AT 11.9? Those are two different things and it’s unclear which you mean. Again, this is a pretty serious issue and there no other reports. I would need to see the logs to understand what is going on.

You need to increase the number of attempts. Centering is an iterative process and it seems like you have only asked SGPro to attempt 1 time. Take a look in the Control Panel in the Plate Solve tab.

Two things to add up.

If PHD2 is not run as Admin, aster the settle, the program will timeout.
With Native ZWO driver, you can only set gain and offset, but dew heater cannot be turned on.

Ken, as I said initially, there may be settings I have not set properly, or don’t fully understand. Reading your answer, is seems obvious that there is, :wink:

Having the settling criteria turned on seemed like a good idea. Anyway, that criteria should not prevent autofocus to continue as long as it don’t prevent frames from starting. It should be looked into.

Having blank frames after an aborted routine happened several times. This is an ASI294. My other camera is ASI1600. Se my detailed post on this. It has never happened with any other capturing software.
I will try again with the ASI1600 tomorrow to see if I can recreate this.

I set the temperature to -15. (That is my standard for the ASI294.) In the docking window, even though I set the temp to cool down to -15 in a few minutes, SGP refused to change the setting and showed -11,9 for the set temperature in the upper edge of the window. Of course, the actual temperature also stopped at about that temperature.

I’ll have a look at the settings for plate solve.

I’ll find the logs for this session tomorrow.

One final thing I forgot to mention in my initial report: A couple of times a frame refused to download. SGP said “downloading” and the progress bar was moving, but nothing happened. It was not downloaded. This may not be an SGP problem as there are more players involved, like the harddisk etc. But I’d like to mention it anyway.


I did look into this and was unable to reproduce that behavior. Logs will help here.

Are you using the ASCOM ASI driver or are you using the native ASI driver. There is a possibility that this could happen with the native driver (maybe? abort and restart is pretty common), but the ASCOM driver is widely used and should be solid.

SGPro shows this as a fraction. The “numerator” is the current temperature and the “denominator” is the temp the camera is trying to reach. Are you saying that you could never get the denominator to change to -15 or that the current temp just never moved past -11.9, but the denominator was at -15?

Lastly, have you made sure that all your ASI drivers are current? These drivers, at one point, went through a bit of a rough patch. It isn’t all that relevant if the camera seems to work fine in another application since we all access the camera’s in slightly different ways

I’m using native drivers, but when checking I see a new driver has been issued. However, I never saw these issues with the prod version of SGP using the same drivers.

Yes, this is exactly what I’m saying. It looked like 11,8/11,9. I could not get the 11,9 figure to change.

I have sent the log from that night to your support mail.

I have not have time to run any further tests on either camera (blank frame issue). Hope I can do that tomorrow.


You should strongly consider moving to the ASCOM drivers as we will likely end support for native ASI drivers once their ASCOM driver is stable.

Could be true. There have been some changes in how we talk to the native drivers in 3.1. We will try to look at this sometime in the near future, but, because it has a viable workaround (ASCOM), it probably won’t be prioritized.

Same as above. I am not sure what is going on here, but I bet it will go away when connecting via ASCOM.

  1. Autofocus problem are usuaully related to wrong autofocus settings, could upload some of your sessions so we can look at your autofocus runs and settings?
    If the autofocus keeps going it’s using the “smart focus” function, i believe this is limited at 20 images.
    You could try to disable smart focus to stop this behaviour.

  2. You need to change the autocenter attempts

  3. You should check the recovery settings, i guess you have not enabled recovery?

  4. You might want to try connecting directly to the dome in SGP, using POTH isn’t the best option if you can get it working directly.
    Also something to not is that Lesvedome isn’t a very good driver and it doesn’t use the best hardware board either, i helped a friend setup a system and we could never get it 100% accurate at ok slew speed, we had to turn speed down a lot or else it would skip steps. (we used grey code, it would never work accurate without grey code because of the dome not stopping instantly which)
    Check the log files for levedome for skipped steps.

For it to be accurate we had to set speed to around 8 min for a full rotation, that’s obviously way too slow when using it visually so we changed the system to Scopedome which now takes around 75sec for a full rotation.

Ole Alexander

I will have anoter look, but last time i checked I could not change camera offset as I remember.

I moved on to .359 and had a session last night.
I still experience the focuser keep going and going, creating donuts and has to be aborted. Luckily I did not experience any lost frames after the abort like I did last time. Hope this is a problem gone.

If the “Park scope on sequence complete” is checked SGP also parks the scope (and dome) if the sequence is aborted for some reason. Is this pr. design?

Another, and much worse problem I experienced was this:
After finishing one target, the sequence was set up to slew and senter at the next target. It slewed but when it came to sentering (plate solve2) it just stopped. The plate solve window was just sitting there doing nothing. No frame was captured.
After some minutes I tried to cancel. The cancel button changed to Wait and another 2-3 minutes passed without being able to close the window or do anything else in SGP. I tried several tames to plate solve the position with no luck. At the end I was so frustrated I closed the whole thing down and went to bed.

Smart focus is not in use. Experienced behavior is bug.

Done. :blush:

No I have not. Will do that as well. What does that mean, “Restart sequence when conditions are SAFE”?

Allow me to disagree.
I have used this driver for years and I have never experienced any problems with it. If the gray coder is accurately designed and produced, it will record azimuth correctly and send the dome to where it should be. At least accurately enough for the scope to look through the shutter opening. I can send the dome a full 360 turn in less than 60 sec, but I have extended the time to about 90 sec to reduce the motor load. To me it sound like what you experienced was a gray coder/read out problem. Not a driver/hardware board problem.
What other alternatives are there for a home built dome (hardware/drivers)?


This, or something similar, was resolved in I can’t help much without logs. Please let me know if continue to see it.

As for the focuser, we need logs to see what’s happening.

So I run last night session from .163. Unfortunately I did not have the opportunity to test the “Slew and Center” option. I was on the same target until the clouds rolled in. But I have a question regarding the plate solve. When it’s successfully done I’m left with the “Solve window” on the screen. I have to press Done to make it go away and start/continue the sequence. Should it not disappear by itself when the solve was successful?

Last night I had serious problems with the auto focus. Have you guys changed it in any way?
I was not able to get a defined focus point a single time as I remember. I had to go out an check if the focus motor was moving, and it was. So that was not the problem. It is a RASA8 scope so I can not see if the mirror is moving, but I’d be surprised (disappointed) if not.

I’ll send you the logs from last night and the night before.

Only when a sequence is actively running. When you run it manually, SGPro assumes you are present and might want time to redirect the results to somewhere meaningful.

Sure, there have been a couple of tweaks… nothing major, but bugs could still be around. I’ll look through your logs.

Still on .363 I tried to image last night. Not a single frame came though. They were all (6 of them) blank as I have described before.
I tried to switch to the ASCOM driver, but that had no effect. Then the frame would not even download.
Also, with this driver I can not set the Offset parameter and is is also difficult to see what gain settings is applied unless one of the predefined settings is chosen.
(Only had one frame attempt with the Ascom driver because the clouds rolled in.)
Do you want the log?

Heno - I am a long term user of SGP with a range of refractors, cameras and reflector scopes. From an earlier description, you mention donuts, which suggest you are using a centrally-obstructed scope. A have a 10-inch RCT and you have to be careful about how you go about AF. At the beginning of an imaging session I use Frame and Center on repeat, on a bright star and check I’m in rough focus. My AF routines will then take over from here and typically, my graphs will have a 2:1 ratio between best and worse star diameter. If you stray too far and get donuts, especially with short exposures and seeing, the HFD can latch on to a hot spot and get confused. Even though my RCT has drifted out of collimation over the summer, I was still able to get good focus with the latest quadratic fit method. If you are coming from another application that uses a single bright star, you need to make sure that the exposure length is sufficient. I typically focus through Lum and then apply an offset for other filters, which makes things quicker. If you look at the screen during the AF routine, it should be circling the detected stars. If it is only picking up a few, either the focus is too far out, or the exposures are tool short.
With regard to your camera issues - I have never had this with my old QSI camera but I have witnessed a few oddities with my latest QHY CMOS camera. It does not like being massively over-exposed before taking a ‘normal’ frame and other USB traffic that interferes with image transmission. I can only suggest to minimize USB traffic and, if possible, use a direct USB connection to the PC, rather than through hubs. If that brings no joy, you may need to do a little more diagnostics. In essence, if SGP sends the same ASCOM commands to all our cameras and we are OK, then it may be a local issue. I would check all the usual suspects, including firmware, driver and ASCOM updates. You can try something else with the camera through ASCOM (beware - some of the other apps use their own driver code and it is not immediately apparent). Lastly - cables, power supply integrity and connection reliability.

Hi, and thanks for your thoughts. The thing is that the scope is in focus (about) and when the autofocus routine starts it moves the focuser out, and then step by step inwards. Problem is it never stops. It should stop taking images after 7 or 9 frames, but it just keeps going taking frames, moving the focuser furter and further away from the focus point, hence the donuts.

Yes, it is going through a HUB. A direct cable is not possible (except for testing possibly). The thing is that if I change over to Shapcap or any other software it works fine. It only seem to happen with SGP. I will of course test this further. I also have an ASI1600 so I can take the cable out of the 294, without changing anything else, and see if that camera works OK. I need to do this when I have a ASI294/SGP failure because most times it works fine.
It is most annoying when this happen in the middle of a session and I might not even notice for a long while. I’m not babysitting SGP. And I should not have to.

We need more info- can you take a screen grab in one of the cases where it keeps on going? This still could be a settings issue. If the collimation is bad, BTW, the odd star shapes confuse most focus routines. Please note my earlier comment about other apps. Sharpcap has native drivers for ZWO as well as using ASCOM. You need to be sure you are not by chance hopping over an ASCOM issue.

I will try to remember this if it happens again.

Not sure what you mean by this, but I’m using native ZWO drivers in both SGP and Sharpcap.
Have not had time to test camera any further.