Meridian Flip Fail and Rotator Not Being Updated With Degrees


I have not changed any settings and for the past few times (over the course of the past two or three months) the meridian flip will fail at the stage of slewing the scope. I am using a Losmandy G11-GT with an EdgeHD 1100. Guider stops fine, platesolve works fine, fails at the scope slewing stage.

Also, I just got a new Moonlite Litecrawler which is for the EdgeHD scopes. My regular Nitecrawler for my other scopes gets the degree updated on its LCD screen just fine when I do a Solve and Sync. WIth the new LItecrawler, the LCD screen will still read 0 degrees even though my Solve and Sync found that I’m at 153 degrees.

Any help would be greatly appreciated!

Attached are the logs from this past Saturday night.

sg_logfile_20171216191253.txt (378.6 KB)
sg_logfile_20171218175829.txt (19.2 KB)
sg_logfile_20171216204253.txt (30.1 KB)


I have one log file that is too big to upload…what should I do?


Hi Zach,

Right-click on it, select “Send to” then select “ZIP-compressed folder”. Upload the result.

Kind regards,


Thanks, Horia. Btw, my original post was under some random account as I initially forgot my login/password. Here is the compressed file to be looked at…

I’m using the updated and latest stable version that was just updated at the beginning of December I think. All of my ASCOM drivers are up to date. When I use my Nitecrawler, everything works just fine. But when I plug in the Litecrawler, the only issue I have is after doing a Solve and Sync, the angel degree doesn’t get updated to the Litecrawler. Ron at Moonlite said it is the exact same driver for Nitecrawler and Litecrawler.

Then also, my meridian flip errors out at the slew scope stage.

Thanks for the help! (165.1 KB)


Can someone from SGP please assist? I am sitting on this $2500 part that I need to know whether it needs to be returned or if it is a communication error within it and SGP which won’t require it being returned.


It looks as if the rotator is always reporting a position of zero, that looks like a problem with the rotator. I’d contact Ron.

To save time one thing that is essential is an ASCOM log from the rotator showing exactly what commands are being sent to the driver, what it is sending to the rotator hardware and what comes back. You enable logging in the rotator setup dialog - with a bit of luck it is already set - and the logs are in MyDocuments\ASCOM\Logs [date].

I wrote the driver so Ron will probably contact me and I’ll need the log.


Thanks, Chris. Here are a few logs from that night. SGP crashed a couple of times and I thought rebooting it a couple of times would fix the issue. It works fine with my Nightcrawler but not my Litecrawler. I had already spoken to Ron and he told me it must be a SGP thing because I can make the rotator rotate, but when I do a platesolve (or manual set of rotator angle), it won’t update on the LCD of the Litecrawler.

#8 (3.1 KB) (112.6 KB)
ASCOM.Gemini Telescope (565.6 KB) (756.7 KB)


Thanks for that Zach.

The rotator position is reported as 0 by the hardware for the 2044 and 1916 logs but no attempt is made to move it. There are no errors.
The 2052 log also shows no attempt to change the rotator position until 03:09;54 when a MoveAbsolute command to 206 degrees is commanded. This translates to -159393 steps.
The move finishes at 03:10:59 because a Halt command is sent. By this time the rotator has moved to 355.6 degrees, that’s -4580 steps.

At 03:10:04 a MoveAbsolute to 359.95 degrees is sent, that’s -52 steps.
This finishes at 03;10:08 at the correct position.

There are no more moves. The long move was halted after a rotation of less than 5 degrees, this may be hardly noticeable.

This seems to show that the rotator is working correctly. Zero is an entirely likely position to be at and when a move is commanded the rotator position changes as expected.

Could SGP be sending a halt command that’s stopping the move?


I was setting up a new scope that night so there was no action until the end of the logs…as you saw. I performed a plate solve later on and noticed it gave like 153 degrees as the angle. I looked on the Litecrawler and it stayed at 0. I tried a manual move, as you saw, and when I noticed that it wasn’t doing the correct thing (rotator was starting from 0 degrees and not 153 degrees) I stopped it, as you saw. SGP does make the rotator move, but the rotator doesn’t get updated with the angle degree of SGP.


I started this post off with another issue that my meridian flips were failing for the past few months as the slew scope step. I’m wondering if maybe I need to tell SGP to go maybe 30 minutes or 45 minutes past meridian to solve this. This same night, when everything failed, I slewed the scope to a random place and tried to tell Gemini to go back to my target within the driver catalogue. It was trying to put the scope on the same side of the pier as before. So in my mind, I think that it is failing because SGP is telling Gemini to do a meridian flip but Gemini isn’t ready to do a flip because it will make the scope hit the pier on the other side? My thoughts…unfortunately a lot of cloudy nights ahead so don’t know when I can get out next.


