Observatory dome controller

The controllers are based on the old NexDome shield as I'm the one who design it for NexDome.

This new controller use an Arduino Due (ARM Cortex-M3 CPU at 84MHz) and a new shield that integrate a dedicated USB port using a usb-serial FTDI chip, an Ethernet port using the same controller as the standard Arduino Ethernet shield (WIZnet W5500) and a standard Powerpole connector for the power.

It still uses the XBee modules for the rotation controller to shutter controller communication.

Rotation controller features :

• 12V powerpole power input.
• Ethernet connection.
• USB serial connection (using a FTDI chip).
• Fully upgradable using the Arduino IDE.
• Ability to change the XBee Pan ID for location with multiple domes.
• Can drive any stepper driver or servo drive that use the standard 3 signals: Enable, Direction and Step.
• Has a calibration procedure to allow it to work on any dome size.
• XBee for communication with Shutter (it uses the recent XB3-24Z8PT-J).
• 2 inputs for weather event auto shutdown (first one is for the Hydreon RG-11).

Here is a photo of the current rotation controller shield :

The dome controller is meant to be used on dome like Nexdome, Explora Dome, any dome that can me moved by a good stepper motor, assuming you get the track and the cogwheeel or gear from the manufacturer. In all case, make sure to get a motor with a good torque and a gearbox on it (default Ratio is 15.3:1 on the NEMA 23 motor used by Nexdome). If your dome is on the heavy side, I would recommend something in the 9 to 12 Nm torque with a 16:1 gearbox on it, powered at 24V or 48V with 4 to 8 Amps (this usually requires the use of larger NEMA 34 motors and gearbox). When chosing a motor and gearbox make sure the output shaft can be used on the gear you'll get. The NexDome and ExploraDome gear (or cogwheeel) have a 12mm shaft hole (aka bore) on their hub. A lot of gearbox come with a 14mm and 16mm shaft so some adaptation might be required (enlarging the hole with a drill press)

As more people test this on their own dome and get new ways of getting a track and motor on them I'll build a list of motor, gear, track vendors ...

If you only need/want to automate the dome rotation, you don't need the XBee module and the firmware can be configured for standalone mode.

This has been tested with the original Nexdome stepper driver (TB6600) as well as some ISD04 from StepperOnline.

Depending on what stepper driver you use, you can set the proper level for the enable signal in the firmware (HIGH or LOW) to ensure that when disabled the stepper driver doesn't draw any current.

Do not apply more that 16V to the shield input as this would damage the Arduino DUE. If you need to power the motor with 24V or 48V, see my power adapter bellow. The default settings work for the TB6600 and ISD0x stepper drivers

Here is the wiring diagram for the current version :

As said, if you need to power the motor with a higher voltage than 12V (the absolute max for the Arduino DUE is 16V), use this adapter, it will take between 24V and 60V and output the same voltage on one output and regulated 12V on the other. If you build it yourself, make sure the PCB is manufactured in 2 Oz copper thickness (0.0696 mm) which should support up to 20A of current (probably more as the power is routed on both side) :

The shutter shield is a lot simpler as it only need to connect to the rotation controller over the wireless link using the onboard XBee module.

Shutter controller features :

• 12V powerpole power input
• Fully upgradable using the Arduino IDE
• Can drive any stepper driver or servo drive that use the standard 3 signals: Enable, Direction and Step.
• Support for dual shutter system (require a Cytron MD13S, about $10, to drive linear actuator(s) for the bottom drop out shutter). Not implemented yet in the current firmware (hardware is ready for it)
• XBee for communication with Rotator (it uses the recent XB3-24Z8PT-J).

Here is a photo of the current shutter controller shield prototype :

The stepper driver type is configurable in the same way as the rotation controller (HIGH or LOW for Enable) in the firmware.

In addition to the 2 sensors input for the main shutter, 2 inputs are wired for future use (like open/close sensor for a drop-out shutter) as well as 2 outputs (to potentially control Cytron MD13s to open/close a dropout shutter using a linear actuator).

Here is the wiring diagram :

All the PCB files are in the git repo ( PCB files ) . I use Eagle CAD to make the PCB.

There is also CSV files in the repository with all the commponents and manufacturer part number. As some component might be out of stock you can replace them with equivalent ones from other brands (mostly resistors, capacitors and buffers).

The controllers firmwares are based on the old NexDome 2.x code with a lot of part rewritten (bug fixing, better XBee configuration which result in a very stable connection between the 2 controllers, new features, ...).

The calibration and homing were totally redone. They now use edge triggered interrupt to detect the home sensor and always from the same side. So no matter where you are, a find home will always rotate the same way (clockwise) and potentially go the long way around.

This garanties that we always hit the magnet sensor from the same side as it's fairly wide depending on how you install it.

All input are using interrupt (buttons, rain sensor, ...). This is a lot more reliable than pulling in the main loop and was needed for the new calibration and homing code.

All code changes are first tested on a test rig and then on my Nexdome dome to make sure it also worsk in real conditions (My NexDome is currently running with this, not the original hardware, and this has been extremly reliable)

You can find the firmware on my github repo : RTI-Dome Firmwares

By default the rotation controller network configuration is set to use DHCP. If no DHCP server is available, it will default to 192.168.0.99 with a netmask of 255.255.255.0 and set its default gateway to 192.168.0.1 after about a minute. The TCP port is 2323. Only one connection is allowed at a time over TCP to avoid conflict.

The USB serial connection is set to 115200 bauds (115200 8N1).

The default PAN ID for the XBee is set to 0x4242. It can be changed and if the rotation controller is already connected to a shutter controller, it will send it the new PAN ID, reconfigure itself while the shutter controller does the same, then reconnect using the new PAN ID. This is usefull if you have more than one set of controllers close to each other (multiple domes). If you plan on having more than one set, I would recommend that you change the PAN ID even on the first one before setting the others (aka you only have one for now but plan on having more).

All settings are saved to an EEPROM on both controllers.

Controllers Commands documentation : rti-dome-commands.pdf

As I mostly do X2 PlugIns for TheSkyX, that's the only supported application for now via a new X2 plugin : RTI-Dome X2 plugin

If someone want to write an ASCOM or INDI driver, contact me and I will send you a set of dome and shutter controllers (including the Arduino Due and XBee modules).

Here is a quick list of things I'd like to add or change to the current firware and hardware :

• Replace the AccelStepper library with something more adapted to running under interrupt (still need acceleration/decelleration).
• Add support for drop out shutter. The hardware is there, I need to add the code to the shutter firmware to control linear actuators with a Cytron MD13S (or something similar).
• If we can design some type of power bus/ring to power the upper part of the dome, we could remove the XBee and use RS485 for wired communication and get rid of the whole battery system.
• Add an option to operate the shutter at park only so that it connects to some power pads and is only powered at this position. This is another way to not have the battery on the upper dome. This might already work but need testing.
• Make a firware version for Roll-off Roof.