Home, Park and Home Sensor Magnet Positioning

The NexDome Rotator control system defines two well-known positions:

1. The Home Sensor Azimuth
2. The Park position

These positions need to be carefully set during installation and commissioning, and will likely not need to change thereafter.

The Home sensor azimuth should be established first before the park position, since the Park position depends on the fixed positioning reference provided by the home sensor.

Important Definition: Home is a calibration process, not a position or state. When the calibration process completes successfully, rotational positioning is calibrated and should correspond to real-world azimuths, as long as the sensor has been installed and configured correctly. The Homed status flag reported in the :SER response indicates the result of a homing (@GHR) operation; it does not indicate that the dome is in any particular position nor does it indicate the state of the magnetic sensor. It is only an indication of whether the the calibration process succeeded or failed. Therefore client applications must not use this status flag as an indication that the dome is in any particular position.

One implication of this is that the rotator firmware does not have any concept of a home 'position' that you can go to. The rotator can only be positioned by issuing normal go to azimuth commands: @GAR or @GSR.

This definition was adopted because the home position sensor is a magnetic device that activates over a region of several degrees of azimuth. Therefore, the "home sensor" being active does not accurately indicate that the rotator is in any particular position and the firmware does not report the state of this sensor to the client application.

Client applications are free to introduce the concept of a home position at the application level but the client application must then provide its own interpretation of what it means to be "at home" and this has no meaning within the firmware. If the application wishes to know the position of the sensor (not reccomended) then it may obtain this using the @HRR command, but be sure to understand how that value is defined (see below).

Home Sensor Azimuth

The Home sensor azimuth is a fixed reference point from which to measure the absolute rotation position, or azimuth. Azimuth is measured from true north and increases clockwise. It can be anywhere around the dome circumference and the control software needs to be configured correctly.

The home position depends on several variables:

1. The orientation of the structure with respect to true north.
2. The installation position within the dome of the drive motor.
3. The installation position around the dome circumference of the magnet.

Rather than try to measure and enter all these factors, the software boils it all down to a single value: the Home Sensor Azimuth. This is defined as:

Home Sensor Azimuth is the angle, starting with the dome slit at true north, through which the dome must rotate clockwise so that the magnet aligns with the home sensor.

Note: the home sensor azimuth is not the slit azimuth when in the home position. Read the definition carefully.

While this definition may seem a little opaque at first, it does wrap all the variables up into a single value that can be easily determined, particularly for a new installation, as explained below.

If you already installed your azimuth sensor magnet with the slit pointing towards true north, then provided your dome positioning is accurate enough for your needs, you are in good shape and may not need to do anything further. The software and firmware defaults to zero so you are good to go. If you haven't yet installed the rotator or it doesn't perform well enough for your needs, then you can proceed as follows.

New Installation

It is assumed here that the rotator hardware has already been installed and is able to drive the dome, but that the home position magnet has not yet been installed.

In a new installation, we can arrange for the home position to be at azimuth 0. This keeps things nice and simple.

First, you need to find the direction of true north (not magnetic north) from the centre of your dome. True North can be found by a shadow cast at local noon, by sighting on a star known to be near the northern meridian at night, or by taking a compass reading on magnetic north and adjusting for your local magnetic deviation. Once you have a position, mark it as you may need to return to it several times as you make adjustments.

Once you have your dome slit facing true north, you can place the home sensor magnet on the moving part of the dome, so that it aligns with the sensor on the rotator drive unit. Fix the magnet temporarily to begin with, in case you need to make adjustments. You could use "Blu Tack" or equivalent, sticky tape, or some other means of temporary fixing. This will give you a position accurate to within a few degrees.

If you are lucky, this position may be "good enough". However, the magnetic field of the magnet is both invisible and of unknown size, so while the sensor may look aligned visually, you may discover that it actually triggers the sensor some distance before it comes into alignment. This is why the dome always approaches the home position in the clockwise direction. It is looking for the first point at which the magnetic field will trigger the sensor and to get consistent results, it must always approach from the same direction.

You can test the effectiveness of your magnet placement by having your planetarium or control application issue the Find Home comand (or, connect to the rotator with a terminal emulator and issue the @GHR command). The dome will rotate clockwise (possibly all the way around) until the magnet triggers the home sensor. It will then decelerate to a stop, reverse, and stop at the exact home position. If you are "close enough" for your needs, then you could stop here. Configure the ASCOM driver to use a value of 0 for "Home Sensor Azimuth" and you are done.

Iterative Refinement

If your magnet position is not accurate enough, then it can be refined iteratively. After the "Find Home" command completes, observe the difference between the dome slit position and the true north position that you marked earlier. If the shutter needs to go further clockwise to reach true north, then move the magnet a little bit anticlockwise. If the shutter overshoots true north, move the magnet a little bit clockwise. Re-issue the Find Home command and observe the new results. Repeat until you are happy with the results, then permanently attach the magnet.

Due to inherent tolerances in the electronics and various other factors, it is unlikely that you will be able to achieve better than 1 degree accuracy, which is a little bit less than 1 tooth on the drive rack. If you are within 1 tooth width of true north, there is probably not much point in continuing further.

At this point, fix the magnet permanently and configure the software to use 0 for "home sensor azimuth".

Existing Installations

If you are setting the home sensor azimuth in a situation where the sensor and magnet have already been placed and you can't or don't want to move them, or if for some reason it needs to be at a position where the shutter is not at true north, then the sensor azimuth will not be zero and will have to be determined experimentally. Remember, the home position can be anywhere around the dome circumference, as long as the sodtware is configured correctly.

