Satellite Dish Tracking System: A Project Report, Study Guides, Projects, Research of Electrical and Electronics Engineering

Download Satellite Dish Tracking System: A Project Report and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

SATELLITE DISH TRACKING SYSTEM

By Randall Brace and Daniel Whitted ECE 345 Jon Benson May 2, 2000 Project #

ABSTRACT

The purpose of this project was to allow the Electrical and Computer Engineering Department to control the 5 m satellite dish on the roof of Everitt from inside one of the labs. This would allow classes to utilize the communications capability of the satellite dish without having to access the roof to move its position. Control of the dish is accomplished by the use of an East motor and a West motor. Its position is known by the use of sensors, which give a 5 V signal for every three rotations of the motor shaft. The hardware/software interfacing was done through the use of a National Instruments Data Acquisition Board. LabView programming software was then used to produce the controlling program. ii

1. INTRODUCTION

1.1 Background The Department of Electrical and Computer Engineering at the University of Illinois at Urbana- Champaign recently received the donation of a 5-meter satellite dish. This satellite dish was capable of receiving television signal for classroom and departmental use. The hardware that accompanied the dish was a horizontally operating motor as well a control panel residing directly beneath the dish. This control panel contained manual switches capable of moving the dish east or west within its 180 range of operation. This crude system had several key limitations. There was no system for the determination of relative position other than by sight. This was one of the main goals of the project. It was accomplished by the acquisition of a pair of digital sensors. These sensors would generate a periodic digital signal that was used by the hardware/software to detect the position of the satellite. Counting the rising-edges of the sensor output and continuously comparing the accumulated count to the previous position accomplished this. The relative position of the satellite dish was also referenced to the operational limits and the original known position gained through the use of a calibration routine. This calibration routine tested for the limits of operation of the control motor by sensing when the motor operating and the sensor output was zero. This gave us a numerical reference for the range of allowable operation. Since the program also runs the satellite dish to the center of the range of operation, the position of the satellite in relation to the limits is known. 1.2 Block Diagram Figure 1.2.1 – Block Diagram Motor (^) Sensors Optical Isolator National Instruments DAQ Board

1.3 Performance Specifications The sensors needed to be attached to the motor in such a way that for a rotation of the motor, the sensors would give a certain number of pulses. These pulses needed to be digital high-low defined by +5v or 0v. In addition to this, there was a necessity to isolate the sensor signal from the National Instruments DAQ board. This was a precautionary measure that was intended to protect the computer from lightning strikes or any other surges that could possibly harm the computer. This was accomplished using an optical isolator. The motor wires also had certain guidelines. The motor wires are normally +5v and must be grounded to a common ground in order for movement to take place. These wires also ran to the roof and were thus subject to the same isolation requirements as the sensor wire. This was accomplished by using Reed Relays to tie the motor wires to common ground while also isolating the hardware from the roof. Certain performance characteristics were also required of the National Instruments DAQ board. The board needed to output a digital +5v high and 0v low in order to drive the implemented TTL. The program and the sensor also had certain restraints on their operation. The entire program loop delay had to be less than the period of the sensor output under maximum operational conditions. This was a restraint that was placed by trial and error. It was noted that when the sensor signal period was less than the loop delay of the program, the program would miss counts and not be able to accurately start and stop the motor. 1.4 Subprojects This project was divided into five parts: hardware design, software design, hardware testing, software testing, and unification of hardware and software. Hardware design consisted of the acquisition of the sensor as well as the design of the TTL interfacing the laboratory equipment with the roof equipment. The software design was comprised of learning how to use LabView in addition to the construction of the actual software from a flow chart. Hardware testing dealt with the complications of interfacing the National Instruments DAQ board with the motor wires such that the motor wires were reliably controllable. Software testing involved checking the outputs of the National Instruments DAQ board to verify that our design produced the desired program function. The testing of the unification of the hardware and software was intended to test for deficiencies within our overall design. This included testing the National Instruments DAQ board output to the motor wires such that the motor would still run.

2.4 Software Testing The testing of our software design was extremely important in producing a working project. Because we did the hardware and software at different times, we had to test the software separately in order to make sure that it was working properly. We were able to do this by wiring the outputs of the breakout box into the breadboard and monitoring their outputs on the oscilloscope. We were also able to hook up a function generator to the breakout box in order to simulate the digital wave that would be acquired from the sensors. This allowed us to run the programs independently of the hardware and still be certain it was working properly. 2.5 Unification of Hardware and Software The additional hardware that was required in the lab proved quite difficult to implement accurately. In order to interface the roof-mounted hardware with the DAQ board, we were supplied with five wires, which were attached to the hardware on the roof. Each of the two motors and sensors had one wire apiece and the fifth wire was a reference ground. The DAQ board had a breakout box which was attached to the PC card by means of a SCSI cable. The design process was centered on interfacing the five hardware wires with the breakout box using a breadboard and TTL microchips. The use of TTL microchips helped us out immensely due to the fact that they are extremely easy to obtain (from the parts shop in Everitt Lab) at no cost to us, and because they are relatively simple to debug. Figure 2.1. shows the final circuit layout of our hardware/software interface.

3. DESIGN DETAILS

