Unexpected Merdian Flip with CGE Pro

JerryK · July 4, 2015, 4:50pm

Hi, everybody.

I browsed the forums a bit for other meridian flip questions, particularly those on Celestron mounts but didn’t find anything that seemed to entirely correspond to my experience last night.

In short: my scope tried to do a meridian flip that I totally wasn’t expecting.

The time until meridian flip indicator was still showing three hours or so remaining. The scope was on the west side of the mount, pointing east, but still had not reached the meridian. Indeed it visually looked like the scope had a good distance to go before even reaching the merdian, much less flipping, and the CGE Pro is supposed to be able to track a full 20° past the meridian, something that looks plausible given my tube length and physical configuration.

Here are my software versions, an excerpt from my logs around the suspicious event, and the entirety of the logs in case my excerpt is a red herring:

SGP:                  2.4.1.10
CGE Pro HC firmware:  4.21
CGE Pro MC firmware : 6.09
NexRemote:            1.7.22
NexRemote DLL:        1.7.2

Grepping the logs for hour angle checks I see the following over my session:

[7/3/2015 10:32:59 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -71.2389993667603 < 15
[7/3/2015 10:43:43 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -68.537929058075 < 15
[7/3/2015 10:49:17 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -67.1451759338379 < 15
[7/3/2015 11:04:24 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -63.3678531646729 < 15
[7/3/2015 11:10:56 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -61.7128872871399 < 15
[7/3/2015 11:16:29 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -60.3208637237549 < 15
[7/3/2015 11:22:04 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -58.9240121841431 < 15
[7/3/2015 11:27:36 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -57.5371170043945 < 15
[7/3/2015 11:33:09 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -56.1466383934021 < 15
[7/3/2015 11:38:42 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -54.7569966316223 < 15
[7/3/2015 11:44:15 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -53.3662819862366 < 15
[7/3/2015 11:49:47 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -51.9791722297668 < 15
[7/3/2015 11:55:20 PM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -50.5944871902466 < 15
[7/4/2015 12:00:54 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -49.2006182670593 < 15
[7/4/2015 12:06:27 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -47.8102040290833 < 15
[7/4/2015 12:12:02 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -46.4106702804565 < 15
[7/4/2015 12:17:35 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -45.017101764679 < 15
[7/4/2015 12:23:08 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -43.6292624473572 < 15
[7/4/2015 12:28:40 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -42.2406721115112 < 15
[7/4/2015 12:34:13 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -40.853111743927 < 15
[7/4/2015 12:39:46 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -39.4609594345093 < 15
[7/4/2015 12:45:18 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -38.0731201171875 < 15
[7/4/2015 12:50:52 AM] [DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: -36.6774272918701 < 15
[7/4/2015 12:56:27 AM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 45.7921957969666 >= 15

The unexpected flip attempt seems to go with the last check where, after just 5 minutes have elapsed we suddenly see hour angle jump from -36.67° to 45.79°! At that moment, the meridian flip UI window pops up and the system starts going through the process generating logs as follows:

[7/4/2015 12:56:27 AM] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[7/4/2015 12:56:27 AM] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[7/4/2015 12:56:27 AM] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 45.7921957969666 >= 15
[7/4/2015 12:56:27 AM] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[7/4/2015 12:56:27 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure
[7/4/2015 12:56:27 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Calling SGM_TELESCOPE_SOLVE
[7/4/2015 12:56:27 AM] [DEBUG] [Pier Flip Thread] Meridian flip: Waiting for scope solve to complete…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] SGM_TELESCOPE_SOLVE message received…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Telescope solve with plate solver Astrometry.NET…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Setting filter for scope sync…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Setting filter position 5…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Filter position 5 is already set. Skipping…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Plate solving scope frame…
[7/4/2015 12:56:27 AM] [DEBUG] [Telescope Thread] Created full file name (file does not exist): C:\Users\Jerry\AppData\Local\SequenceGenerator\Temp\plate_solve_image.fit
[7/4/2015 12:56:27 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE message received…
[7/4/2015 12:56:27 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[7/4/2015 12:56:27 AM] [DEBUG] [Camera Thread] Collecting FITs headers for plate solve frame…
[7/4/2015 12:56:28 AM] [DEBUG] [Camera Thread] SBIG Camera: CaptureImage…
[7/4/2015 12:56:28 AM] [DEBUG] [Camera Thread] SBIG Camera: Start exposure…
[7/4/2015 12:56:28 AM] [DEBUG] [Camera Thread] SBIG Camera: exposure time = 200
[7/4/2015 12:56:28 AM] [DEBUG] [Camera Thread] SBIG Camera: shutter is open…
[7/4/2015 12:56:28 AM] [DEBUG] [Camera Thread] SBIG Camera: capture command sent…
[7/4/2015 12:56:30 AM] [DEBUG] [Camera Thread] SBIG Camera status check: INTEGRATING
[7/4/2015 12:56:31 AM] [DEBUG] [Camera Thread] SBIG Camera status check: INTEGRATION_COMPLETE
[7/4/2015 12:56:32 AM] [DEBUG] [Camera Thread] SBIG Camera: end exposure called…
[7/4/2015 12:56:32 AM] [DEBUG] [Camera Thread] SBIG Camera: read data…
[7/4/2015 12:56:32 AM] [DEBUG] [Camera Thread] SBIG Camera: starting readout…
[7/4/2015 12:56:32 AM] [DEBUG] [Camera Thread] SBIG Camera: reading lines…
[7/4/2015 12:56:45 AM] [DEBUG] [Camera Thread] SBIG Camera: end readout…
[7/4/2015 12:56:45 AM] [DEBUG] [Camera Thread] SBIG read complete. Took 13590ms…
[7/4/2015 12:56:45 AM] [DEBUG] [Camera Thread] Created full file name (file does not exist): C:\Users\Jerry\AppData\Local\SequenceGenerator\Temp\plate_solve_image.fit
[7/4/2015 12:56:45 AM] [DEBUG] [Camera Thread] ---------> Save file took 122ms
[7/4/2015 12:56:45 AM] [DEBUG] [Camera Thread] SGM_CAMERA_PLATE_SOLVER_CAPTURE complete…
[7/4/2015 12:56:46 AM] [DEBUG] [Telescope Thread] Astrometry.NET convertedAstrometry.fits path: C:\Users\Jerry\AppData\Local\SequenceGenerator\Temp\convertedAstometry.fits
[7/4/2015 12:56:46 AM] [DEBUG] [Telescope Thread] Astrometry.NET - File is too large, resizing
[7/4/2015 12:56:46 AM] [DEBUG] [Telescope Thread] Astrometry.NET - Saving file
[7/4/2015 12:56:46 AM] [DEBUG] [Telescope Thread] Astrometry.NET using endpoint: http://127.0.0.1:8787/api/
[7/4/2015 12:56:46 AM] [DEBUG] [Telescope Thread] Astrometry.NET - Calling Async Solve
[7/4/2015 12:56:46 AM] [DEBUG] [Unknown] Astrometry.NET uploading file: C:\Users\Jerry\AppData\Local\SequenceGenerator\Temp\convertedAstometry.fits
[7/4/2015 12:57:01 AM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[7/4/2015 12:57:01 AM] [DEBUG] [MF Update Thread] Performing serialize…
[7/4/2015 12:57:14 AM] [DEBUG] [Unknown] Astrometry.NET - Upload complete
[7/4/2015 12:57:14 AM] [DEBUG] [Unknown] Astrometry.NET - Waiting for solve to complete
[7/4/2015 12:57:15 AM] [DEBUG] [Unknown] Astrometry.NET - Job successfully solved
[7/4/2015 12:57:15 AM] [DEBUG] [Unknown] Astrometry.NET solve done in 28 seconds.
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Astrometry.NET - Solve Completed
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Astrometry.NET - Solve Successful
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Plate solving scope frame successful, scope is synced, writing FITs header info…
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Checking to see if solve might be bad…
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] User chose to abort sequence due to bad solve…
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 20.935787137 Dec: 31.6688313349
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Telescope Sync: Passed in J2000 but mount requires JNOW, converting…
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to JNOW RA: 20.9469547808002 Dec: 31.7298302469482
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Attempting to write fits header info for
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] Scope solve complete…
[7/4/2015 12:57:16 AM] [DEBUG] [Telescope Thread] SGM_TELESCOPE_SOLVE message complete…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Meridian flip: Scope solve complete…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Solve and Sync was Successful
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Stopping the Auto Guider
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Attempting to stop PHD2 guiding…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Checking PHD2 state…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Sending to PHD2:
{“method”: “stop_capture”, “id”: 1004}

[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Checking PHD2 state…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] PHD2: Successfully stopeed PHD2…
[7/4/2015 12:57:16 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[7/4/2015 12:57:17 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[7/4/2015 12:57:17 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using sideOfPier
[7/4/2015 12:57:17 AM] [DEBUG] [Telescope Thread] Setting Pier East
[7/4/2015 12:57:17 AM] [DEBUG] [Telescope Thread] Pier Flip failed when using side of pier: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Setting the side of pier to East cannot be done because the current position cannot be reached with the mount on that side of the pier
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object args, Boolean byrefModifiers, Int32 culture, String namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object providedArgs, ParameterModifier modifiers, CultureInfo culture, String namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 331
[7/4/2015 12:57:46 AM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[7/4/2015 12:57:46 AM] [DEBUG] [MF Update Thread] Performing serialize…
[7/4/2015 12:57:48 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope command to meridian flip has completed
[7/4/2015 12:57:48 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope failed to perform meridian flip
[7/4/2015 12:57:58 AM] [DEBUG] [Pier Flip Thread] Meridian Flip: Procedure complete
[7/4/2015 12:58:02 AM] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (False)
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] SBIG Camera: end exposure called…
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] SBIG Camera: end readout…
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] Run event requested sequence abort…
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] Clearing timed monitoring events…
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] Checking RunEndOfSequenceEquipmentOptions, force = False
[7/4/2015 12:58:03 AM] [DEBUG] [Sequence Thread] Sequence was aborted, skipping end of sequence options…

If I’m interpreting the above correctly, it seems that SGP asked the mount to perform a meridian flip, and the mount rightly refused since it couldn’t go from the “scope on the West pointing East state” to the “scope on the East still pointing East,” which makes sense since the OTA still hadn’t reached the meridian and looking at the physical configuration of the scope while this was going on showed it to be impossible.

Any suggestions? Did I do something to bring this on myself via misconfiguration of either SGP or the connected gear? I was fussing about the laptop desk at the time this happened, but AFAIK I hadn’t touched the keyboard or mouse. My first thought when the meridian flip window came up was that I’d trigged it myself, but I’m having trouble guessing what I might have done that would have caused the sudden hour angle leap we see above.

I’ve not actually done a meridian flip with this gear configuration yet, and had been hoping to save that for a night of drill and practice dedicated to meridian flipping sometime in the next few days. I’ll definitely be trying deliberate meridian flips next time I get out. In the meantime, if anybody has any pointers, I’m all ears.

Beyond the surprise meridian flip though, the night of imaging was great. The SGP/PHD2 combo in my current configuration performed otherwise beautifully and it was faster to get started than any night so far.sg_logfile_20150703220406.txt (569.6 KB)

mads0100 · July 4, 2015, 5:02pm

Personally I’d do a factory reset and turn on detailed ASCOM logging in your ASCOM driver. The details I needed for fixing my meridian flip issues were in there. SGP really just asks the mounts to do the flip based on your flip settings; it’s up to the mount to decide if it’s in the right position based on your limits.

I found with my mount there was a pretty tight tolerance for it.

With the ASCOM logs,Chris might be able to help you too.

Ken · July 4, 2015, 5:50pm

Jerry,

OK… Thank you for the detailed breakdown… always makes things easier to track. The problem in this case is that SGPro suddenly failed to get your mount’s sidereal time:

[7/4/2015 12:56:27 AM] [DEBUG] [Main Thread] ASCOM Telescope: Error in GetLst : Timed out waiting for received data (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Timed out waiting for received data

As to why, I cannot be sure. Sometimes this is a simple loss of connectivity. Not really sure what caused it. That said, future releases of SGPro will be way less dangerous when this failure occurs. Instead of automatically initiating a flip on failure (bad), no action is taken and a warning is issued to the notification system letting you know there is a problem.

JerryK · July 4, 2015, 6:35pm

Hi, Ken:

Very interesting. Thanks for the quick response!

Revisiting the log I see:

[7/3/2015 11:18:45 PM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetLst : Timed out waiting for received data (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Timed out waiting for received data
[7/4/2015 12:56:27 AM] [DEBUG] [Main Thread] ASCOM Telescope: Error in GetLst : Timed out waiting for received data (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Timed out waiting for received data

So it looks like it had this grievance once earlier in the evening about an hour and a half before the premature meridian flip incident occurred without any apparent ill effects that time. How often does SGPro ask the mount for the sidereal time? Is there something I should look for in my logs to confirm that there are presumed successes earlier in the evening? How many tries does SGPro make on GetLst when it decides it needs to do so? I’m guessing that when SGPro failed to get the proper sidereal time, it didn’t really know what the meridian should be, and thus improvised in an unfortunate way by trying to flip?

JerryK · July 4, 2015, 6:43pm

Hi, mads0100;

Are you also a CGE Pro user?

I assume by Chris you mean Chris Rowland, the author of the Celestron ASCOM driver? Does he lurk on this forum?

I’ll definitely check out the ASCOM logs.

Thanks,
Jerry

Ken · July 4, 2015, 6:54pm

Just bad timing. In this case, your mount had several good calls (after the bad one) to get sidereal time before checking on the need for a flip. On the failure later, it was the last check on sidereal time before SGPro checked if a flip was required.

Once every 5 seconds.

Just one. This is not something that should be an “iffy” call so there is no retry mechanism around this (nor should there be).

Yes. This has been fixed.

The fact that your mount is actually reporting a timeout error when attempting to get this property necessitates the need for ASCOM logs.

JerryK · July 4, 2015, 7:42pm

Thanks, Ken. I’ll dig into the ASCOM logs next.

The auto-meridian-flip on GetLst timeout fix will land in the next SGPro release?

Thanks again for the help!
Jerry

Ken · July 4, 2015, 7:44pm

Actually, it will be out in the first public beta. The private beta is already out so it will probably just be a few days until you can use it (if you are inclined to use beta software).

JerryK · July 4, 2015, 8:19pm

Hi, Ken:

Thanks. SGPro versions historically seem pretty solid by the time they hit public beta, so I’ll probably install it as soon as it lands.

In the meantime, I’ve turned on ASCOM tracing for the Celestron mount driver, and I’ll spend an evening doing some near meridian flip experiments and see if I can get any more insight.

mads0100 · July 4, 2015, 11:29pm

Jerry,

I used to have a CGEM that I used in my observatory . Not much I couldn’t fix with a factory reset! Sounds like you just had bad luck. Could be a cabling issue? Maybe try a different serial cable if you have one. Or, a different USB to aerial adapter (I have the worst luck with those things!)

JerryK · July 5, 2015, 12:08am

Continuing the discussion from Unexpected Merdian Flip with CGE Pro:

Ah cool. Did you have the CGEM or the CGE Pro? I don’t think I’ve had occasion to factory reset this unit yet. I turned on ASCOM tracing as you suggested and will keep that log file open in a window the next night out I get to see if there’s anything untoward going on. Ken said they’re going to remove the premature meridian flip that happens if a request for sidereal time from the mount fails, as they sometime seem to (I saw two of these events in last night’s log, one of which didn’t really hurt anything, the other which caused the incident).

USB to serial adapters are fussy. I tend to buy multiple copies of any one that I find that works since you never know when chipsets are going to change or models are going to be discontinued and create some new annoyance to debug.

Next night out the watchword will be play with meridian flips and make sure they work as expected. With that taken care of I may have this rig at the point where it can run through the night without much human intervention!

Chris · July 5, 2015, 7:56am

Yes. As people say I need the ASCOM driver logs.
By the way, the HC version that matters is the one that’s loading into NexRemote. With NexRemote the HC is passively passing commands between NR and the mount.

Chris

JerryK · July 5, 2015, 8:05am

Hi, Chris!

The version numbers I included in my original post were all read off the display of NexRemote on my imaging laptop, so those should be correct.

I’ve turned on ASCOM tracing for the mount driver and will make a habit of leaving it that way the next night I get out and have a chance to fiddle around the meridian a bit. I’ll update this thread with any observations or discoveries if I can get the timeout on getting mount sidereal time to happen again.

Thanks for your work on the driver, BTW. You also wrote the software for the Moonlite Focuser/Rotator gear as well, didn’t you?

Best,
Jerry