Anyone trying to use a Celestron scope with NexStar knows that hibernation is not available through the ASCOM driver. This is because Celestron uses a bizarre, undocumented interchange between its hand controller and the scope. They have replicated this interchange with NexRemote, the PC version of their hand control. For those of us who are using our scopes remotely (even if it's the backyard), this is most annoying. For distance remotes (like mine at 100 miles from my observartory), this is impossible.

Celestron remains invincible in their unwillingness to document/disclose that interface, so we're on our own to "reverse engineer" a set of message traffic, none of which make any sense by casual inspection.

While I am continuing my analysis, I have developed a workaround, some would say an ugly workaround, that does work. Here is a description.

I have developed an interceptor to the ASCOM Telescope driver which sits between the driver and ACP (or any other set of clients). We did this in order to more seamlessly integrate our AtPark Monitor so that ASCOM "AtPark" includes input from our device on park position. The interceptor functions well without this hardware installed. It's a little like "Pipe" without all the display capability.

So what we incorporated in this SupreDriver is a method to invoke a script of mouse movement and clicks at two points in the process: First Client Connection, and Final Client Disconnection.

These scripts fire up the NexRemote software and "effect" the WakeUp and later "Hibernate" command sequences. Yes, there are sequences At the conclusion of Hibernate, the script shuts down NexRemote.

The NesRemote is configured for Virtual Port operation and the ASCOM Celestron driver is connected to that virtual port. (The NexRemote software is connected to the real scope port).

I know, I know. Everyone is recoiling at this point. Biut this is at present the ONLY way you can operate a Celestron NexStar/NexRemote configuration.

Maybe someday, Celestron will see sales waning and provide a better answer that would fit into the ASCOM driver. And I'll oontinue to "break the code" on the interface. Until then clunky is good enough.

If you would like any more info on this, email me at:


Stan Ralph