×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Feature Request -- Align to last image on meridian flip

  • Posts: 185
  • Thank you received: 28
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.
The following user(s) said Thank You: Mike
3 years 2 months ago #65979
Attachments:

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

  • Posts: 10
  • Thank you received: 2

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?
3 years 2 months ago #66056
Attachments:

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

  • Posts: 185
  • Thank you received: 28
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.


File Attachment:

File Name: Notes_on_l...9-31.txt
File Size:0 KB


File Attachment:

File Name: log_17-59-31.zip
File Size:3,055 KB
The following user(s) said Thank You: Jasem Mutlaq
3 years 2 months ago #66057
Attachments:

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

  • Posts: 1009
  • Thank you received: 133

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?
3 years 2 months ago #66070

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

  • Posts: 1208
  • Thank you received: 559
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
3 years 2 months ago #66071

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

  • Posts: 185
  • Thank you received: 28
I haven't used the scheduler yet. I often am making decisions on what to image as I go along.
3 years 2 months ago #66073

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

  • Posts: 1208
  • Thank you received: 559
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.
3 years 2 months ago #66074

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

  • Posts: 185
  • Thank you received: 28
Trying the scheduler tonight with a meridian flip expected to occur (unless clouds interfere).
3 years 2 months ago #66078

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

  • Posts: 10
  • Thank you received: 2

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.
Last edit: 3 years 2 months ago by Mike. Reason: Said NGC instead of IC originally.
3 years 2 months ago #66084

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

  • Posts: 10
  • Thank you received: 2

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.
3 years 2 months ago #66085

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

  • Posts: 10
  • Thank you received: 2

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.
3 years 2 months ago #66087

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


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:
[2021-01-16T18:57:23.720 CST DEBG ][     org.kde.kstars.ekos.align] - Target Coordinates updated to RA: "05h 47m 50s" DE: " 00° 05' 05\""
[2021-01-16T19:13:51.569 CST DEBG ][     org.kde.kstars.ekos.align] - Target Coordinates updated to RA: "05h 47m 48s" DE: " 00° 04' 27\""
[2021-01-16T20:03:35.263 CST DEBG ][     org.kde.kstars.ekos.align] - Target Coordinates updated to RA: "05h 47m 42s" DE: " 00° 02' 19\""
[2021-01-16T22:29:37.156 CST DEBG ][     org.kde.kstars.ekos.align] - Target Coordinates updated to RA: "05h 47m 25s" DE: "-00° 02' 01\""
[2021-01-16T22:46:19.177 CST DEBG ][     org.kde.kstars.ekos.align] - Target Coordinates updated to RA: "05h 47m 18s" DE: "-00° 00' 06\""

So you see last job has the last coordinate above. Next the meridian flip happens.
[2021-01-16T22:57:39.543 CST INFO ][     org.kde.kstars.ekos.align] - "Solver RA (86.55396) DEC (-0.00794) Orientation (-0.97348) Pixel Scale (6.46481)"
[2021-01-16T22:57:39.549 CST INFO ][     org.kde.kstars.ekos.align] - "Solution coordinates: RA (05h 47m 18s) DEC (-00° 00' 07\") Telescope Coordinates: RA (05h 47m 17s) DEC (-00° 00' 06\")"
[2021-01-16T22:57:39.550 CST INFO ][     org.kde.kstars.ekos.align] - "Target is within  00° 00' 01\" degrees of solution coordinates."
[2021-01-16T22:57:39.553 CST INFO ][     org.kde.kstars.ekos.align] - "Target is within acceptable range. Astrometric solver is successful."

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.
3 years 2 months ago #66095

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

Time to create page: 1.745 seconds