TOP

Table of Contents

1. Introduction
2. User Requirements
3. Functional Requirements
4. Non functional requirements
5. Approach
6. Analysis
7. Design
8. Build
9. Test
10. Links

User Requirements

TOP

Non Functional Requirements

Non functional requirements describe the qualitative elements of a system and may include its weight, its performance, its 'look and feel' etc. They do not describe what a solution needs to do but are more environmental limits.

For this project they are defined as:

• The temperature range that the system must operate over is from -30 to +50 Centigrade
• The case must provide IP55 protection against water or damp ingress
• There should be one or more user displays in the system
• There should be one or more data entry methods that do not rely on a PC.
• The device(s) should be capable of being connected together at more than one point to allow flexibility of cabling.
• The system should minimise length, number and weight of cables where possible.
• The system firmware where any exists, must be capable of being updated.
• The system should be capable of being shutdown and started up in an orderly manner to allow system restart and continue without re-configuration.
• The solution should be capable of support of more than one of these systems side-by-side.

TOP

Functional Requirements

Functional requirements speak to the things the system must do to be a useful system. Rather than specifying detailed items, this concentrates on what the system must do and should ignore largely how the system should do it. So I should be able to use different approaches with different technologies to achieve the same ends with the same overall requirements. In this case :

1. The system should provide a computer interface to the telescope. This may be USB, I2C, serial (any type) or IP. Note that of these IP and serial provide the longest cable runs while USB and Bluetooth are the shortest. Bandwidth may also be important. Individual components need not support a computer interface as long as one does that can manage the rest of the system.
2. The computer interfaces supported must include ASCOM. Linux OTI is optional.
3. The system must provide simultaneous telescope drive in 3 axis ( worst case). It is enough to support two for first release but eventually should support all types - EQ, Alt-Az, Alt-Alt etc: multiple telescope mount type control .
4. The system must provide telescope object GoTO and object display. A signal should be issued on arrival at the target.
5. the system must support self-alignment and selection of different axis models ( alt/Az, equatorial, .. etc.)
6. the system must support slew rates of at least : guide, track, slow slew, moderate slew, fast slew. Fast slew should aim to be at least 250X track speed.
7. The system must support PEC inputs. The PEC inputs should be recording, averaging, reset and on/off.
8. The system must support Autoguide inputs. The autoguide inputs can be SBiG interface or via electronic command.
9. The system must support pointing synchronisation and pointing modeling to an arbitrary level beyond 10 stars. This modeling should be capable of being performed without a PC and the stars maintained capable of being deleted individually..
10. The system must support multiple type of motors and encoding. e.g. servo motors, AC gearmotors, DC gearmotors, stepper motors and harmonic motors.
11. The telescope position control must support pointing to 1" precision with 1' accuracy and a repeatability of 5'.
12. The system must support motors with built-in encoders, external encoders or open-loop position control. This interface may be either sin, TTL quadrature or TTL absolute.
13. The system should support user catalogues, user target object sequences and TLEs for small bodies. These should have an easy update interface. If not supported in the system , there should be a PC interface to allow this.
14. The system controller where implemented should support a remote control interface accessible from the internet.
15. The system should support internal catalogues and their update or replacement
16. The system should support PERIODIC error control either centrally or per motor both on a once-per-worm and an averaging method .
17. The system should provide an upgrade path to USB and ethernet control interfaces.

18. The system should be scalable to control multiple focuser motors, telescope shutters, sensors and remote power control switches and define interfaces to support this. (i.e. become some sort of telescope hub).

TOP

History - the Autoscope project

The project at the start in 1996 was to create a handset to drive the stepper motors of the Vixen GP DX and SP DX for which the Vixen DDx controllers where notorious for blowing up and the replacement driver chips hard to replace.

Hence I came up with the idea for a distributed processing solution comprising local intelligent controllers slaving to a master. The master in this case is the hand controller or a PC which processes the user actions through a menu, keyboard and display and then updates the remote devices. The purpose of this is to remove the high performance central processing requirement for something a lot smaller, compatible with the limited intelligence of the microcontrollers available off the shelf for amateurs.

The code in the original project was written entirely in microchip assembler and aimed at the 16C62a/72 chip series.

The components and their current state is :

1. The motor controller provided up to 10 microsteps per step based on dithering the step between two adjacent steps and allowed the user to specify 7 speed break points and remotely control the stepper via the I2C interface through a set of exposed registers. The stepping routine and the I2C routine were both interrupt driven to maintain critical timing dependencies, trying to avoid slowing the telescope down because the stepper had to wait for an I2C exchange to complete. The PCB for this was double sided and can be found here as a Protel PCB project Protel99 Teldrive PCB . The source code in assembler for the stepper can be found here : stepi2c2.asm . A second version can be found here : stepi2c.asm . A third version can be found here : steppert.asm .

2. The quadrature encoder interface was split into a second chip. It provided a slave I2C interface to read and reset the current position count. This was completed and tested.

   The encoder driver assembler source code can be found here : encoder.asm .

3. The mpu (master proc unit) provided the keyboard interface, the display and user menus to a 2x16 line LCD display.

   The display code was tested and is complete lcd.asm

   The keyboard code was not completed.

   The master internal logic as a telescope controller was partially completed mpu.asm

4. Supporting code for the assembler can be found here:
   • rate_test.asm used to test the stepper rate control
   • macros.inc include file
   • serint.asm - sample RS232 serial code.
   • i2c.inc include file of I2C commands and device addresses
