NexStar Resource Site

line.gif (861 bytes)
Pop-Up Info Window
(close when finished)
line.gif (861 bytes)

Internal Communications of Celestron Computerized Telescope Mounts

When it comes to logically troubleshooting problems on a Celestron mount, it is useful to understand that all of the cabling and interface boards inside the mount have a single purpose - connecting the hand control to all of the other individual modules of the system. At a minimum, every current Celestron computerized telescope has one internal module: the motor control (a board with two processors, one for each axis). Other possible modules in the system include GPS, Real Time Clock (RTC), StarSense camera and Celestron Focus Motor.

Everything in the system is connected together via a shared communication bus we call the AUX bus. The AUX bus is directly presented outside the mount via the hand control and AUX ports. The PC Port (for mounts with that port) is simply the AUX bus with an RS-232 communications buffer to make it compatible with more external devices, most notably a laptop or desktop computer. When the SkyPortal WiFi module is plugged into an AUX port, it is basically presenting the AUX bus via WiFi. For mounts with an internal WiFi module, that too is basically presenting the AUX bus via WiFi.

Some of the devices on the AUX bus occasionally send out unsolicited packets of information but generally the hand control initiates all meaningful communication either sending actionable commands to another module (for example, movement commands to the MC board or imaging commands to the StarSense camera) or asking a module for information (for example, date/time/location info from the GPS module or current ALT/AZM coordinates from the MC board). The bus is pretty rudimentary in that multiple devices might send data at the same time, corrupting the messages, so the hand control is resilient in analyzing received packets and asking for them again if something is corrupted. Finally, the way the system currently works, all communication is between the hand control and other modules, the other modules do not communicate with each other.

If the hand control sends a command to a module and does not receive the expected reply, it will display a No Response XX error where XX is the internal device ID of the module.  For example, 16 is the device ID of the azimuth processor in the motor control module while 17 is the ID of the altitude processor.  Read this for suggestions on resolving No Response errors.

Note that if you are using SkyPortal/SkySafari or CPWI to replace the hand control on a system with Celestron WiFi, you can substitute SkyPortal/SkySafari/CPWI for hand control in most places in the previous discussion. The same for NexRemote - you can substitute NexRemote for hand control in the discussion above.

line.gif (861 bytes)

line.gif (861 bytes)
Michael Swanson
  Contact the webmaster: