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!

Hi Bill, sorry for your troubles! Please try to enable logging under KStars Setting --> Advanced (Look for the video in my signature on how to do this).

1. Will inform QHY as their driver sometimes fail to abort exposures.
2. Very odd, but with log file we can figure out what happened exactly.
3. I'm guiding with ASI120 and it's been doing great. This is just yesterday:



4. This depends on how accurate you want to get (configurable thresholds in arcseconds), and how well the mount responds to syncing by updating its internal model. At some point, I hope we can incorporate INDI Alignment Subsystem into LX200 based drivers so that they can benefit from mount modelling independent of the handsets model.

For IMAGTYPE, is there a standard for the string used? It seems each one defining their own strings.

Thanks. I just went in and set up the logging per the video. Glad to hear that the ASI 120 camera is working great as a guider, I got the -S one, but I think the only difference is that it supports USB 3, which of course the Pi is on USB 2, so basically the same camera. I will be putting it into a Celestron OAG on a Takahashi FSQ-106ED next week. That will be my main imaging scope, and I am looking forward to it.

About the accuracy of the slews, I really just care that the object is centered in the crosshairs and thus in the image FOV. I am not sure what that means in terms of arcseconds, so I just left that value at default. Any changes that make centering faster and more accurate I am all for. Like I said, getting centered on a DSO was easy, it was a single star that proved to be a challenge. In terms of actual AP, I would rarely need to center a specific star, although there are some objects where that would be useful.

IMAGETYP (note there is no E in at the end) is the standard for FITS image types (FLAT, DARK, BIAS, LIGHT). The string is usually all in caps too.