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.)
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.
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.
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 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.
The program options are divided into three menus;
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.
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.
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.
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;
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 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.
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