I have a QHY10 camera and I’ve noticed an issue with SGP for a long time. If I start SGP with no profile and just connect the camera, it starts cooling even though SGP indicates that the cooler is not on. This may be an issue with the camera in that it auto starts, however, looking at the SGP log it appears that SGP may not be checking the cooler state when connecting. It strikes me as strange the cooler is on just by connecting but the ASCOM standard does not address this issue. Nevertheless, SGP should be showing the correct state of the cooler after connecting. Alternatively, SGP could set the cooler to a known state (e.g. OFF) when connecting. Here is a short log that just connects and disconnects the camera. While the camera was connected the temperature was decreasing.
OK, Thx, we’ll take a look.
I don’t understand this. If there is no profile, then there is no attempt to alter the camera’s cooler in any way. I verified in the logs you sent that the cooldown process is not started. Specifically, we would see a line like:
TEC Change: Starting…
if it had…
Might need the QHY logs to see both sides of the story here.
We do actually check… reviewing the code, it’s almost the first thing that is done. We would also need the QHY logs to see how the camera responds to that query. That said, I did add a little more trace code on the SGPro side, but it still may not answer the question.
We used to do this, but removed it because it placed too much thermal stress on cameras when, for whatever reasons, they were connected and disconnected several times (in a short period of time), so we added code to detect and show the camera’s state on connecting (and, as such, respect the current state of the camera upon connect).
I’ll see if I can figure out what is happening on the camera end. However, to restate what is odd on the SGP end.
I connect; SPG says the cooler is off yet the temperature is decreasing. So perhaps the camera is lying about the camera cooler state.
Right… there is something weird going on here… some unforeseen combination of parameters that is allowing this to happen. It seems to be working out in your favor though (rather than the bug not allowing cooling). The trace code I added for the next beta should help clarify how SGPro allows for cooling when the cooler is off (I hope).
I just finished two tests to isolate this issue. The first test I used SGP to connect to the Simulator Camera to see what SGP was doing. I noted that SGP was polling the camera at 1 second intervals and it checked CCDTemperature and PowerOn. I noticed that it was checking PowerOn twice for each poll.
For the second test, I created a stand alone program that connected to the camera ASCOM Driver and then checked PowerOn, CCDTemperature, and PowerLevel. I found that PowerOn was false but PowerLevel was increasing and Temperature was decreasing. The only way I could find to sort of stop the cooler was to set SetCCDTemperature to CCDTemperature. It appears the driver ignores the PowerOn value.
Despite this driver issue, if I use an SGP profile that sets the cooler on connect, things sort of work out because SGP is setting SetCCDTemperature which does control the cooler even though it can’t be turned on or off.
So the reported behavior appears to be an ASCOM driver issue, however, you may want to look at the camera polling code to remove the extra PowerOn check.
Right. Thx for the report.
I have used this camera also and I wondered the same. What I was thinking though was if people get this cameras FAN confused for the cooler… The cooler is a TEC cooler. The FAN is simply there to maintain airflow over the TEC when it is running… As soon as you apply power to the camera the FAN starts to run. The TEC will most likely still be off although I honestly haven’t checked…
Yes, the fan seems to run all the time. From what I saw, the cooler is not cooling until you connect via ASCOM. So the fan and cooler do seem to be independent.
Just a quick update on this issue. QHY has supplied me with the existing ASCOM driver sources and the CoolerOn property does nothing but set a local variable. I’m trying to get some lower level documentation to see if I can tweak the hardware driver but so far they are not able to locate it. They are about to take a vacation break until Feb 7 so stay tuned.
It might be worth looking at the SetCCDTemperature property, that could be where the cooler is being turned on.
AFAIK the intent of the ASCOM specification was that SetCCDTemperature set the CCD temperature set point but didn’t change the cooler state and CoolerOn turned it on or off. But so many applications and drivers implemented SetCCDTemperature as turning the temperature on that it’s now the defacto standard.
With hindsight these properties should have been
bool CoolerState {set; get };
double CCDTemperatureSetPoint {set; get };
Chris
No, that is not the case. There does not appear to be any CoolerOn function via the driver. It seems that the driver initialization does it as a side effect.