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.


It seems to me that the name of the last file saved and appropriate flags and associated changes in logic are all that are required to implement this.

I don't have a solution, but I noticed the same thing while imaging last night. I think it's more than a target name change. As you indicate, the pre- and post-meridian flip images don't align correctly.

Last night (see screenshot) I was imaging M65. After a successful meridian flip, the alignment process started. The first post-flip solution was off by a few thousand arcsec, but the second slew and align chose a new target (IC 2695) rather than keep with M65. It then claimed alignment success on the third alignment and restarted captures - on the new, wrong target!

This behavior seems to be similar to a "SYNC" rather than "SLEW TO TARGET", though I had the slew option chosen.

This seems to be more of a bug than a feature request - but maybe equally likely is that I've got something misconfigured.

Does anyone have suggestions?

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.

Well, AFAIK "Slew to target" does sync and then moves to the target. "Sync" will only sync, but stay wherever you are.
There is an option in Align, under Scale&Positions, to use differential slewing instead of syncing. I think it's intended for mounts that build their own pointing system. What is your mount and your setting of this option?

Not familiar with that code, but just to add my experience--I've done imaging with meridian flips the past two nights and had no issues. The align went to the proper spot.
I'm using the latest code, compiled on an RPi4 running Raspberry Pi OS.

I run with the scheduler--always--even if it's one capture sequence job. It seems to do a better job of error recovery, etc.
Are the folks who have been having issues running with the scheduler? If not, I suggest you try and see if that fixes things.
[Of course the underlying issue should be fixed as well.]

Also, @RDBeck, you should probably rename this thread as something like--Bug Report. Misalignment after Meridian Flip.
Hy

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.

Rendering Error in layout Message/Item: array_keys(): Argument #1 ($array) must be of type array, null given. Please enable debug mode for more information.

Please Log in or Create an account to join the conversation.