OK, thanks - that was just for confirmation. I also have it unchecked, and for me it works as expected, several times in the last nights.

As per Jasems explanations: The image you posted, is that a comparison of the first image of your series with the first one after the MF? From the text I had assumed it compared two images directly before and after the flip. The target name in alignment is - AFAIK - a 'secondary' variable, i.e., it gets determined based on coordinates, but doesn't change coordinates. So it is not that it says "oh those coords are close to object XYZ, so lets change coordinates to those of that object". So the target name doesn't really matter, it's only the coordinates that do. And according to the log, the coordinates were the same before and after MF.

One question: Do you dither a lot and/or by large amounts?

Would checking "clear mount model at meridian flip" in options cause it to solve to the target and not previous mount location?

Sent from my moto g(7) using Tapatalk

The pictures posted were by RDBeck, so I can't speak to those exactly. However, I pulled my own data from before and after my meridian flip and have attached it here. Apologies if the images are hard to see - it's probably a combination of light pollution and reducing the file size.
- Pre-Flip image: image immediately preceeding the meridian flip
- Post-Flip image: image immediately following meridian flip and (re-)align
- Misalign - Stack: the stack of the two images to show the magnitude of the misalignment
- INDI_log..._shortened: the log with most of the night removed to show only around the meridian flip
- INDI Log Explainer: what I think is the relevant alignment debug messages (apologies about the wave of guiding and focus debug messages - I've recently worked/solved an issue there but hadn't changed the logging)

I've pulled the INDI log and clipped about 10 minutes on either side of the meridian flip (3:09 to 3:38, with the flip happening at 3:28-3:29). If you want the whole log, I can provide that too, but it's 8 hours of info. As best I can tell, the meridian flip target should be RA= (11h 20m 02s) DEC= (12° 58' 36"), but once all is said and done, it syncs to RA (11h 17m 43s) DEC ( 13° 43' 12"). Dec is pretty far off. And I was using the scheduler here, so this all automatic - at least until I saw the misalignment in my post-flip image and stopped everything! It could certainly be a mis-configuration on my end, but I'm stumped - I've never seen this happen before.

To your other question: I do dither a fair amount, but it's still on the order of 10 pixels - so it shouldn't show as much movement as I'm seeing. I've also never seen that much movement from dithering over the course of a night, much less from one frame to another.

Jasem,

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.

Check your logs for this message: "Target Coordinates updated to RA"

What does it report? Check all the instances for the message above, and the first alignment post meridian flip. I couldn't find it in your log.

Jasem,

Thanks for taking a look. I found the following:

Start of M65 (From wikipedia: RA: 11h 18m 55.9s, Dec: +13° 05′ 32″)
[2021-01-17T00:11:06.679 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (11h 20m 02s) DEC ( 12° 58' 36\")."
...
<em>Followed by meridian flip (which is successful)</em>
[2021-01-17T03:28:12.544 Pacific Standard Time INFO ][ org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "11h 20m 02s" DEC= " 12° 58' 36\"" Hour Angle "00h 00m 16s"
...
<em>Followed by post-meridian flip alignment, but with unexpectedly large error:</em>
[2021-01-17T03:29:18.704 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (11h 20m 04s) DEC ( 12° 58' 51\") Telescope Coordinates: RA (11h 20m 03s) DEC ( 12° 58' 36\")"
[2021-01-17T03:29:18.706 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Target is within 00° 56' 44\" degrees of solution coordinates."
...
<em>Followed by unexpected coordinates:</em>
[2021-01-17T03:29:19.868 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (11h 17m 42s) DEC ( 13° 43' 12\")."
[2021-01-17T03:29:34.676 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (11h 17m 42s) DEC ( 13° 43' 12\")."

I'll note:

• I was using the scheduler, and that the target for the captures during and after the flip was M65 (RA/Dec listed above).
• There are other "Slewing to target coordinates: RA" instances, but they are after I caught the mis-alignment and stopped the scheduler and decided to change targets.

Thanks!