Need help with some issues with


Hi Ken, last night I had few troubles with SGP and I hope you can help me out. They all in one log here:

I’ start with PlateSolve2, it seems that PS2 get’s bad hints or something else, because its always failed to solve the very first frame of the centering. After fail, it drops to Astrometry’s blindsolve, solve it, move it again and then PS2 works in just a second. Seems like blind solve give more hints or more precise hints for PS2? I tried couple of times, slew the mount to somewhere else, reset the sequence and run it again. The same thing, first frame fails to solve, drops to blindsolve then solves fast and center.
My camera angle was set to 0 in sequence, while after solving it shows the angle is 180 deg. Could that be a problem?

(P.S. Trying to solve the mystery, I can see that at 20:30:05 PS2 gets hints of RA 16.74 and DEC 90…weird, were from those numbers came from? That is totally of the Targets coordinates. At 20:33:18 that happens again…)



I am honestly not sure… These two log snippets are representative of a solve that doesn’t work and then a solve that does work (respectively):

C:\Users\Sergio Kaminsky\AppData\Local\SequenceGenerator\PlateSolve2.exe 4.38268989203048,1.57079632679490,0.00842969788029,0.00629651768341,999,C:\Users\Sergio Kaminsky\AppData\Local\SequenceGenerator\Temp\

C:\Users\Sergio Kaminsky\AppData\Local\SequenceGenerator\PlateSolve2.exe 4.38268995121377,1.57079632679490,0.00842969788029,0.00629651768341,999,C:\Users\Sergio Kaminsky\AppData\Local\SequenceGenerator\Temp\

They seem to be the same really so I’m not sure. Maybe saving the image that failed to solve and sharing it might provide answers, but all the hints look to be good (maybe). Is your dec really exactly +90? Seems very exact… how did you perform the initial sync to the mount?

PS2 does not require a camera angle hint to solve.


Thank you Ken,
unfortunately, the image is gone. I didn’t sync the mount initially, I never do, I just make sure that I’m very good polar aligned and set precise home position, then I start the sequence with “slew to target” enabled. The scope always land very close to a target and solve and centers from there.
I figured out that those coordinates RA 16.74 and DEC 90 are actually of the home/park position. But if I understand it, after the first slew, should PS2 get the hints from the mount, when it actually points after the slew? According to logs, after the slew, he got hints of parked position (RA 16.74 and DEC 90) then of course it fails.
If you say that I have to sync the mount first, what comes to mind, is that I should disable “slew to target” option, then when I run the sequence, it will take the image while in home position, solve it and then move the mount to target and center. Would that be a better way to do it?
Also, I just dig that my EQmod epoch in setup, was set to Epoch Unknown, don’t really know how that happened, but may that be the culprit?


I see the same thing, first solve of PinPoint fails, but astrometry does it and then the mount is properly synced …
Even with a mount that was synced on previous run and it even has the additional Ra Dec encoders …
So for me this is normal behaviour and not really an issue …



This probably explains it then. What your mount reports as its position and what you are actually pointed at are 2 different things so the initial solve will always fail.


Ok, just to mention that when I used local astrometry as main solver, that never happened. Seems like it was more forgiving or used wider search, anyway, I’ll look into it next time. Thank you!

The second issue seems like a bug, the camera cooler went off silently, without me knowing about it. I was lucky to notice this just when I started the sequence.
I was using frame and focus to check the collimation, at some point I wanted to zoom into image with mouse wheel but instead it raised FnF exposure, happens to me all the time, forgetting to click on image to zoom, anyway, it took very long exposure so I had to abort the exposure. Looking at the log 20:34:51, I can see that SGP reports that camera not connected, when it actually was, then connects to it, then switches cooler off.
While investigating further, I did search in the log looking for “Camera is not connected” and OMG, so many. But the camera were ON all the time, please have a look at this.


It is… it’s a blind solver and does not require hints. PS2 is not a blind solver.

I’m not sure this is a bug. It could be… we have certainly been wrong before… with stuff like this though, odds are generally against it. You need to know that your camera uses the same code that every other ASCOM camera uses (almost the entirety of our user base). If this were a problem, there is absolutely nothing about it that is specific to Atik and, as a result of this, would be way more prevalent in the forums (meaning that if everyone’s cooling turned off right before a sequence started, there would be a lot of posts about it).

Not sure what this means… there are only 8 of these log entries made (one for each time you started a sequence). Camera on and camera connected are not the same thing… If SGPro says the camera was not connected, it wasn’t… meaning the ASCOM driver reported that it wasn’t. We sent the command to connect. That was fine. Then the radio button that controls the cooler was in the “off” position so the cooler was tuned off.

SGPro does protect against this.

You seem to have SGPro set to cool the camera on sequence start rather than on camera connect. SGPro attempts to turn your cooler on when the sequence starts and gets this:

[05/05/2016 20:34:52] [DEBUG] [Main Thread] ASCOM Camera: Error when trying to set cooler power : CheckDotNetExceptions ASCOM.Atik.Camera CoolerOnSet System.Exception: Set CoolerOn failed (See Inner Exception for details) (System.Exception: Set CoolerOn failed)