3.1 Hardware The hardware in our circuit is what made it possible for us to control the satellite dish motors through the use of the National Instruments DAQ board. Optical Isolators were chosen because of their ability to limit the power of its output. They were needed so that we could ensure the safety of the computer and lab based hardware in case of a power surge such as a lightning strike. The reed relays were used because of the fact that they allowed the motor and ground wires to be totally independent from the breakout box circuitry. This was needed because otherwise the breakout box circuitry drew too much power and was unable to bring the motor wires from 5 V down to ground. Please refer to Fig. 2.1.2 for a diagram of our final circuit layout. When we realized that we were actually dealing with an archaic sensor instead of the chosen digital sensors, we had to make some alterations in the roof-based hardware. In order to get a reasonable signal from the sensor, a differential was required. This meant wiring one of the sensor wires to +5v in order to get a recognizable digital signal out of the toggle switch. A comparison of the desired digital signal to the actual sensor signal can be seen in Figure 3.1.1 and Figure 3.1.2 respectively. 3.2 Software The software that we used to control the satellite dish consisted of two major parts. The calibration program was meant to set operational limits for the dish and center it. The control/movement program is intended to provide an intuitive interface for moving the satellite manually or by moving to a set of saved satellite positions. The calibration program is used to offset any error in the tracking system that may occur due to either outside movement or compounded errors that may occur over time. Figure 3.2.1 provides a flowchart of the calibration program. This program starts out by moving to the west until reaching the motor’s kick-off point. We chose to move west because, essentially, we can’t rely on any current readings to determine which limit point is nearest to the present position. We measure the frequency of the sensor output and, when equal to zero, the program stops the motor and begins the counter and moves east. Again, we move to the east kick-off point. The counter now contains the absolute maximum range of the satellite dish’s operation. The program divides this by 2 and moves the dish back west until the middle point is reached. The program then calls this position 0 and subtracts a small number from the half-range count. This subtraction is done in order to ensure the motor does not hit the kick-off points during standard operation. This is a safety precaution to prevent possible motor failure. The program will finally save the adjusted half-range count to a file named calibration.txt. This file will then be available to the control/movement program in order to define the limits of operation. The software we created to control the movement of the satellite dish was considerably more complex than the calibration routine. Refer to Figure 3.2.2 to see an in-depth flow chart of the satellite interface. The options we included in this program are a manual east/west movement control, a visually based meter that shows the current position of the satellite relative to its endpoints, and the ability to load, store, and move directly to one of 2 predetermined satellite positions. Additional satellite position can easily be added with a small software alteration.

5. COSTS

5.1 Parts Price List Reed Relays $1. Optical Isolators $5. Total Cost $6. 5.2 Labor Costs Machine shop labor cost $15/hr * 4hr * 2.5 = $150. Student Labor cost $25/hr * 125hrs * 2.5 = $7,812. Total student cost 2 * $9,375.00 = $15,625. Total Cost $15,715. 5.3 Total Costs Parts Cost $6. Labor Costs $15,715. Grand Total $15721.

6. CONCLUSIONS

Our hardware/software interface worked very well when integrated properly. The program was easily able to pick up both the frequency of the sensor waveform as well as count the pulses that the sensors generated. Through the use of reed relays the program required nothing more than the flip of a switch to start one of the motors moving in the appropriate direction. The only errors that we ran across was due to the fact that when the motors were turned off, the satellite still moved a small amount before coming to a complete stop. Although the position only varied a small amount the first couple of times the dish is moved, it quickly becomes compounded and results in a drastic decrease in the accuracy of the position. While this problem is not accounted for in the submitted code due to its existence being discovered after the project demo, it is easily remedied by simply allowing the counters to remain on for 2-5 s after the motors are stopped. This would allow any remaining pulses to be accounted for and in turn being able to have precise knowledge of the position of the satellite dish. Through the development of the hardware and software configuration used to move the satellite dish, a lot was learned. Many considerations were taken into account when dealing with the designs of both the hardware and the software components of the satellite dish tracking system. The design of the software was implemented for maximum performance while still maintaining a user-friendly interface. Also, due to the fact that it was made in LabView, changes to the GUI or the code itself are relatively simple. LabView also makes it possible to allow the program to be accessed as a web page. This means that worldwide control of the dish is possible if the desire arises. The design of the hardware was implemented so as to achieve maximum functionality while still isolating the entire roof mounted hardware from the lab-based hardware. This was a safety feature that was included in order to reduce the amount of hardware damage that would occur in the event of a power surge. The optical isolators were used on the sensor and ground wires to effectively isolate them, while simply running the motor wires through the reed relays was just as effective. There are alternative designs that would have worked equally as well. One such alternative would have been to build an entire control unit. This would have required no software or computer interfacing at all; rather it would have consisted entirely of hardware. While this would have worked just as well as our design, it is not as versatile. It would have been inaccessible from the internet, and any changes to the internal design would have been costly and time consuming. Therefore, we feel that our design is the best because of its combination of functionality, ease of use, and versatility.

Figure 2.1.3 Calibration GUI Figure 2.1.5 Final Circuit Diagram

Figure 3.1.1 Desired Digital Sensor Signal Figure 3.1.2 Actual Sensor Signal

Initialize Counter Load Calibration and Position Files While Move = True Load = True? Store = True? If East Set E-Line to 0 V Move and Count until Stop = True If West Set W-line to 0 V Zoom to Sat = True? Load names/ pos from file Store names/pos to file Compare desired and current positions Move until desired position reached Update Motor Position Move = True? Yes Load position to file No END Figure 3.2.2 – Detailed Satellite Control Software Flowchart