Thanks for this. I can now confirm my issue is user error or user misunderstanding. Hopefully, my comments below will be useful for others on this thread.
Using the standalone StellerSolver, I have computed the JNow centers of the first frame of the session, the last frame prior to the meridian flip and the first frame after the meridian flip. The difference between the first frame and last frame before the flip is 1'7" in RA and 5'41" in DEC. The difference between the first frame of the session and the first frame after the flip is 3" in RA and 2" in DEC.
There was another question on this thread about dithers. I dither every 5 frames for 5 pixels (~8 arc-seconds at my image scale) in a random manner. The number of frames before the meridian flip on this session was 179, giving approximately 35 dithers.
I guess one way to minimize drift issues would be to use the scheduler on a filter-by-filter basis. I can confirm that the post-meridian flip alignment with the scheduler was to the fits file given in the scheduler.
Trying the scheduler tonight with a meridian flip expected to occur (unless clouds interfere).
I haven't used the scheduler yet. I often am making decisions on what to image as I go along.
I had a similar misalignment issue after the flip last night. I have attached a zip file of the relevant log and notes on the lines where the coordinates can be found.
I have been babysitting meridian flips. When the routine starts checking the alignment I press stop until it stops. I then load a reference image for my target and hit "Load and Slew". This works well but is something I don't feel like I should need to do. Part of the reason I do this is I have seen the target name change sometimes after flipping. I don't care what the target name is, I just want to preserve my framing.
Last night I let the alignment proceed and captured about 12 of the 20 OIII subs on the Rosette Nebula. I have attached a screenshot of the integration (autostretched) as an example of the misalignment of subs before and after the meridian flip.
I recently purchased a G11G and wasn't getting meridian flips to occur. Setting the western go to limit at western limit -90 appears to have worked. I have only had one occasion for the flip so far, but it sounds like this is equivalent to the ASCOM guidance I have seen on the Losmandy and/or Gemini groups.
I broke down and compiled indi_asi_ccd and placed it in /usr/bin. This replaces a version from 21st August.
So far, it seems to be working .
I tried a reboot in the event there was something running I didn't realize, but that didn't fix it.
I prefer to use the more stable branch, and it looks like I will need to wait for Jasem to do the necessary update to that. Fortunately, there are clouds in the forecast for the next several days.
I just started up KStars/EKOS/INDI to capture some darks. The ASI camera drivers are telling me both cameras are in streaming mode, and I cannot reset the imaging camera to 16-bit because it is streaming. On the streaming tab, stream is off.
I'm running the following packages from the PPA:
All the equipment in this profile is from ASI, two ASI cameras, an ASI EFW and the ASI EAF. One of the relevant indi_asi_ccd logs is attached for information.
I now have a Davis Instruments Vantage Pro with a Weatherlink Live connection. The Weatherlink Live device is on the LAN and can be queried using http to get information formatted as JSON. I have written a Python 3 script for one level of monitoring the weather station.
I'm willing to assist development (or do the development with some coaching) of a driver for the Weatherlink Live (LAN connection). My C++ skills are limited to what has been necessary to get some Arduino/NodeMCU (and my 3D printer) projects running.
Is there any other interest in taking this on?
I implemented backlash compensation in my moonlite-compatible arduino code at
. I always move x steps beyond the targeted amount when moving outward and then move to the target inwards. As Jasem mentioned, the focus module just waits for the moonlite driver to report that the focuser is at target position.
Feel free to use the code or logic as you see fit for your implementation.