The mystery is why your camera puts itself in a state that tells SGPro it is no longer connected. There is not a single line of code in SGPro that will attempt to disconnect the camera without the user explicitly clicking a button… You may want to check some things out on your side… The cooler was tuned off because the cooler state for the camera is set to off by default (when it connects to SGPro… this is normal). Then SGPro simply cannot turn it back on.

  • Is the camera connected via a USB Hub? Is it powered?
  • Is the USB cable verified good?
  • Is your ASCOM driver up to date?
  • Is your camera firmware up to date?

Troubleshooting this effectively would require the camera’s ASCOM logs.


Ken, as far as I know, all is up to date. Hub is powered and rest of the night was flawless. I connect camera manually and turn the cooler on manually. I don’t have option checked to cool the camera on sequence start. Not sure what to do if that is Ascom Driver probleWhen I start sequence I make sure that camera is cooled already. Not sure if there is Ascom logs for it, I’ll check later. All I know for sure right now that it went off without me clicking anything.


Well, I’m actually did clicked, I canceled frame and focus and cooler went off. Now i found this thread :Atik One filter wheel and cooler in unstable status, when Frame and Focus is aborted reporting same issue. But the thread is dead withiut any final answers.


As Ken says, the camera DRIVER logs are essential.

  • Check the Trace on checkbox in the camera driver setup.
  • Run to get the error. something similar to what you did to generate the SGP log above.
  • Post the SGP log and the camera driver log covering the same events.
  • The camera driver logs are in the "Documents\ASCOM\Logs " folder.

I’ve stressed the driver logs because I often get many sets of logs where I get everything but the driver log.

The impression I get from the SGP log is that the camera is connected and is working well, then suddenly is disconnected for no obvious reason. SGP tries to connect but seems to have trouble because there are errors from the driver but it eventually succeeds.

The reason for disconnection could be almost anything, a USB connection failure for example. The driver log will help to show what is happening, .



Thank you very much, Chris, I’ll definitely do that and post the logs here later today.


Well, I’ve been stressing my system for two hours at least, trying to reproduce the error and guess what, not a single error. Man, why is that our equipment have to always act under the skies…Feel like a fool right now…
Anyways, at least I know how to keep logs of everything now, next time I’ll be smarter to back up my claims.

Ok, now for the last issue.
I had “Set absolute focus position for first filter use” enabled. I had defined absolute focus position for Lum filter in Filters setup, but the focuser didn’t racked out to that position when sequence started. I also tried to abort the sequence, set different filter manually and run the sequence again, making it switch to Lum filter as first filter use and see if that helps. It didn’t and eventually I had manually click on Focus for Lum then the focuser racked out to its position and I started from there.


Sorry. We are unable to help diagnose this stuff without proper data. Specifically logs and the sgf file.

For what it’s worth, this is tested as working in, but it’s possible that you have some unanticipated combination of options selected (or not selected) that is producing a bug.


Ken, the log is the same as in first post, all happened in one night.
The sgf file here:
Thank you.


Ok guys, caught it red-handed last night!
Around 20:31:34 I have aborted FnF frames and from that moment Cooler Power stopped to receive it’s state. It’s just show 0 as percent, while actually camera cooler stayed on. Logs show that the CoolerOn false, but cooler stays on, as temp continue to report around -15.
I continued with FnF and then at 20:42:31 I abort the FnF again and more errors come. I raised FnF to 10 seconds and after finishing it SGP hang for 30 seconds to download that frame and when it did, the frame was unusable. I remember now, same bad frame ruined autofocus sequence last time.
Now I can see that amplifier is turned on for a sudden? Something is not right.
I uploaded SGP log :
camera log:
and bad frame :

At 21:15:43 , eventually it turns cooler of silently.


I really wish I could be of more help…

At first glance, SGPro logs appear normal. Looking through the camera logs, I see stuff I am not able to explain, like this:

20:31:34.826 CoolerOn get CoolerOn True
20:31:34.830 GetCoolingInfo flags Controllable, OnOffControl, Warming, level 88, minlvl 0, maxlvl 255, setpoint 0
20:31:34.830 CoolerPower get 0
20:31:35.998 CCDTemperature get 0
20:31:35.998 CoolerOn get CoolerOn False

There are no attempts to manipulate the cooler and all in the matter of a tenth of second the cooler goes from on to off…

Additionally, there is stuff in the log where the TEC query fails and then 30 seconds later starts returning good numbers:

20:43:12.989 CCDTemperature get 0
20:43:12.990 CoolerOn get CoolerOn False
20:43:12.990 CoolerOn get CoolerOn False
20:43:13.941 CameraState get cameraExposing
20:43:13.942 CameraState get cameraExposing
20:43:13.942 ImageReady false, CameraState cameraExposing
20:43:45.789 CCDTemperature get -15.03


The smoking gnu is probably just before the camera log fragment that Ken references:

20:31:34.036 AbortExposure
20:31:34.824 CCDTemperature get 0

AbortExposure seems to be what’s turning the cooling off, it shouldn’t of course.
There are a few more examples of this in the log - and a number of it not doing so.

All the ASCOM driver does is call ArtemisAbortExposure in the Atik driver.

@AstroScience, you need to contact Atik support. Give them as much information as you can, a link to the log files certainly.

I’ll send something to me contacts there but you need to contact them as well.