CoSaTrak - Computerised Satellite Tracking
- Electronics and Software overview -

by Willie Koorts

Introduction:

My first attempt at a motorized satellite tracking mount
My first attempt at motorizing my satellite tracking mount using old floppy disk drive motors proved not to be geared down enough resulting in a very rough track. However, this system was good enough for developing the software.
(Here is a page on this original mount.)
(Here is a page on my new mount.)
Two major factors lead to the making of this program. First when Greg Roberts got me interested in satellite tracking as a hobby some years ago and second, after coming across the website of Mel Bartels and his excellent explanation of motorizing a Dobsonian telescope and putting it under computer control.

After manually tracking satellites for a while, the idea of a computer controlled satellite tracking telescope started growing in my mind and I soon built up a circuit and wrote some software that was able to turn old floppy-drive stepper motors under computer control. As the program grew these motors were subsequently installed on my telescope mount in order to try out new features. For various reasons however, I lost interest when the program was at the point of being able to perform some primitive motor movements.

About three years later, Greg retired and started working on a similar project. Following a chat during tea break one morning I was again inspired and dug up the code, circuit diagrams and hardware. By this time he had just about finished constructing a Bartels system, so I gave him a copy of the primitive program to play with. He soon came back with a favorable report on what little existed of the program at that stage, which was all the inspiration I needed to resume working on the program again. With Greg's continual encouragement and support, and about four months of sometimes very late night programming, the program has reached a point where it could be released to the larger telescope building and satellite tracking community on 21 June 2000.

Electronics:

My electronics box with its lid removed
My electronics interface box includes the transformer (left) and hardwired circuit (right) with the mains and printer port connections coming in from the bottom and the feed to the motors going out at the top.

Although similar, the hardware I built was not an exact copy of Mel Bartels circuit and my program had to be slightly modified to drive Greg's Bartels-implementation. The circuit is very simple since the computer essentially becomes the indexer, generating the complicated step patterns needed to drive the two stepper motors. Eight output bits (four per motor) from the standard PC parallel printer port are simply boosted by transistors in order to switch the motor windings as required. Mel suggests buffering the printer port output by making use of a TTL inverter or non-inverting buffer chip, particularly when driving higher voltage motors, in order to protect the printer port. This, however means also generating a +5V supply to feed this chip. Since I am using low current 12V motors, I did not include this chip and made use of Darlington driver transistors without any ill effect (yet!). As a safety precaution I am not running the circuit from my motherboard-based printer port but from a seperate plug-in I/O card.

To insure as smooth a movement as possible the motors are half stepped, effectively converting a 200step/rev. motor into a 400step/rev stepper, moving 0.9 degrees per step.

Computer requirements:

Although initially thought that CoSaTrak would not be very demanding on computing power, practice has shown that there is a definite gain when running on a faster PC. The system has been tried on computers ranging from XT's through to Pentium I class machines. The limit at which a particular mount could keep up with fast moving satellites was found to be directly related to computer power.

Greg originally ran on a 386 and got fair results. After switching to an equivalent 586 type machine (without co-processor) he immediately found that he could get faster speeds out of his motors. He can now easily track most 80° elevation passes while still having full display updates switched on (level 0).

The Azimuth drive
The Azimuth drive consists of the spring tensioned motor pushing against a home-made gear consisting of a toothed belt glued inside-out to the protactor "setting circle" base-plate.

Software:  

Note, the screenshots below are for and older version of CoSaTrak and will be updated soon.

The program is written in Turbo Pascal and runs under DOS, the main reason being that Windows is not a real-time operating system. For a very good demonstration of how poorly Windows handles real-time applications try running the program inside a window and note how much slower the motors turn and how irregularly the time ticks by. You can also forget trying to smoothly run any motor when Windows occasionally sports into a hive of disk activity doing its housekeeping.

The program options are divided into three menus;

