Embed Size (px)
Citation preview
Michigan State University
ECE 480
Design Team 3
“Connect-on-Demand” Satellite/Radio Link for Tanzanian Schools
Sponsored by: George & Vickie Rock
& Dow Chemical Company
Luis Garcia Eric Hatch Joe Larsen
Michael Moulton Rafael Ocampo
Rodney Singleton
Dr. Selin Aviyente – Facilitator
Wednesday, April 28, 2010
2
Executive Summary
In rural Africa MSU has a small network of schools sharing an Internet connection. The
Internet networking equipment is centrally located at Baraka Primary School, which subsequently
routes the Internet connection to other schools via WiFi and WiMAX. Unfortunate in terms of
power use, Baraka is solar-powered and this system is operating near capacity. As a result the
power usage of the networking equipment has to be configured to allow the expansion of the
network and allow Internet access in the evening, when the source of solar power (the sun) is no
longer available. Team 3 produced a system that powers on networking equipment when an end
user is attempting to access a website. When the Internet connection is idle, the equipment is turned
off. The networking equipment can be turned on and off from schools up to 5 miles away through
the use of a low power FM radio. This system has been tested to ensure it is power efficient and
requires little to no user interaction. In May 2010 this system will be installed in Tanzania. As a
result, another school can be added to the network without a significant increase of the solar system,
and students will have more access to the Internet, in terms of the time of day.
3
Acknowledgment
We would like to thank our sponsors, George & Vickie Rock as well as Dow Chemical
Company for the opportunity to work on a very challenging yet rewarding group project. Their
generous contributions helped us to acquire the equipment necessary for the development of our
final product.
Also, we would like to thank Professors Erik Goodman and Kurt DeMaadg for the
opportunity to travel to Tanzania where we will actually install and implement our working
prototype.
A special thanks to Eric Tarkleson for being our informant on what equipment in Tanzania
that we will have to interface with, as well as our liaison to suppliers located in Tanzania.
We would especially like to thank Greg Mulder for all his technical advice, and his keen
interest in particular to our project. His knowledge was just what we needed for our continual
progress. Without his expertise in amateur radio, we would not have been going in the direction
that led us to our success.
A very special thank you to the Radisson Hotel in downtown Lansing for supplying us with
a room on the top floor for the half an hour required for the FM radio link testing.
Finally, we would like Design Team 4 for a cooperative approach to solving one another’s design issues as they arise, as well integrating the computing stations to the “Connect-on-Demand” project.
4
Table of Contents Introduction ........................................................................................... 5
Approach ................................................................................................ 7
Work Performed ................................................................................... 16
Testing .................................................................................................... 35
Summary ................................................................................................ 48
Appendix I .............................................................................................. 50
Appendix II ............................................................................................ 56
Appendix III .......................................................................................... 57
5
Introduction
A quality education is critical for providing people with the means to attain a better life, and
is especially important for the populations of developing countries. While there are many schools
in developing countries, such as Tanzania, these schools lack the financial resources for the
materials necessary for a quality curriculum. In order to avoid the cost of purchasing textbooks,
MSU's Department of Engineering and the Department of Telecommunications, Information
Studies, and Media have taken an interest in providing the Internet via multi-seat computing stations
at individual schools. This will allow students to access educational material on the Internet
comparable to information given in textbooks. While this will lower costs in the long run, up front
equipment costs can be very expensive. In order to justify the large upfront cost of such a system,
each component of the overall product should be uses as efficiently as possible. In this particular
case, that means allowing the Internet to be accessible as much as possible, while balancing the
trade-off of power consumption from a limited source.
The project described in this document will build upon the work achieved by previous
design teams. MSU’s network in Tanzania currently consists of two multi-seat computer
installations at Baraka Primary School and Manyara Secondary School. These two installations are
nodes of a local area network (LAN) with a WiFi network bridge used to connect them. The
gateway to the Internet is provided by a very small aperture terminal (VSAT). This VSAT and the
router controlling the LAN are located at Baraka Primary School. The shortcoming of the current
network results from Baraka being a solar-powered. As a result, the networking equipment at
Baraka must stay on throughout the day to ensure Manyara can connect to the Internet. The
correction of this inefficient use of resources is what our group’s objective is.
This inefficiency is magnified as a result of a new node, Rift Valley Secondary School,
which will be added to the LAN in May 2010. In order to accommodate this school another
network bridge will have to be installed at Baraka causing greater power consumption.
Conventional thinking to would be to simply add more solar panels and batteries at Baraka to
compensate. This would be sufficient; if increasing the size of the network was the only issue, but
it is desired that the local students be able to use the Internet during evening hours. Simply adding
more solar panels and batteries is not sufficient for solving this problem.
Most Internet users in the United States access the Internet through an “always on”
connection. It is done for the convenience of always having the “world at one’s finger tips”. Team
6
3’s goal is to simulate this “always on” user interface by automating powering on and off the VSAT
and network bridges at Baraka. With this proposed solution, Team 3 was presented with another
problem. How to turn on when desired, and turn off the networking equipment when not in use; at a
distance up to 5 miles away?
To address this problem Team 3 decided to implement a radio link that will operate in
parallel with the network data bridges. Its sole purpose will be to send a “turn-on” signal whenever
an Internet request is made by a user. This “turn-on” signal will be received and processed at
Baraka by a receiver and a low-power microcontroller. The Internet request that is made will be
cached on the muti-seat computer until a network connection has been detected. After a set amount
of time, with no outgoing Internet requests the network bridges and VSAT will turn off.
Through the use of this system, the batteries will charge faster when the networking
equipment is shut off during the day. At night, the power stored by the batteries will be used more
efficiently. As a result, Rift Valley Secondary School can be added with out significant expansions
to the solar power system at Baraka. Additionally, users at Manyara and Rift Valley will be able to
access the Internet into the evening hours. This will allow the users to have greater access to the
Internet and hopefully improve the educations of the students of those schools.
7
Approach
In the beginning of the semester, our first task to obtaining a solution to our design team’s
specific task was to come up with an overall breakdown of what we wanted to build. Joe Larsen,
being fairly familiar with networking systems was a great help. He mentioned that networking
equipment can simply be turned on or off, without any form of a “start-up” mode, such as when
someone switches on their computer. With that in mind, we came up with a simple (in theory)
approach to solving our problem of conserving power at Baraka, while being able to continuously
provide Internet to any of the schools when they request it.
We decided that using relays to “connect” the power to networking equipment was a viable
solution. We did ask the question, “can we use the WiFi and WiMAX routers themselves to boot
up the VSAT”? We found that approach would be cumbersome, so using relays to simply power on
the equipment was a valid method. The only question remaining now was, “how do we send a
signal from the remote schools to Baraka to engage the relays to switch on the networking
equipment”? We decided that sending a signal via radio was a viable solution for this specific
problem. Therefore, we would have a radio signal used as a “turn-on” signal, in parallel with the
data (WiFi and WiMAX) signal itself.
The problem now is, what signal do we send over the radio link. Eric thought of the idea of
just sending some sequence of audio tones. Thus we needed to find a way of developing these
tones, as well as a way of using these tones at the receiving end to engage the relays. Some sort of
decoder would have to be built.
One of the many goals of this course is to incorporate a computer (microcontroller) into our
design. Luckily, a microcontroller would suit our purposes very well. When the decoder decodes
the audio tones at the receiving end, we will send a simple logical high to the microcontroller,
basically telling it which location is requesting the Internet. Thus, the microcontroller would have
to be programmed in such a way to decipher which school sent the signal, and also to turn on those
set of relays to establish the Internet connection for that location. Other tasks included in our group
outline were to determine when the solar power battery was at 40% of its charge capacity (if in use
below this level, the lifetime of the battery is reduced at an accelerated rate), and not engage any
networking equipment until the battery was back to 60% of its charge capacity; the microcontroller
would suit these purposes very well.
8
We were also charged with the task of minimizing the time of making a request and getting
to the web page as small as possible by locally caching the TCP packets at a computer terminal at
the various schools. When a request is made, the packets are stored, then, when a connection is
finally established, the user will be sent right to the web page they requested.
WiMAX
FM radio
FM transmitter FM reciever
decoder
modem
router
microcontroller
Battery charge controller
Figure A.1: Overall Conceptual Design
Gantt Chart We experienced a few deviations from the original plan dictated by the Gantt chart. First,
we changed our designed AM radio to an FM radio, halfway into its construction. We also did not
meet time constraints we set in the beginning. Some parts took longer than expected to test, such as
the relays and the microcontroller. However, we accommodated for that in the original Gantt chart,
allowing more time than necessary to finish each task.
9
Send data Efficiently
Power equipment when needed
Monitor network interface
Sniff user requests
Control power
Look for destination port
Monitor batteries
Switch relays
Send turn on signal
Generate AM signal
Figure A.2: FAST Diagram
10
Design Evaluation
The following table provides an overview of possible designs. This is later broken down
into examining solutions for the software, wireless bridges, and radio link that could be used.
Design Justification Table
Parallel Antennas (Remote turn on)
Parallel Antennas - Router monitoring network usage
Router monitoring network usage
Low Power Consumption (At Baraka)
Only new hardware would be low power microcontroller, receiver, and relays. Power consumed would be very low. Wireless bridges would be turned off when not in use.
This would require a low power microcontroller, receiver, and router to place software on. The router would be an additional device that would have to be powered. But the wireless bridges could be powered off when not in use.
This would require a low power microcontroller and router to place software on. The router would always be on as would the wireless network bridges
Durability/Robustness Microcontroller, relays, and decoder will be placed inside of a protective case. Transmitter, receiver, and antennas will be exposed to the elements so smaller cases might have to be fabricated.
Microcontroller, relays, and decoder will be placed inside of a protective case. Transmitter, receiver, and antennas will be exposed to the elements so smaller cases might have to be fabricated.
All equipment would be housed inside of a protective case
Low Maintenance There will be an ability to remotely connect to administer software, but hardware will be designed to require as little servicing as possible
As long as there are no hardware failures almost all aspects of this system could be accessed remotely.
All components, other than relays and the microcontroller could be administered remotely as they would be software.
11
In determining the software that can be used to detect user generated requests there are
several options available. These range from developing an application using only modules or
libraries to handle low level details to modifying currently existing software to accommodate the
system requirements. The table below presents three options. Scapy and a shell script would
require the most testing and development time, but would allow for the most control over how the
system works. Tinyproxy is a piece of software which is considered to be very stable and mature.
Time would have to be invested in learning the functionality of existing code.
Networking Software Design Justification Table
Scapy Tinyproxy Shell Script Durability/Robustness Scapy is a powerful
program, but has proven that it can
crash unexpectedly in testing.
This would require a lot of error detection
to prevent the application from malfunctioning.
Tinyproxy has been in use for a very long time and has been
proven to be effective.
The functionality that would be added would
be minimal.
Currently being used in Tanzania.
While this application could be run in a shell script, these scripts are meant for batch jobs,
not demons running in the background.
Reading and writing to a file at the same would most likely make this option
unstable. Low Maintenance Application could be
easily modified without recompiling
the program.
There is an extensive configuration file that could be easily edited. If a program bug has
to be fixed the application will have
to be recompiled.
This would probably have to be restarted multiple times in a day and edited for
efficiency after installation in
Tanzania. Safety This would be
accessible by only those with sudo or
root privileges. But no physical risk would be
associated with this software.
This would be accessible by only those with sudo or
root privileges. But no physical risk would be
associated with this software.
This would be accessible by only those with sudo or
root privileges. But no physical risk would be
associated with this software.
Low Cost Free and open source Free and open source Free and open source
12
Team 3 is also responsible for selecting a device to use for the network bridge between
Baraka Primary School and Rift Valley Primary School. Several devices where considered that
could meet the distance requirements and operate in the unlicensed spectrum. Below are the two
solutions that were considered.
Wireless Data Bridge Justification Table
Ligo Point to Point 5 GHz Motorola Canopy Point to Point 2.4 GHz Low Power Consumption (At Baraka)
Maximum power consumption of 12 W. This will probably be adjusted to something less as the transmission only needs to go 5 to 6 miles while the device has a maximum range of 25 miles.
The maximum power consumption would be 8.2 W. This can be adjusted to a lower amount as the maximum range of the devices is 35 miles.
Durability/Robustness This device is built for rugged outdoor environments. It is able to handle the temperatures of up to 60 degrees Celsius. The average temperature in Tanzania is 27 degrees Celsius.
This device is designed for outdoor use and has an expected mean time between failures of 40 years. The maximum operating temperature is 55 degrees Celsius and can survive wind speeds of up to 190 km/hr.
Low Maintenance This device simply has to be attached to an existing network via Ethernet. Management can be preformed through the browser or via SSH. This will allow for remote maintenance from MSU.
This device simply has to be attached to an existing network via Ethernet. Management can be preformed through the browser or via Telnet or FTP. This will allow for remote maintenance from MSU, the connection may be unsecure. If the device had to be replaced the reflector dish would most likely make removal and installation more cumbersome.
Safety The primary physical safety concern is individuals climbing up on a roof or pole to access the device. Best solution for this is to restrict access to the devices in Tanzania by placing Acacia branches at physical access points.
The primary physical safety concern is individuals climbing up on a roof or pole to access the device. Best solution for this is to restrict access to the devices in Tanzania by placing Acacia branches at physical access points.
Low Cost $1912.00 (2 antennas, power adapters, and mounting brackets)
$2017.60 (2 antennas, power adapters, and mounting brackets)
13
While not part of our design criteria, a consideration must be taken into account is the ease
at which equipment can be transported to Tanzania after testing in the United States. As a result of
being smaller, the Ligo PTP 5-23 is a better option, as it does not have a bulky reflector dish.
The table below shows some of the consideration that went into choosing what type of radio
will be used for the radio link. The FM radio ended up being the best choice overall.
Justification Table for radio link
Design Criteria AM Radio FM Radio no-modulation 'RF tone' Receiver Power Consumption
low higher very low
Robustness -more prone to interference -able to send encoded signal
-more reliable in adverse conditions -able to send encoded signal
-most reliable -only able to send one command (two are needed)
Cost very cheap cheap cheapest
14
Costs
Product Price Quantity Total PriceTone Generator/Transmitter PST-SP24AS (Transformer) $55.00 3 $165.00Quad op-Amp $0.46 2 $0.92Power Supply Cord $4.96 3 $14.88Cushcraft (Yagi Antenna) $119.99 2 $239.98In-Line TV Antenna Amplifier $22.39 1 $22.39Antenna 433MHZ $9.94 1 $9.94Extension Cable $14.99 3 $44.97FM Radio Transmitter $11.25 3 $33.75Miscellaneous $15.00 1 $15.00
Decoder/Receiver Latching Relay $3.79 1 $3.79Quad op-Amp $0.46 3 $1.38Antenna 433MHZ $9.94 2 $19.88FM Radio Receiver $19.50 2 $39.00Miscellaneous $15.00 1 $15.00
Microcontroller Miscellaneous $15.00 1 $15.00
Outlet Box Programmable Timer $85.00 1 $85.00Cam Flush Lock Kit $14.75 1 $14.75DIN Rail $3.11 1 $3.11Enclosure $43.77 1 $43.77Single Outlets $3.92 5 $19.60Power Cord with Plug $15.43 1 $15.43Strain Relief $1.78 1 $1.78DPDT Rocker Switch $1.53 5 $7.65Miscellaneous $15.00 1 $15.00
Data Bridge N-Male to RP-TNC Plug $35.99 2 $71.98Linksys $40.00 2 $80.00PTP WiMAX $995.00 2 $1,990.00Miscellaneous $15.00 1 $15.00
Final Price $3,003.95Table A.1
15
As the table above shows, the cost per unit of our design is approximately $3,000.00.
However, if another team were to add another computing terminal that needed “Connect-on-
Demand” Internet, the cost to them would simply be the tone generators, FM transmitter, and an
addition decoder (we already have a relay/electric socket combination for an additional port), and
additional WiFi, WiMAX. Their total cost would be around $2,390.00.
16
Work Performed
As mentioned, the objective of our project is to be able to connect to the Internet when
requests are made, while conserving solar power at Baraka Primary School. Our method of
performing this function was using an FM radio to transmit a pair of audio tones from Rift Valley
and Manyara to Baraka so that the networking equipment is enabled for those locations. Also, in
the case of Baraka itself, there will be a signal to a microcontroller from its computing stations to
enable the VSAT and satellite for Baraka students. This paragraph is a breakdown of the functioning of the “Connect-on-Demand” project with
detailed sections to follow. When a request is made at either Manyara or Rift Valley, a tone
generator will generate two distinct tones (each location has its own set of two tones, resulting in a
total of four tones to be decoded) which will be summed together and then sent to an FM
transmitter. The transmitted signal will then be received by a receiver at Baraka. This signal will
be decoded by a custom decoder. The two-tone method was chosen so that an accidental signal
received by another source would not accidentally trigger the networking equipment. Once the two
tones of a specific school have been detected, a signal will be sent to a microcontroller, and the
microcontroller will then send a pulse to a relay, which will then connect the circuit to the AC
power of the required networking equipment of a specific location where an Internet request is
made. In the case of Baraka, a signal will simply be sent directly to the microcontroller.
After a specified amount of time has elapsed of no Internet activity, the microcontroller will
send another pulse to the specified relays to shutdown the networking equipment, thereby
conserving power. Another task of the microcontroller is to shut the entire system down at specific
time of day (late night – when the students are sleeping) so that the lifetime of the system can be
maximized by not constantly draining the solar power batteries. This will be done with the aid of
timer that has a built-in alarm, sending a signal to the microcontroller.
With all that being said, we would like the request for the user to be as quick as possible,
without interruptions. For this purpose, software has been developed that will cache the TCP
packets locally at each school, while using the computer itself to send a signal to the FM radio to
transmit the “turn-on tones”. It will appear that the connection was always there in the first place,
for all of the above mentioned will happen in seconds.
17
System Power We will be implementing four power supplies at the three locations in Tanzania; Baraka,
Manyara and Rift Valley.
Baraka:
We will be running off of a 12 VDC photovoltaic system source; we will use two 5 Volt
linear voltage regulators to run the receiver and decoder as well as the microcontroller. The 12
Volts will be used to switch the relays and charge the timer.
Manyara:
At this location, a PST - SP24AS transformer will be implemented to convert the 240 Volts
AC to 24 Volts DC. The 24 volts DC will power the tone generator as well as the FM transmitter.
The 240 Volts AC will power the POE (Power-Over-Ethernet) adapter and computer.
Rift Valley:
This location is broken up into two separate buildings. Here, we will also use a PST -
SP24AS transformer to convert the 240 Volts AC from the grid to 24 Volts DC at each building.
Due to the geography of this location, it was deemed better to use a “repeater” format. One
building is where the actual computer terminal will be placed, and the other building will have line-
of-sight to Baraka for both FM and WiMAX signal transmission. The tones will be generated at the
computer terminal, transmitted to a receiver at the building with line-of-sight, and then
retransmitted to Baraka. This process also holds true for the WiMAX connection.
Therefore, the 24 Volts DC will power the tone generator and the FM radio transmitter at
one building, and another 24 VDC will power the second FM transmitter for the signal to Baraka.
The 240 VAC will power the computer, POE adapter and the wireless repeater.
FM Radio Transmission For transmission of the pair of audio tones at either Rift Valley or Manyara, an FM radio
transmitter/receiver was used at a frequency of 433 MHz. The reason for this choice of frequency
was because this is used for ISM Band, which does not require special government licensing.
Our method for implementing this is to have the actual transmitters at Manyara and Rift
Valley outside close to the antennas, and run the audio tones via stereo cable from the tone
generators to the transmitters. It is perceived that it is better to run the stereo cable from the tone
generators to the transmitters at a longer length than the coaxial cable from the transmitters to the
antennas due to attenuation affects of the high-frequency FM transmission signal. We will be using
400 series coaxial cable, 50’ in length from the transmitters to the antennas. One end of these
18
cables will be terminated with a PL-259 male connector which fits the PL-259 female connector on
the Yagis, and the other end of the coax will be terminated with an N-male connector. The interface
between the coaxial cable and the transmitter is BNC style, so we will use an N-female to BNC-
male adapter. These coaxial cables have a loss of 6.614 dB/100’ at 2.4 GHz. We will be operating
at 433 MHz (approximately 1/5 of 2.4 GHz) with a length of 50’, so the losses will not be
significant with this type of cable.
The FM transmitters/receivers we purchased are from a company called RFSolutions, part
numbers FM-RTFQ2-433R and FM-RRFQ2-433, respectively. One issue we encountered using
these transmitters and receivers is that they operate by transmitting and receiving the signal in
square-waves; meaning they were not sending and receiving the sinusoids we were generating with
the tone generators. Square-waves are comprised of infinite sinusoids (Fourier decomposition), so
there was interference with respect to the bandpass filters of the decoder in regards to each pair of
tones, tricking the decoder into thinking that both schools were transmitting, when only one was.
Thus, we started from scratch and picked tones where the harmonics of the square-waves did not
overlap and outputted them through a comparator so that square-waves were being outputted to
further reduce any form of interference.
Figure W.1: FM Transmitter Figure W.2: FM Receiver
Anyone who took a wireless communications course knows that the antenna dimensions
have to be on the order of the wavelength of the signal that is being transmitted (both receiving and
transmitting antennas). The wavelength of 433 MHz is approximately 70 cm. As stated, we chose
high-gain Yagi antennas for transmission, thus the driven element of the antenna is approximately
32.7 cm (half-wavelength). We purchased these antennas from Cushcraft, and the model number is
A430-11S. At the receiving end (Baraka Primary School), we chose a monopole antenna of length
17.5 cm (quarter-wavelength), purchased from Antenna Factor, model number ANT-433-PW-QW.
The monopole antenna will use the same type of coaxial cable as the Yagis.
19
Figure W.3: Cushcraft A430-11S 70 cm Yagi Antenna
Figure W.4: Antenna Factor ANT-433-PW-QW
Due to the soil conditions at Rift Valley (volcanic rock), we will be implementing a repeater
station at that location. This location is comprised of a dormitory building, as well as the actual
building for the school. The school will be the physical location of the computer terminals,
however line-of-sight for radio transmission to Baraka is located at the dormitory. Therefore, the
audio “turn-on” signals initiated at the school (location of computers) will be transmitted to the
nearby dormitory, where it will be received, then retransmitted to Baraka. We will use the quarter-
wavelength monopole antennas for the repeater purpose. Thus, there will be two transmitters and a
receiver located at Rift Valley for this repeater method.
Mounting of the antennas will most likely be on metallic, circular poles purchased in
Tanzania, as with previous projects. Both of the WiMAX and FM radio antennas will share and be
mounted to these poles (estimated at 10 meters). This is why we need such long coaxial cable (50
feet).
Tone Generators When an Internet request from Baraka or Manyara is made, the first step to turn on the
necessary communications equipment is to produce a specific set of analog tones that the decoder
will recognize. Each set of tones consists of two audio frequency tones. One set of tones
20
corresponds to an Internet request for Manyara, and one set of tones corresponds to an Internet
request for Baraka.
The first consideration in this design was how to produce an audio frequency sinusoid.
Phase shift oscillators were chosen because they are easy to implement and require a small number
of parts. They only require resistors, capacitors, and one op-amp. Another consideration in the
design was the operating voltage. Early on, it was decided that most things would be powered with
5V. Part of this decision was based on the radio transmitters and receivers. The radio transmitter
used 5V for power and its input was a 0 to 5V signal.
The LM324 quad op-amp was chosen because it can run off of a low supply voltage, it has
four op-amps per case, and it is designed to work as a single supply op-amp. Typically, op-amps use
typical plus/minus voltage rails and a 0V reference, For the tone generator circuit, the voltage rails
were 5V and 0V, and the reference was 2.5V. The reference was made from a simple voltage
divider. The resistors for the voltage divider were chosen to be as high as possible while still
remaining a reliable 2.5V reference.
The phase shift oscillator circuit is shown in figure W.5.
Figure W.5: Phase Shift Oscillator
The frequency of oscillation can be calculated using the following equation.
621
RCf
π=
In order for the circuit to oscillate, the feedback resistor must be chosen such that:
RR f 29≥
21
To create a set of two tones, two tones were simply added together using a summing
amplifier. This summing amplifier was implemented using the same integrated circuit as the rest of
the circuit.
One problem with the entire analog tone encoding/decoding was the radios. The radios that
were being used earlier in the semester used ASK modulation, and the current radios use FSK
modulation. This means that the signal is run through a comparator before being sent. This
comparator does not switch exactly at 2.5V, and there is some hysteresis. Therefore, when decoding
the signals, the original signal can not be recovered. To resolve this issue, a 'zero' crossing detector
was added as the last stage to the tone producing circuit. The 'zero' is in quotes because, since the
reference is 2.5V, it is actually a 2.5V crossing detector. This crossing detector is exactly centered
where the signal is biased, and there is zero hysteresis. Therefore, the signal can be recovered after
being made into a square-wave. The crossing detector is also implemented on the same op-amp.
The circuit is powered from a 24VDC supply, which is fed through a 5V regulator. Before
going through the regulator, the 24VDC is fed through a relay. The relay contact is only closed
when a 5V signal from the computer's serial port is sent. Since the serial port cannot supply enough
current to switch the relay, a simple transistor circuit was added. The transistor circuit requires the
serial port to provide only 5mA. This current saturates the transistor. A resistor was added in series
with the relay coil to limit the coil current. This was necessary because the relay was made to switch
from 5V, but is being switched with 24V.
Complete schematics of the tone generators are provided in Appendix III.
Tone Decoder Once the tones are modulated, transmitted, received, and demodulated, the signal must be
decoded. The decoder was actually designed before the tone generators, as it is a much more
complicated circuit. Like the decoder, this circuit was designed to run off of 5V. This is largely
because the radio receiver requires 5V to run and has an output of 0.8V to 4V. Once again, this
circuit was setup to have 0V and 5V rails with a 2.5V reference. The voltage divider for the 2.5V
used fairly low resistor values to maintain a reliable 2.5V reference. LM324 op-amps are also being
used in this circuit because they are cheap, require low voltage, and are single supply op-amps.
The first stage of the decoder is simple voltage follower. This stage acts as buffer. The input
impedance of this stage is very high and the output is able to supply up to 20mA. The output of this
stage is fed to the four band-pass filters.
22
The band pass filters are the most important part of the circuit. The goal was to create sharp
band-pass filters while using only one op-amp. Butterworth filters were considered, but it was
decided that they require too many stages to achieve the desired sharpness. Therefore, second order
filters with imaginary roots were used. One of these filters is shown below figure W.6.
Figure W.6: Second Order Band-Pass Filter
To choose the components for each filter, A simple algorithm was followed. First the center
frequency gain was chosen to be 2.1=H . Then the sharpness was chosen to be 10=Q . After that
the center frequency was chosen: 00 2 fπω = . Next a standard capacitor value was chosen:
54 CCC == . Once all these parameters were chosen, the resistors were calculated using the
following equations:
( )
CQ
R
HQCQ
R
CHQ
R
0
05
200
02
0
01
22
ω
ω
ω
=
−=
=
This process had to be tweaked and redone several times to find a filter with a center
frequency close enough to the oscillator frequency. After building several of the filters with a
sharpness of 7, the circuit was redesigned with a sharpness of 10. The higher the sharpness, the
more difficult it was to use standard components to obtain the correct center frequency.
The output of each filter is fed to a peak detector. This circuit detects the highest peak of the
AC signal and makes it a DC level. A resistor was added to the typical peak detector so that once
the decoder is no longer receiving the signal, the capacitor quickly loses its charge. The peak
23
detector detects one diode drop lower than the actual peak of the waveform. Therefore, when no
signal passes through the filters, the peak detector voltage is about 2V, but when a signal passes
through the filters, the peak detector is about 3V.
The next stage in the circuit is a 2.5 V crossing detector. When the signal is above 2.5 V, the
output is 5V, or a logical 1. When the signal is below 2.5 V, the output is 0 V, or a logical 0.
These logic signals are connected to a 74LS08, which is an integrated circuit containing
AND gates. The output of these AND gates are connected to the input of the microcontroller.
Therefore, the microcontroller only receives an input if both tones of one pair are received.
The frequencies for the tone signaling were changed at one point because the radio made the
signals into square-waves. Because of this, some harmonics were registering as different tones and
creating false inputs. Also, interference sometimes creates false inputs. A safety feature was
implemented so that the microcontroller must receive the signal for a full second to register as an
input.
In order for the decoder and receiver to be turned on and off at night, a two coil latching
relay is used to switch on an off the circuit. The latching relay is controlled by the microcontroller.
Transistors are used to amplify the current to switch the relays.
A complete schematic of the decoder is provided in Appendix III.
Outlet Box For actual powering of the network equipment via the relays, we purchased a commercial
grade circuit breaker box to combine the necessary components. Inside this outlet box will reside
the tone decoder, external shutdown timer, an actual circuit breaker in case of a power surges, the
microcontroller, the relays, and the electric sockets that the networking equipment will actually plug
into.
When either Manyara or Rift Valley send a signal to switch on the equipment, the receiver
will send the signal to the decoder, then output a logic high to that specific pin on the
microcontroller. The microcontroller will then engage those specific relays for that location, which
will send power to the electrical sockets of the needed networking equipment, thereby turning on
the equipment to connect the Internet. This is a great way to consolidate all these components that
need one another for the overall functionality of the product at Baraka.
We also incorporated switches into our design for either “auto” or “manual” modes. In auto,
the path of the electricity is through the relays, where the relays control the power. In manual
mode, the path of the electricity is directly to the electrical sockets, thereby constantly powering the
24
networking equipment. This was done as an intentional bypass in the event that the auto mode fails,
e.g. a relay breaks, or the radio signal is no longer functional.
Figure W.7: Outside of outlet box. Figure W.8: Inside of outlet box.
25
Software (Microcontroller/Locally Caching Packets/Transmit FM Signal)
Microcontroller In the design, a microcontroller is used to handle all switching functions at the site of the
satellite link at Baraka. The microcontroller decides whether to turn on/off the satellite link based
on four different inputs:
• Battery life notifications
• An individual Internet request from either of the three schools
• External clock
• Countdown internal timer
There are also four outputs which are used to switch relays in order to turn on/off the system:
• WiFi link (Manyara)
• WiMAX link (Rift Valley)
• Satellite
• Decoder/AM Receiver
Battery Life The first input is a signal from the battery system, which allows the microcontroller to have
access to the voltage readings from the battery. The most efficient and effortless way of doing this
is by using the Analog-to-Digital converter function on the PIC18F4520. An Analog-to-Digital
converter takes a continuous signal, such as the life of a battery, and converts it into a discrete one,
making it computer-friendly. Using the microcontroller, the discrete signal is then interpreted and
placed into coding in which you can define its use. Considering the battery present in Baraka, we
determined the lowest threshold voltage we will allow to run the system without damaging the
battery. Using the battery data sheet, and consulting East Penn Co., we determined this voltage to
be 13.5 V. If that voltage or a lower one is detected, the microcontroller turns off the system and
enters into no-operation mode. The decoder and FM receiver are also turned off to conserve power
and allow the battery to charge more efficiently. In this mode, the PIC will not accept any Internet
request from any school until obtaining another alert from the battery system, determining if battery
voltage is at the most desirable voltage for operation. This voltage was obtained the same way as
the lowest threshold voltage, and was found to be 13.8 V. When that voltage is reached, the
microcontroller comes out of its no-operation state and accepts Internet requests.
Although we knew what to do, and how we wanted to implement the battery check, we ran
26
into a few problems. First off, the microcontroller can only handle voltages up to 6 V, and will burn
out if anything higher is encountered. This served as a problem because the battery we need to
check is more than twice this maximum value. To alleviate this issue, we used a voltage divider to
step down the voltage of the battery using two resistors and a capacitor. The end result can bee seen
in the figure below.
Figure W.9: Voltage Divider
The resistor values were chosen to decrease the amount of power dissipated. Thus, a 1 MΩ resistor
was chosen for the 5 V to run across. The other resistor is then solved for using voltage division.
R2 = R1 ≜ ((vim / volt) – 1)
R1 in this equation is 1 MΩ, vim = 14.5 Volts, and volt = 5 volts. R2 was found to be 1.9 MΩ.
However, the closest resistor value in the lab is 1.8MΩ, which was used in our design. The end
result allows us to map the 0-14.5 V battery spectrum to a 0-5 V spectrum. Thus, we can check the
battery voltage without burning the microcontroller.
The next issue was adding code to check the battery in the middle of an operation, such as a
countdown. This issue was resolved by implementing a battery check in each iteration of the for
loop of the countdown. This type of functionality is demonstrated in the sample code below, which
merely lights up an LED.
27
loop=50; while(loop>0) //Battery Check SetChanADC(ADC_CH0); ConvertADC(); while(BusyADC()); adc_result = ReadADC(); for(count = 1; count < 40000; count++); PORTDbits.RD3 = !PORTDbits.RD3; //Lights up the LED loop--;
This program will continuously check the battery even during the flashing of the LED. For every
iteration of the while loop, the Battery Check commands will be called, in the midst of the program.
The last problem we faced was how to interrupt normal operation in the event the
microcontroller receives a low voltage from the batteries. As stated before, the ADC converter
function of the microcontroller converts the analog battery to a digital, hexadecimal value. In order
to test whether the battery is low, we can compare this number to another hexadecimal value. This
number is determined by the number of bits that represent the reference voltage. In the case of the
PIC18F4520, the voltage is spread over 1024 bits. Therefore, if you had 5 Volts as your Vref+, you
would have 5/1024 volts per bit, or 4.88mVolts per bit. Knowing this number, you can turn any
voltage limit into a binary number. For instance, if you wanted 2 volts as the cutoff limit, you
would multiply it with the reciprocal of 4.88m.
2 volts * 1 bit = 409bits
4.88m Volts
Now, you can take whatever value you got in your ADC conversion and compare it to 409,
or 19A in hexadecimal. From there, you can write statements for the program to interrupt whatever
is functioning and power down. An example code for this type of interrupt is found below, using
the same LED function as in step 3. Notice there is a place where you can alert the user of an
imminent shutdown.
28
loop=50; while(loop>0) //Battery Check SetChanADC(ADC_CH0); ConvertADC(); while(BusyADC()); adc_result = ReadADC(); //Voltage Comparison if(adc_result<0x019A) //Output “Low Battery” break; for(count = 1; count < 40000; count++); PORTDbits.RD3 = !PORTDbits.RD3; //Lights up the LED loop--;
Instead of continuing to run the program, the µC will break the function and the main program to
power everything off. We also allowed the battery to charge back up to the optimum battery level,
while the program lies dormant. We did this by using more comparative statements, and
periodically re-checking the battery. Using the same example, let us code the program to start
running again after the battery is charged to 3 V.
3 Volts * 1 bit = 615bits
4.88m Volts
615 decimal = 267 hexadecimal
29
loop=50; while(loop>0) //Battery Check SetChanADC(ADC_CH0); ConvertADC(); while(BusyADC()); adc_result = ReadADC(); //Switched from ‘if’ to ‘while’ while(adc_result<0x019A) //Output “Low Battery” //Re-check battery SetChanADC(ADC_CH0); ConvertADC(); while(BusyADC()); adc_result = ReadADC(); //Check if battery is still less than 3 volts if(adc_result<0x0267) adc_result=0x00; for(count = 1; count < 40000; count++); PORTDbits.RD3 = !PORTDbits.RD3; loop--;
By switching the if statement to a while statement in the figure above, the program will come to a
halt as soon as the battery falls lower than 2 V. There is also a spot in the code in which one can
alert the user of the low battery life. The advantage of this new code is that the program will stay
halted until the battery increases above 3 V. Thus, the program will run again after we have
reached our optimum voltage.
30
Internet Request The second input is a signal from Baraka, Manyara or Rift Valley requesting access to the
Internet. Each individual school has its own pin which alerts the µC if the school requests Internet
access. Whenever a user from either of these locations generates Internet packets, the
microcontroller will tell the satellite to and respective routers to turn on. This was the main
function of the microcontroller program. We ran into problems accepting multiple requests and
handling them at the same time. Once one input was received, the code ran just for that request and
neglected any other that came after. To battle this, flags were designed to interrupt whatever code
was running at that point. For instance, if the Baraka countdown was running and a Manyara
request was made, the “Mflag” was set to 1 and broke the code. For the most efficient program, a
three-state machine was formed. In the first state, only Baraka has a request. The second state is
the “Mflag” state, and this state is achieved when the last Internet request made was from Manyara.
Similarly, the third state is the “Rflag” state, in which the last request made is from Rift Valley.
The program jogs back-and-forth between states, depending on those factors.
Countdown Timer The third input, the countdown, was clocked using an external crystal of 40 MHz. As soon
as the microcontroller receives a high value from a particular school, the clock starts at 15 minutes
and counts down. If another request is sent during that time from the same school, the
microcontroller resets the countdown timer to 15 minutes. After the countdown is complete, the
microcontroller sends a high value through the relays to shut down that particular connection of the
system, whether it is the WiFi, WiMAX, or the satellite. In each case, a separate countdown is kept
for each school. While the program may move from state to state, the countdown value for each
school is passed, thus keeping track of how much time that school has before timing out. This
allows one part of the system that is not in use to shutdown while another part is still fully
functioning. “If” statements were used to determine whether the countdown reached 0 or not.
Depending on which state is running, the program checks for the given countdowns to make sure
that specific school has not timed out.
External Shutdown The last input is the external shutdown signal based on what time of the day it is. The
microcontroller was synchronized to an external clock we ordered. When that clock reads 11 PM,
the microcontroller is programmed to shut down the system for the night and enter in a hibernation
31
mode. The external clock will then flip a relay when the clock reads 7 AM, in which the
microcontroller was prompted to wake up and be ready to receive requests. As a precaution, the
program shuts down any link that may be running at the time, even though it is expected that the
schools will be closed for the night. The decoder and FM receiver is also shut down during the
night to conserve power. Along with the consumption of power, the external timer has a built-in
feature; in case of a power failure, the internal rechargeable lithium ion battery will retain the
programming and the time for up to three months. The downside of that is it will only retain the
memory, but not functional. An external 12 V must be supplied in order to activate the time switch.
Relay Outputs As stated before, relays are used to trigger on and off the WiFi, WiMAX, and satellite links.
These outputs are generated by the microcontroller, and are called when timeouts, low battery, or
the external shutdown curfew are set. In order to trip the relays, a pulse was constructed. The most
efficient way for the microcontroller to generate this pulse was by using a for loop. Here is the code
used to create a pulse, shown below.
PORTCbits.RC6 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC6 = 0;
However, a problem occurred when the relays needed more current in order to function. Thus,
transistors were added to boost the output current of the microcontroller to a magnitude the relay
would take in.
Detecting and Caching User Requests Team 3’s project called for networking equipment to be turned on and off with a user
request. This could have been simply been done by having the user run an application. But the goal
of this project was to activate network equipment with no user input outside of entering a URL.
This section will describe how a modified proxy server, serial interface, and modified configuration
of Firefox can be used to detect a connection, catch requests, and initiate a signal to turn on
networking equipment.
Tinyproxy is an open source, lightweight proxy server. It is currently being used in MSU’s
multi-seat implementations in Tanzania for content filtering. Tinyproxy’s inputs come from a
browser which is configured to send requests to it. For this configuration, Tinyproxy will be
configured to listen on port 8888. When a request is received by Tinyproxy on that port, the request
32
is examined. Depending on the local cache and content filter configuration, either a locally cached
webpage is returned to the end user or the request is repackaged and sent out over the network.
When a response is received by Tinyproxy from a web server, it is passed along to the user.
When Tinyproxy is examining a request, it is temporarily storing it in memory, effectively
caching it. To take advantage of this feature to fulfill the needs of the project, the function that
handles all outgoing data to a network interface was modified. The system()function was used to
run a Python script that checks for a network connection and initializes a “turn-on” signal. The
system() function is particularly useful because it prevents Tinyproxy from processing the request
until a value is returned. The value returned is an integer, if it is negative, then an error has occurred
and the event is logged. If the value returned is 0, then the script was successful.
Python was chosen to modify Tinyproxy for two reasons. The first was the developer
responsible for this portion was most familiar with that language. The more significant reason is
that modifications can be easily made in Tanzania if there are unforeseen problems. Furthermore,
because of Python’s encapsulation of lower level commands this script can be kept relatively short
and simple. It is broken up into 4 functions.
The first function, getIP(), is used to check for an Internet connection. It does this by
pinging www.google.com, www.yahoo.com, and www.bbc.com. It is highly unlikely for any of
these three sites to be offline. It would be even more unlikely for all of them to be down at the same
time, and for that reason to provide an accurate sampling to determine if there is Internet
connectivity. If one of those addresses can be reached then there is an Internet connection and the
getIP() function will return True. In other words, it will have been determined there is an active
Internet connection. Otherwise, if all the sites previously listed do not respond to a ping, the
function will return False.
The Next function is sendSig(). It uses a library called Py-Serial to open a serial COM port.
The interface is opened for 1 second and is then closed. By doing this +5 V is sent over pin 4 of a 9
pin serial cable. While this is very simple, the only interface required is to turn on networking
equipment by initiating a “turn on” request. As a result, the presence of a voltage is used to signal
the 433 MHz transmitter to generate a signal.
The exiting()function can be thought of as an administrative function, but it is none the less
critical. It redirects the stdout from outputting to this script’s log file, back to the Linux terminal. It
also generates an exit code. This is the value that will be returned by the system()function that was
added to Tinyproxy’s source code.
33
The final function is the main()function. First it redirects stdout to the script’s log file. It
then enters an infinite while loop. This continually checks for an active Internet connection with the
getIP()function. If it returns True, then the sendSig() function is called. Then the exiting() function
is called, breaking the loop. The sendSig() function is called because the “turn on” signal not only
switches on networking equipment, but also resets the timer used to determine when equipment is
turned off at Baraka.
If getIP() returns false then the loop continues. It will call the sendSig() function and then
wait five seconds before running through the loop again. The sendSig() function is called multiple
times to protect against a signal not being received due to factors such as interference. The number
of times a turn on signal is sent during a loop is logged.
The last step is to modify the configuration of Firefox. This must be done because Firefox
will also detect the lack of an Internet connection, thus preventing the user’s HTTP request from
going to Tinyproxy.
The settings are changed by typing about:config in the address bar and setting the following values:
• Toolkit.networkmanager.disable = true
• Browser.offline = false
• Browser.offline.notify = false
Creating a WiFi repeater Near the end of the project, Team 3 learned that the 433 MHz antenna used to transmit a
turn on request and WiMAX data bridge was going to be placed about 150 meters away from the
building housing the multi-seat computer at Rift Valley Secondary school. To avoid having to dig
into volcanic rock to lay cable Team 3 decided to transmit signals wirelessly. For the data
connection that meant creating another bridged connection, separate from the WiMAX point-to-
point solution used to connect Rift Valley to Baraka.
To accomplish this, two Linksys WRT54GL routers were flashed with the open source dd-
wrt firmware. One was configured to be a router and outfitted with two aftermarket 15 dBi Yagi
antennas. This will be connected to the WiMAX data bridge via a CAT-5 Ethernet cable as an input
to the WAN port. Wireless security settings were then set using WPA2.
The second router was configured as a repeater. By being set up as a repeater, it can be a
client of the first router. This is done by setting up a virtual interface on the device acting a repeater,
configuring the interface to listen for the first router’s SSID and provide it with the WPA2 passkey.
34
Finally, to provide access to other client devices, the repeater was set up to allocate IP addresses on
its own subnet. In this way, it is also acting a router.
35
Testing
Microcontroller Testing separately from the entire system, the microcontroller showed that it takes in each
input and correctly generates the proper outputs. When the microcontroller takes a request from a
school, the following happens based on the order; for the first request, the microcontroller turns on
the respective Internet link. If Rift Valley or Manyara gets an individual request and the satellite
link isn’t on, the microcontroller first turns on the satellite, and then the respective WiFi or WiMAX
link. Every request after that properly restarts the countdown to 15 minutes. The microcontroller
also only works as long as the input from the external clock is high, or in “daytime” mode. As soon
as the clock switches to “nighttime” mode, the microcontroller properly shuts down whatever is on
and no longer accepts Internet requests, until the clock switches back to “daytime” operation.
Furthermore, the microcontroller battery check function was tested using a power supply for the
battery. As coded, the microcontroller properly outputs a pulse to the respective relays of all the
links that are on, including the FM receiver, as soon as the battery falls below 13.5. Also, upon the
alert of the battery being 13.8 Volts or more, the microcontroller allows the system to generate
Internet requests again.
FM Radio Transmission When we first began testing with the radio link, we initially used AM radio transmitters and
receivers. We then decided that the AM signal is more susceptible to noise, and may not suit our
long distance purposes in Tanzania. Based on this, we switched over to frequency modulation
(FM).
Once, we got the tone generators and decoder working properly with a direct link to one
another, it was then that we tested them wirelessly, via the FM link. We initially tested with the
homebuilt Qwagi antennas, first in the Engineering Building hallway (in order to make the system
as mobile as possible, we used 9 VDC batteries with a 5 V regulator for power – these circuits
require 5 V for power). This was successful, so we took the transmitter/receiver with tones and
decoder, signal transmitted via Qwagi antennas outside, and experimented from the Trowbridge
parking ramp, and one person continually walking further away. The only problem experience was
when trees were in the way of line-of-sight. This is what leads us to believe that line-of-sight will
be required for transmission, regardless of any antenna/amplification configuration.
36
Greg Mulder, one of the ECE technicians was kind enough to supply us with his personal
folded-dipole Yagi antenna for further testing. It was time for long distance testing of the radio
link. We decided that transmitting from Lansing to East Lansing would very nearly approximate
the maximum length for which we would need to transmit in Tanzania. The Radisson Hotel in
downtown Lansing supplied us with a room, which had line-of-sight to Hubbard Hall. We were
successful with transmission, spanning 4.5 miles. One person with the transmitter used the folded-
dipole Yagi, while the person at the receiving end used the quarter-wavelength monopole antenna.
One thing that stood out was the fact that the polarization of the radio EM field was more apparent;
when the two antennas were perpendicular to one another, no signal was received, but when in
parallel, the signal was crisp and clear. This was so successful, that it reenergized our group, and
productivity accelerated.
There were still other configurations of antenna/amplifier setups that we wished to test. We
purchased a 25 dB amplifier (finding out that it was meant for receiving and not transmitting). We
tested transmission using strictly monopole antennas (transmitting and receiving) and found we
could get about ¾ of a mile with this configuration. We tested this configuration with the 25 dB
amplifier, and that gave us a little more distance, but not much. Also, during this testing phase, one
person was transmitting, while another was driving in a car going further and further away with the
receiver from the transmitting source. Unfortunately, there were trees and other objects interfering
with line-of-sight. We then switched back to the Yagi configuration with a monopole at the
receiver, and that did in fact give us the best results.
Tone Generators and Decoder The tone generators and decoders were tested together. For testing purposes, the output of
one tone producer was connected directly to the input of the decoder. In reality, this wire
connection will be replaced by a radio link. The tone generators and decoder were tested with the
radio link, and the results were nearly identical.
37
Figure T.1: One of the Two Tone generators
Figure T.2 shows the waveforms produced by the tone producer. The top right is a 123 Hz sinusoid.
The top left is a 1.31kHz sinusoid. The bottom left shows the tones summed together. The bottom
right shows the waveform after the comparator. This is the waveform actually being sent by the
radio. One of the tone generators is shown in figure T.1.
Figure T.2: Tone Producer 1
38
Figure T.3 shows the waveforms as they go through the decoder. Top left is the waveform after the
234Hz filter. The top right is the waveform after the 2.24kHz filter. The bottom left is the waveform
after the 123 Hz signal. The bottom right is the waveform after the 1.31kHz filter. It can be seen
that the top two filters reject most of the signal, while the bottom two filters pass their respective
signals. The final result of receiving this signal is shown in figure T.4. In this figure, the green LED
is lit, meaning that one set of tones is being received. The other set of frequencies has similar
results. The oscilloscope images for the other set are included as Appendix III.
Figure T.3: Decoder while receiving tones from tone producer 1
39
Figure T.4: Decoder decoding a signal
External Timer Triggering Mechanism
Testing the external timer yielded positive results. In figure 1 below, the green LED is
turned on, which is simulating day time in Tanzania; this can also be seen as the red LED on the
external timer is also lit.
Figure T.5: Timer switched to ON simulating day time
The simulation also calls for a night time curfew at approximately 11:00pm. To simulate
the time triggering, by pushing the “MANUAL” button twice, the system shuts down, therefore
40
simulating night time. The “MANUAL” button is an override switch for the system. As seen in
figure 2, the red LED of the timer is not on and hence, the green LED is shut off.
Figure T.6: Timer switched to OFF simulating night time
Concluding that the external timer operated as desired, the final step was to ensure that the
microcontroller received 5 volts from the output of the timer. In order to observe a successful 5 volt
transfer, referring to the figure below, a 5.1 Volt Zener diode was placed in parallel with the load.
Figure T.7: Interfacing External Timer to Microcontroller
By implementing the schematic from above, the following result was measured for the
voltage across the microcontroller shown in figure 4.
41
Figure T.8: 5.09 Volt Output for Microcontroller
42
Tinyproxy The modifications to Tinyproxy were tested to ensure the application is caching user requests,
detecting an active Internet connection, and initiating a “turn on signal”. The application had the
desired results. To show it worked, log outputs were examined, the physical connection to the
Internet was disconnected and then reconnected, and LEDs were used to show an output was being
sent on Pin 4 of the serial cable.
Two log files were examined. They were both located in the /usr/local/var/log/ directory.
They are called tinyproxy.log and python.log. Two terminal windows were opened. In one window
the command tail –f tinyproxy.log was given. In the other tail –f python.log was entered. This
allows the log outputs for Tinyproxy and the Python script to be monitored in real time. At this
point the computer was connected to the Internet and Firefox was used to load tism.msu.edu. The
log outputs for this request are below. Tinyproxy.log:
1. CONNECT Apr 25 16:59:01 [23241]: Beginning IP test 2. CONNECT Apr 25 16:59:01 [23241]: Connection Confirmed 3. CONNECT Apr 25 16:59:01 [23241]: Connect (file descriptor 6): localhost
[127.0.0.1] 4. CONNECT Apr 25 16:59:01 [23241]: Request (file descriptor 6): GET
http://tism.msu.edu/favicon.ico HTTP/1.1 5. INFO Apr 25 16:59:01 [23241]: No proxy for tism.msu.edu 6. CONNECT Apr 25 16:59:01 [23241]: Established connection to host
"tism.msu.edu" using file descriptor 7. 7. INFO Apr 25 16:59:01 [23241]: Closed connection between local client
(fd:6) and remote client (fd:7)
In Firefox the webpage loaded as expected. At line 1 of the tinyproxy.log file, it shows the
Python script was executed to check for an IP address. Then at line 2 the log file show an Internet
connection was detected successfully. Tinyproxy finally continues on to send out the user request
and return it to the user when a response from tism.msu.edu is received. Python.log:
2010-04-25 16:59:01 STATUS Internet Connection Confirmed 2010-04-25 16:59:01 STATUS Sending turn on single 2010-04-25 16:59:01 CLOSING
The Python.log file looks as we would expect it to. It shows the script starting and since
there is an active Internet connection, at least one of the sites (google.com, yahoo.com, bbc.com)
can be pinged successfully. A turn on signal is sent and the script exits. It is evident from the time
stamps these log entries occurred at the same time. Under the testing conditions it can be concluded
they refer to the same HTTP requests. The next step is to test the ability to cache a user request.
43
To test this functionality the Ethernet cable was unplugged from the computer and a request
was made from Firefox. This time cnn.com was visited because tism.msu.edu has been cached by
Tinyproxy and the request may not have gone out to the network. Under normal circumstances
Firefox would timeout, but the screen simply appears as though it is loading:
Figure T.9: Normally when an Internet connection is not available Firefox would immediately time-out.
The output form tinyproxy.log is:
1. CONNECT Apr 25 17:18:25 [24211]: Beginning IP test
This output only shows one line. That one line was the python application being executed. The log
does not show successful completion of the script or an error being returned. This means the python
application was running, if we look at the output for python.log this is confirmed: 2. 2010-04-25 17:17:58 STARTING Entering main loop. 3. 2010-04-25 17:17:58 STATUS Sending turn on single 4. 2010-04-25 17:17:58 STATUS Connection invalid, sending Turn on signal 5. 2010-04-25 17:17:58 STATUS turn on signal has been sent 1 times 6. 2010-04-25 17:18:03 STATUS Sending turn on single 7. 2010-04-25 17:18:03 STATUS Connection invalid, sending Turn on signal 8. 2010-04-25 17:18:03 STATUS turn on signal has been sent 2 times 9. 2010-04-25 17:18:08 STATUS Sending turn on single 10. 2010-04-25 17:18:08 STATUS Connection invalid, sending Turn on
signal 11. 2010-04-25 17:18:08 STATUS turn on signal has been sent 3 times
44
It should be noted that the output is truncated as it is rather long. The timestamps can be
compared to from the two log outputs to show the events are related. The python.log file repeatedly
shows no Internet connection being detected. After each failed attempt to detect a connection a turn
on signal is sent and the loop continues. The last set is to plug the Ethernet cable back into the
computer to simulate an Internet connection becoming available.
After a couple of seconds the output from python.log is very similar to when there was an
active Internet connection. This means an Internet connection was successfully detected. The
Python script exited and allowed Tinyproxy to send out the HTTP request. The applicable log
entries are below: 1. 2010-04-25 17:23:38 STATUS Internet Connection Confirmed 2. 2010-04-25 17:23:38 STATUS Sending turn on single 3. 2010-04-25 17:23:38 CLOSING
By looking at the output from tinyproxy.log it is also evident that the Python script
completed successfully (line 2 below). And the request was sent onto cnn.com. A response was then
received from the web server and the connection was closed: 1. CONNECT Apr 25 17:18:25 [24211]: Beginning IP test
2. CONNECT Apr 25 17:23:38 [25878]: Connection Confirmed 3. CONNECT Apr 25 17:23:38 [25878]: Connect (file descriptor 9): localhost
[127.0.0.1] 4. CONNECT Apr 25 17:23:38 [25878]: Request (file descriptor 9): GET
http://i.cdn.turner.com/cnn/.element/img/3.0/video/thumbnail_play_hover.png HTTP/1.1
5. INFO Apr 25 17:23:38 [25878]: No proxy for i.cdn.turner.com 6. CONNECT Apr 25 17:23:38 [25878]: Established connection to host
"i.cdn.turner.com" using file descriptor 10. 7. INFO Apr 25 17:23:38 [25878]: Closed connection between local client
(fd:9) and remote client (fd:10)
45
Finally by looking at Firefox it is evident that cnn.com loaded:
Figure T.10: Successful connection to CNN.com.
This is proof that the modifications to Tinyproxy allow it to detect the presence of an active Internet
connection and cache a user’s HTTP request in the even there is not a connection to the Internet.
The only criteria left to test are that the serial interface is capable of initiating a turn on
signal by outputting a voltage on pin 4 of a serial cable. To do this a HTTP request is made with
Firefox. As a result of the sendSig()function being called regardless of how the script is
executed, there is no need to unplug the Ethernet cable. The following images are a time laps over
about 3 seconds showing an LED on pin 4 tuning on for one second and then off again. This is a
result of the sendSig()function executing.
Figure T.11: Time lapse of serial terminal.
In the first image, the LED is off just before the request is sent out. In the second page
HTTP requests are being sent out and the LED is on. In the last image the LED is off after all
HTTP requests have been sent. The page has loaded.
46
The voltage outputted by the serial interface is then used as an input for the Transmitter.
With this final test it can be concluded the modified Tinyproxy application works as expected.
WiFi Repeater To test the WiFi repeater it had to be shown that a device can connect to a network device
outside of its subnet. The router had an IP address of 192.168.2.1. The repeater had an IP address of
10.0.0.1. An Ubuntu 9.10 laptop was connected to the repeater via WLAN, as see below:
Figure T.12: Screenshot of joe-laptop.
The labtop’s name is joe-laptop and it has an IP address of 10.0.148. This is confirmed
locally on the computer via terminal with the command ipconfig wlan0. In Firefox the
computer joe-laptop is connected to the repeater’s HTTP server. At this screen the repeater is
showing its current status. There are two pieces of useful information. It shows the DHCP clients
the repeater is acting as a router for. In this list is joe-laptop with an IP address of 10.0.0.148. When
this is compared to the information collected locally it confirms the computer is connected
wirelessly to the repeater.
47
The other useful piece of information is the WAN or Wide Area Network IP. This assigned
by the router who’s Internet connection is being repeated. In the image above that IP address is
192.168.2.88. From the same computer we can attempt to connect to that router via Firefox. Upon
completion of this request it is proven the computer can get to a networked device outside of the
subnet it is in. As shown by terminal, the computer joe-laptop still has an IP address of 10.0.0.148.
Figure T.13: Screenshot of router acting as a DHCP host.
The image above also shows the router is acting as a DHCP host for one device with an IP
address of 192.168.2.88. This is the same IP address of the repeater, confirming that repeater is
paired with the router and configured correctly.
48
Summary
Our project was an overall success. We started with an idea of how to implement “Connect-
on-Demand” Internet to the various schools of Tanzania, and walked away with working project
that we are very proud of. The concepts that we thought of made their way through the end of the
project to the final product, though their implementation was not built as exactly as they were
intended. As an example, we intended to have an overall bypass to bypass our system in the event
of system failure; instead, we used switches to switch the individual networking equipment from
manual to auto mode.
Due to the fast pace nature of this course, we did not have time to do as much research as we
wished. For example, as far as the radio signal is concerned, perhaps there are other unlicensed
frequencies that will not be susceptible to interference from neighboring broadcasters. Also, maybe
there is another method of signal coding other than our two-tone method. Another thing is that our
project implementation was based on a manner that heavily reflects on hardware design. Perhaps
there is an alternative approach that could use the WiFi/WiMAX routers themselves with the aid of
software design that can perform the necessary functioning.
Once we had the project scope in mind, and broke up the work to be done amongst the
various group members, the individual tasks were easily accomplished. Some tasks were finished
well ahead of time, that other members could help each other on their specific tasks, making the
overall design process more efficient. We successfully tested all our necessary equipment, that our
failures were brief; simply debugging our circuitry. Debugging can be very tedious and
cumbersome, and this is where most of the work lies; correcting human error.
There were slight deviations from our proposed Gantt chart for certain areas of the project.
As stated before, the quick finish of other areas of the project led to the ability to help other
members of the group with their work. Thus, even though some things were not finished when
proposed, they were accomplished non-the-less.
Due to the nature of our project, we did not have a set budget; we were able to purchase and
test equipment at our leisure, though we did so in a disciplined manner as best we could. As a
matter of fact, our total costs are comparable to groups that did have a set budget. Not only did we
accomplish our project scope, we did so efficiently in terms of both time and money. Our project
final costs totaled $3.003.95.
49
The first couple of weeks of the semester, we setup the routine of our group, including
meetings with each other as well as with our facilitator. Also during that time, we came up the
method of implementing our project; design and construction. During the time leading up to Spring
Break, we broke up the work to the individual group members, which led us to start asking
questions of our individual components, and how to interface them with the other components.
During the week of Spring Break, most of us stayed to work on the project. We made a lot of
progress during this time. The tone generators as well as the decoder prototype were built. The
radio receivers and transmitters were received the following week. We then began testing and
debugging the overall radio signal over the course of the next few weeks; fine-tuning the audio tone
generators, the decoder, and experimenting with different antenna configurations. Once we knew
exactly how we wanted to implement the radio transmission system, we began finalizing and
ordering the necessary parts. During the same few weeks after Spring Break, Joe Larsen was
successful at his software of locally caching the TCP packets. Around the eleventh week of school,
he also successfully found a way for the computer to send a signal to the radio transmitters when an
Internet request is made. Knowing that we were making very good progress, our team’s spirits
were raised, and work continued at an accelerated rate. We ordered all the necessary parts for the
outlet box and had it constructed within the last few weeks of the semester. Rodney Singleton made
the finishing touches on his microcontroller, and tested it with the actual hardware. There were
some issues, but he successfully debugged them and was able to make the microcontroller function
exactly how we needed it. We also determined all the miscellaneous materials we will need in
Tanzania and made all the final purchasing within the last couple of weeks of the semester. At this
point, all components are functioning and enclosed in their respective enclosures, and interface well
with another.
We have successfully accomplished the task set before us in the beginning of January 2010.
We started with an idea of what we wanted, and came away with a design that works and performs
all the necessary functions.
50
Appendix 1
Luis Garcia
Luis Garcia was the lab facilitator for the team. Luis’ main undertaking was to determine
how every component of the design was going to be powered. He had to make sure how much
power he actually had available to him. This turned out to be a harder task than anticipated, since
this is an ongoing project in Tanzania and he had to rely on pass groups designs. Once Luis had the
parameters he needed, he started designing the power supplies for the final design. Luis had to work
very closely with Rodney and Eric to determine how much power they will need to power the
components of their own individual designs. Luis had to make sure none of the components of the
final design will burn out and also maximize the life cycle of the design that will be implemented in
Tanzania. Luis also worked very closely with Eric with the design of the relays. Luis worked with
Eric on the different types of relays that were chosen for the final design which includes: the relays
that will switch the networking equipment by taking the 5 Volt signal from the microcontroller and
amplifying the amperage via a transistor and this will switch the 12 Volt relay (the relays need
approximately 400mA). Another type of relay that Luis and Eric had to research was the relay that
will send power to the receiver and decoder at Baraka; and the intent of this is to shut off the
receiver and decoder in order to preserve power during night hours (the same transistor amplifier
scheme will also be used for these set of relays). The third type of relay that Luis worked on had to
power up the transmitter at Manyara and Rift Valley when an Internet request is made (This too
uses the transistor amplifier method).
51
Eric Hatch
Early on in the semester, I worked with Joe to understand the entire project. I came up with
several solutions for the group to decide upon.
My main responsibility was to create the 433 MHz remote control link. Early on, I
researched possible radio links. The original idea was to build a simple AM radio to operate at the
frequency that walkie-talkies operate on. This idea was changed when I found commercially
available radios that operate on 433MHz. I also researched short range monopole antennas and
amplifiers to increase our range. Mike took over from there and worked with high gain antennas.
The main part of the remote control that I worked on was the hardware tone decoder. I
designed the decoder, tested it, and moved it to a PC. I worked with Mike extensively to make sure
the decoder was compatible with the tone generators. Once the remote control was working for a
short range, Mike and I decided how to transmit the signal the necessary distances. We tested
several combinations.
When this was completed, I worked with Luis to figure out the power requirements and
decide how to switch the outlets. Mike and I built and wired the final outlet box. Throughout the
semester, I also worked with everyone on the team aiding in designing and implementing several
components of the overall system. I also worked to make sure the whole system worked together as
planned.
52
Joe Larsen
My technical role for this project was to create a solution that identified user HTTP requests,
catch those requests if their was no Internet connection, and initialize a turn on signal. To do this I
created a proof of concept packet sniffer that would constantly look for user requests in python.
While it worked, it was unstable and on many occasions froze and crashed the system it was
running on. As a result Tinyproxy was modified using a combination of Python and C. I was also
responsible for creating the serial interface Tinyproxy used to initiate a turn on signal. I then tested
this to ensure Tinyproxy worked as expected through examining log outputs and altering the
computer's access to the Internet. I also worked with my team members to ensure the output
produced on the serial connection would be adequate as an input for the transmitter.
The modification of Tinyproxy was my primary technical contribution to the team. In
addition to that software modification I was also responsible for acquiring and testing the WiMAX
antennas to be used in Tanzania to create a wireless link between Baraka and Rift Valley. The
WiMAX antennas had to operate on the unlicensed spectrum, transmit a minimum of 5 miles, and
achieve a throughput of at least 5 Mbps. The devices I bought had a maximum range of 25 miles
under ideal conditions, used the 5.8 GHz ISM band, and have a maximum throughput of 35 Mbps.
To test them I set up private subnet with a computer acting as a DHCP server with an IP address of
192.168.2.1. I then configured the antennas to have different IP addresses on the same subnet as the
computer and sent network requests between all devices.
Finally, I was responsible for configuring a router to act as a repeater. This will be used to
create a small wireless hop between a boy's dorm and the computer room at Rift Valley. To do this I
flashed a Linksys WRT54GT router with the open source firmware dd-wrt. A virtual interface was
then configured. This allowed the repeater to act as a wireless client of another router. The physical
interfaces then act as access points for which the repeater acts as a DHCP server. To test this I set
up the receiver to connect to a router via WiFi. That router was in turn connected to the Internet. I
then connected my laptop to the repeater and proceeded to work for a day using the repeater. This
consisted of casual web browsing to transferring large PDF's to FTP servers.
53
Michael Moulton
My technical role was in the development of the audio tones. My original pursuit to develop
these tones was to use some sort of software to make these tones which would be outputted to the
FM radio transmitters. However, an easier approach was to use hardware to develop these tones.
Looking back over previous course notes, I found what were called phase-shift oscillators that
produced sinusoids of a given signal without any external input. Once I found the schematic and
theory of how to build these things, the actual building of them was fairly easy. It was thought that
this would be a major task, so it would take some time. I then had more time to apply myself to
other aspects of the project.
Another responsibility of mine included helping Eric with the radio transmission itself.
With the help of the ECE technicians, they informed us that the best way of transmission long
distances is with the use of high-gain antennas, rather than amplification of the audio signal.
Browsing on the Internet, I discovered a “Qwagi” (square Yagi) antenna for the 433 MHz
frequency. I was able to build these with accessible materials, which enabled us to test the radio
transmission. It was this testing that led us to the conclusion of using standard high-gain Yagi
antennas for the radio link. I also did the research and ordering for the coaxial cables used between
the transmitters/receiver and the antennas.
Also, I put together the backbone of the main circuit box encompassing the decoder,
microcontroller, relays, timer, and sockets for the networking equipment at Baraka. It required
some welding and organization of the individual components to be placed in the box.
Finally, I helped in odds-and-ends of deciding what connections to use between
components, building these connections, testing of the various components, as well as helping to
build the housings of the various circuit components.
54
Rafael Ocampo
I was in charge of conjuring a method for an external triggering mechanism in which to
power-up and power-down the overall system when needed. The evolution of this process has had
many revisions. I ordered two DS1305 programmable timers. The initial idea was to program the
microcontroller; however the schematic to interface the DS1305 programmable timer used a
PIC16F628 and it required a type of user defined assembly code. After realizing that I essentially
needed an alarm clock, I used my own alarm clock to figure out how to use it as a triggering
mechanism by sending pulses to a microcontroller. This was more beneficial, hence it could be a
user-friendly programmable timer. I concluded that by removing the speaker for the alarm, then the
wires from the speaker could send a pulse to the microcontroller and trigger a “shut off” reaction for
the Internet system. The fallback; it was only a one-event timer and there needed to be an alarm
event in the morning to turn the system back on.
After realizing that the alarm clock procedure was not going to work, I looked online for a
commercial external timer that would trigger more than one event. I chose the Flextimer 8-Event
Programmable Timer. The timer performs efficiently and is able to satisfy the conditions for
curfews. I was successfully able to trigger a system on and off.
55
Rodney Singleton
My technical role in this project was to write the code for the processing unit of our design,
or the microcontroller. The microcontroller was used to centralize all of the Internet requests in
order to process them and direct the corresponding links to power on and/or off. It was also used to
read the battery voltage from the solar-powered units in Baraka to determine if the voltage was
dropping below the desired threshold. One of the main functions of the microcontroller was to
conserve battery life, given the instantaneous characteristics of the system use. With this task given
to me, I commenced to outlining all the inputs and outputs that the microcontroller would need to
complete this task. In order to handle the requests for Internet usage, I allowed three I/O ports to be
reserved for Baraka, Manyara, or Rift Valley Internet requests. Given an input, I created a
countdown timer in order to shut down whatever link was not in use after a certain period of time.
I also used the Analog-to digital function to convert a continuous voltage signal into a
discrete signal, which I used in order to run the programming in between the desired voltage
constraints. Since the microcontroller can only handle up to 6 volts, I used a voltage divider to map
the battery to a 0-5 volt scale. Furthermore, I reserved one I/O port for an external clock which was
used to shut the system down while the sun isn’t available to charge the batteries. For the outputs, I
reserved 5 I/O ports to serve as pulses for relays to the WiFi, WiMAX, satellite, and decoder/FM
receiver. In my code, I created a pulse which trips the relays to turn on/off their respective links.
I was also responsible for the testing and soldering of the entire circuit dedicated to the
microcontroller. This included the external clock, the microcontroller, and the relays. Using LEDs,
I was able to see exactly what the microcontroller was doing, and how it was handling all the
various inputs. The microcontroller dealt with each individual request correctly, and the pulses
generated tripped their respective relays causing an LED to light up, declaring that part of the
system “on.” Overall, the microcontroller treated each individual input almost completely separate,
and shuts down items that either are not in use, or in threat of damaging the battery.
56
Appendix II
References http://datasheets.maxim-ic.com/en/ds/DS1305.pdf
http://www.flexcharge.com/flexcharge_usa/products/programable_timer/programable_timer.htm
http://www.renewcanada.com/images/flexcharge%20timer%20manual.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/39631a.pdf
http://www.maxim-ic.com/app-notes/index.mvp/id/2361
https://www.banu.com/tinyproxy/
http://en.wikipedia.org/wiki/Proxy_server
http://ubuntuforums.org/showthread.php?t=1047150&page3 -
http://www.linuxquestions.org/questions/programming-9/using-grep-awk-get-ip-address-627626/
http://docs.python.org/library/time.html
http://diveintopython.org/scripts_and_streams/stdin_stdout_stderr.html
http://docs.python.org/library/commands.html
http://pyserial.sourceforge.net/
http://www.dd-wrt.com/wiki/index.php/Universal_Wireless_Repeater
http://www.ligowave.com/sites/default/files/LigoPTP%205-23_5-Npv_0.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/39631a.pdf
http://ww1.microchip.com/downloads/en/devicedoc/MPLAB_C18_Libraries_51297f.pdf
http://ww1.microchip.com/downloads/en/devicedoc/MPLAB_C18_Users_Guide_51288j.pdf
G. M. Wierzba, ECE 302 e-Notes. August 2008
G. M. Wierzba, ECE 303 e-Notes. August 2008
G. M. Wierzba, ECE 402 e-Notes. August 2009
http://www.datasheetcatalog.org/datasheet/nec/EC2-3TNJ.pdf
http://datasheet.octopart.com/RT314F12-Tyco-Electronics-datasheet-526658.pdf
57
Appendix III
Detailed Technical Attachments
Circuit Schematics
-
+
5
+
-
5
2.5
5
2.5
+
-
5
2.5
5
2.5
+
-
5
2.5
5
2.5
+
-
5
2.5
5
2.5
5
5
5
2.5
U1a
-
+U2b
-
+U2c
-
+U3b
-
+U3c
U2a
U2d
U3a
U3d
U3a
U3b
234Hz
270k
1.5k
0.022µ
680k0.022µ
2.5
2.5
2.5
2.5
560k
1.8k
0.002µ
1.5M
220k
1.2k
0.05µ
560k0.05µ
1M
1k
0.001µ
2.2M0.001µ
0.002µ
1N4148
0.1µ 1M
1k
1N4148
0.1µ 1M
1k
1N4148
0.1µ 1M
1k
1N4148
0.1µ 1M
1k
2.24kHz
123Hz
1.31kHz
To microcotnroller “Manyara input”
To microcotnroller “Rift Valley input”
1k
1k1µ
U1: LM324NU2: LM324NU3: LM324NU4: 74LS08NRelay: RT314F12
5
-
+U1c
1k
2.5
yellow
1k
green
1k
5
12
LM7508AR1
5
from microcontroller: ON
12
R1-close
from microcontroller: OFF
12
R1-open1N4148
1N4148
TIP31A
TIP31A
RF SolutionsRRFQ2
1 2 16 17 18
Audio Cable
151413
5VDCDATA
GND
GN
D
12V
DC
IN
5VD
C O
UT
SIG
NA
L O
UT
Man
yara
Out
Rift
Val
ley
Out
Terminal Block
Decoder (Baraka)
58
PIC
18F4
520
MX
045H
S
Microcontroller (Baraka)
59
LGN G L N
30ACB
L NG
L NG
L NG
L NG
R1 R2 R3 R4
S1 S2 S3 S4
Tone Decoder Micro-Controller
5Vsignal
DC ground
to FM receiver
from Baraka Computer
9-pin D4 - signal
5 - DC ground
onoff
Tone Decoder
Relay
switched 12VDC
Battery12Vground
R1 R2 R3 R4
Notes:R1: Satellite Router and Satellite AntennaR2: No longer usedR3: Rift Valley Secondary SchoolR4: Manyara Secondary School9 PIN D connector is female
AC Circuit
DC Circuit
Timer
Outlet Box (Baraka)
60
Tinyproxy
Computer
UPS(240 VAC)
Wireless Router
Tone Producer
FM Radio Transmitter
24VDC Power Supply
POEAdapter
UPS(240 VAC)
Wireless Repeater
WiMAX Antenna
24VDC Power Supply
FM Radio Receiver
FM Radio Transmitter
UPS(240 VAC)
24VDC Power Supply
Tinyproxy
Tone Producer
POEAdapter
WiFi Antenna
FM Radio Transmitter
24VDC Photovoltaic
System
12VDC Photovoltaic
System
Tinyproxy
120VAC Inverter
FM Radio Receiver
Microcontroller
240VAC Inverter
Tone Decoder
Outlet Box
POE Adapter
WiFi Antenna
POE Adapter
WiMAX Antenna
Satellite Router
Satellite Antenna
Computer
Computer
To Baraka To Baraka
To Baraka To Baraka
From ManyaraFrom Rift Valley
From Rift Valley From Manyara
Baraka
Rift Valley Manyara
PowerDataRemote ControlWireless DataWireless Remote Control
Overall Schematic in Tanzania
61
5
2.5
2.2k
2.2k1µ
U1: LM324NRelay: EC2-5NJ
24
LM7508AR1
5
from computer
24
R11N4148
TIP31A
+
-
5
2.5
U1b
0.022µ
2.5 2.5
68k
2.2k 2.2k
2.2k
0.022µ 0.022µ
+
-
5
2.5
U1c
0.05µ
2.5 2.5
330k
10k 10k
10k
0.05µ 0.05µ
+
-
5
2.5
U1d
10k
10k
5.6k
5
2.5
-
+U1a
1k
5
9-pin Dpin 4
pin 5
370
600 (3 - 1.8k in parallel)
RF SolutionsRTFQ2
1 2 3 4 5
5VDATA
GND
Audio Cable
Manyara
2.24kHz
234Hz
Tone Generator (Manyara)
62
5
2.5
2.2k
2.2k1µ
U1: LM324NRelay: EC2-5NJ
24
LM7508AR1
5
from computer
24
R11N4148
TIP31A
+
-
5
2.5
U1b
0.01µ
2.5 2.5
82k
2.7k 2.7k
2.7k
0.01µ 0.01µ
+
-
5
2.5
U1c
0.1µ
2.5 2.5
82k
2.7k 2.7k
2.7k
0.1µ 0.1µ
+
-
5
2.5
U1d
10k
10k
5.6k
5
2.5
-
+U1a
1k
5
9-pin Dpin 4
pin 5
370
600 (3 - 1.8k in parallel)
RF SolutionsRTFQ2
1 2 3 4 5
5VDATA
GND
Audio Cable
Rift Valley
1.31kHz
123Hz
Tone Generator (Rift Valley)
63
PIC18F4520 Code #include <p18cxxx.h> #include <ADC.h> #pragma config WDT=OFF //Initialization of parameters long int count, count2, bcd,rcd,mcd, bflag, rflag, mflag, mflash, rflash, bflash, mto, rto, saton, curfew, decrec, reboot;//countdown=1800, count=250000 int adc_result, loop; void main() TRISD = 0xF0; TRISC = 0x00; OpenADC(ADC_FOSC_32 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 & ADC_INT_OFF, 0); //open adc port for reading ADCON1 =0x10; //set VREF+ to CH3 and VREF- to GND (VSS) //First case is annotated to show what each line of code does //All other cases follow the same logic with few deviation while(1) //**********While no requests are being made. Turns on the decoder if the reboot flag is set**********// while (PORTDbits.RD6==0 & PORTDbits.RD5==0 & PORTDbits.RD4==0) PORTCbits.RC6 = 0; PORTCbits.RC7 = 0; if (reboot==1) PORTCbits.RC7 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC7 = 0; decrec=0; reboot=0; PORTCbits.RC5 = 0; PORTCbits.RC4 = 0; PORTDbits.RD3 = 0; //Case 1: Only Baraka makes a request //Baraka Request if(PORTDbits.RD6==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD6==1) bflash=1;
64
//Pulse code if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; bcd=50; //Starts countdown while(bcd>0) bflash=1; decrec=1; //Battery Check SetChanADC(ADC_CH0); ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result if (PORTDbits.RD7==0) curfew=1; //Interrupt runs as long as battery is lower than 13.5 Volts or curfew flag is set for 11pm while(adc_result<0x03DC || curfew==1) bcd=0; //Shuts down components that are on at the time if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; if (decrec==1) PORTCbits.RC6 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC6 = 0; decrec=0; reboot=1; bflash=0; //Continues to check battery SetChanADC(ADC_CH0);
65
ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result //if battery voltage is still lower than desired, sets the reading to 0 to keep it in the loop if(adc_result<0x03F2) adc_result=0x00; //If daytime signal is given, takes the program out of the loop if (PORTDbits.RD7==1) curfew=0; //Timeout Programming for(count = 1; count < 250000; count++); bcd--; //When another Baraka request is made, it resets the timer if(PORTDbits.RD6==1) //safety check to make sure it’s an actual request coming in and not just noise for (count = 1; count < 300000; count++); if(PORTDbits.RD6==1) bcd=50; //Manyara request during Baraka countdown. Breaks program if(PORTDbits.RD5==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD5==1) mflag=1; break; //Rift Valley request during Baraka countdown. Breaks program if(PORTDbits.RD4==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD4==1) rflag=1; break; //Red light flash for timeout if(bcd==0) if (bflash==1) PORTCbits.RC5 = 1;
66
for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; if(PORTDbits.RD6==1) bcd=50; //**********Individual Manyara Request**********// if(PORTDbits.RD5==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD5==1) saton=1; mflag=1; //**********Individual Rift Valley Request**********// if(PORTDbits.RD4==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD4==1) saton=1; rflag=1; rto=1; //**********Case 2: Rflag bit is set. When the last request made is from Rift Valley**********// if (rflag==1) //Turns on satellite if it isn't already on if (saton==1) if (bflash==0) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; saton=0; //turns on WiMAX if it isn't already on if (rto==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0;
67
rto=0; bcd=50; rcd=50; rflag=0; //Runs countdown based off satellite while(bcd>0) bflash=1; decrec=1; //Battery Check SetChanADC(ADC_CH0); ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result if (PORTDbits.RD7==0) curfew=1; //Program halt while(adc_result<0x03DC || curfew==1) bcd=0; mcd=0; rcd=0; //Shuts down everything that is in use if (mflash==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0; mflash=0; if (rflash==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rflash=0; if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; if (decrec==1)
68
PORTCbits.RC6 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC6 = 0; decrec=0; reboot=1; SetChanADC(ADC_CH0); ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result if(adc_result<0x03F2) adc_result=0x00; if (PORTDbits.RD7==1) curfew=0; //Timeout Programming for(count = 1; count < 40000; count++); if (rcd>0) rflash=1; rcd--; if (mcd>0) mflash=1; mcd--; bcd--; //Checks for new requests and resets respective timers. Also turns on what needs to be used if(PORTDbits.RD6==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD6==1) bcd=50; if(PORTDbits.RD4==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD4==1) if (rto==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rto=0; rcd=50;
69
bcd=50; if(PORTDbits.RD5==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD5==1) if (mto==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0; mto=0; bcd=50; mcd=50; //Red light pulse for timeout works individually if(rcd==0) if (rflash==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rflash=0; rto=1; if(PORTDbits.RD4==1) bcd=50; rcd=50; if(mcd==0) if (mflash==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0; mflash=0; mto=1; if(PORTDbits.RD5==1) bcd=50; mcd=50; if(bcd==0)
70
if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; mflag=0; rflag=0; //**********Case 3: Rflag bit is set. When the last request made is from Manyara. Follows the same protocol as RFlag**********// if (mflag==1) if (saton==1) if (bflash==0) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; saton=0; bcd=50; mcd=50; mflag=0; while(bcd>0) bflash=1; decrec=1; //Battery Check SetChanADC(ADC_CH0); ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result if (PORTDbits.RD7==0) curfew=1; while(adc_result<0x03DC || curfew==1) bcd=0; mcd=0; rcd=0; if (mflash==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0;
71
mflash=0; if (rflash==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rflash=0; if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; if (decrec==1) PORTCbits.RC6 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC6 = 0; decrec=0; reboot=1; SetChanADC(ADC_CH0); ConvertADC(); //perform ADC conversion while(BusyADC()); //wait for result adc_result = ReadADC(); //get ADC result if(adc_result<0x03F2) adc_result=0x00; if (PORTDbits.RD7==1) curfew=0; //Timeout Programming for(count = 1; count < 40000; count++); if (rcd>0) rflash=1; rcd--; if (mcd>0) mflash=1; mcd--; bcd--; if(PORTDbits.RD6==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD6==1) bcd=50;
72
if(PORTDbits.RD4==1) for (count = 1; count < 300000; count++); if(PORTDbits.RD4==1) if (rto==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rto=0; rcd=50; bcd=50; if(PORTDbits.RD5==1) for (count = 1; count < 300000; count++); if (PORTDbits.RD5==1) if (mto==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0; mto=0; bcd=50; mcd=50; //Red light for timeout if(rcd==0) if (rflash==1) PORTCbits.RC4 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC4 = 0; rflash=0; rto=1; if(PORTDbits.RD4==1) bcd=50; rcd=50; if(mcd==0)
73
if (mflash==1) PORTDbits.RD3 = 1; for (count = 1; count < 300000; count++); PORTDbits.RD3 = 0; mflash=0; mto=1; if(PORTDbits.RD5==1) bcd=50; mcd=50; if(bcd==0) if (bflash==1) PORTCbits.RC5 = 1; for (count = 1; count < 300000; count++); PORTCbits.RC5 = 0; bflash=0; mflag=0; rflag=0;
74
The following code was added to the file reqc.c located in the tinyproxy root/src
directory. The function that was edited is handle_connection(). This code was placed at the
beginning of the function.
void handle_connection (int fd) int res; /* This is in the original Tinyproxy Source Code */ ssize_t i; struct conn_s *connptr; struct request_s *request = NULL; hashmap_t hashofheaders = NULL; char sock_ipaddr[IP_LENGTH]; char peer_ipaddr[IP_LENGTH]; char peer_string[HOSTNAME_LENGTH]; /*End of original source code */ /* code added for ECE project */ log_message (LOG_CONN, "Beginning IP test"); / res = system ("/home/ece480/test/test.py");
/*Call being made to python script */ if (res == 0)
log_message (LOG_CONN, "Connection Confirmed");
log_message (LOG_CONN, "Error Running Python Script"); else log_message (LOG_CONN, "Error Running Python Script"); /* End of modifications to Tiny proxy */
75
Python Script Source Code #! /usr/bin/python import sys import time import subprocess import serial saveout=sys.stdout fsock=open("/usr/local/var/log/python.log","a") def getIP(): # This function checks to see if the Internet is accessible via a # a ping. It pings Google, yahoo, and bib. Upon one of these being # successful the function returns True. If none of they are # reachable the function returns False domains = ["google.com", "yahoo.com", "bbc.com"] for domain in domains: ret = subprocess.call("ping -c 1 %s" % domain, shell=True) if ret==0: return True else: return False def exiting(): # This is a function that is used to clean up all loose ends when # ending this script. This includes, writing the exit to the log # redirecting stdout back to the terminal (or where ever it has to # go and closing the log file. print "%s CLOSING" % time.strftime("%Y-%m-%d %H:%M:%S") sys.stdout=saveout fsock.close sys.exit(0) def sendSig():
# This function is where a call will be made to send a turn on signal # to Baraka from the satellite school (At time of writing this Rift Valley # and Manyara Secondary) # All this does is open a serial connection for 1 second and then closes it.
# this allows a signal to be sent to the transmitter. print "%s STATUS Sending turn on single" \
76
% time.strftime("%Y-%m-%d %H:%M:%S") s=serial.Serial(0) time.sleep(1) s.close() def main():
# This is a where almost everything happens, like all good programs this is # rather short and should be easy to follow. All that is happening here # is there is a loop that is started which looks for the and active
Internet # connection. # If it is detected the loop breaks and the program exits. # If the is no Internet connection valid then a turn on signal is sent # and the loop continues until an active connection is detected.
sys.stdout=fsock print "%s STARTING Entering main loop." \ % (time.strftime("%Y-%m-%d %H:%M:%S")) count=0 while True: n=getIP() if n==True: print "%s STATUS Internet Connection Confirmed" \ % time.strftime("%Y-%m-%d %H:%M:%S") sendSig() exiting() break else: sendSig()
print "%s STATUS Connection invalid, sending Turn on signal" \ % (time.strftime("%Y-%m-%d %H:%M:%S")) count+=1 print "%s STATUS turn on signal has been sent %d times" \ % (time.strftime("%Y-%m-%d %H:%M:%S"), count) time.sleep(5) main()
77
Gantt Chart (Screenshots go in order from top-left to bottom-right)
Gantt Chart Screenshot 1
78
Gantt Chart Screenshot 1
79
Gantt Chart Screenshot 2
80
Gantt Chart Screenshot 3
81
Gantt Chart Screenshot 4
82
Gantt Chart Screenshot 5
