Hi,
I'm new to KStars and Ekos. I have recently installed Astroberry 2.0.1. I used Windows / ASCOM / EQASCOM before.
I'm trying to take some flats with my Canon EOS 1000D and I seem to have an issue with exposure time.
I have some old flats that show an exposure time of 1/4000sec. So I set up a plan in Ekos - Camera tab, set Type to Flat, duration to 0.000250, count 5, ISO 800.
Ekos proceeds to take the exposures, but when I open them they are completely white. The exposure time shown is 1sec (that would explain the white as they would be completely overexposed).
I've tried several values below 1sec for exposure time but I always seem to get 1sec exposures.
How can I get very short exposures for flats?
Could it be because the camera is set to M mode? I tried changing the camera to Av mode but then the capture fails and I get an error in Ekos Control Panel:
[WARNING] Camera auto exposure mode is not set to either BULB or MANUAL modes (AV). Please set mode to BULB for long exposures.
thanks!
Chris
Read More...
Hi,
I'm working on motorising my roll-off observatory roof and ultimately I would like to control it from Ekos.
I understand this would fall under Dome control but I would only need the park / unpark (i.e. Roof close / open) functionality and not the dome rotation that follows the mount.
I'm fine with the mechanics and coding on the roof controller side (probably an Arduino).
The question is: is there an existing INDI dome driver that I could use where the communication with the controller is documented? I could then write the controller firmware according to that protocol.
I have done something similar with my DIY motor focuser where I found a project with Arduino code that simulates a Moonlite focuser ("myFocuserPro" -
sourceforge.net/projects/arduinofocuscontrollerpro/
) and modified the code slightly to fit my focuser.
I have Arduino and .NET coding experience, but no experience whatsoever with coding on Linux / INDI.
And I also want to build a motorised dust cap with flat frame light source later. I would have exact same question for that project.
I have found this page on the INDI website that talks about a DIY dust cover but this is not the way I want to do it (connecting to the RaspberryPi I/O pins directly. It would have to be over USB.
indilib.org/support/tutorials/165-diy-au...telescope-cover.html
Thanks!
Chris
Read More...
Thanks for taking the time to look at the flats again.
Do you think it is a big problem that they are very blue?
Read More...
OK, I got the solution for the FITS issue. Posting it here in case someone reads this thread later.
I had also posted the question in the DSS group on groups.io and got a pretty good reply there.
The issue is that DSS does not know the real bit depth of FITS files. It *does* know it for RAW / CR2 files. So DSS scales the CR2 files automatically to 16bit (in my case from 12bit). But since it does not know the bit depth of FITS files it does not scale them which makes them look 16 times darker.
The solution is to set "Brightnes" in the DSS FITS settings from 1 to 16 (for a camera with 12bit sensor). This will multiply each pixel value by 16 which is the same as scaling 12bit to 16bit (i.e. left bit shift by 4 bits). For a 14 bit camera you would need to set it to 4.
Full topic here if anyone is interested. Not sure if this can be viewed without an account.
groups.io/g/DeepSkyStacker/topic/73054745#23793
Read More...
OK, hat's what I thought it was without reading up on it.
I was just a bit worried because someone here suggested to use the sensor size in mm for "Pixel Size X/Y".
Read More...
Kaczorek wrote:
stash wrote: Radek , do you know why the Indi system,dealing with DSLR's, has Pixel size in UM but allows the X & Y in both MM and UM - which is correct? it seems both !!!!
I think pixel size just takes any float number. However it is assumed to be in um. At least it is my understanding
Kaczorek wrote: I would say it's typical pitfall Exposed frames always look totally black before you shift histogram to right. No matter before or after stacking.
...
OK, so it's just me then. I didn't actually stack them.
What do you get when you just load the light frame in DSS (add to list) and then click on it to see the preview? Does that show data for you? This is where I see it completely black, including the flat.
Yes, they are only 30sec frames. I will ramp up exposure time once I get guiding working.
Thanks for testing this for me, guys!
Read More...
Does that mean it is also wrong for my QHY5?
stash wrote: Your pixel size X,Y are wrong - surely they should be 22.2 and 14.8 ??????????
Thanks, I have added one FITS and one CR2 light frame to the same folder.
I'm somewhat surprised by your comment about my flats. It was my understanding that it was best to let the camera choose the exposure when pointing at the flat panel (light source). When I do that, my camera selects 1/4000sec. I then selected that in Ekos.
The next higher exposure setting seems to be 1/100 (0.001sec). When I use that the flats are over exposed. When I open the CR2 flat it looks good to me (if a bit blue-ish), but I'm by no means an expert...
Is my flat panel too bright? It's an old LED TV with the display removed and only the backlight left, which I made remote controllable. It is mounted on the wall in front of the telescope when it's parked.
Read More...
Kaczorek wrote: An example file would be very helpful here
1. When you take an image does the Indi viewer show the image as black even when stretched ?
No, the viewer in Indi shows the correct image, as does the Ekos dashboard ("Settings" tab)
2. Double check your frame settings and pixel sizes in Indi settings - I suspect this is the problem
Do you mean these settings?
Not really, the only reason why I tried FITS was that FITS is a standard and CR2 is a Canon proprietary format. I thought it would make sense to save my data in a format that is a standard for astrophotography to be a little more future-proof.
If that doesn't work (though I still wonder why), then I have no problem saving my data in CR2 format.
Read More...