Extensive use of "hot keys" are made to minimise keystrokes with escape routes when the wrong option was accidentally selected.

  • Motor/Mount calibration Menu:

    •  A screendump of the Motor/Mount calibration Menu The software provides full compatibility with Mel's system which involves changing two program settings and you can start tracking satellites with your standard Bartel's system right away. (Read here about the restrictions of your astronomical system with satellite tracking.) Another choice selects whether the mount has a cable that can get twisted up in the azimuth mechanism or not. Without such an umbilical the mount is free to always take the shortest route when slewing to the next position. When tracking a satellite or celestial object this setting gets temporarily disabled to allow the mount to traverse the meridian - the mount would otherwise have gone back "the long way" when slewing past the meridian in order to unwrap the cable.

    All the different motor parameters like maximum speed, direction, ramp and even the step angle (which depends on the installed motors and gearing) are determined interactively by actually running the motors and observing when they stall. The results are then stored in the control file as future defaults. The motors and gearing on the two axis can be different as each axis is optimised individually. There is thus no need to do any calculations to determine the results for your particular motor, gearbox, etc. For extra convenience, the last position of the mount is stored and is taken as the starting position the next time the program is run.

  • Settings Menu:

    •  The PC real-time clock is used throughout as the time base for satellite tracking and sidereal time calculation which is used for pointing at astronomical objects. The accuracy of pointing and tracking thus depends on how well the computer clock is set and how stable the clock is.

    Up to 50 observing site coordinates can be added to the database and stored in a disk file for easy selection later. Your favourite site is stored in the control file by default so there is no need to select a site unless you change your location.

  • Pointing and Tracking Menu:

    •  The Pointing and Tracking Menu Although the real intention of this program is to track satellites, a database of up to 700 astronomical objects, grouped in 7 lists of 100 objects each, can be edited to one's own taste and is available to point, track or calibrate the mount. To simplify programming the Sun, Moon and planet positions are not computed in the program, but any Alt/Az or RA/DEC coordinate can be directly entered into the program and subsequently tracked.

    For tracking satellites the program does not do its own predictions but reads in prepared text files of predictions. This done by first running SeeCoSat, written by Greg. Real time curve fitting interpolation is performed between these predicted positions when tracking a satellite.

    Starting with the last option, the simplest from of satellite spotting is "Slew and Wait". For this a .SAW-file is used which can have as little as just one prediction entry for each satellite and can have up to 100 entries per file. The mount gets slewed to each successive position and waits for the satellite to pass through the field, before slewing to the next file entry co-ordinates on command.

    Waiting for a Satellite When a prediction file is selected, the current PC time is compared to the satellite's predicted times. An error will result if the satellite has already passed, otherwise the mount is slewed to the predicted position of the first time-valid entry. In this way a pass that is already underway can still be observed, provided the mount can get into position fast enough. If not, the next position is tried until the satellite is either caught up or the pass has finished. Once the mount is in position and waiting for the satellite to arrive in the field, a few options exist;

    Automatic tracking is useful when fresh elements are used to make the predictions and the satellite is know to be faint, phase angle sensitive or have a long invisible period between flashes. Manual starting of the track is best when some uncertainty exist re the accuracy of the elements or the satellite is expected to be late or early. This time difference is then displayed. (Greg has virtually defaulted to using the manual start method.) Slewing to the next position can be used when the telescope is being obscured by a tree/building/cloud or when the predicted time had passed (announced by a beep) and the satellite was not seen.

    Tracking a Satellite Once the mount has locked onto the satellite and is busy tracking, the arrow keys can be used to move it into the centre of the telescope field. The amount of offset with respect to the predicted position is then displayed. The prediction file entries are displayed and updated as the pass progresses as well as the mount Alt/Az and RA/DEC position. RA & DEC is useful, for example, to identify a star or star-field through which the satellite moves.

    Since altazimuth telescope mounts usually have a limit in their ability to track high elevation passes through culmination, especially at near-zenith transits because of the large azimuth swings required, the mount can start falling behind. The speed characteristics of your system were also measured during the calibration procedure and is therefore known to the program. The speed requirements of the predictions are constantly calculated and if found to exceed the mount's limits, tracking is temporarily suspended and the mount automatically slewed ahead to the first prediction that is within the capabilities of the mount again. Once such a position can be reached before the satellite arrives, the mount will wait there and start tracking automatically at the same time offset found before. However, if the mount was unable to catch up with the satellite the track aborts after running out of predictions.

    The Altitude drive
    The Altitude motor gear is also made up by glueing a matching drive belt to a circle sector. Again, the gears are kept in mesh by a spring.

    Conclusion and Results

    I would like to return Greg's thanks with gratitude for firstly introducing me to the hobby of satellite tracking and for teaching me such a great deal. This software would never have matured as it has without Greg's continual constructive suggestions, encouragement, thorough beta-testing and reporting back on every new version and option I could throw at him. Thinking back to the times when we were struggling our way through some really tough bugs the "normal" situation did not arise with the hardware-man trying to blame it on the software or vice-versa. Greg kept modifying his mount while I took a harder and harder look at possible software solutions - we eventually found a very nice solution midway between these two.

    Because I was developing the software on a crude setup at home, nothing could prepare me for the result of seeing what is possible on a good mount, when watching the first VHS recording Greg made where he took his system through its paces for me by showing a camera-view of a few typical passes. The satellite would virtually stay dead-still on the same position on the screen, as if a star! When it crossed a bright star field one feels a bit disorientated for a moment until one's brain finally works out that it is the telescope that is moving! (Click here to see crude animations of some actual footage.)

    Willie Koorts - 18 June 2007

    Back to CoSaTrak pages.