The Celestron Nexstar AUX Bus

The AUX bus is called a "bus" for good reason. It is NOT a point-to-point serial link, but rather a shared, multi-master communication line with a hand-shake signal. The signalling is 5V TTL async serial 19200-8N2, with tri-stating when idle.

It uses 6-pin/6-conductor (6P6C) connectors and flat telephone style cabling. The connectors are often referred to as RJ12 plugs, and either RJ12 or RJ25 sockets. The six conductors on an accessory, in order, are (1) no-connect, (2) TX, (3) +12V-power, (4) RX, (5) Ground, (6) BUSY. On the mount end, the RX and TX are labelled the other way around, but this doesn't matter.

At first glance, it appears to have separate RX and TX lines, but those are actually a single line, hardwired together at the mount end. TX has to be tri-stated when not in use by any given device. The 6th wire on the connector is what I call the "BUSY" line. It too is normally tri-stated and gently pulled HIGH when idle. Prior to transmitting, a device must check that it is HIGH, and then drive it LOW for the duration of the transmit operation. This reduces bus collisions, but does not guarantee they won't still happen.

To prevent electrical damage from bus collisions (short duration short-circuits), devices use inline resistors on their TX and BUSY lines. Celestron uses anywhere from 100-ohms to 47K-ohms on theirs, depending on the product/vintage, with 470 to 1000 ohms giving the best results. The HBG3 uses 470-ohms.

Ohms Law says 5V/470-ohms = 10mA max current during bus-collisions, safe in short bursts for most micro-controllers. In the event of a collision, or more generally when no response is received for any particular command, the sending application is supposed to retry the command after 100msecs or more, up to perhaps five times.

The NXGPS also introduced the modern AUX bus protocol, featuring generic mount control commands that work with degrees of rotation, rather than mount-specific gear/encoder counts. The same protocol has since been extended, and is used with all of Celestron's current go-to mounts and accessories.

Each "packet" sent on the AUX bus normally begins with a 0x3b protocol-identifier. This is followed by a length byte, with values from 0x03 to 0x0d being used. The length is a count of all message bytes which follow, not including the 0x3b or length bytes, nor the final checksum byte. So the real byte-count of a packet is the value from the length byte, plus three. Or a maximum of 16-bytes in all.

After the length, are a byte each for source and destination. These are fixed known address values, common across the Nexstar line. Then a destination-specific opcode byte is required. After this, any additional parameter bytes appear, followed by a final checksum byte. The checksum is determined such that the sum of itself and all message bytes (except for the 0x3b) will add up to an 8-bit value of zero.

In response to a message packet, the destination will normally reply with a similar packet, but with the source and destination bytes reversed. The same opcode byte is used here, but possibly with different data, or no data at all for a simple ack.

The Celestron StarSense AutoAlign Accessory camera product is an outlier here. It uses the regular Nexstar AUX 0x3b protocol for most things, but it also has to send 800+ bytes of image data in response to certain commands. These don't fit the 0x3b protocol, so an entirely new 0x3c protocol is used for the image data only.