universityofcalifornia,santacruz ee129 …pnaud/reports/153-report-b.pdf · 6" "...
TRANSCRIPT
1
University of California, Santa Cruz
EE 129 Senior Design Project
Amateur Radio Satellite Ground Station
March 19, 2013
2
Team Introductions Jason Ragland, AG6RM, EE Project Manager Antenna design Andrew Martino, KJ6RFK, EE Documentation Motor control Sander Middour, KK6BSI, CE Procurement Microcontroller design Shashwat Kandadai, KK6BSH, CS Web Master Software design Mentors/Advisors Paul Naud John Vesecky Stephen Petersen Funding
3
Table of Contents Team Introductions ..................................................................................................................................... 2
Mentors/Advisors ........................................................................................................................................ 2
Funding ........................................................................................................................................................ 2
Purpose ........................................................................................................................................................ 4
Summary of Subsystems .............................................................................................................................. 5
Motors ..................................................................................................................................................... 5
Microcontroller ...................................................................................................................................... 13
Communications .................................................................................................................................... 25
Software ................................................................................................................................................ 33
Integration and Testing ............................................................................................................................. 39
Conclusion ................................................................................................................................................. 41
Appendix .................................................................................................................................................... 42
4
Purpose We set out to design a communication satellite ground station operating on ham radio
frequencies. While there are programs out there that track satellites and even a few that can run your
radio or motors, there doesn’t exist a program that can run an entire station effectively. We want to be
able to design not only that software, but a system that can be put in place by anyone and easily
operate a satellite station. Included will be software to track satellites and control the antenna array as
well as the radio. The software should be portable so that other hams could use it in their own stations.
All subsystems will be designed for long-‐term use and expandability. The motors are robust and can
handle the same weight as commercially available parts, such as the Yaesu G5500. The antennas have
enough gain to easily reach all amateur satellites and have the ability to switch between right and left
circular polarization.
Figure 1 High Level Project Overview
5
Summary of Subsystems Motors
The research that was conducted to aid in the preliminary design of the motor control and
manual Azimuth Elevation control systems was done by examining what current ARS operating ground
stations are using today and what things worked for them and what didn’t. I obtained most of this
information from the ARRL Satellite Handbook which is a comprehensive overview of station setup and
operating procedures that are necessary for communications with amateur radio satellites.
First the research for what the manual control box should contain began with a close
examination of the commercially available systems and what where their basic features and how could
these systems be improved on. This yielded a narrow result due to the fact that my research could only
turn up one fully assembled widely used commercial system, specifically the Yaesu G5500.(see motor
figure 2)
Figure 2 Yaesu G5500 commercial tracking system
After examination of the unit’s technical specifications, specifically the underlying driving circuitry that
translated digital and manual commands to motor motions, a good base line was established for the
functionality that our system should be able to provide. However to determine what things could be
6
improved upon from the G5500 our group consulted Professor Petersen, a veteran operator of Amateur
Radio satellites and an owner of a Yaesu G5500 and asked him some things he would change with the
G5500. The main thing that he thought could be improved was to have a continuous slew and not a
pulse mode to track satellites. After reviewing the technical documentation of the G5500 it was
discovered that it utilized relays to control motor movement. While simple to implement this design
does not lend itself to smooth slewing using slow periodic pulses to rotate the antennas resulting in a
jerking like motion at slow slew rates. The team was able to witness this at the ground station of
Professor Petersen first hand as he demonstrated the operation of the G5500 tracking a satellite pass.
This problem was decided to be solved in our teams system by not using relays but an H-‐Bridge
that would be able to use PWM to vary the speed of the motors, this way during slow speed tracking the
antennas and structure would not need to be put under unnecessary physical strain (jerking) to track a
satellite. This is due to the fact that PWM lends itself to a continuous slew rate as opposed to the slew
rate of discontinuous relay action that result in low frequency pulses. Using PWM also has the added
benefit of a more precise tracking system that it is able to follow a satellites path more closely and
thereby direct as much of the radio signal as possible towards the satellite resulting more efficient use
of transmitter power.
The other surprising realization that was made by observing the operation of professor
Petersen’s station was that the accuracy of the tracking system needed to communicate with a satellite
was not very high, for example, an angular error in either elevation or azimuth could be as high as +or-‐
15degrees while continuing to maintain contact. These observations lead me to believe that a simple
feedback control system to direct the motor motion would suffice. After some consideration on to what
kind of feedback control system would meet our desired specifications I determined that a simple
potentiometer with a corresponding bias voltage would be sufficient to guide the feedback control
required to track satellites. The benefits of using a potentiometer as a feedback device consisted of
7
simplicity of implementation, reduced cost; it retains its position value despite loss of power, and also
can allow for relatively accurate readings of position.
Next our preliminary design began to be formed and was decided it would include a manual
motor control system that would include displays that would give the operator an Idea of where the
antenna was pointing without the need to be connected to a computer or see the antenna. These
displays would be controlled by the feedback potentiometers that would provide information about the
relative position of the antennas. It was also decided that the system should also incorporate a logic
system that would allow for computer control as well manual control of motor movement, this system
would give the manual operator precedence over the computer. This logic system would interface to the
H-‐Bridge indirectly through optical couplers a device that allows for total electrical isolation between 2
systems through the coupling of the 2 systems through light. This electrical isolation between the logic
system and the H-‐bridge is to preserve the logic systems from dangerous transients that could be
damaging.
During the second quarter there were multiple integration system that were also brought to our
attention that required a preliminary design. One of these systems was a system that would restrict the
motor motion so as to not allow for unwanted motion of the antenna system, for example winding of
the coaxial cable. This system consisted of multiple relays acting in a sense as circuit breakers to prevent
the motor from driving the system to unwanted positions.
Other integration systems included the mechanical systems that would allow for the motor
rotation to control the position of the antenna. This consisted of a system of bearings and drive couplers
that were machined to fit into our high torque motors. (See motor figure 3 and 4)
8
Figure 3 Motor drive coupler shown. Also potentiometer feedback.
Figure 4 Antenna super structure with motors mounted
9
Figure 5 Motor drive block diagram
Tests Conducted:
I began my testing of our preliminary designs by observing the rotation rate of a linear
potentiometer verses its change on a voltage divider. I conducted this test to explore the viability of the
potentiometer position sensing system for use with tracking satellites. I set the system up to consist of a
linear potentiometer that has a range of 100 ohms per rotation in series with a 100ohm fixed resistor.
By biasing this system with a fixed voltage and measuring the voltage drop across the potentiometer I
was able to relate a voltage to a position. To use this data to keep track of antenna position I modified a
pair of digital voltmeter displays, specifically the Velleman 9v PMLED meter to show 360 for a 3.6volt
reading. The test was simple and involved only reading voltage from the potentiometers relating it to an
antenna position and displaying it in a characteristic way.
10
Next I conducted a long term reliability test on the power supply that was designed to power
the motors that were donated to our team by professor Elkaim. The motors were specified to run at
24volts with .5amps it was decided that to extend the life of the motors they would be run slightly
below the maximum voltage since even at 21volts the motors rotated plenty fast (in fact too fast) for the
tracking of satellites. I then began to first the power supply transformer for no load heat problems. The
reasoning behind these tests was that I was unable to obtain proper specifications on this part since I
bought it second hand. This was accomplished by the use of a Fluke thermal probe and running the
transformer no load for 48hrs and checking temperature variations, additionally heat testing was done
on the power supply by running the motors for long periods of time and measuring the temperature rise
of the transformer in a similar way using a Fluke thermal probe. The testing showed that the
transformer did not rise above ambient temperature and it was not necessary to use active cooling on
the DC power supply or aided cooling in form of a heat sink.
Next with testing the development of logic control involved working out on paper the logical
combinations that would result in a logical interface between the micro and manual interface and would
allow for the manual controller to have precedence over the micro controller. The results of these tests
resulted in the design of the logical system shown in (figure 6) .The test was set up with a signal
generator to represent the micro controller PWM signal and on – off – on switches to represent the
manual input. All outputs were attached to a Techtronic’s Oscilloscope and were monitored to verify
correct logic behavior. It was determined that the logic interface would work with the microcontroller
and then was routed to a PCB with allegro.
Before moving on to solidifying my H-‐Bridge design I needed to explore the ways in which
electrical isolation could be made between the H-‐Bridge and the Logic interface. Testing of the various
11
optical couplers (optical devices that offer total electrical isolation) involved selecting some low cost
Figure 6 Final circuit diagram of h bridge driver
optical couplers and sending them a series of pulses from a signal generator and observing the output
on the Tecktronic’s Oscilloscope and looking for rise time and decay characteristics as well as trying
different ways to bias the Darlington array that made up the optical receiving side. From this test it was
determined that the 4N33 was to slow and had biasing issues so the part was to be changed to the
6N137 which has a rise time of 23ns and a CMOS logic out put this proved to be a superior part and was
selected to swapped with the 4N33.
Testing the H-‐Bridge involved working with a small scale mockup of the H-‐Bridge system that
was intended for use and then scaling it up to a larger full scale system. This later turned out to not be
feasible due to over looked design problems with the high current H-‐bridge that was selected (the L298).
These design problems then lead to the need to create a full scale prototype using the board router and
a full scale test then ensued which proved successful and full motor control could be established using
PWM. After this test a final revision was developed and implemented as shown in figure 6 with this final
12
revision I have been able to successfully drive the motor system with no further problems, coming from
the H-‐bridge directly or any of its surrounding components.
The 2 final technical challenges that faced the motor systems included the position limiting and
various mechanical systems. While the UC machine shop allowed for rapid solving of the mechanical
coupling. The position limiting was slightly more involved, since the L298 H-‐Bridge like most current
driving circuits drives current using a totem of 2 BJT’s. Using this information I was able to determine
that by using a 2 position relay system I could limit the motion of the motor by cutting off its motion in
that direction by grounding the current sink in that direction. This would force the motor to stop
rotation in that direction and would only allow motion in a reverse direction. Then to trigger this stop I
wired the triggering coil of the relay to a 12v source and used the motor chassis ground as the triggering
system. By setting up sensing conductors at the 2 restricted positions for each motor and putting a
position needle on the drive shaft grounded through the chassis which allows for simple position
restriction of motor rotation. During testing I was able to successfully limit both elevation rotation and
azimuth rotation without incident.
Technical Problems:
-‐power supply: During the preliminary design phase of the DC power supply it was decided that active
cooling should be used to cool the DC power supply. As it turned out this decision was premature since
a lack of knowledge of how hot the system would actually get lead to the need to modify the
preliminary design to only include natural cooling.
-‐Motor controller: The original prototype was constructed using a bread board and small heat sink, this
was a direct result of a pushed time table and getting the motor controller ready for check off. This
resulted in the catastrophic failure of 2 consecutive L298 H-‐Bridges. It was then decided that the check
off deadline would be extended to allow for time to properly route the motor controller and acquire an
13
adequate heat sink. After the L298 was properly heat slinked and set up on an adequately routed board
the motor controller worked successfully and the heat problem was also mitigated. This aided in the
determination of the cause of the failures of the previous 2 L298s which was a combination of bad
contact with power and ground and an inadequate heat sink.
Microcontroller To interface and control the antenna position using the computer console, a
microcontroller was used as the medium between the computer console and the antenna
motors. This microcontroller should be capable of reading a movement command from the
computer console, reading the current antenna position, moving the antenna, and sending
current antenna position to the computer console.
Figure 7 High-‐Level Block Diagram of Microcontroller Function
The antenna will be moved by two motors, one controlling the Elevation angle (EL) and
one controlling the Azimuth angle (AZ). The angles will be determined by monitoring the
voltage from a potentiometer pot attached to each axis of the antenna. This will translate
angles from 0-‐360 degrees to analog voltages from 0-‐Vmax.
14
Figure 8 Look angle visualization
There are two ways to control the speed of a DC motor: by varying supply voltage and
pulse width modulation (PWM). First system is not convenient in digital systems since it
requires analog circuit, but the second system is very convenient for digital systems because all
controls is made using digital signal.
Finally, the microcontroller requires some kind of peripheral communication capabilities
back and forth between the computer console and the microcontroller. Some common
communication protocols are SPI, I2C, RS232, etc. However, we wanted to have USB
connectivity since most new computers don’t have serial ports. This requires us to use a virtual
USB (V-‐USB) converter (a.k.a. USB bridge).
The block diagram of the microcontroller interface is shown below. Note: this diagram is
the same for both the Azimuth and Elevation control. Only one motor is shown for simplicity
and clarity.
15
Figure 9 Block Diagram of Microcontroller I/O Interfacing
Process:
This task was broken down into the following parts:
1. Choosing an appropriate processor
2. Designing an I/O microcontroller development
3. Write firmware for reading ADC values
4. Write firmware for motor controls
5. Write firmware for USART
1. Choosing the processor:
Power consumption was not an issue since the microcontroller would have a constant
power supply. Physical size was also not an issue but price and speedy available was a concern.
Our main areas of concern were:
• High ADC resolution • Compatible with V-USB • Sufficient number of analog to digital ports to support • Dedicated hardware to provide a PWM signals for at least 2 channels • Cheap and readily available • At least 4KB of memory
16
Being able to read each motor position requires an Analog-‐to-‐Digital-‐Converter (ADC).
And since these voltages are representing angles, our needs required that the processor have
ADC with at least 10-‐bits of resolution in order to maximize the number of “angular steps” that
the microcontroller can move the antenna. 10-‐bits of resolution allows us to represent angular
degrees as small as 0.5 degrees using the relation:
(1024 steps)/(360 degrees) = 2.8 steps/degree à 1 step = 0.35 degrees
Since this is much less than the focal diameter of the antenna (approx 30 degrees), we conclude
that a 10-‐bit resolution ADC should suffice.
For USB interface, we looked at the CP2103 V-‐USB controller chip. The CP2103 is an
integrated USB-‐to-‐UART Bridge Controller providing a simple solution for updating RS-‐232
designs to USB using a minimum of components and PCB space. The CP2103 includes a USB 2.0
full-‐speed function controller, USB transceiver, oscillator, and an asynchronous serial data bus
(UART).
Figure 10 Block diagram for CP2103 V-‐USB from CP2103 datasheet
17
However, the datasheet for the CP2103 states a minimum processor speed of 1Mhz.
This means that we need a microprocessor with at least 1Mhz built in clock or the ability to use
an external frequency oscillator.
There are several processors that fit our requirements, but we chose the ATMEGA8L
based on the multiple tutorial and help sites on the Internet and written text.
2. I/O microcontroller Board:
In its most basic form, the UART hardware consists of a transmit (TX) line and a receive
(RX) line. The software configures how fast data is sent (the baud rate) and the specifics of the
protocol.
Since the UART module is asynchronous, there is no external clock line like the
synchronous protocols SPI or I2C. Instead, both communicating devices must have their own
clock sources configured to the same frequency. As long as these clocks match one another,
data should be transferred smoothly. Common baud rates include 4800, 9600, 19200, 57600,
and 115200 Mbits/s. The datasheet for the CP2103 tells us that it’s best to select a lower baud
rate to reduce the chance of errors. While there is a formula to determine the frequency and
BAUD rate, we used table 9 in the CP2103 datasheet to come up with a BAUD rate of 57600 and
a frequency 3.686MHz.
The CP2103 V-‐USB features simplify the SPI (Serial Peripheral Interface) type of interface
a great deal. Additionally, two standard SPI connectors are provided by the Atmel ISP (In
System Programmer); a 6 pin and a 10 pin connector. In addition to the data lines (MOSI and
18
MISO) and the bus clock (SCK), target voltage VTG, GND and RESET (RST) are provided through
these connectors.
Figure 11 Microcontroller board layout
Control Overview:
Controlling the antenna is a non-‐trivial component of the project. Resolution of the A/D
(Analog to Digital) converter will be a great concern on this micro as the analog signal from the
scanner will be extremely volatile and will consist of intermittent noise.
U2
ATMEGA8L
ADC619
GN
D2
5
(PC4/SDA) ADC427
GN
D1
3
Vcc1
4
(PC3) ADC326
(PC0) ADC023
(PC0/SCL) ADC528
ADC722
(PD0) Rxd30
(PD1) TxD31
(INT0) PD232
(INT1) PD31
(XCK/T0) PD42
(PC1) ADC124
(PC2) ADC225
(XTA
L/TO
SC1)
PB6
7 8(X
TAL2
/TO
SC2)
PB7
(MOSI/OC2) PB315
(AIN1) PD711
(SCK) PB517
(AIN0) PD610
(MISO) PB416
(T1) PD59
(~Reset) PC629
(SS/OC1B) PB214
(OC1A) PB113
(ICP1) PB012
Aref20
GND21
Av cc18
Vcc2
6
ADC5
ADC4
ADC3
ADC2
ADC1
ADC0
ADC7
ADC6
ADC[0:7]
J61
2
3
4
5
6
7
8
9
10
U1
CP2103
REG IN7
V BUS8
D+ (USB D+)3
D- (USB D-)4
NC215
NC013
NC114
~Suspend11 NC10
GND2
Suspend12
Reset9
VDD
6
Vio
(sup
ply
V)5
~RI (D in)1
DCD28
DTR27
~RTS23
~CTS22
NC421
NC320
GPIO118
GPIO217
GPIO019
GPIO316
TxD25
RxD24
DSR26
SG29
PAD
30
Y1
3.686MHz
DN1SP0503BAHT
4
13 2
VBUS
D-
D+
GND
C1(gnd)
C2(gnd)
J3USB CONN
1
2
3
4
5
6
J4ISP 6P
2 4 6
1 3 5
+3.3V
+5V
J1
HEADER 3
1
2
3 J2ISP 10P
2 4 6 8 10
1 3 5 7 9
PB2
PB1
PB0
PD7
PD6
PD5
J5
I/O Ports
1
2
3
4
5
6R1
100
R2
100
R3
100
R4
100
R5
100
R6
100
R7
100
R8
100
R9
47K
+ C64.7uF
+
C84.7uF
+
C1
4.7uF
L1100nH
SW1RESET
1 4
2 3
C21nF
C330pF
C430pF
C50.1uF
C9
0.1uF
C7
0.1uF
VCC
+3.3V USB+5V USB
VCC
+5V USB
+5V USB
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.0
microcontroller board
A
1 1Wednesday, March 06, 2013
19
Figure 12 Control block diagram
Motor position feedback is done by comparing the current position of the motor,
represented by a potentiometer pot voltage Vpot controlled by the motor, to a reference
voltage Vref, which represents the desired motor position.
ADC Reading:
The10-‐bit ADC resolution translates analog voltages to values between 0 and 1023 steps. If the
reference voltage is 5 volts, this means that the smallest detectable change in voltage on the
input pin is 5V / 1023 = 0.0049 volts or 4.9 mV/step. Since there are 360 degrees in 1024 steps,
we can expect an error of about 0.17 degrees per step.
We decided to use an average of multiple ADC read samples to average out noise, which
we can do easily in software. The flow diagram below shows the process for getting the
average of 32 ADC readings for an ADC pin using the ADC_Complete flag:
20
Figure 13 ADC Averaging Flow Diagram
Driving the DC motors:
The motor speed is set by the average voltage generated by a PWM signal on the I/O
board connected to the motor M+ terminal while the motor direction is controlled by a digital
I/O pin connected to the motor M-‐ terminal.
This average voltage works by separating the PWM signal in to 'on' time an 'off' time
within a cycle. One cycle is divided into a maximum number of steps and the Duty cycle is the
number of steps the signal is 'on' out of the maximum number of steps within the cycle.
The ISR_overflow (Interrupt Service Routine for timer overflow) determines the cycle
frequency by regulating how fast the steps increase.
21
Setting the direction was just a matter of changing the direction signal on M-‐ terminal
and the complement the Duty cycle on the M+ terminal. And turning the motor off was done
by setting the output to the M+ terminal the same as the M-‐ terminal (see diagram below).
Figure 14 ADC Averaging Flow Diagram
Lastly, we needed to implement the UART functions. We decided to use circular buffers
for character transmission and receiving in order to utilize the full duplex capabilities of SPI
interfacing and to avoid polling for data transfer completion. There are four separate parts for
the UART: receiving a char, transmitting a char, getting a char, and putting a char.
The Receive handling is done by the ISR_RXC (Interrupt Service Routine for Receive
Complete flag) every time the Receive Complete flag (RXC) is set. When this flag is set, this
indicated that there is new data (a character) in the Uart Data Register (UDR). The ISR_RXC will
then load the Receive circular buffer (RX_buff) with the new data at the tail.
22
Figure 15 ISR handler for Receive Complete Interrupt Flag: adds Char to RX_buff
Getting a character from the RX_buff is handled by the get_char() function which
removes data from the head of the RX_buff and returns it (see figure below).
Figure 16 get_char() function: Removes Char from RX buffer
The Transmit ISR and put_char(char) functions work similarly:
Figure 17 put_char(Char) function: adds Char to TX buffer
Figure 18 ISR handler for Register Empty Interrupt flag: adds Char to TX buffer
After all of the separate control modules were completed, tested, and debugged, we
wrote the one final module to integrate everything together. Commands from the computer
console were in the form of a 7-‐indices long character array. Each index was defined as follows:
23
Index 0 = START bit, indication the start of an instruction.
Index 1 = STATUS à send current antenna position to console
= MOVE à move antenna in the direction indicated at the indicated speed
index 2 = direction (u=up, d=down, l=left, r=right)
indices 3-‐5 = PWM speed from 0-‐100
index 6 = STOP bit, indicating the end of this instruction
Current status from the microcontroller to the console was in the form of a 13 indices long
character array indicating:
Index 0 = START bit, indication the start of the response.
Index 1 = ACK à last received command was a valid command
= NACKà last received command was invalid
indices 2-‐6 = Azimuth angle position
indices 7-‐11 = Elevation angle position
index 12 = STOP bit, indicating the end of the response
24
Figure 19 Flow Diagram for Main Program structure
Technical Problems and Changes:
Initially, we planned to have the microcontroller receive a desired antenna position
from the computer console and the microcontroller would handle moving the antenna to that
position using the Proportional, Integral, Derivative (PID) method with rotary encoders, and
sent a DONE flag to the console when complete. Prof. Pederson advised us that this was not
the best way since it would require a lot of memory and/or have slow response for our
application. Further research seemed to back this up. Based on our discussion with Prof.
Pederson, we decided that the microcontroller should just move the motors and monitor the
antenna positions and let the computer console handle position control since it can do it faster
and more dynamically.
25
The default clock speed that comes shipped with most AVRs is 1 MHz because they have
internal clocks which keep time. We needed to set up an external clock source to support the
V-‐USB, which requires a faster clock than the internal one. This proved to be quite a headache
but it turned out that the problem was within the ATMEL compiler environment.
The last problem was with the circular buffers for the UART. We were having an
intermittent problem with random garbage or skipped characters in the buffer. We later found
out that ''...it is VERY IMPORTANT that global variables which may be changed by interrupt code
are tagged as volatile. Failure to do this leads to a disastrous intermittent bug where rxq.length
is occasionally not incremented when it should be!'' ''... or compiler optimizations may lead to
incorrect code.'' [Embedded C Programming and the AVR, 2nd Ed].
Communications Antennas
Because there is no antenna class at our university a lot of research had to go into how
antennas work in order to prove that the antenna we designed would actually function and that
it was the best choice for the project. The ARRL Antenna Handbook was the first source that
was used. It covers all antenna theory from basic physics all the way up to design
considerations for antennas across all ham bands from frequencies from 2 MHz to 3 GHz. This
gave us a deeper understanding of how an antenna works and a better understanding of what
antenna type we should pick. From this research three antennas were chosen: the Yagi, helix,
and cubical quad.
26
The Yagi and helix are typically used in amateur satellite communication because of
their wide spread use and that there are many proven designs floating around. One thing about
ham radio is that if it works everyone will use it without really questioning it. We chose to be
different for a few reasons. We wanted to actually learn how an antenna works, we wanted a
unique station, and we wanted the antenna to meet certain needs. We went with the cubical
quad because of its adequate gain, wide beamwidth and compact size. The beamwidth is the
3dB area of coverage, while Yagis tend to have around 30° of beamwidth, the cubical quad that
we went with has a beamwidth of over 45°-‐50°. We wanted this because we wanted our station
to be able to not only communicate with satellites but be used for ground contacts in case of
emergencies or just for fun. A wide beamwidth helps ground communication so that you can
easily point your antennas at another station.
The antenna design comes from W4RNL (SK) L. B. Cebik. He was a prolific antenna
designer for the ham radio community. This particular design was nice because it has the 2m
and 70cm antennas on the same boom without much interaction between the two, since the
frequencies are third harmonics of each other. He ran many simulations on the spacing of the
elements as well as their lengths. He did not provide the antenna model, however, as he had
made a business on selling his models. The antenna had to be modeled to confirm his findings
so the NEC2 modeling software was used. The specific software package that was used was
“4nec2” which is a C++ implementation of NEC2. The dimensions from W4RNL were entered
into the software and the model checked out. There are algorithms to tweak the dimensions of
the antenna within the software to attempt to improve certain aspects of the antenna such as
27
gain, beamwidth, impedance, and SWR but the model was very solid and tried to maximize all
these areas already.
Figure 20 Cubical Quad antenna model
With a solid design already in hand, parts were selected and an actual implementation
had begun. A square aluminum tube, 2” in diameter, was used as the boom for its light weight
and rigidity. Square, wooden dowels make up the element spreaders which push the wire out
into a square. RG-‐62 coax feeds the antenna because it's impedance of around 93 ohms closely
matches that of the antenna's feedpoint impedance. Feeding the antenna at adjacent corners
with a phase difference of 90° causes circular polarization. The phase can be altered between
right and left with a pair of circuits that are placed on the antenna and at the control point.
CPOL Boards
If there is one drawback to satellite communication other than the fact that satellites
move, it’s circular polarization. When electromagnetic waves travel through the ionosphere
they tend to go from linear to circular polarization from what is called the Faraday Effect. This is
caused by the charged particles interacting with the EM wave in a way that causes rotating of
28
the electric field at a rate proportional to the frequency of the wave. Most satellites also
naturally spin in space and rotate about some axis, others are spinning on purpose. The
problem with a randomly rotating satellite is that the circular polarization sense will also
change from right to left and in between as the satellite tumbles. Most satellites are spun on
purpose to give them an inertia that points one side down. This is beneficial in a few ways. The
antennas can be put on that side and will also supply max power to the Earth. The satellite will
also have a “permanent” spin sense of left or right. Waves that are already circularly polarized
are less affected by the Faraday Effect which is also a benefit of this.
With the satellite supplying circular polarized waves, our ground station now has to be
able to receive such waves. We can set up our antenna to be circularly polarized, but if we
make it only able to go right or left circular, then we would have to have a pair of antennas for
each frequency band. This problem is accomplished by having a circuit that can switch the
polarization sense of the antenna with a switch. There was no commercially available circuits
that we could just buy to accomplish this task, so we decided to use a design that AC6P,
Stephen Petersen, came up with. His design utilizes RF switches, in the form of PIN diodes, to
add 180 degrees of phase to one side of the feed point of the antenna. These 180 degree shifts
will switch the polarization from right to left and vice versa.
The first board I worked on was the control board that would stay in the station and
reside in the control box. Figure 21 shows the schematic for the control board circuit. This
circuit implements a few flip flops that allow a switch to send a ‘1’ or ‘0’ to the boards on the
antenna. Two saturation amplifiers will “rail” the voltages to 0V or 5V and the antenna board
29
will do what it needs to do to bias the PIN diodes properly. This board also supplies a 12V rail
to the antenna board because the diodes become fully biased in either direction with 12V.
Figure 21 CPOL control board
The next board was the circular polarization, CPOL, board that would go onto the
antennas. Figure 22 shows the schematic for the circuit. It uses an impedance matching Pi
network at the input that matches 50 ohms from the coaxial feed line to 93 ohms on the
30
antenna/boards.
Figure 22 CPOL antenna board
The cross hatches lines on the schematic represent transmission lines that are set at 93 ohms.
Diodes D1, D2, and D3 are PIN diodes which are used as RF switches. When forward biased they
pass RF and look like a 1 ohm resister. When reverse biased they look like a capacitance and
block RF. When D2 is on, D1 and D3 are off. When D2 is off, D1 and D3 are on. With D2 on the
signal from the input will travel down the first Tx line and go directly out of the two sma
connectors on the right side of the board. When D2 is off the signal has to go through the Tx
line on the top, left. The dashed line represents a length of coax cable that, along with the Tx
lines on the left, makes a half wavelength shift in the wave that travels on it. This means that
31
when D2 is on, the two waves that exit on the right of the board will be in phase and when D2 is
off, the two waves that exit will be 180 degrees out of phase.
The biasing is accomplished by feeding our logic signals to a half h bridge. 5V
corresponds to a positive 12V bias and a 0V logic level corresponds to a -‐12V bias across the PIN
diode. This circuit will go into a control box with the microcontroller and motor logic. The I/O
will be a switch for the 70cm and 2m antennas and LEDs for left and right for each. The logic
outputs and 12V signals will be sent to the antenna via a DB-‐9 connector and 4-‐pair shielded
cable.
ICOM CI-‐V
In order to control and read data from the radio we needed to match its serial interface
on the back of the radio. Most ICOM radios use a 3.5mm jack with an open collector driver to
communicate with one another. The catch is that they don’t plug right into each other, but use
a proprietary circuit that ICOM calls their “Communication Interface” or IC. They put this circuit
in a box with a DB-‐9 to connect to your computer’s serial port, because every computer has a
serial port still. And then it has a few 3.5mm jacks. The idea is that you can daisy chain up radios
with the mono audio cables and be able to control all your radios. The black box that houses
the circuitry costs in the neighborhood of $135 (http://www.hamradio.com/detail.cfm?pid=H0-‐
003750, 6-‐12-‐13) and a DB-‐9 to 3.5mm cable can be purchases from various sources or made by one’s
self.
While this is all and good, there is no reason to pay that much money for something so
simple. A simple Google search on “homemade icom ci-‐v” gives countless examples of people
attempts, failures, and successes in making their own circuit. All the circuit has to accomplish is
32
have an open collector driver/receiver and convert that to an RS-‐232 port. Because not all
people have a serial port on their computers anymore it would be advantageous to convert that
serial connection to something more useful, like USB. Discussed at length in the microcontroller
section is the CP2103 USB to UART bridge chip. We used the same chip for this part of the
project, only in this case we used a pre-‐made breakout board from Sparkfun because we had
one laying around.
Figure 23 ICOM CI-‐V
With a way to easily communicate with our computer we needed the open collector
buffering part of the circuit. Once again, AC6P came to the rescue with a simple circuit that
accomplishes this task. Figure 23 shows our “ICOM CI-‐V” interface board. It consists of a 6 pin
header to connect to the USB to UART bridge board and two open collector buffer chips, one
for transmit and one for receiver. There is also some biasing components and RF choking. The
33
I/O for the radio is a 3.5mm mono jack. We added an extra jack in the case where we wanted to
hook up an HF radio in the future.
Problem Areas
The main issue with the antennas, as stated above, is that neither of us had any real
idea how any antenna other than a dipole worked. We had to build up our knowledge of
antennas over a few weeks before we could get to satellite antennas and circular polarization.
We had to do a link budget to make sure that the antenna would have enough gain as well. The
modeling software was also a troublesome area as the first one that we used, NECWin Pro, has
a very clunky interface and not much help can be found on the internet. Learning the NEC2
software was also difficult as we didn’t have much time to get a model ready and it has a fairly
steep learning curve. Once we started using 4nec2 is became much more manageable as the
help files were very useful and readable and there is a fairly large network of users of the
software.
Software We began by familiarizing ourselves with the major papers written on this subject. Most
famously, Space-‐Track Report #3 (http://celestrak.com/NORAD/documentation/spacetrk.pdf)
served as the basis of our understanding. This paper describes in detail the SGP4 algorithm,
used by NASA and NORAD to convert ephemeris to position and velocity of a satellite at any
given time. This paper, though a landmark work, is incredibly dense, so we ended up relying on
TS Kelso's CelesTrakcolumns (http://celestrak.com/columns/). Kelso makes clear how to
reference a satellite's position relative to a ground observer, which is non-‐trivial. Kelso makes
clear the importance of using geodetic coordinates over spherical. Kelso also goes into detail
34
about the importance of sidereal time. Kelso's papers were supplemented by
http://satelliteorbitdetermination.com/orbit_elements_wiki.htm and
http://www.physics.ncsu.edu/courses/astron/orbits.html#MA, which describe important
components of SGP4 and orbital propagation in general. With regards to rotating frames of
reference, we found the handouts for the ASEN5070 at University of Colorado Boulder
(http://ccar.colorado.edu/ASEN5070/handouts/coordsys.doc), to be very enlightening.
“Simplified perturbations models are a set of five mathematical models (SGP, SGP4,
SDP4, SGP8 and SDP8) used to calculate orbital state vectors of satellites and space
debris relative to the Earth-‐centered inertial coordinate system.”
(http://en.wikipedia.org/wiki/Simplified_perturbations_models, 6-‐12.-‐13). The SGP4 models takes
the two line elements, TLEs, from NORAD which are themselves coefficients of Kepler’s
equation and some identifying information. These numbers are then turned into useful
information that we can use such as the velocity of the satellite and its position relative to the
center of the Earth. We then convert this position to spherical coordinates because it is more
useful to us. With spherical coordinates we can then calculate look angles of elevation and
azimuth relative to our position on the Earth. This is tricky because the Earth itself is not a
sphere, it is squashed into an “oblate spheroid” shape. Kelso goes into great detail on how to
model the Earth to compensate for this and to make the satellite position much more accurate
than it would have if we ignored this fact.
For the implementation, we used Brandon Rhodes' Python SGP4 implementation
(https://pypi.python.org/pypi/sgp4/) as our base material. Rhodes' code is based off Vallado's C++
implementation (http://celestrak.com/software/vallado-‐sw.asp). We used Rhodes’ approach of
35
“Least Interference”, and only changed the lines of code which directly required a changed
(could not work in JavaScript). The JavaScript library is promising, and stands up to some
benchmarks such as the savage benchmark (http://celestrak.com/columns/v02n04/).
Testing
Figure 24 Chrome app as it stands right now
To verify our SGP4 implementation into JavaScript works we ran the supplemental
testing TLEs provided in Space-‐Track Report #3
http://celestrak.com/NORAD/documentation/spacetrk.pdf). This method of testing supplies the
SGP4 with specific inputs, for which the outputs are known. We can compare the outputs from
our own SGP4 algorithm with the known outputs. Running these TLEs gave us an error that was
really small, 1 in 1 million. This was promising and from this we knew we could trust our values.
36
With the SGP4 code tested and benchmarked we knew we could proceed with the software
and start implementation with other systems.
Software Architecture
The Main Thread (which includes Worker Manager) ONLY deals with initial setting up of the JS
environment, and responding to various callbacks. This ensures that its number one priority
remains Graphics Refresh, via the requestAnimationFrame() call. Otherwise, the Main Thread
will delay Graphics updates for other logic, the graphics will appear choppy, and the UI will
seem non-‐responsive. The Main Thread relays any UI commands that require a change in the
WebGL objects (such as zooming, rotating, tracking a satellite), to the WebGL Renderer, and
allows it to update the 3D world.
37
The Tracking worker is told which satellites to track, and regularly reports those satellites’ live
position. It runs one SGP4 calculation per satellite being tracked, every update cycle, and
returns all the live values for each satellite.
The Propagation worker is given a satellite and told to provide several position coordinates in
an array, depicting the satellite's path of travel. This thread does many SGP4 calculations for a
single satellite over a given span of time.
AngularJS Architecture
AngularJS provides us with “two-‐way data binding”, which means that the data in the
Presentation layer (HTML/CSS) will always be consistent with the data in the Model, regardless
of which one is changed. AngularJS divides a project into four sections, Controllers, Services,
Filters, and Directives. The Controllers and Services are the most important aspects of this
particular project.
38
Controllers
The Controllers should all be very small, and should be limited to setting up the Model,
instantiating the Services, defining callbacks for UI events, and not much else.
This app is a single view, currently run by UICtrl, which is quite simple. UICtrl takes in user
mouse/keyboard actions and relays them to Services like ThreeJS and WorkerManager.
Services
Services are singletons, often used to encapsulate Web APIs, but here they are used to wrap up
complex local logic.
ThreeJS is used to abstract the WebGL world from the AngularJS/HTML/CSS world. UICtrl
detects user actions, such as scrolling, and informs ThreeJS to appropriately update the 3D
objects.
WorkerManager corresponds exactly to the Worker Manager in the Software Architecture. This
Service instantiates Web Workers (threads), sets up their callbacks, and provides the Web
Workers with their parameters. Both UICtrl and ThreeJS rely on WorkerManager to provide up-‐
to-‐date satellite tracking information, for display in HTML and WebGL.
The Radio and Motor Services encapsulate the hardware control logic. It does not rely on Web
Workers, because the chrome.serial API is only available from the Main Thread. They both rely
on WorkerManager to provide them with up-‐to-‐date tracking information.
Technical Problems
39
The software was one of the biggest trouble areas for us mostly because it was central
to the entire project. Interfacing hardware to software is hard enough most of the time but we
had a lot of layers of abstraction to deal with by using a Chrome app. We had a few issues with
the microcontroller that we figured out after a few weeks of debugging. Motor control,
however, was the biggest problem area. Implementing logic to move an antenna array
intelligently is not a trivial problem in the slightest. Pointing the antenna at the satellite by
taking the shortest path seems easy, but if you don’t want to wrap the cables around the tower
you have to keep track of where you are and try to stick to one side of the tower. Also since we
wanted hard limiting of motion, we had to try not to cross those boundaries. At this time we
have yet to implement fully intelligent antenna control and are relying on a “dummy” approach
where we take the shortest path and just keep the antenna favoring one side so we don’t cross
over the hard limiters. In the future we plan to have a “flip mode” where we can flip the
antenna past 90 degree elevation in order to compensate for the hard limiting.
Integration and Testing Integration and testing is always one of the biggest problem areas for projects like this
and our project was no different. With all the main parts of our project completed by the first
week of Spring quarter, we set out to connect these parts and the subsystems of our project
began to take shape. The microcontroller was the translation between the computer and the
motors. The antenna system had a few circuits as well as interfacing with the radio. And the
software was a bunch of modules that now had to interact with each other in an event driven
scheme that was by that point not thought up yet. Integration and testing would not end until
the last possible day because of unforeseen issues.
40
One of the first systems to see integration was software control of the radio. Because
we used a proven design for the serial interface board there wasn’t much testing that had to
occur. The bulk of the problems with that system was getting Chrome to open up a serial port.
Plugging the board into the computer and radio and running AC6P’s program was a breeze and
there was no issues. But we had nothing but trouble in getting our software to work. The issue,
as it turned out, stemmed from Chrome’s clunky way of handling hardware. For security
reasons Chrome makes it very hard to interface with hardware and we had to look up many
tutorials on USB and serial ports to get it to work, but after a week or so we were able to
change the radio’s frequency.
The second major subsystem to be completed was the motor logic and power system.
All the components of this system were mocked up and tested in the first quarter, but up to
that point no boards had been populated and the system as a whole was disconnected. The
logic board was populated and the h bridge board was laid out and routed on the board router.
We had a lot of issues with the h bridge chips because of how they were designed and our lack
of understanding of them. We burned a few up in experimenting and finally came up with a
fairly bomb-‐proof design. We were able to manual move the motors early in Spring quarter and
were doing motor control through the microcontroller soon after that. Full system integration
with the Chrome app would not happen until the last week of the quarter due to some
software bugs and logical errors, but we were finally able to move the antenna and track
satellites on the bench.
41
Conclusion We have accomplished a lot this year but we still have a few features that we would like
to implement before we call this project complete. We eventually want to try to get our code
running on some commercially available microcontrollers like an Arduino or PIC32. The end goal
is to make our project an open source satellite tracking system. We believe we have a novel
way of getting the Yaesu G5500 working under pwm control and integrated into our system. If
we could work this out our system would be completely open source. Our software is available
on github, https://github.com/shashwatak/EarthStation, and soon our PCB layout and
microcontroller code will be available. Some of us plan to work on this during our free time
over the summer to make this a reality. I think the ham radio community would appreciate this.