After a year of being in the astrophotgraphy hobby, using a Nikon D850 DSLR as my main camera on a Star Adventurer Pro tracking mount and with an ASIAir Pro in control of my imaging sessions, I finally upgraded recently to an iOptron CEM40 mount. For autoguiding, I use a ZWO Mini mounted to an ASI120MM-S camera. In general, I love how the AAP greatly simplifies an imaging session, and once I finally resolved connection issues so that it would recognize the CEM40 mount, I began to use it with some measure of success and greatly enjoying the convenience of goto functionality.
Unfortunately, I also encountered some issues that appeared at first to be related to the occurrence of a meridian flip, and although I had made certain that Daylight Savings Time was off for my mount, the issues persisted and I started going through efforts to try and discover some repeatable series of steps that might aid ZWO in duplicating those issues. However, given their unpredictable nature, I've been unable to identify a set of test steps to try. That said, in my most recent testing last night, the problems seemed to be increasing and none of them were related to a meridian flip, as no flip had occurred within my 2.5 hours of imaging. What I observed did further convince me of my suspicions about the root cause of the problem, and it surfaces as stale screen images, goto centering errors, and other activities depending upon obtaining a valid plate solution. It could be my specific AAP is failing, and if I could immediately swap it and try another, I would, as I really love how easy it makes an imaging session. However, there is also enough similarity I see with problems others have spoken of in the Facebook group for the AAP that I do think the root cause is more complicated than my simply having a bad AAP.
I know ZWO is aware of the plate-solving issues the users of the AAP has been experiencing, but I don't think anyone has suggested the following, which I now believe is the root cause:
*** There is apparently a cache or buffer area where the AAP queues up 1 or more images and that area is not being properly erased or flushed to prevent either of (1) old image data being displayed on screen or (2) an incorrect pair of images being used for a plate solution. ***
Example issues I've seen that such a root cause would result in:
(1) The most obvious....perform an image capture at a clearly different location from a previous capture, or simply cap the lens. The displayed image after the "spinning circle" indication, remains as the old image.
(2) Perform a goto and observe the initial landing location seems roughly correct for the intended target, but the target centeriing fails to validate after a test image is captured, and the resulting corrections are more extreme than is reasonable for a moderate offset.
(3) Perform a plate solve and note the reported RA/DEC coordinates, then perform a goto for different target. When the goto is initiated and first reports the current location and the desired target location, the current location is not the same as given by the plate solution previously performed.
(4) A seemingly successful goto (I had chosen Alkaid), yet one which fails the target centering validation and is cancelled before another attempt. The image capture for centering validation is a brief one yet it is loaded and appears to be a new image on screen. However, upon performing a plate solve and also annotating the image, the target is identified but is significantly incorrect (Polaris was shown).
Adding one further complexity to these problems: During an Autorun to capture Light subs, I capped the camera lens to produce some blank images, expecting to likewise see the Autorun screen update to show a blank image for each, and it did not. After the imaging session was complete, I inspected the FIT files save to my USB drive to the NEF raw files which my D850 saved, and I began pairing up the images between the two formats based upon their time tags matching very closely (within 5-10 seconds difference, allowing for different processing for the two locations of file storage. For the NEF files, there were two such blank images at the end of the autorun sequence. For the FIT files, there were no blank images!
This made no sense, so although uncertain that my approach was valid, I used the Windows "FC /B" command to perform a binary file comparison of one image file to the next file in the sequence. For the NEF files, all files proved to be different. But, for the FIT files some compared as being different and some as identical, in a very specific pattern. For 18 files compared and which I will just name as 1 through 18, I observed the following files as the same image: 1&2, 3&4, 5&6, 7&8, 9&10, 11&12, 13&14, 15&16, 17&18. I will call these "successive pairs". However, the "linking pairs" were different images: 2&3, 4&5, 6&7, 8&9, 10&11, 12&13,14&15, 16&17. At the very least, if one was only using their FITS files as their working images to be stacked, then there will be some missing files that may help produce a better image stack. At worst, the existence of duplicate files seems likely to introduce the risk of erroneous plate solutions and whatever behaviors may result from that.
I have a 2.5-hour video covering my most recent testing, but I really need to go through it to pare it down to the most meaningful details before it might prove worth sharing. Likewise, I have the PHD2 log and Autorun long, but a cursory review of them only shows me that guiding is working and accurate, consistent with the nature of the problems I observed which are not so much about guiding but instead about stale image captures and how they affect plate solves. I honestly feel the video and log files are unlikely to provide any further information of use but I'm happy to make them available once I edit the video to a shorter and hopefully more usable length.
I apologize for this very lengthy message, but I do hope the breadth of problems observed and yet how I believe they share a common root cause is helpful in ZWO finding a solution for the AAP's erroneous behavior.