×

INDI Library v2.0.7 is Released (01 Apr 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 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: 1220
  • Thank you received: 565
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: 1220
  • Thank you received: 565
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.

  • Posts: 1009
  • Thank you received: 133

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?
The following user(s) said Thank You: Mike
3 years 2 months ago #66100

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

  • Posts: 10
  • Thank you received: 1
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
3 years 2 months ago #66101

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

Time to create page: 1.382 seconds