I've been trying to find some actual data on the subject but all I've found so far is recommendations to raise temperature "gradually" to avoid thermal shock. This is from the QHY163m manual:
>9. How to protect the cooler in QHY163M?
The cooler in QHY163M can lower the CMOS temperature to a value that’s almost 40 degrees centigrade below the ambient temperature. So you need to be careful to avoid thermal shock, which refers to when the cooler’s temperature rises or fall dramatically, the cooler is subjected to strong internal stress due to contraction principle. Drastic thermal shock can shorten cooler’s service life or permanently break it.
So when you begin to adjust the CMOS temperature, you should avoid setting “Cooler Power” to its maximum value, and you should gradually turn up the “Cooler Power” value. When you turn off the power, if the “Cooler Power” value is very big, you should gradually turn it down before turn off the power.
I also read that ZWO camera firmware has a built in 5minute period.
I don't know much about the sdk, but if it only accepted target temp, couldn't you just ramp it up by setting the target temp every T/N seconds, where N is the number of steps and T is the ramp time?
I just started getting my new setup (QHY163m) working on a fresh install of indi and temperature ramping was one of the first things i started looking for. Is there still no way to ramp temperature?
Even if it's not in the SDK it seems like an easy application level thing to implement (sgp does it). I would probably rather the application have control of it anyway tbh. Seems like it would be safer for the sensor.
Thanks for the reply. The problem requiring disconnect/reconnect happens literally every time I use looping mode and then stop it.
For guiding, like I said I just left everything the default because I wasn't sure what any of the settings meant. Next time I try I'll see if I can specify guiding through mount (since it is working with PHD2 through indi, I thought that much would already be configured). I don't plug anything in the guider port, I'm always guiding through mount commands.
I'm not sure about loose connections, I didn't touch the cables after setting up and after restarting it would work again for a while. If that's the cause than it is probably the actually camera port that isn't tight enough and other than trying to tape the cable to the camera I'm not sure how to test that out.
I use PHD2's looping mode when setting up, but I don't turn on guiding until after everything is aligned and then I slew to the target. Polar alignment will not even work while guiding (when both applications try to use the camera at the same time it starts giving errors and I have to disconnect/reconnect the SSAG)
Trouble with Ekos:
This past weekend I had a full night to try out an imaging run with KStars/Ekos/Indi on Ubuntu 17.04. While I did get a good number of Images I also had a fair number of issues. I unfortunately only had the logs set to normal instead of verbose, but I'll attach them anyway. The main problems I ran into (in increasing severity) were:
### Polar Alignment
Once I got all the astrometry.net index files installed and the local solver working this actually works fairly fast. Unfortunately, it does not seem very reliable. I could probably create a separate topic just for polar alignment, so I'll just breifly mention that (1) running it multiple times produces different results, and (2) it doesn't seem like it rotates the mount correctly (at least not how I am expecting).
While an inconvinence, this didn't really hinder the imaging session.
### Guide Camera Driver (QHY5)
I have a SSAG guidecam and it uses the QHY5 indi driver. For the most part this works fine, but I am constantly having to disconnect/reconnect it from the indi control panel. Any time an image capture is stopped/canceled (which happens every time a 'looping' mode is stopped), the connection to the camera breaks any any attempt to capture an image after that results in an error until it is reconnected.
While annoying, this also isn't a show-stopper, although I suspect if I was using a headless indi server remotely this might be more trouble.
I haven't been able to get guiding to work in Ekos yet. I don't really understand the settings, so I left them at default and just tried to calibrate, but it always fails. Maybe if there were a tutorial on this type of thing I could get it working, but for now I just open up PHD2 and guide in that (connecting through indi server).
This works fine but it doesn't allow dithering. Last night I tried a quick setup in my backyard so I could test the "external guiding" setting in Ekos and enable dithering. It worked successfully for the first couple of images, then one of the dithers failed with "timeout waiting for settle" and the image captures just continued without dithering. I aborted the run, and disconnected/reconnected to the guider, but after that happened it never dithered again (even though it would say that it WAS dithering).
This is a bigger hangup as my DSLR has a lot of pattern noise that shows up after stacking.
During both the weekend run and last night's run I was unable to complete a full sequence. Most of the times the image capture will just stop and hang, a couple times it showed a popup saying the indi server crashed. Once, KStars itself crashed.
The last thing that makes using Ekos difficult is the fact that any changes/settings in the Ekos/Indi control panels don't seem to persist. When I disconnect/reconnect indi (which I have to do quite a bit), all my setup sequences, settings, etc get reset to the defaults. It would be very helpful if these settings just persisted to whatever you set them last.
I use the bleeding edge ppa so I know things change fairly frequently, but I am surprised I am having so much trouble getting a full run to go smoothly. Maybe I have a particularly odd setup or am doing something wrong?
My setup is:
Canon 650D on a Celestron AVX with a SSAG guider.
the update stopped the spam, thanks!
Ah cool. I had a feeling it was coming from INDI (it happened when I used PHD2 with the INDI server). Glad you were able to fix it! I probably will not get to setup my stuff again till Monday so I'll try it out then.
Looks like I have 2.8.2, I'll try and update again.
That's just it, I have that disabled in the INDI control panel. I tried to disable everything I could find related to logging.
I attached a screenshot of a couple of the messages.
Looks like raw traffic logs, stuff like "COMMAND (.. hex numbers... )" and "RESPONSE ..." "NBYTES=2 ..."
kecsap wrote: As a temporary solution, you can go to the INDI settings inside KStars and select "Message notifications". This option will turn the INDI dialog boxes to desktop notifications. They will be still annoying, but the computer will be more usable until the root of the problem is fixed.
I'm using the Celestron driver with an AVX
I haven't messed with imaging in a while (it's monsoon season), but there was a clear night tonight so I updated all my packages and setup my stuff. I'm not sure what changed and when, but now when I try to run a guider (in ekos or in phd), I get flooded with "INDI server message" dialog boxes (or notifications). They seem to be displaying all the traffic to and from the mount for some reason.
For dialog boxes it makes the computer unusable, for notifications it's just annoying. It didn't do this last time I used it, and I cannot find any options that seem like they would control this, am I missing it?