5. To support the development of the I2C interface and be able to drive the system from a PC two interfaces were developed - one was a breadboard ISA bus card for attaching inside the PC with wire wrapped Philips PCF8582 I2C driver chip. To support this I wrote polled X86 C-code which is available here :
   1. i2c.c
   2. i2c.h
   3. i2c.exe compiled executable (DOS!, expects access to hardware)

6. The other was a bit-banged I2C/parallel port adapter which provides the open-collector return path through the input port. The schematics for this can be found on the web I2C parallel port adapter and the code to drive it can be found here

7. The last was a USB to I2C converter based on the FTDI chipset available from the UK Robot Electronics website. I use a lot of stuff from this site to drive the observatory. The hardware implements a virtual serial port so the code driver for this is in the form of Windows VBscript which can run in a cmd line window on the desktop to talk to the hardware for testing purposes. The VBScript can be found here : obbotools_v1.vbs

While I did complete several breadboards for stepper motors and encoder interfaces and went so far as to make some double-sided PCBs, the whole thing was shelved when I changed jobs, got some cash and bought a SS2K which did all this and more.

TOP

Fast forward to 2009

The point of the design this time around was to guide and control a large mount I had acquired capable of carrying up to a 16". The initial reasoning was to transfer my Skysensor 2K DC motors, encoders and all to the new mount. However it was more of a challenge than expected mostly due to concerns over the open encoders on the DC motors, lack of an enclosure to put them in and the fact that the SS2K was now obselete and hard to find parts for. So I re-considered the original autoscope design and decided to bring it up to date and complete it.

TOP

Design Analysis

Based on the above requirements, the design for the GoTo controller system must include :

• PC as optional system controller and intelligence since in the first instance there will be no intelligence to control motors or other devices

• PC as development platform due to their low cost and availbility of development environments for all target systems - includsing Windows CE, Linux, embedded systems etc.

• Two motors. This handles the simple telescope mount case

• I2C system bus - this is due to being familiar and having the tools already available. On top of this the bus is multi-drop so meets the minimum cable requirement and can use small cables with few conductors. The options here are limited to a system where each device is independently powered and receives signalling somehow or all devices are bus-wired and receive power from the bus, This is unlikely to be true for high-current devices such as motors and maybe other devices.

  Note that I have a range of I2C sensor components in the observatory already - mostly from the robot electronics range of I2C devices. These include a DC motor controller used on the dome, a magnetometer used to orient the dome and the wireless I2C link to talk to the me electronics which rotate with the dome. The details on this can be found here : wireless dome

TOP

Implementation Approach

The design strategy was to begin small and easy, qualify components and core functions at each stage and incrementally approach a working solution that eventually satisfied all requirements. The motor controllers and pcbs would come first, having qualified the serial and I2C handlers, then the motor control logic, kbd, menu and display code.

TOP

Design components

The design components required include :

1. Intelligent motor controllers - implementing open loop interfaces via step counting and a closed loop interface via a quadrature encoder hardware interface which decodes the quadrature to individual pulses - a gain in counting of factor x4. The motor controller is a compromise between the linistepper linear stepper motor controller and a PWM current control stepper motor and uses the drive circuit from the linistepper and the PIC 10-bit PWM output to generate and count up to 128 microsteps per step. this is done by running the motor in half-step mode and controlling the single changing step phase line. In this mode two signal lines are always powered and a third is rising or falling between steps.

   The command interface to this motor is via an I2C interface. The motor is a slave device only and handles all commands via the interrupt handler, sycnhronised to the main stepping processes.

   The command interface is specified in pic_microstep.h.

   The code file is pic_microstep.c

2. The main controller - this provides the user interface to the telescope. The main controller provides this in the form of :
   • 16-key keyboard interface (0-9, RLUD, Esc, Enter, STOP)
   • LCD display. This can take the form of a moderate-sized graphics device or the familiar 2 or 4-line LCD text device.
   • Menu driven telescope configuration
   • Ascom support for serial interface using the LX200 protocol, later with extensions for additional devices.
   • Slave device control interface for DC & step motors, focusers, telescope shutter etc.

   The telescope controller code can be found here telcontrol.c

   The controller itself provides these functions :

   • Timer reset of slew actions
   • Stop/Emergency stop
   • System park and unpark to a known position, preserving pointing attributes when cycled correctly
   • Time and date functions including alarms using an RTC
   • n*16 line lcd displays or I2C/SPI graphical displays.
   • Conversion of ephemeris position to apparent place, precession, refraction, nutation, aberration
   • Calculation of tracking rates based on mount type, alignment model and motor configuration
   • Telescope mount alignment modelling using n-stars where 2<=n <9 using Taki's algorithm adapted for least squares fitting with additional alignment parameters.
   • Mass storage interface to provide firmware update, user catalogues, telescope TLEs update etc via FAT files.
3. Shutter controller This is expected to be a simple servo device controlled using a PIC12F to drive a servo motor and commanded via the I2C interface. Its purpose is to allow the telescope aperture to be shuttered and controlled for cameras without internal shutters.
4. Dew-band interface. This is an I2C servo device providing PWM control of multiple heating devices with a local temperature sensor included.
5. Focus Rotator
This the third motor of a n-axis alt-alt mount and may rotate the entire telescope or just the eyepiece mount at a rate dependent on the mount alignment solution.
6. Focuser motor controller

TOP

Build components and tools

TOP

Links

• iOptron GotoNova

• FS2

• Boxdo¨rfer

• Vixen SS2K

• Vixen Starbook

• Vixen SS2K

• Losmandy Gemini telescope controller

• WinCTC

•