I haven't used the scheduler yet. I often am making decisions on what to image as I go along.

OK, that is reasonable, but it is still possible to use the scheduler for on-demand right-now jobs.
It adds a little overhead, but not too much, and does make your imaging a little more resilient to
things like clouds passing by.

If you can, please try that. It might help diagnose the issue, and it might also be a work-around for
you until that gets fixed.

Trying the scheduler tonight with a meridian flip expected to occur (unless clouds interfere).

I’m using an EQ6-R Pro and I have the differential slewing unchecked.

I suppose I wasn’t super clear: after the meridian flip is accomplished, the align module starts. It completes its first iteration and notes that I’m misaligned by a few thousand arcsec. Instead of fixing the misalignment, it appears to choose a ‘new target’ at or near the center of the field of view. It then begins a second align iteration, finds its maybe 100 arc seconds away, and slews to this ‘new target’ rather than the original one.

In my image, my desired target was M65, while this ‘new target’ was the IC2695 target.

Generally, when I send a goto command from Kstars, the mount slews to it and aligns no problem. This was new to me. I’ll note that I was using the scheduler, though was probably only my second night doing so. Also for clarity: The ‘new target’ from the IC catalog (redundant, I know) was not on the observation list/schedule. It came out of nowhere.

The scheduler is indeed a great tool - I wish I had used it sooner, but I suppose now is the second best time to start.

As for the original issue: I was using the scheduler at the time the misalignment/target swap issue occurred.

Sorry for the multiple replies! For more context, I’m running the current KStars version (3.5.1) and one version behind on Indilib (1.8.7) on a RPi 4. I tried to update indi in the past couple of days but for whatever reason it didn’t work with the usual ‘apt-get update’ command.

Thank you Richard for providing the logs and the useful notes along with it. Let me offer an explanation on what is going on. Each time you start a new capture job, the mount position is recorded as the target position in the alignment module. We can see this here:

So you see last job has the last coordinate above. Next the meridian flip happens.

So from KStars point of view, all is OK. There is some progressive drift as you can see above when a new capture job executes. Align module resets Target Coords to the mount coordinates whenever a new capture process starts. I suspect if you solve the first image you captured vs the last image captured prior to the meridian flip, you'd find the progressive deviation above.

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.