Start by finding true north as detailed above. Move your shutter slit so that it faces true north and note the azimuth reading An in your dome control software.

Now, manually rotate the dome using the rocker switch until the magnet visually aligns with the home sensor. Note the new azimuth reading Ah in your dome control software.

Compute the home sensor azimuth as Ah - An. If the result is negative, add it to 360.

You now have your first approximation. You can now refine this iteratively as noted above, but instead of moving the magnet, adjust the software setting for Home Sensor Azimuth setting.

Park Position

The rotator firmware has no concept of a park position. "Parking" is a concept introduced by ASCOM but is not well-defined for domes, stating only that the Park command rotates the dome to the programmed park position. Other ASCOM device standards have a much stronger definition, and by inference, parking a device should place it in a "safe state" ready for shutdown.

For the NexDome driver, this has been interpreted to mean that the observatory is shut down and that the shutter charging contacts should be engaged. When the ASCOM Park command is issued, the dome will rotator to the Park position, then the shutter will be closed if it wasn't already. This puts the dome in a safe state with the shutter batteries charging, until it is needed for another observing session.

Therefore, you should set your park position in the ASCOM driver settings to be the position where the shutter motor contacts align with the battery charger contacts.

Assuming you have already set your home position (see above) then you can determine this position by manually rotating to the correct position, then reading off the azimuth value from yoru dome control software, or from the ASCOM driver status panel. This value should then be entered into the ASCOM driver settings page, under Park Position.

Alternatively, you can instruct your dome control software to issue the SetPark command, if your software supports it.

Changing Software settings

Please note that the ASCOM driver settings only take effect after all clients have disconnected. Therefore, after changing any configuration settings, your should always disconnect all client software from the driver (at which point it will exit). The next time the driver is loaded, the new settings will take effect.

Related Questions

Why isn't there a way to calibrate the number of steps per rotation?

Calibration is a double-edged sword. On one hand it can be easy and requires little thought or effort. On the other hand, the value obtained from the (relatively) low-precision sensor used by NexDome would probably not give the exact number of steps per rotation. One motor step translates to only 0.00654° of azimuth. This would be challenging to measure with a bar magnet and hall-effect transistor and the physics of toothed gear systems moving an inertial mass. The small error in measurement would would introduce a slow 'drift' in position over time.

In a stock NexDome installation, the toothed track always has the same number of teeth - 288. The stepper motor is a fixed angular rotation per step and the gearbox ratio is known. Therefore there is a fixed mechanical relationship between motor steps and angular dome rotation. The number of steps per rotation can be computed exactly with no error. One complete dome rotation of 360° will always take exactly 55080 steps. There is never a need to recalibrate this value as it is a fixed gear ratio.

The firmware adopts a compromise between these two positions. There is no calibration procedure for the "number of steps per rotation" (circumference) because this is a fixed value that can be computed in advance and simply entered into the firmware. There is no advantage to measuring this value; that would only introduce innacuracies due to the measurement process. There is, however, a need to establish absolute positioning in the real world. This is achieved using the "Find Home" (@GHR) command. This process uses a consistent approach (clockwise) to minimize any measurement error. This is something you might do only once, or perhaps once at the start of each observing session for a remotely operated installation. Provided the dome mechanics are working correctly, this should provide reliable and accurate operation.

For custom installations, there is still no need to calibrate because the required number of steps per rotation is always exactly determined by the number of teeth in the toothed rack. The firmware repository contains an Excel spreadsheet for computing the number of steps per rotation. Simply count the number of teeth in your toothed rack, enter that number into the spreadsheet and read off the number of whole steps per rotation. This value can be programmed into the firmware using @RWR,nnnnn ("range write rotator", nnnnn is an integer number of whole steps). Test your settings to make sure they work, then when you are happy, use @ZWR to save the settings.

Why doesn't the azimuth value reset as the dome rotates through the home sensor?

For a dome with a friction drive, DC motors or a friction-driven azimuth encoder, this is absolutely necessary because there will be slippage between the drive mechanism and the dome and/or azimuth encoder. However, the NexDome drive system uses stepper motors and a fixed gear ratio between the motors and the dome rotation. Therefore, a complete rotation always takes exaclty the same number of steps and there is no need to reset the azimuth each time around. In a geared system, there will be small positioning errors due to backlash. However this error is constrained to small values and will not accumulate over time.

The criticism of stpper motor systems is: "The motor can lose steps". This is true, but to say that "bad engineering produces bad results" is a tautology. Any badly designed system will give bad results. A properly engineered stepper motor system can be relied upon to never lose steps. The NexDome rotator uses NEMA 17 geared stepper drive which produces 240kgcm torque. This probably translates to in excess of 100 kg of force pushing on the dome. The firmware uses an acceleration curve ("soft start") so that the stepper motor is not overloaded by the inertia of the dome. The motor should always be well within its specifications. "Lost steps" should never happen in this system and if they do, something is badly wrong.

The design philosophy for the NexDome software is that it assumes that the mechanics are working properly and does not try to create "software victories over bad mechanics". In general, automation does not solve underlying mechanical issues, so any slippage must be solved mechanically. The software will then give you reliable and repeatable operation.

If for any reason positioning is compromised (e.g. a physical collision causes the motors to stall or teeth to slip) then it can be easily restored using a Find Home command (@GHR). Note: the software does not attempt to recover from "exceptional conditions". If something has gone wrong, then operator intervention is required.