Chris,
What you are seeing with 1.27l is exactly why the ASCOM_COMPAT_SWAP_PSOP flag was added beginning with 1.27p. There is another flag, ASCOM_COMPAT_SOP, in EQMOD.INI. It controls the Pointing/Physical setting via EQMOD Setup, but actually has 4 different values (Pointing = 0, Physical = 1, None = 2, v1.24g = 3). I remember reading at one time what “None” accomplished, but can’t recall now. The “v1.24g” setting was added beginning with v1.28b based on an EQMOD Yahoo Group message thread (called Physical Setting, but it’s easier to find by searching for 1.24g) that is directly related to SG Pro. The user said meridian flips with SG Pro quit working with EQMOD releases more recent than 1.24g. So Chris Shillito simply added another flag to mimic the way things used to be reported. karambit27,you might want to try the “v1.24g” setting and see if that helps.
By the way, there is yet another flag, ASCOM_COMPAT_SWAP_SOP, but I have never played with it, never read about it and have no idea what it does.
At one point, ChrisS told me that there had been a long debate in the ASCOM community as to what SideOfPier should report. He also told me that CONFORM seems to report “OK” even when SideOfPier returns values that differ from the above diagram!
Ok, so much for the history of these flags. When I was writing my dome control program, the reasonable thing to me seemed to follow what ASCOM was expecting (in the documentation, if not in CONFORM). Additionally, my program uses DomeControl.cls (thank you very much for creating that – you saved me untold amounts of work), which expects SideOfPier behavior that matches the ASCOM documentation.
On a side note, as I recall, you own the Celestron driver. What does SideOfPier report in your case?
All of the above is not simply an academic debate. The fact that EQMOD has had to create different ways respond to SideOfPier calls tells me that applications and drivers are probably all over the place as to what they are expecting/providing. The result is the End User is left trying to find a common ground between Application A and Driver B and may find it impossible to concurrently use Application A and Application C. And the sad thing is that ASCOM was created to prevent all of that.
–Ernie
P.S. If it isn’t obvious from my comments, I haven’t started using SG Pro in the observatory yet. It’s not from lack of desire; I have it on the laptop and have been doing extensive testing with it. But taking the last step of implementing it in the observatory is out of my control right now. But soon…at which time, you’ll probably see more activity from me on this forum. 
