Better:

Could you provide "pelicano.esl"?

In the log, at 22:23, that scheduler file is requesting a slew to 20:53:21/44:06:26. As this is not what is visible on the screenshots, I'm puzzled. I'd like to say this behavior is "fixed" by D14679, but I can't confirm the symptom.

-Eric

pelicano.esl
TIA

Hi
Another session. A bit better but still missing a chunk...
log: drive.google.com/open?id=1xdimBwqfOstUNW6EFPlIJMqynCmlIRdS

In the third image, the one of the solver, you can see that first NGC 6857 gets resolved and then Sh2-100. I see in KStars that these two objects lie very close together so I assume that NGC 6857 was selected before the meridian flip and Sh2-100 after. The question is why?

Would it perhaps be easier to take the coordinates entered into the scheduler... everywhere?
And/or use the same epoch for both scheduler and align?

I don't think it is that simple. There are multiple coordinate epochs in KStars/Ekos (epoch of today which is actually set to 2018.6 which is mid-2018 and J2000.0) which have different applications in all this.

At first I thought that perhaps a mix-up of the epoch could explain what is happening. If you look at the first and second image then you'll see that the Scheduler claims to be at position 20h 01m 48s, 33º 31' 33". However, the plate solver shows it is pointing at 20:02:30 33:34:43 before and 20:02:47 33:35:20 after the meridian flip assuming again that in between the meridian flip did take place. Also I assume that the first image is from before and the second from after the meridian flip. Can you please confirm?

I looked at the J2000.0 and 2018.6 coordinates as stated by KStars:
So the J2000.0 position of NGC 6857 is what the Scheduler says it is pointing at. However, the J2000.0 position of NGC 6857 is not close to the 2018.6 position of NGC 6857 so there is no mix up there. However, it does look like the Scheduler uses the J2000.0 coordinates while the Plate Solver uses 2018.6 (or rather epoch of day) coordinates.

Perhaps the Plate Solver communicates with the mount and there are some conversion issues there that may explain the difference. What mount are you using? Perhaps you can put your gear in your signature so we don't have to ask

Hi. The mount is listed in my signature. Do you mean there's not enough detail?
It's a SkyWatcher eq6 with indi-eqmod connected via a eqdir cable to a hub and then to the computer. It's pretty much as it comes; nothing special. I used a canon 700d on a 208mm f3.9. Would the epoch thing account for over 200px?

**Yes, the flip took place: log drive.google.com/open?id=1xdimBwqfOstUNW6EFPlIJMqynCmlIRdS
Thanks for your reply,
Steve

Ah sorry I didn't see that. When you compose a reply and then scroll down to see the original messages then the signatures aren't shown!!!

EDIT: As for the different epochs accounting for the 200 px difference I don't know. My point is that after the meridian flip (thanks for confirming!) the position at which the solver decides that it is pointing accurately enough is very different from the one before the flip and the coordinates used by KStars alone don't account for that. Back to the developers to demystify this!

6857.esl says 20:01:48/33:31:32, assumed J2000. That is what the scheduler *must* use.

Scheduler starts and requests a slew to 20:02:31/33:34:44. This is perhaps unexpected, but as mentioned by @wvreeven there is a reference change.

The RA/DEC boxes are catalog coordinates, J2000. That is what is recorded in the esl file. When the scheduler requests the mount to slew, it provides true sky coordinates, that is catalog coordinates to which is applied precession, nutation, eventually light bending, and aberration. JNow.

Now, the coordinates from the plate solver (astrometry.net) are used as J2000 coordinates, eventually converted to an alt-az J2000 sync point for the mount, then logged as JNow. We can see the solution coordinates in the log being JNow 20:03:31/33:34:42 at 22:22:38. That is unfortunately 0.20828 degrees off from the requirement, which was JNow 20:02:31/33:34:44.

On a D=208mm f/3.9 scope with a Canon 700D, resolution is 1.09"/pixel, so 0.20828 degrees is an offset of 688 pixels from the original target.

After the flip, J2000 requirement is still JNow 20:02:31/33:34:44, and now the solution coordinates are JNow 20:02:46/33:35:34. This is an offset of 0.05389 degrees, that is, 177 pixels.

Unfortunately I'm far from being clear on this part of the code, and my offsets seem quite far off from expectations (although they seem proper for the xy to radec Nasa converter). Yet, there seems to be something off in the alignment procedure.

-Eric

It was sending J2000 to Ekos but Ekos expects everything in JNow. So this is fixed in GIT.

There is another option I'd recommend to turn on in Configure --> Ekos --> Capture --> Reset Mount Model After Meridian Flip

Hi. Thanks everyone
Will the he fix make it into tonight's build?
TIA.