ChrisRowland wrote: You are right Wolfgang, the meridian flip slew move does not involve a meridian flip. It's possible that the flip has already happened, or that a guide command has blocked it.
alacant wrote: Hi everyone
The eqmod side if pier was fixed here and has worked perfectly ever since:
Eqmod users are fortunate in that we have accurate side of pier reporting.
@OP. Is there any way you could get a physical imaging camera to test this with align and eqmod? A DSLR with a lens would be fine.
Is your computer set to receive Internet date and time?
Cheers and HTH
OK, so the time of KStars is correct. When you take your hand controller, what does the mount say? If you take a look a the INDI EQMod tab, do the time, date and location values match with KStars?
That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?
It's not optimal, but you are right, that should not be a significant problem. By the way, you could add your own location with precise GPS coordinates.
With respect to location, I've set up KStars with the city of Ottawa, Canada as its location using its default coordinates in the KStars setup wizard. From my phone, it tells me I'm about 6' west and 1' south of those coordinates. Now if I understand the implications of that correctly, with no other data available, the mount would tend to aim slightly west of the true location of an object and thus it would tend to flip slightly *earlier* in time than it would were the precise coordinates known.
Plate solving has no effect upon this, it only helps to position the scope in the right direction.
So how would updating that with information from a plate solve affect it? I've already determined that an HA>0.2h has the same results, and that's more than the time difference introduced by my physical offset from the default Ottawa coordinates.
Sure, either the the mount was already on the eastern side of the pier before crossing the meridian or - vice versa - remained on the western side when the meridian flip function initiated a re-slew to the current target.
Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibility that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip?
Don't think that this helps. More alignment points improve the model but it does not have an influence which pier side the mount selects. This is only dependent on date, time, location and target position.
I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.
You do not need plate solving for testing it, it is sufficient if you have your mount running.
But that would have to wait for another clear night, not until Thursday.