All I can comment on is what the log shows me. It shows that although the rotator position starts at zero when a move is commanded the position reported changes as expected. There is no evidence of anything wrong with the rotator.

The plate solve gives a different angle, that of the image with the sky. The rotator doesn’t know this and has no way of knowing.

The rotator and the sky have different zero positions. SGP is designed to handle this by plate solving, reading the two angles and allowing for the difference for a move to a particular image alignment. AFAIK manual rotator moves bypass this so if you command the rotator to move to 153 degrees then that is where it will move. In fact the command I see is to 206 degrees which the driver interprets as 206-360=-154 degrees.

My interest in this is to support the rotator and from what you have reported I can reassure you that it’s behaving correctly. The reason it’s always reporting zero is because that’s where it is.


Thanks for replying, Chris. Hopefully someone from SGP can chime in to look at my logs and see why SGP isn’t pushing updated FOV angle data to my Nitecrawler. I might have to return this thing being that it is so expensive and I purposely got it for the rotator capabilities.

Anyone from SGP? Any assistance would be greatly appreciated and its been over a week since my original post.


SGP and the Rotator will almost never agree on the angle and that’s ok. And technically they can’t because there is no way for SGP to update the angle of the Nitecrawler. SGP reports sky angle and the rotator will report something that makes sense to it. SGP computes and stores an offset with the rotator angle but before this can work a sync needs to happen.

You should see the rotator angle moving when commanded from SGP. I’ve looked through the logs and I’m not entirely sure how to read the NiteCrawler logs. It generally seems like they’re focuser logs so maybe I’m looking at the wrong bits?

If you have things hooked up during the day will SGP move the rotator at all?



As for the meridian flip. SGP is set to flip right at the meridian, so if your G11 is set so that it can’t make that then it would fail. It looks like we asked it to flip but it did not. Unfortunately I can’t be much help there. I would check to make sure that your location and time are all set correctly in the mount. Also be sure never to perform a solve and sync while pointed at the pole as that will certainly cause weirdness with the model in the mount.



Hey, Jared. Thanks for the reply. I am baffled by this. I have had a Nitecrawler for almost a year and it works perfectly. During the beginning of my nightly routine, I do a plate solve and the angle is automatically updated on the Nitecrawler. I recently got a new EdgeHd 11" and got the Litecrawler (which is thinner than the Nitecrawler and specific for SCTs for back focus purposes) and this is the only time I’ve had an issue. Ron says that the Moonlite driver is the same for Nitecrawler and Litecrawler. The logs I posted, the only rotator action is towards the end…it was my ‘initial setup’ night as I was trying to find the focus position. I finally performed the plate solve which had me at 153 or so degrees. I noticed the Litecrawler still said it was at 0. I tried to manually set the Litecrawler in SGP which didn’t work. Then I tried to move it and when I noticed it wasn’t starting off at 153 degrees, I stopped it.


Don’t you have a Nitecrawler as well? If I’m not mistaken, Ron said your name as being the SGP user (obviously) and a Nitecrawler user? Is there some other log that is I need to post? I’m hoping for another night out this weekend to do tests. Not sure how I’m supposed to sync the program and the rotator other than plate solve and/or manually setting the angle in SGP.


I do have and use a Nitecrawler but haven’t seen any of these issues with it and SGP. When instructed to rotate it works fine, but the angles between the two are never the same (and won’t ever be).

I’m not sure how this is the case. ASCOM provides no ability for us to tell the rotator where it is pointing. My Nitecrawler and SGP never show the same angle, but SGP knows how to account for this.

Here’s an example of how it works:

  • Rotator Reports angle of 90
  • Solve and Sync performed and SGP finds angle is 120
  • SGP stores an offset of +30 degrees
  • Focuser still displays 90 degrees, SGP now displays 120
  • Next target has a skyangle of 135 degrees
  • SGP tells the rotator to move to 105 degrees.
  • Rotator shows 105, SGP shows 135

SGP will report the sky angle once a sync happens but cannot update the rotator with this information. Therefore after a solve and sync the rotator and SGP will not report the same angle.

Just to reiterate SGP cannot and will not update the angle on the LCD of the rotator.

Hope that helps,


Thanks, Jared. When you select to center on target, say from plate solving an image from a previous night, do you select rotate as well or do you do the rotation first (via what the plate solve reported) and then just center on target? Or do you allow SGP to do the whole thing? I’ve tried to allow SGP to do the whole thing before (unless I was doing it wrong) it was taking forever. Every iteration would report minuscule pixels off target, then it would rotate a crazy amount, take another picture, report closer to centering but still a few pixels off, rotate again for a crazy amount, etc etc. Just curious how you utilize your Nitecrawler.