This is a great idea. I manually do this now, but it is a bit hit and miss. Where i live the temperature difference between ambient and set point cooling is so high, rapid cooling or warming of a sensor may not be the best (shock to the sensor and dew freezing up).
So a simple time lag between ambient (when you first start the camera) and your final cooler set point is all is required to create a linear temperature ramp for a gradual cooling and warming up.
Hi all, I recently purchased one of the new Canon Mirrorless Full Frame cameras (Canon EOS RP). The camera connects and can be triggered (to some extent) via USB using gphoto driver, but no images are transferred and it seems to continue capturing photos even after the Sequence Queue has completed. Because it is such a new camera, it looks like gphoto drivers may have not caught up yet, so ill just wait until this happen.
The main reason for this post is the potential for control and capture via WiFi. The camera has the ability to tether via wifi (in either Station mode or Access Point Mode) which means one less cable to get in the way. gphoto has no support for this yet (apparently they are in the process of writing something for this), but the potential is huge.
Hi avarakin, what about fits format? Can you get it to spit out fits files??
I have an original EOS-M which connects to Ekos, but Ekos cant trigger or control it. Which is weird. I have read somewhere that Canon have disabled USB control on this particular model which is a pity. As you say they are a great little camera, low noise and light.
My question is if gphoto via Ekos can see the camera and can populate most of the camera information, maybe full control is possible? Would this be a question for gphoto developers or indi developers??
Hi all, i have a suggestion.
I understand this is an Indi/kstars/ekos development site, but why not spice it up a little.
I have been involved with this excellent project for a while now. And the whole program has come a long way and i think it is the premier astronomy hardware control package around.
But what is missing is what the package has set out to do, produce images. I know some people post some images, and i understand this forum is just for development, but i reckon a little competition will make it better. How about a say monthly (or quarterly or what ever) competition where members can submit one of their images, and Indi members can vote for their favorite image.
What's a competition without rules hey, so here are some to start the process with:
1. All images (obviously) must be taken using Indilib. This would be the only prerequisite.
2. All images must be submitted by a certain time , to make it fair for all. Something like the last Sunday of the month at a specified UTM so everyone around the world can submit their image by that time to make things fair.
3. All the images submitted are maximum size so not to overload the site, so say 1 or 2 meg max. If this happens the developers can decide on the size.
Then people can vote for their favorite image and the winning image can be announced 2 or 3 weeks later. and the winner can have their name and image in flashing lights on the indi website. And who knows, others around the world will see how good this thing is and use it as well.
No prizes or anything, just for fun. Because that's why we do this hobby. We will be able to see the sorts of images being produced by people around the world using this great piece of software.
Anyways, this is just a suggestion which i think will be fun.
I would start by looking here: gphoto.org/proj/libgphoto2/support.php
It will give you an idea of what DSLR's/mirrorless cameras are supported by gphoto.
Plus search through all the indi forums to see what others are using.
I use a Canon 550D, but any of the lower end Canons work with gphoto and are pretty light. Perfect to start with.
excellent feature. looking forward to trying it out.