Re: RA Problem

Russell R

Hi Gary,

What is your version of SiTech?
Assuming this is a worm gear drive and well lubed.
Have you checked the amp load in both directions in controller stuff?
Have you tested the motor with "test and tune" in Servo Config? Here you can check the encoder also?

Age is no embarrassment....unless you are under 30!  Your mileage may vary.

Russell R.

Re: Meridian Flip Settings Explained

paul K

Thanks for the explanation Don. For ordinary GEMs that need to flip, is there any advice on optimum settings for the meridian limits?

Are there any useful criteria to apply? I guess the settings will depend on Lattitude too?


Re: Meridian Flip Settings Explained


Hi Russell,

You are correct, EQ mode is an option. But due to the 'shortest route' scenario, for a new target in the east it usually results in a weights up situation; which is what I'm trying to avoid.

Cable management on the e200 is very nice. The RA cables can route straight up the inside of the pier and be fixed at the top. With such a long length several rotations could be executed without any issue. 

What's really nice and very clever about Sitech is that it 'remembers' the rotation count. So when you park, the cables unwind by the requisite number of turns. This illiminates the risk of cable wind-up over time.

On the e200 there are 2 cables for the DEC motor that cross the route of the RA cables at 90 deg. These can become wrapped round the bundle of RA cables. That's almost happened to me a couple of times.

Best wishes

Sent from my Galaxy

RA Problem

Gary Hug

Recently after nearly a decade of good use, Ive had an issue with the RA drive.
I've a SiTech Controller II and use it on a rather large and heavy fork mounted reflector scope. My number of RA motors ticks for 360 degree are in the range of 93,000,000 and I'm limited to just under 1 degree per second slews after ramping. No Problem with that.

The latest issue with the RA drive is when slewing to the west the slews are accurate and after briefly ramping up it does indeed obtain just under 1 degree slews.

The problem arises when I try to slew to the east (no matter where I am in relation to the meridian) The motor starts out ramping OK but after ramping the motor speed cuts back to about 1/2 or less and the results are it overshoots the target by a considerable distance. I changed out 3 different servo motors with the same results in each. I've also replaced the wiring and connectors.

The RA timing pulley is easily moved either east or west with little change in resistance. I'm assuming there is a problem with the encoder numbers somewhere. Either in sending or receiving or converting.

Probably something I'm not thinking about but at my age I throw embarrassment to the wind.

Thanks for reading,

Gary Hug

Re: Meridian Flip Settings Explained

Russell R

Don W &  "bent pier" GEM users,

My question to you is.....why can't "bent pier" GEM users just put SiTech.exe in equatorial mode and forget about all the flip setting hoopla, that is providing one does not have to deal with dome walls, elevated shutters or piers.  With this you can go over/under pole and horizon to horizon.  The only issue...if you are pointing at an object say at the 4 o'clock position near NCP and perform a goto for an object at the 9 o'clock position, then SiTech will take the shortcut clockwise, and possibly twist some wires if your not set up for it.  Platesolves are no problem anywhere in the sky.

Russell R.

Meridian Flip Settings Explained

Don W

Hi All,
The settings in SiTech /ChangeConfig/MountParms concerning GoTo's and Tracking vs the Meridian are very straightforward (they do exactly what they say), but are still confusing to some users.  In particular, the use of a "bent pier" allows a GEM to rotated mostly without "hitting the pier".  This means the telescope can be pointed at the sky while the counterweight shaft is pointed UP (above the horizon).  This just means that SiTech can track (and image) a target starting well east of the meridian and continue all the way to the West horizon without a meridian flip.

OK, how do you setup to do this???
First lets define the terms and what they do.
1. These are only for a GEM, so GEM must be selected.
2. There are two check boxes, one for Auto Flip and another for Auto Track.  These boxes control whether the mount will Flip or Stop when the mount gets to the limit.  That is IT!, there is no other option.
3.The key to tracking without a flip is the setting for Track Past Meridian in the lower left of the window.
4. The limits are set in the wide boxes for 'Over Pole and Under Pole.  These limits are in degrees-minutes-seconds of arc, FROM THE ZENITH!  The angles are measured positive in the direction of the limit.  So +10° for the west limit is toward the west, and +10° for the east limit is toward the east.  Both of these limits can not exceed 90° (the horizon).  Now with 095M and later versions, these limits CAN be set to a negative angle, which allows the limit to be set BEFORE the meridian.

The same methodology applies to UNDER POLE, so the settings are angle from the meridian - directly Under the pole is 180°.  so if you set for 2 degrees after the meridian, set 178° or -178°.

