The role of motorized telescope mount is to provide automated motion control of optical tube assembly around. Regardless of the mount type it needs two axis control, either:

Former are preferred for observational astronomy and astrophotography, but the latter is more common among amateur astronomers due their simplicity and price, and popularized by John Dobson. The GoTo technology (automation of tracking and tracing process) is identical in both cases with an addition of necessary recalculation of astronomical coordinates both systems operates in. Equatorial mount drives the mount directly in equatorial coordinates, while alt-azimuth (Newtonian/Dobsonian) mount still needs to recalculate into appropriate coordinates. When astrophotography is involved, a further motor has to be used to rotate the camera to match the field of view for long exposure photographs (https://en.wikipedia.org/wiki/GoTo_(telescopes)).

I decided to build my own controller to fit my needs and to reach my goal of $100 total component price tag:

In total it would make up approx $60 (for accountable items).

Hardware components

Controller comprises of the following modules:

The role of MPU is to take care of controlling everything from start, to step both stepper motors smooth enough, communicate with Stellarium software via Bluetooth link, and to allow user control via button interface. The main "brain" is provided by 80MHz 32-bit ARM Cortex-M4F CPU with 256KB of FLASH ROM and 32KB of RAM and 2KB of EEPROM (not used at the time of writing this document).

PCB Top

PCB Bottom

Software modules

  • time reference
  • location
  • LX200 protocol support - Bluetooth communication
  • non-volatile configuration storage
  • stepper control
  • homing
  • star alignment and coordinates conversion
  • star and object library
  • Time reference

    Sidereal clock gives the earth-bound location independent clock, that is calculated as relative to the fixed stars rather than to the Sun, as traditional (sundial) clock. It allows easy recalculation of right ascension for any given location on earth, as the virtually all star maps uses declination and right ascension as coordinates. Very fast fixed-point arithmetic routine was used in A Low Cost Sidereal Clock, but due to a FPU, the floating point math is just as fast.

    Location

    GPS module provides longitude and latitude of observer location with NMEA protocol and is parsed with help of TinyGPS++/GIT library. The accuracy and resolution is slightly improved by means of averaging series of acquired positions. As fall-back option an RTC chip with NV-RAM was added to provide time and location reference in case of GPS cold start, or problems with long acquisition - which should be actually impossible for an open field operation.

    LX200 protocol

    Today's GoTo telescopes support either of two most popular serial communication protocols:

    I implemented most of the LX200 commands necessary to operate with Stellarium software:

    Other commands, such as GPS related requests (get time/date or location) were also implemented but never tested. Communication is provided wireless via software port emulated with Bluetooth protocol. HC-05 is configured as slave part awaiting for connection from a master PC. In Linux it requires a configuration with commands:

    $> rfcomm bind hci0 00:11:22:33:44:55

    where Bluetooth MAC is found with command

    $> hcitool scan

    Pairing key is currently hardcoded (but could be also stored in NVRAM). By default set to in firmware to 1234. Bluetooth device name is hard-coded tough - here set to Lightbridge.

    Stepper control

    Steppers used to motorize the mount are bipolar stepper motors, driven by DRV8825 chips that requires just a few binary configuration and control pins. Namely: three binary control pins for micro-stepping selection, direction pin and edge sensitive step input. It was critical to provide timing accurate stepping signal, therefore the AccelStepper software package was adapted to support interrupt driven stepping routine. The original AccelStepper requires timely polling, therefore support of other facilitates would have to be very quick and might easily hinder mechanical action in very undesired moments. Nevertheless, the interrupt driven AccelStepper allowed the only timing critical events in the telescope controller (stepper motor control) to work regardless of CPU load. The main API functions remained the same as the original AccelStepper. To set target point use:

    void moveTo(long absolute);
    void move(long relative);
    

    The significant difference is lack of method

    boolean AccelStepper::run()

    that needs to be called as frequent as possible. In iAccelStepper, stepping is performed in the interrupt routine handled by timers (ISR).
    Mass and stiffness of mechanical construction might require adjustment of the maximum speed and acceleration used in the AccelStepper routines. These two timing parameters needs to be established experimentally for different types of motors, size (mass) of tube assembly and gearing. Once stored in NV-RAM will be used each time controller is powered on.
    For health monitoring, a set of I2C temperature sensors can be hooked up to the I2C bus. Each of 4 possible sensors can be used to monitor different parts of system, with two dedicated for the azimuth and altitude stepper motors. Their I2C addresses are stored in NV-RAM.
    To achieve acceptable results with respect to the quality of position accuracy and vibrations observed during slewing, the size of a single step should be small enough. Stepper motors I used are equipped with roughly 1 to 63.68 gearing ratio. Micro-stepping gives additional 64 steps per electrical revolution. Effective number of steps per entire travel around 360° is a product of motor electrical and mechanical gearing, and mount gearing. In my mount this number builds up to a figure 3574144, which yields approx 0.362" (arcseconds) per step, or approx 41 steps per second in azimuth movement while slewing. Similarly, in altitude axis the resolution achieved with identical stepper motor, but different mount gearing, is even less than 0.30" per stepper motor step. To visualize stepping of 41Hz in view finder, imagine a screen with refresh rate of 41Hz. It should not be too annoying, and allow comfortable watching experience even for a long duration observation. Another reference of positioning resolution is an angular size of large objects to observe in the sky. Jupiter disc is visible as approx disc of diameter 30" when furthers, up to 50" when closest, while Venus as 10" and 63", respectively.
    Stepper motor drivers DRV8825 are configurable with three micro-stepping control inputs M0, M1 and M2:

    M2M1M0micro-stepping resolution
    000Full step
    001Half step
    0101/4 step
    0111/8 step
    1001/16 step
    1011/32 step
    1101/32 step
    1111/32 step

    To save GPIO pins, because these configuration pins are not timing critical, are not connected directly to Tiva-C GPIOs, but to I2C I/O expander chip PCF8574.

    Homing

    The role of homing is to perform initial positioning of tube assembly in one of the known reference positions. In this design it is one of the four geographic positions of azimuth direction, and either top altitude end travel position "zenith", or bottom "horizon". Homing is performed with help of tube assembly rough orientation detection sensors.

    Their operation is based on reflective optical sensors TCRT5000 Detection is based on the two-bit hamming encoded position for each axis with two strips of aluminum foil glued in arc shaped tracks.

    For azimuth, one track gives reflection (state low on respective input) for the entire west side, while the other track is reflective for south direction. Their combination gives rough information about the current quadrant tube assembly is point to, while the respective edges gives (rough) estimation of each of four geographical directions. For altitude position estimation, due to mechanical limitations of movements, the strips are located so to give information if the tube is out or in possible movement (altitude below/above horizon line, or below/beyond zenith), and if the tube is below or above the midpoint of travel. It is of course due to mechanical accuracy, and is solely used for the initial estimation, and has no impact on the overall optical tube assembly pointing accuracy.

    eastnorthdirection
    00South/West
    01North/West
    11North/East
    10South/East

    Similarly, the altitude sensors provides position and movement direction feedback (pitch):

    highenddirection
    00beyond zenith
    01high
    11low
    10below horizon line

    Notice the Gray encoding used for both direction sensor detection.
    Additionally, during homing procedure a play size is measured to establish (not used at the moment) amount of backlash in the train. In latter stage of development it could be used by cancelling the deadband in software.

    With help of magnetic compass and inclination meter mounted on the base of telescope mount should be placed on flat surface and rotated in position before homing is performed. Homing procedure initially decides into which of the respective reference points move the optical tube assembly. To make the subsequent alignment procedure easier for a user it is of course necessary to point azimuth base on relatively leveled surface, pointing the the north side to the (rough) geographical north direction. An alternative start-up routine selected with the joystick fire button held, proceeds with the measurement of the entire travel distance. It might be necessary to be performed just one time, as the travel distance is stored in NV-RAM and reused each start-up automatically.

    3 star alignment

    For (relatively) accurate alignment, procedure called 3 star alignment is performed.
    It requires user to wait for the assembly to point at a reference star, correct position to move reference star within the mid point of viewer and accept.
    The stars are selected among currently visible (high above horizon line), 100 brightest, not too close to the 90° declination, with relative high angular difference between them, to make up a large triangle across the sky. Stars are also ordered to create shortest travel path across the sky. The path is displayed in the first status display screen.
    Once the first reference star is reached, the user is requested to provide correction vector, with the digital manipulator, and confirmed with a fire button. This is repeated three times.


    Selection for such three star gives highest accuracy of alignment in the area covered by said triangle and within close proximity of its edges and vertices, being reference stars. Alignment procedure produces matrix used to recalculate actual position given by the numerical position of stepper motors and the corrected position. For more details please refer to the Toshimi Taki description or project I took inspiration from in the beginning Arduino based Telescope Controller Position of telescope and objects are primarily represented in equatorial coordinates. To find the azimuthal coordinates (azimuth and altitude) used by the stepper motor drive to control telescope tube, we proceed by computing the HA (Hour Angle) of the object. Now we have the RA, DEC and HA for the object, and the Latitude (LAT) of the observing site, the following formulas will give us the ALT and AZ of the object at the current LST. (http://www.stargazing.net/kepler/altaz.html)

    sin(ALT) = sin(DEC)*sin(LAT)+cos(DEC)*cos(LAT)*cos(HA)
    ALT = asin(ALT) 
                   sin(DEC) - sin(ALT)*sin(LAT)
    cos(A)   =   ---------------------------------
                       cos(ALT)*cos(LAT)
    A = acos(A)
    If sin(HA) is negative, then AZ = A, otherwise
    AZ = 360 - A

    Stellar library

    The remaining of flash memory was used to store the positions of the most interesting fixed objects in the night sky: Messier objects and over 200 brightest stars with information regarding their:

    The star atlas is constantly browsed through to find objects closest to the current location. The list can be used for example for "star-hoping" - while on one of the status screens one can select to hop to the next closest object/star. Other interesting objects in the night sky, such as planets in solar system require perpetual recalculation. I have included calculation of all solar system planets (meaning as of 2015, sorry Pluto fans ;) ) and the Sun and The Moon. Their positions and magnitudes are calculated with high accuracy, including perturbations of Jupiter, Saturn and Uranus. These terms needs to be taken into account since a single arc minute accuracy was required for positioning and tracking. Position of the Sun is also used to warn user of potential danger of pointing the instrument towards it with an audible (annoying) signal.

    User interface

    To communicate the user about it current status of operation, an LCD display with (configurable dimmable) red back-light is used for preservation of night-vision. If you are lucky you get red back-light module, but most of the eBay offer I have seen are modules with white back-light. Either replace white LED's with red ones, or cover with red film to filter red light only. The metal frame can be easily removed after bending tiny lips to fit in the PCB slots. Nokia 5110 is connected via SPI and make use of hardware SPI module of TM4C123G. Software module buffLCD was heavily adopted Rei Vilo, extended with double buffering, extra methods to draw primitives (lines, circles, boxes, rectangles, etc). The following set of screens informs about:

    User provides control via digital manipulator widely known as joystick. It consists of four partially independent direction controls up/down, left/right, mutually exclusive. In most of the display screens joystick acts as tube assembly control input: it allows manual control of telescope in four directions, limited by the acceleration and speed profile and horizon/zenith limits. In configuration screen, joystick is used to traverse menu (up/down) and modify parameters (left/right).

    In case of alarms, an audible feedback is made through buzzer. Tones are formed in short and long durations to create telegraphy messages.

    Horizon line

    A virtual line above zero degree altitude used in various points of the controller (visibility statuses, alignment star selection, etc.) It can be defined to reflect the obstructs visibility at the current location. It can be set using fire button whenever telescope is pointing at the highest point of obstruction, and the menu item is selected. It is stored in NV-RAM and will be also reused next time controller is powered on again.

    Stellarium

    Even tough the goal was to make the controller completely standalone, it makes it much easier to use when connected via Bluetooth serial link with a PC running virtual planetarium software. The communication is based on LX200 protocol. Telescope controller provided continuous information about its position, and fulfills the requests to move around. To correctly configure Stellarium, enable Telescope Control plugin, and configure it according to the following settings:

    Once set, the communication should be automatically established when the button connect is pressed. The hair cross reticle should appear in the location where telescope is currently pointing at. To command telescope to slew in certain direction, press Ctrl-1 (where 1 is the index of telescope plugin). For debugging, one might use telescope server. It helped me a lot to debug implementation of LX200 protocol. If you plan to implement LX200 in your controller beware of buggy parser in Stellarium plugin - it crashes if the coordinates do not follow strictly its expected format.