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…)
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 …
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.
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, .
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.