I have said you should not use Under the Pole unless you are very far north latitude (or south latitude), like Canada or northern Europe.  Any DSO will be above the pole for at least 6 months of the year.  OK, if you are doing science measurements of double stars orbits or variable stars then you want to make measurements all year long - That is what Under the Pole is for - targets of opportunity.

I live and observe in southern California at latitude 32° so I don't ever use "Under the Pole" so I don't have any experience using it.

Meridian Flips are not caused by Platesolves!  Platesolves simply initialize the mount to the local sky, either Looking East or Looking West.  when SiTech is not initialized, and you do a platesolve, now it is initialized, and if SiTech is connected to any other ASCOM program, once initialized SiTech will report via ASCOM where it is pointed.

If SiTech is NOT initialized, then any motion via the handpad WILL NOT BE REPORTED to any ASCOM program like SGP.  Once SiTech is initialized SGP will have all mount motion reported.  If you don't understand this, then you WILL have unexpected results.

Don W

Re: message to all members regarding wiki idea

Dan H

I think that's a great idea. Finding info on a specific problem in a users group is an exercise in frustration.


For an astronomer the sky isn't the limit, it's just the beginning.

Re: message to all members regarding wiki idea

James Roe

I say great idea, go for it!

Jim Roe

Re: message to all members regarding wiki idea


Hi Paul, 

I think that's a very interesting suggestion. We have something similar (different format) where I work for technical support issues. I reckon it would need to feature some form of configurable search facility but to answer your question I think your idea has merit.

Best regards

Sent from my Galaxy

message to all members regarding wiki idea

paul K

I have been a member of the forum since around 2015 and during that time I have seen some real gems (sorry!) in posts, which subsequently disappear into the depths of the forum, which by the very nature of forums (fora?) is relatively unstructured.

So I am floating the idea (and it's just that at present) of a wiki which would capture all the gems and present the information in a structured way.

The most recent exchanges between Martin and Don provide a nice example - it could be a wiki article "How to configure flipless mounts" There are many other exmples too.

As we all probably know, wikis are built by the community for the community and therefore are great for sharing experiences. They are dynamic documentation contexts and very much depend on the community they serve being active contributors.

If the idea gets support, I'll offer to install MediaWiki on my host (it's there as a one click install) at no cost to the community. There may be better hosting options and these should be considered too.

If authenticated access to the wiki can be automated, the admin overhead related to that will be small.

So I'll throw this open to folks - what do you think?


Re: 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

Re: scope and motor encoders fighting?

Joshua Hufford

Huw, just tossing out an idea but maybe guide for a while with no corrections and see if you still see the spikes? Of course you will have the PE in your graph but if no guide commands are being sent to the mount but you still see large spikes in your guide graph then likely the problem is mechanical. If you don't see any spikes perhaps that points more towards software/guiding? 


On Fri, Apr 16, 2021 at 12:21 PM Huw O <huworwig@...> wrote:
Thank you both, looks as if it's going to be cloudy tonight, will experiment when I get some stars and see what happens.
Incidentally, I read somewhere on this forum that Scope Encoder and Motor Encoder should match within about 12 arc seconds or so.
Mine in normal tracking is anything up to 30 arc seconds or so out, I'm putting it down to bad PE on my worm. When I slew Westwards the error keeps relatively the same, but when I slew East it goes up to quite a few arc minutes.


Re: scope and motor encoders fighting?

Huw O

Thank you both, looks as if it's going to be cloudy tonight, will experiment when I get some stars and see what happens.
Incidentally, I read somewhere on this forum that Scope Encoder and Motor Encoder should match within about 12 arc seconds or so.
Mine in normal tracking is anything up to 30 arc seconds or so out, I'm putting it down to bad PE on my worm. When I slew Westwards the error keeps relatively the same, but when I slew East it goes up to quite a few arc minutes.


Re: Offset Init & flip during SGP sequencing



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



Re: scope and motor encoders fighting?

Don W

Hi Frank,
That is enlightening, setting the Comm Loop time to 100 is recommended.  I had not heard that longer times caused problems.  I have always used 100.

Hi Huw,
Try Franks solution, it might fix your spikes.

Another thought I have is to check your PC to see if there is another program running that periodically (every hour) runs - possibly causing SiTechexe to spike.  Programs like anti-virus scans or data backups that run every hour might be the cause if Frank's comm setting doesn't work.
Don W

Re: Guide Setting

Don W

