SGP Attempting to perform Meridian Flip when it shouldn't

SGP appears to be trying to perform a meridian flip when it shouldn’t be. I started my sequence on M82 tonight when it was already past the meridian. This appears to have happened in other sessions. It successfully took 7 exposures and then decided to flip and never recovered.

[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 92.3798327010798 >= 0
[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[4/25/2015 3:07:02 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure

sg_logfile_20150424192328.txt (629.9 KB)

I’m not sure if we can be of much help to you as it looks like SGpro is functioning properly. The real question is what happened here (something internal to your mount driver changed):

[4/25/2015 2:46:20 AM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[4/25/2015 2:46:20 AM] [DEBUG] [Sequence Thread] Meridian flip not needed, telescope on East side

And then 20 minutes later, your mount reports something entirely different:

[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[4/25/2015 3:07:02 AM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 92.3798327010798 >= 0

Thanks Ken. I’ll try checking other logs. I am using an Atlas with EQMOD. I’m not sure if there are logs for it or not. It almost is as if the time is off I’ll check that as well

SGP for some reason does not report a time to flip when I am pointing at M82. If I point to a nearby star it displays the proper time in the bottom status bar.

I’m not familiar with eqmod. But I believe there is a setting about how it sends the pointing state and it needs to be set to physical. Otherwise it sends the incorrect meridian info.

So as Ken pointed out the pointing state changed without a flip taking place which is problematic.

Also the “time to flip” will display N/A when your scope is on the east side of the pier since the flip has occurred. When the pier flip is disabled this will change to “time to meridian” which does not take the pointing model into account.


If you do find out what the problem is, could you please post your solution as I use EQMOD and I’ve had the same problem.

Many thanks,


Looking at your images again I think this may be due to some “above the pole/under the pole” calculation issue. What should be happening is that your driver pointing state should actually change when your gaze passes above the pole. I’ll setup some tests in SGP and verify we’re handling this correctly.


It’s also worth mentioning that this will probably only occur when you’re imaging under the pole and transition above it. You could disable the meridian flip until your target gets a little above the pole and then enable it. Not idea but it should allow you to work around this for the time being.


I have EQMOD set to physical. Jared that makes sense. Slewing to various stars I did notice that the time to flip said NA when below the pole and gave a time when above it.


In May of last year, I corresponded with EQMOD’s Chris Shillito about the Side of Pier issue. There is a document in the ASCOM developers package called ASCOM SideOfPier Behavior which contains a diagram (provided below, I hope) that shows what their conformance program (CONFORM) expects the telescope drivers to report in the 4 different quadrants of the sky. At that time, EQMOD was reporting just the opposite. Beginning with version 1.27p of EQMOD, there exists a flag, ASCOM_COMPAT_SWAP_PSOP. When this flag is set to 0 (the default setting), SideOfPier matches what CONFORM expects; if the flag is set to 1, it reports what it did prior to v1.27p. There is no way to change this flag with the user interface; you have to edit EQMOD.INI. NOTE: HCSMALL (the EQMOD screen) still shows the old reporting method regardless of the flag setting, so the screen may not reflect what SG Pro is being told.

karambit27, I tested the software this evening and having EQMOD set to Physical puts the driver in a non-conforming state (according to ASCOM). It is in a conforming state only when EQMOD is set to Pointing.

Jared/Ken, I would be interested in what SG Pro expects in each of those 4 quadrants. I have a vested interest because when I wrote my dome control program, I coded it to match ASCOM’s expectations.


From what I’ve seen looking at EQMOD 1.27l their Pointing Side of pier option matches this diagram EXCEPT that East and West are swapped. This upsets SGP but allows domes to work correctly if the OTA offset is set negative.

Physical has Quadrant A as East and D as West. This is what SGP needs to handle the meridian flip correctly. Unfortunately Quadrant B is East and C is West and this means that the pier side changes as the mount tracks through hour angles +6 and -6. The pointing state should not do this. While it’s OK for SGP dome to mount synchronisation will fail for quadrants B and C.

Looking at the sources there are later versions of EQMOD which have this fixed - at least by providing more configuration options. I don’t know the state of these versions, maybe they are only available through the EQMOD Yahoo group.



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.


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. :blush:

Thanks StargateCO. I am running 1.27I for EQMOD. I have updated the EQMOD.ini file to 3 for 1.24g and will test to see how that works.

Hi Ernie,
Are you one of the EQMOD developers?

It’s been difficult to get any sort of consensus about what Side Of Pier (SOP) means, I think that it seems obvious so there’s no need to document it - or read the documentation. The trouble is that there are actually multiple interpretations of SOP.

We (ASCOM) have tried to document it clearly. We are trying to move from using Side of Pier to Pointing State, partly, I suspect, because this is less obvious so it’s more likely that people will not understand and seek clarification.

From what I can see the ASCOM compatibilty application detects the difference between physical and pointing state styles of SOP but not if East and West are swapped.

I’m trying to put together a Pointing State Checker application that will help users and developers have an idea of what should be happening.

Is the 2.71p version generally available?

I agree that getting this right is what ASCOM was developed for but it’s a huge job getting it right. People have a great talent for finding the smallest crack in a specification. Even to aspire to it is a bit of an achievement.



Nope, not an EQMOD developer, just a user/developer who likes to poke around to see how things work. Chris Shillito is the current maintainer of the code and has been for some time. Raymund Sarmiento of the Philippines reverse engineered the supported mounts and wrote the core routines.

I agree that the current definition of SideOfPier seems straightforward – once I got my hands on that PDF in the developer documentation. Figure 4 gave me four very concise locations to test the Pierside value so I could write my code accordingly.

The latest “official” version of EQMOD is 1.27i, located on SourceForge. However, the latest builds are available in the Files section of the EQMOD Yahoo group. The current version there is 1.28e. That’s where I go to get my latest copy and I suspect most of the other 5000+ members do as well.

Let me know when you get the Pointing State Checker finished; I would like to try it.

Is there a simulator version or Simulator Mode associated with your Celestron driver? I have another reason I’m asking. I’m currently creating a .NET version of EQMODLX, an application that takes Meade commands, translates them and passes them on to EQMOD, as well as Celestron and Astro Physics mounts. EQMODLX is used in conjunction with a satellite tracking program to vary the tracking rates of the mount as the satellite moves across the sky. I’m also hoping to use EQMODLX with Sky Safari to control my Orion Atlas mount.

Please don’t consider my comments as disparaging the ASCOM Initiative in any way; you guys have done a fantastic job. One of my first jobs when I joined Compaq Computers (and later HP after we were “assimilated”) was on the development team that brought the first Compaq-specific version of Windows NT to market. The number of specifications we encountered was endless (it still is) and every one had to be interpreted correctly. Those specifications are extremely difficult to create and sometimes challenging to implement, so I understand the challenge you guys face.

I’m hoping either Ken or Jared will join in at some point and describe how they are interpreting SideOfPier so I can figure out if I (1) need to change my Pierside flag settings within EQMOD and (2) need to create some “translation code” in my dome control program so that the parameters I pass to DomeControl.cls are still correct.



I would upgrade EQASCOM to 1.28e so you have the latest version.


Where can I get that version? On the sorceforge page 1.27I is the latest.

EDIT: Never mind I didn’t see your previous post.

I’ll pass the Pointing State checker around when I’m happy with it.

I don’t have a simulator for the Celestron driver but NexRemote can be run with no telescope connected and this serves the same purpose. I do a lot of testing that way because it allows me to check things on a multitude of different Celestron scopes, including ones I don’t have.