Hello all,
Finally got a chance to stop messing with testing the software out and to get some photons. Unfortunately the clouds came rolling in once I was off and running, but I still managed to get a few frames.
Here is what I ended up with:
www.astrobin.com/full/285004/0/
Excuse the obvious disregard for flats, as I did not take any because I have plans to tear down my gear anyhow and this was more for proof of concept than anything else. The scope was a AT65EDQ and the mount was an AP1100GTO. 39 frames of Lum filter data @60 seconds (75 gain/12 offset) with the ASI1600MM-Cool.
A few interesting things popped up while I was getting imaging.
1. My QHY CCD Driver for the Orion SSAG stopped responding. This happened when the software was trying to abort a guiding attempt. I tried disconnecting the QHY in Ekos, and reconnecting it and that didnt see to help solve the problem. I was able to stop and restart INDI to get it functioning, but then my AP mount was lost in space so I had to get back to park 3 to start again. This made me curious if there is a way to tell INDI to unload/reload a single driver while it is still running. Perhaps there is, and I just dont know how.
2. When trying to use INDI Server to do plate solving, I got some really weird results. Like, it told me my focal length of my scope was 25000-something during a capture and solve, rather than 420, and sent my scope flying off to some land far far away, which I again had to manually intervene to resolve after aborting the slew. I am not sure why this happened, but luckily I was able to SSH the indexes off of the Pi, and just run it locally on my desktop I was controlling from which runs Linux. When I did that, I was told my actual focal length was 421.7, which I updated. Very nice feature! Astrometry.net being down all day long (right after I installed Ubuntu MATE on my desktop) was not cool! Thankfully I had a copy of the indexes!
3. Overall guiding was pretty good with the built-in guiding software. I was only polar aligned as far as RAPAS was concerned, which is usually off a bit on my system since I havent done the fine tuning calibration of it yet -- but will be doing so very soon. Anyhow the guider worked pretty well. Did dithering well too. I did notice that it is very picky about the tightness of stars on the guide camera. I had to make a few adjustments to get into more critical focus for it to work right, but once that was done it worked well. This may be a product of the QHY/SSAG camera, of which I have a shiny new ASI1200MM-S to take its place.
4. When using the align module, I was able to resolve in 3-4 seconds (when running it locally) but I do have to saw that for some objects, stars specifically, the align module took a very long time to get the object centered. I am talking about like 20 solve and slews to get Dubhe centered in my field of view. I tend to start my night off with easy star slews to get everything moving, and this was a bit concerning. I slewed to M81 and it only took a few solves to get it dead center, so I figured it must have had something to do with centering stars in some way. Any ideas?
Some really good news now...
1. Meridian flip -- went off without a hitch. In fact, I was doing some work for a class I am taking, and noticed that the telescope reticle was moving out of the corner of my eye on KStars. Initially I freaked out thinking some mischievous slew had occurred, only to find out that it went right back onto M81, solved to get it centered, and went back to work. Flawless execution, and that is the first time I have allowed automation software to do the flip for me.
2. Sequencer/Capture - I really like how these two work together. Reminds me a bit of Sequence Generator Pro -- but different. Its much faster to create entries for each filter in Ekos. Especially if you are going to input all of the same values, and just want to change the filter. Change filter, click button, done. I think yo ucan clone in SGP, but this was just way too easy.
And one suggestion
1. I noticed in the FITS header that the header name of FRAME is defined for each sub with the type of frame listed in text. While I get that the software can place LIGHT, DARK, BIAS, etc into the name of the file itself, shouldn't the name IMAGETYP be used instead so most processing software can automatically detect the frame type from the header, rather than the name? Seems like an easy fix that would save people some trouble if they forgot to check the box and went to process a nights worth of data in something like Batch PreProcessing in PI.
Just a thought!