Hi Ned,
The guide speed is the speed that guiding uses to correct the position - only with a guide camera.  Usually the guide speed is equal to the sidereal rate = 15 arc-seconds per second.  Autoguider software usually have a factor called aggressiveness which can reduce the guide speed.  Also some users set the guide speed to about half sidereal to minimize excursions of their mount.  That is equivalent to setting the aggressiveness to 5 (on a scale of 0 to 10).

From your description, you must be doing unguided imaging.  Unfortunately, the motion of stars varies across the sky, mostly due to refraction.  Pure sidereal rate is only near the zenith.  The movement due to refraction is mostly i the east and west ( I think it is slow in the east and fast in the west).  This effect is strongest at low altitudes.  This is why it is generally recommended that imaging be at altitudes greater than 30°.

Don W

Guide Setting

Ned Smith

I have used SiTech for years and have had very little trouble.  I have always ignored the "Guide" speed.  Don't really know what it is for.
Now I am finding that in long exposures the image slowly drifts off the screen. Can the Guide speed be used to overcome this drift?  How?  

Ned Smith

Re: scope and motor encoders fighting?


Hi Huw,

I had a similar looking issue two or three years ago. After I had ruled out every mechanical and electrical cause, the spikes kept happening. Eventually I found I could eliminate the problem with a simple config change. You can read all about it here...
I don't know if this issue was addressed in later sitech.exe builds, but at least it is something to look into.


Re: scope and motor encoders fighting?

Don W

Hi Huw,

Wow, those are really bad spikes in RA.  However they look just like a sample in one of the PHD2 PDF's on Analyzing PHD2 Guiding Results – A Basic Tutorial.  I downloaded that PDF a couple years ago ( I don't have the URL now).  The PDF said that such spikes are generally caused by outside events (not caused by the controller nor the guiding).  Here is an excerpt from that PDF:

We see that guiding was going normally on the left-hand side of the graph before the big upward
spike. In particular, there was no huge guide pulse that caused the star to move so far on the
sensor. Instead, you see PHD2 reacting *after* the guide star moved off-target by sending a
stream of 9-10 RA guide pulses in the opposite direction. So “something just happened” to cause
this problem – some sort of mechanical event that started the whole thing, not something caused
by PHD2. Unfortunately, this is a very common problem, particularly for set-ups that aren’t
permanently installed in an observatory. Worse still, the guide log doesn’t give you much help in
figuring out what caused the original deflection, and the possibilities are seemingly endless. One
thing that can help is to get a mental calibration of how little motion is required to trigger these
events, particularly if you’re using a longer focal length set-up. Position your monitor so you can
see it from near the telescope, then start looping on a star. Now gently push on various parts of
the guide scope assembly and tug gently on the various cables. You’ll usually see a little goes a
long way, and it’s very easy to create large guide star excursions.
Here are some of the more common causes of these problems:
1. Any sort of looseness in the mount, tripod, pier, or scope assemblies
2. Dragging cables
3. Wind gusts
4. Anything that jostles the scope, camera, pier, or tripod such as moving around near the
Dragging cables are a particularly common problem, which is why experienced imagers do a
careful job of routing and securing them. Especially in cold weather, these cables become stiff
and unyielding, so if they touch or rub against a stationary surface you will probably see guiding
Obviously, the list of possibilities is endless. Some of the reported causes can be pretty funny
assuming, of course, it’s someone else’s problem. Here are just a few real-world examples:
1. The family cat poking around in the observatory at 3:00 in the morning
2. Owls landing on the end of the telescope tube
3. Leaving a rolling observatory chair near the end of the declination axis (ok, that was me)

I see that the period is VERY regular, the same period between spikes.  This is an important clue - saying that whatever the cause is happening at a regular interval.  So look for something that is happening every hour (maybe a power spike, or a flashing light, not likely an Owl landing on the scope).

This may be a tough one to solve.

Don W

scope and motor encoders fighting?

Huw O

My mount is a traditional worm driven fork mount, with motor encoders. The RA worm wheel had really bad periodic error, so a Gurley encoder was mounted on the RA axis.
I have finally got this encoder behaving, but I now have what I believe is a situation where there are two feedback paths fighting.
I have some strange "bumps" in RA guiding, which were not there before the scope encoder was fitted
I attach a PHD graph from last night : (Capture 15.04.21.JPG) The encoders during this run were differing by about 5-8 minutes of arc according to the 'Controller information window', and the pulses were at approx one hour intervals.
I can see no obvious period corresponding to one hour in the RA drive train
Tonight, I zeroed the difference between both servo systems before of the imaging run, and had no pulses for the first three hours, then two within 20 minutes. (Capture 16.04.21.JPG)

The drive is as rigid as I can make it, is there something I am not taking into account?


1221 - 1240 of 34133