As soon as I started designing and building InFINNity Deck, I needed to think about how to drive the dome as otherwise the observatory would not be able to operate unassisted.

As can be read in the The construction of section, the dome consists of a steel base on top of which the wooden dome was constructed. Although not visible in the images on that page, on the inside of this steel base a SIMPLEX 08B-1 DIN 8187 (½" x 7¾" or 12.70mm x 7.75mm) chain was welded so I could drive the dome. The welding was only done on the bottom side and every third link. The hard thing was to get the chain to fit the circumference of the steel base. Instead of making the chain to fit the base, the base was made to fit the chain. For this the base was only tack welded on one side and when closing the chain this weld was cut and the steel was made to fit the gap that was needed to fit the chain.

As soon as the dome was placed I started to look for a proper electro-motor. First the resistance of the dome was measured so that the required torque could be calculated. Using an unster attached to the chain the force was measured that was required to start turning the dome. This came out to be around 400N (later I managed to reduce this to about 150N by waxing the track and greasing the needle bearings of the wheels).

As AWR Technology showed a Parvalux motor in the dome on their website, I initially looked for one of these motors. Using a 32 tooth sprocket of 64mm radius on the 1360mm radius dome chain would require some 34Nm force to get the dome turning. Initially I found this 24V, 92 Nm, Brushed DC Geared Motor from Parvalux with an output speed of 8 rpm, that would turn the dome 180 degrees in a reasonable 80 seconds. As soon as it arrived I connected it to a power supply and quickly turned it off again as it sounded like a pig in distress. Needless to say that this was not what I wanted to hear in the middle of the night, so the motor was returned the same day.

Another search resulted in a 320W 24V Worm Drive motor from Motion Dynamics with an output speed of 21RPM and a torque of 75Nm (see figure 2). Motion Dynamics is located in Australia, which added to the shipment costs, but they claimed "High Efficiency, High Quality, High Torque, Low Noise and Low Price!". In an e-mail I was ensured that "As long as you mount them onto rubber then they are quiet!". The difference was indeed significant, the wheels of the dome make more noise than the motor, it can hardly be heard!

A steering column from a Citroen Berlingo was arranged by a friend of mine to connect the motor to the sprocket (see figure 1). The advantage of using this column is that the length of the shaft can easily be adjusted and that the sprocket can easily be disengaged using the lever that is normally used to raise or lower the steering wheel.

To ensure that no sound would be passed on to the wooden structure of the observatory by the motor and drive-train, I created a heavy steel bracket of two 20mm thick steel layers with 50mm diameter rubber motor mountings in between (see figure 2). This also allows the motor to build up torque while starting up (i.e. the whole motor can rotate slightly counter wise when it starts to run and the dome yet has to move).

A test with an amps-meter showed that during start-up currents could easily go beyond 25Amps, at times even reaching 30Amps. To switch the motor on/off and clockwise/counter-clockwise I built an H-bridge of solid state relays, see figure 4. The H-bridge consists of four Crydom D1D40K relays. The D1D40K can switch 100V DC @ 40 amps using an input of 3.5-32V DC @ 15milliAmps.

These relays are not cheap, they come around 80 euro each (and four are needed). On the Internet cheaper ones can be found, even below 10 euro each. A video on YouTube where an electronic enthusiast buys and opens up one of these relays to see what is inside shows that those cheaper versions may contain electronics that cannot handle the current that is stated, and as a result will start to smoulder when handling the amps it was acquired for. We did not take any risk on that and spent a few bucks more by buying certified ones.

In figure 6 the actual H-bridge is shown with the 24V leads at the top. The left two are input from the batteries, the right two output to the motor. At the left a 50 W 100 Ohm resistor is mounted that catches the return current from the motor when the relays are switched off, this to protect them. A 24V DC-controller was added to adjust the speed at which the motor runs (now at 40%).

At the bottom end are at the left the black wire from an old 5V power supply and at the right the cable that runs to my joy-stick. Initially the H-bridge was controlled using this joystick at 5V. Later we implemented the Velleman K8055N USB Experiment Interface Board (see figure 8) and switched to 12V, simply because the LesveDome diagrams used 12V as well and I initially wanted to take the 12V from one of the car batteries that drives the 24V motor.

The picture of the H-bridge is an old one and in the meanwhile the white cable has been replaced by a cable that goes to a double polarity change-over switch (see figure 5), which is used to either have the joy-stick or the LesveDome implementation and has a central setting in which neither is connected, so the motor will not turn accidentally. The big aluminium plate the components are mounted upon is for cooling.

Finally I chose to use a 12V DC power supply that sits in the same socket as as the mount's power supply. This socket is turned on and off by a switch in the observatory, which has the advantage that the mount, the H-bridge, and the sensors all switch off at the same time.

The Velleman board for the LesveDome implementation required an azimuth/home sensor (see figure 6 and figure 7). The azimuth sensor was modelled after instructions found in the LesveDome manual and has a six-gap encoder wheel and two optocouplers. A rubber wheel from a robot parts supplier is used to drive the encoder disc. The frame is home-made from aluminium and brass. A spring ensures that it is firmly pressed against the dome to avoid slippage.

