Offset Init & flip during SGP sequencing

Don W

Hi Martin,
You are trying to use Under The Pole, which confuses things.  What is your latitude of your observatory?  Refraction is a problem for imaging at or below about 30° altitude.  The Great Lakes USA are around 46° latitude, so Under the Pole usable for DSO's is about 16° of sky.  BUT, ALL DSO's that are Under the Pole will be OVER the pole in 6 months (or less).  That means for Comets go ahead and view Under the Pole, but don't use under the pole for any other target.

If you stop "testing" under the pole, you will not have any of your problems.

Now the settings I suggested to you a week ago set up to do a flip if the scope was GoTo an east target from the western side (making the mount "looking east". So What should your settings Be???

1. You want to have your mount flip to Looking east when you tell it to GOTO for your FIRST Target in the east - so check the box for "GEM Auto Flip GoTo.  Then set "Meridian Limit East to zero (over the pole).  Set the Meridian Limit West also to zero (over the pole).  This will make your mount always have counter weight down at the start of your imaging when the target is west of the meridian.

2. Do not check the box for GEM Auto Flip Track.  This tells the mount to simply STOP at the limit.  This is OK, because you are going to set the limit so the mount never gets there.

3. Set the Track Past Meridian Overlap to 90:00:00.  Now this will track all the way to the western horizon, never flipping nor stopping.  Note that you can't track more than 90° past the meridian because that would be pointing BELOW the horizon, and SiTech won't do that (purposely).  If you put 178° there it will fail.

Now check your setting for the Altitude Limit.  Realistically you should not image below about 30° altitude anywhere in the sky (because of refraction distortion.  SiTech has two ways to set the altitude limit on the Mount Parms tab: a fixed all around limit or using a tailored SiTech.hrz file.  When the mount gets to the altitude limit, it will simply STOP - no flip, no goto.

It is interesting that Mesu makes a flipless pier, but doesn't advertise the settings to use that kind of pier.  Does Mesu send Mesu mount owners a recommended setting for flipless operation?

Don W



Hi Don,

Apologies for the delay getting back to you. I’ve been conducting a variety of tests using my meridian settings compared against the settings that you kindly suggested, along with the default settings. I have some interesting findings to report back. But firstly may I just clarify my position, my requirements & hopefully better explain my problem.

I recently purchased the brilliant Mesu e200\Sitech combination for the following reasons:

  •          I’ve never read a bad word about either product
  •          I know the customer support for both products is second to none
  •          Both products receive nothing but praise & excellent reviews
  •          Superb tracking & guiding
  •          Excellent reliability
  •          No need for Meridian flips
  •          It simply just works out of the box
  •          Also with a bent knee pier I can image under the pole (within reason)

The e200 mount can be used as an Alt\Az, EQ or GEM purely depending upon how it is mounted. Mesu also sell a bent knee pier for ‘flip-less’ anti-collision operation. I opted to build my own bent knee pier to suit my dome.

SiTechExe can also be configured for Alt\Az, EQ or GEM mode of operation. So as I see it, it’s simply a case of matching the mode of operation to your type of pier.

My specific requirement is for ‘flip-less’ operation but strictly in conventional GEM mode.

Why? Because my dome is small and the scope’s dew shield only just clears my dome walls. Also my shutter opening is quite high. If I begin imaging in a counter-weights up situation compared to a counter-weights down situation my dew shield can be in the order of 1.6m closer to the ground. Unless I’m imaging close to the zenith this means my target quickly becomes unobservable or not observable at all, because the scope can’t ‘see’ over my shutter threshold.

Therefore when I acquire a new target I need the scope to act as a GEM & flip if I slew from east to looking west; and flip if I slew from west to looking east. I.E. for a new target on either side of the meridian I always need to begin counter-weights down.

I would like my mount to track past the meridian without being stopped or flipped by any limit or threshold setting.

I need the mount to only flip on goto’s & not during tracking.

Also, for goto’s, I need it to flip at the genuine meridian. Not at a meridian that has been artificially moved to a different part of the sky.


I soon discovered that once the track-past threshold was breached the mount automatically either flipped or stopped, depending on the “GEM Auto Flip Track” setting. 

Because my sequencing software does not initiate this instruction it has no idea it is happening which causes problems.

I couldn’t find a set of meridian & track-past settings that worked for me without the mount flipping at an unwanted place or being counter-weights up when I didn’t wish it to be.

A few weeks ago I spoke with Dan & explained my situation. He was very understanding & quickly produced the 95MWin version that allowed a free rein of the meridian & track past settings.

I found that with the settings I posted at the beginning of this thread the mount flipped & tracked exactly as I needed & I confidently reported back to Dan that my problem was resolved.

Unfortunately I now realise I spoke too soon as (with those settings) I’ve discovered a caveat which only manifests during plate solving in the east.


My findings:

Please refer to the attached diagram as this helps to picture my testing method. I’ve borrowed the diagram from the ASCOM side of pier behaviour document by Peter Simpson.

I have tested using both my dome PC (W10) and my laptop (W7), SitechExe.95M, SGP, two different plate solvers, two different cameras & the ASCOM simulator V2 camera. I have tested with the ‘GEM Auto Flip Track’ check box both ticked & un-ticked.

Under real imaging sequence conditions and\or ASCOM simulation I have tested plate-solving at sky location points A, B, C & D.

For each of those 4 plate-solving locations I have use 3 sets of Meridian settings:

  1. My original settings:- over pole W = 4, over pole E = 2, under pole W = -176, under pole E = -178, track past = 178
  2. Suggested settings:- over pole W = 90, over pole E = 0, under pole W = -178, under pole E = 178, track-past = 90
  3. Default Settings (as shipped with mount):- over pole W = 2, over pole E = -2, under pole W = -178, under pole E = 178, track-past = 2

W   With my original settings & looking east, when plate solving point ‘A’ the mount will slew to point ‘D’, re-plate solve, slew back to point ‘A’ and continue imaging as if nothing has happened. The same applies if I plate solve at point ‘C’, the mount will slew to point ‘B’, re-plate solve, slew back to point ‘C’ & continue as if nothing has happened.

·        Looking west and plate solving points ‘B’ or ‘D’ is fine. There’s no unwanted slew.

If I were operating in the open air or with a roll-on\roll-off roof then none of this would be a problem. But I’m in a dome with a shutter. My sequencing software has not initiated the unwanted slew & therefore does not ‘know’ the mount has moved. Therefore my slaved dome does not follow the mount. So the second plate-solve fails because the camera is imaging the inside of my dome & my sequence aborts.

·        I then repeated the same tests but this time using the settings suggested to me.

Don, you are quite correct, my mount will then track past the meridian, but unfortunately as you also state, if I acquire a new target in the west then I’m counter-weights up. This is no good for me unless the target is up near the zenith.

·        ALSO VERY INTERESTING is that with the suggested settings I’ve noticed that the plate solving problem is still present but has simply moved round to the next quadrant of the sky. If my target is at point ‘C’ when plate solving the mount will now slew to point ‘B’, re-plate solve, slew back to point ‘C’ and continue as if nothing has happened. If I plate solve at point ‘B’ the mount will now slew to point ‘D’, re-plate solve, slew back to point ‘B’ and continue as if nothing has happened.

·        I reverted to the standard default meridian & track-past limits that my mount was shipped with:

Then plate solving in all parts of the sky works correctly without any unwanted slews & my mount flips at the meridian for goto’s.

But the problem for me is I’m then back to unwanted auto-flips or halted tracking when the track past threshold is breached.

·        I found that parking and\or initialising either east or west does not make a difference.

·        A different PC\laptop & operating system made no difference.

·        A change of camera produced the same results.

·        A change of plate solver also produced the same results.

·        I believe I can rule out SGP because I find that the plate solving behaviour depends only on how my meridian & track past limits are set.


My Conclusions:

Both my original & the suggested settings appear to just move the problem elsewhere in the sky. 

I find the default settings do not suffer from the unwanted slew(s) during plate solving but I cannot avoid breaching a track past limit at some point. This causes the mount to auto-flip or stop depending upon how the “GEM Auto Flip Track” tick box is set.

I find that moving the meridian limits introduces an unwanted counter-weights up scenario and\or unwanted slews during the plate solving routine depending upon what the Meridian settings are exactly & in which sky quadrant the target resides.


I do not believe that flip-less GEM operation should be considered an invalid configuration?

In addition to the above I have experimented with many other values for the Meridian settings.

So far I have been unable to find settings which cater for true flip-less GEM operation.

So where does this leave me & what is the solution?

Many thanks & regards




Thank you Paul,

I believe 'P' is the latest

Best wishes

paul K

ok no probs, I like to keep my s/w upto date, so I'll download 'M' tomorrow. If there's some clear I'll try the settings, it only takes 15 mins or so.
best wishes


Hi Paul,

Ah that's because you need at least .95M to be able to exceed those limits.

Thank you again for your interest and testing on my behalf but please do not do anything you're not comfortable with. You may be quite happy with .95G so don't change it if you are happy with it & it works for you.
And once again please be careful if you do experiment. My scope cannot crash into my pier but yours can.

Best wishes

paul K

perhaps my version of .95Gwin is not the same as your Martin?

When I tried to enter the track past meridian overlap value Sitech will not allow a number > 90 degrees The other values were allowed as per your image. If I try to enter 178, when I leave the field it reverts back to my original number which was 5.


paul K

if the cloud holds off Martin I'll give it a try with those settings tonight (U.K. time).
best wishes


Hi Paul,
I've just thought about what you said & I think the dome movement is not so relevant here because it's under the control of SGP, not SiTech.

In my case the 2nd plate solve taking place without the dome moving is just 'collateral damage'. If I had a roll-on/roll-off roof or was in the open air it wouldn't matter because on the 2nd plate solve it would get a real image & slew back to where it should be.

I made a mistake in my previous reply. Instead of "Don's recommended settings" I mean't to say my original settings - that is the ones in the image I posted at the beginning of this thread.

But only if you have time.

I've been testing using the ASCOM Camera V2 Simulator. You can just enter your sensor details and load a jpg image taken with your camera from a previous occasion. So you can test regardless of conditions & even during the day if you choose an image of what's actually in the sky at that particular time.

Best wishes


Hi Paul,
Many thanks for taking the time to test on my behalf, that's very kind of you. I imagine that as you have a conventional pier your meridian limits are pretty much default & I wonder what you'd find with the settings Don suggested to me earlier in this thread at #32847? If you do try this make sure you are in attendance just in case. Don't try it remotely.

I spent the whole weekend testing various scenarios with my settings, Dons recommended settings & the default settings. What I found was interesting but I have a few more checks to complete first before I post back.

Best wishes

paul K

Hi Martin, I had some clear tonight so at 10 pm I set up M95 (east of meridian at that time) as a sequence in SGP.

On this occasion in Sitech I set the scope horizontal pointing Az 90 and parked it there. So my process was as follows:

unpark the mount (I used Sitech interface to do this)
In SGP, tick slave dome to scope, then in target settings click 'Centere now'


Scope moves quite quickly to target (as usual for me) - no pier flip.
Dome takes a while to catch up and before it does, SGP's centre now routine is taking an image of the inside of my dome.

I repeated this process three times with the same result each time.

So that wasn't particularly useful, it's similar to what you found, but I had no pier flip from Sitech up to that point of failure.

If it's clear again tomorrow night I'll park at Az 270 and centre on a target west of the meridian to see if the same happens on the west side.

I must admit I'll be surprised if it fails to wait on the west side as that's where I image mostly, and I'm sure I'd have spotted the problem before. I will check though.

Also tomorrow I'll post a pic of my mount parms dialog from Sitech.

Best wishes


Hi JonK,
I also agree that imaging under the pole can be of interest and should be straightforward with a bent knee pier.

One thing I've noticed if you set your limits on top of each other is that the RA axis gently oscillates at the end of a slew instead of tracking. Like a PID controller that's not quite tuned.

If you don't mind being weights up then perhaps you could take it out of GEM mode. That will get rid of the limit settings.

Unfortunately for dimensional and spacial reasons I need to be weights down when begin to image; be that in the East or the west. Which means that ultimately Don's suggested settings won't work for me if I choose to begin imaging looking west. I need the mount to function as a GEM.

But I'm going to try Don's settings to check if they illuminate the unwanted slewing during plate solving in the east. Either way it will be an important test.

I shall also try with APT instead of SGP, a different plate solver and a different camera. That should rule in\out any possible equipment compatibility issues.

I shall also test using the ASCOM camera simulator. You can load an image into it and run a real sequence which means I can test during the day.

Hopefully soon I'll have some test results.

Best wishes


I'd like to agree with MartinC and Paul K.

I also have a bent knee pier, designed mainly to avoid meridian flips and any possibility of crashes, and I asked the question about setting limits before on a separate thread.

What I have done is set all limits to +/- 180 degrees, essentially moving everything to be between the ncp and the N horizon. I know this will probably be frowned upon, but in testing this appears to be all I can do to 'remove limits'.

I would like to see a simple switch in the software, turning limits off, with a simple pop up message 'are you sure, damage may result if incorrectly used' or similar, as is in use on other mount control systems I have seen. This would cater for people who do have the possibility of a pier crash.

I also disagree with the comment above about not imaging under the pole - ok, for people with a pier crash possibility, this is sound advice, but people have to take responsibility for their own actions. For people without this issue, there's no reason not to - ok, it's not abundant with targets for imaging, but take last year for example - Comet Neowise - a perfect example of set in the NW and rise in the NE. My observatory location has a fairly good NW to NE view so I would certainly look to be pointing in that area.

But, it's not always about imaging - I am an occasional observer and with my large refractor, I simply remove the imaging gear and fit a diagonal and eyepiece. If I want to point to the N, which I probably will do frequently as it's the darkest part of sky for me and is probably my best horizon taking into account the low skyline and lack of serious light pollution, then the advice of 'don't image' (or observe) under the pole doesn't work for me. Especially with a bent knee pier. Again, Comet Neowise would be a perfect example.

Regarding the initial error discussed about the plate solve then the mount slewing to a mirror opposite without any input from SGP, I am very interested to see if this is a bug. Unfortunately, my equipment is not set up so I can't run my Mesu e200 / SGP combination to see if it does the same, but look forwards to the resolution.

In conclusion, a 'switch off mount limits' button would be great, as I don't really care whether I am weights up or down for the majority of what I want to do.


Hi Paul,


Thanks for the confirmation & offering to test in the east.


My procedure is the same as yours but on the opposite side of the meridian in the east. The only other difference is that I’ve not made a habit of a ‘pre-initialisation’ during the day as you do because I tend not to shut down the drive but leave it energised. If I do and have previously parked then it remembers where it is anyway. I have tried powering it off and re-initialising though but it makes no difference to the outcome.


As you say imaging opportunities are rarer these days which is why it’s so important everything works as expected.


That’s why I invested in the Mesu\SiTech combination; and it is good. I like the construction and the software and tracks & guides very nicely.


This issue can’t be down to SGP otherwise I’d see the same problem in the West and you would too. SiTech-wise the only real difference between us is our Meridian limit settings (because of our different pier arrangements) but I just don’t see why (in the east) that should cause the mount to slew to the exact mirror position on the opposite side of the meridian during plate solving?


Hopefully Don’s solution will resolve this & I can hold up my hand and apologise profusely.


Best regards


paul K

Hi Martin,

Yes I initialise (and park) at Az 270. Each session (there's usually quite a lot of time between them these days) I initialise using skyview to get an offset init @ Az 270 with the scope horizontal. (I usually do this sometime during the day). I then slave the dome to the scope in SGP at the start of an imaging run and use the Sitech handpad to slew to a random location west of the Meridian, and platesolve to get an accurate offset init. I then use centre now or 'run sequence' in SGP, BUT I've always done the first platesolve west of meridian, just 'cos of trees to N and to E.

However, as I mentioned I'm moving my obs to a field with no obstructions and my plan there is to set everything up in SGP and let it start by itself, so if my target was E of meridian, when a timed sequnce starts in SGP, the first platesolve will be in the east.

I do have a bit of visibility slightly E of meridian at my current location, so I'm going to try a 1st platesolve in the East next clear night just to check this out. I'll post back.
Best wishes


Hi Paul,


Yes that’s exactly what I’m saying J


So just out of interest you always initiate in the West? And park in the West too?

If so then you are initiating, parking & plate solving all on the same side of the pier?

I’m just trying to get a handle on how others are working & if this could be relevant?


Many thanks for your support.


Best regards


paul K

I respect your position on this Don, but I can just hear folks saying - why am I getting involved with instructions for driving a car when I drive a motorbike.... :)
Perhaps a minor mod to help those folks who don't need to get involved with the not inconsiderable detail of meridain limits and flips, might be to provide a tick box in Sitech config which auto populates the boxes with the setttings needed for flipless working. Just trying to help....
best wishes

paul K

Hi Martin, so if I have it right, what you're saying is if you decide to image a target anywhere in the east and the mount platesolves in order to centre on the target, your mount will flip. Is that right?

I don't image in the east due to trees, so never tried a platesolve looking east.



Hi Don,


I’ve not had an opportunity to image yet but in preparation I have the settings configured as you suggested. I am initiated in the East and parked in East as I always do.


I can perform GOTO’s via Skyview, SGP, Cartes Du Ciel or Stellarium and the mount behaves as I would expect a GEM to behave. I.E. it flips if select a target on the opposite side of the meridian; either going from East to West or West to East. It goes through the pole if my target is in the opposite sky quadrant. And it re-parks correctly from anywhere in the sky.


It does not auto-flip or stop tracking when the scope tracks past the 90 deg track-past setting you suggested or if the scope tracks past either pole.


This is great but all of the above was also true of my previous settings.


The problem occurs during plate solving in the East, when the ‘InitPoint’ window appears during the adjustment (East radio button active). That’s when my mount would flip – but as I said to Paul – not a ‘genuine’ Meridian flip. It wouldn’t be pointing back at the target. It flips to the same declination but mirrors the RA position on the opposite side of the Meridian. I.E. If the target was 3hrs East of the Meridian, the mount would ‘flip’ to the same declination but 3hrs West of the Meridian.


If my scope was in the open air & not in a dome then it would actually work out because having performed this strange flip SGP re-plate solves, with the InitPoint window showing the West radio button active this time (I assume because the scope is now looking West). The plate solve error is obviously massive but the mount then returns to the correct position, plate solves again (East radio button active again when the InitPoint windows appears) and this time my imaging sequence continues as if nothing has happened.


If my target was in the West the plate solve takes place (West radio button active when the InitPoint windows appears), the mount remains where it should, it takes one or two small plate solve adjustments as you might expect and my imaging sequence continues as it should.


So Don, although I’m really hopeful that your suggested settings resolve this behaviour I’m struggling to understand how the Meridian & track-past limits can influence the plate solving\InitPoint routines in this way?


If you have any further thoughts please let me know. If not then I’ll get back to you once I’ve had a chance to actually image.


Many thanks & regards


Don W

Hi Russell,
The colors are the limits set  for the meridian limits, and they reflect the colors of the limit lines in SkyView.
Don W

Russell R

Don W.,

I don't ever deal with meridian flip limits, but curiosity got the best of me. What are the colors blue, green and yellow referring to in that diagram? 
Ol Chuck is quite the artistic engineer!

Russell R.