We used two optocouplers, a few resistors and diodes for it. For the home sensor we also used an optocoupler. We thought we had bought an inverted optocoupler (so giving a 0 when not blocked) for the home sensor, but it appeared to be a regular one. Using the optocoupler to pull down a line through a resistance worked to invert the signal. We managed to use a RJ12 connector to connect all the signals from the Velleman board to the sensor. In this way it is easy to disconnect the whole sensor for future maintenance.

In order to get the home sensor triggered I made a plastic tab of 2mm thick HDPE and fastened it with a strong magnet under the dome's base. Using a magnet to fasten it ensured that might the height of the tab not fit the opening of the home sensor that it will not cause damage. In order to minimise that risk the tab is fastened at the location of one of the wheels, so that the wheel height ensures the proper height of the tab. Initially this tab was not wide enough as a result of which it was not seen by the optocoupler when it passed through it at high speeds.

InFINNity Deck uses LesveDome and Sequence Generator Pro (SGP) to control the equipment and dome. After having installed all the necessary hardware and software, the system had to be calibrated.

The LesveDeme program needs to know how to precisely rotate the dome. It accomplishes this by calculating exactly how many times to rotate the azimuth wheel to make one full turn of the dome. The way it comes up with that number is by calculating a ratio by taking the “dome diameter” entry and divides that by the “azimuth sensor wheel diameter” entry. The result of that calculation is the ratio (i.e. the number of turns the encoder wheel needs to make in order to spin the dome a full 360 degrees)

LesveDome has a setting that specifies how many counts (or holes, 6 in my case) one full turn of the azimuth wheel equals (the “azimuth sensor wheel - number of holes” entry). So the number of rotations of the azimuth wheel multiplied by the number of holes on the encoder wheel is the number of pulses LesveDome needs to rotate the dome 360 degrees.

LesveDome has no way to know how accurate those numbers are as there is no feedback from the system to tell it so (although it could have easily been built in as after a full 360 degrees the home sensor would be activated again). This is why it needs to be verified that those numbers actually equate to exactly a 360 rotation.

An easy way is to temporarily set the park position in the LesveDome setup to 0 degrees so that when the home button is clicked, it rotates the dome to align the home sensor and resets the azimuth display to 0 degrees (just an easy number to reference from). Entering 355 degrees in the SGP “Goto” box and clicking "goto" makes the dome move. Where the home sensor should stop can easily be calculated from the diameter and number of degrees.

In the final configuration the dome can be brought "home" after which the azimuth display resets at for instance 174.5 degrees. No turn the dome 355 degrees using the goto function and turn the last 5 degrees manually. SGP updates its azimuth readings every 10 seconds, so this should be done at a slow pace. If a jump is visible when the home sensor is activated, the dome settings need adjustment.

LesveDome doesn't care what the actual measurements are; it just uses them as a way to establish a relationship (or ratio) between them. By changing that dome diameter to azimuth wheel sensor diameter the ratio can effectively be changed.

If the 5 degrees gap is undershot (meaning the home sensor is more than 5 degrees from where it should be), the dome diameter entry can either be increased or the azimuth sensor wheel diameter entry be decreased. It is the reverse when undershot.

Once the dome is rotating as accurate as possible, rotate it in the opposite direction and make sure the same accuracy is produced in that direction. Repeatability is very important, so it should be able to repeatedly hit the home sensor accurately in either direction for the system to work as designed. If for some reason performance is not repeated, it’s likely to be an issue with the encoder or azimuth wheel not operating properly (too many holes, by which the non-holes are too small to be properly detected) or some type of drive slip in the system.

In SGP the dome diameter has to be specified, but it appears to be the radius instead of the diameter. And how the diameter or radius exactly is defined, depends on the dome construction in combination with the scope set-up.

In my case the dome has two main half circular rafters which are 150mm wide (i.e. the thickness in radius direction). It depends on the width of the slit in the dome and the height of the optics above the RA axis whether the inside or the outside of these rafters will get first within the field of view. Depending on that one should either measure the radius to the inside or the outside of the dome (I use the outside diameter).

What radius fits best can simply be found by testing it: keep the shutter closed and aim the scope at a point near the celestial equator in the meridian while west of the pier. Let the dome move and mark the spot on the inside of the dome-shutter where the scope aims at. Flip the mount and let LesveDome do its job. Again mark the point on the shutter the scope is aiming at. When the value for diameter is too large (i.e. when diameter is treated as radius like in SGP) the point that the scope aims at while being west of the pier would be west of the point that was found with the scope on the other side of the pier. Reducing the diameter and rerunning this test showed whether or not the two points moved closer to each other.

In this way I found a radius that worked best for my dome of 1500mm. So indeed the "Diameter at Equator" is actually the radius. Finally I shifted the "Home Position" in LesveDomeNet Dome Setup several degrees (initially 20 degrees, now 15) to cause LesveDome to slew the slit to a position that the west edge of it comes closest to the telescope. How much one can change this value all depends on the width of the slit and the accuracy of the azimuth wheel.

For those interested to see the dome in action a short time-lapse is available showing the dome and equipment during 6 hours in the night of 30 to 31 October 2019 while imaging NGC7129:

More videos are available on the Time-lapses page.

For those wanting to build their own dome-drivers a Dome Azimuth Calculation page with a working example is available at the Astro-Software section.