florida university satellite...

Florida Gulf Coast University FUNSAT Project

DDR Executive Summary

The FUNSAT competition offers universities an opportunity to show their student’s

talents and the school’s facilities. Our team’s background in Computer Science leads us

toward a software related project to be showcased through a basic hardware

implementation within to the spirit of the competition.

One of the most important issues in satellite communication is the telemetry. With a

limited budget and hardware/facilities how can the telemetry signal be delivered? Our

implementation of telemetry transmissions will utilize a magnetic sensor to collect data and

exhibit scientific merit. This will let us have the platform to develop telemetry software and

prove the system to be productive and beneficial.

The measurements will be taken by a magnetic sensor and passed to the controller

software for pre-processing and packaging. The controller will send data to the telemetry

module which will then communicate with the ground support equipment. The

investigation of amplification antennas will study how one can extend the range of

telemetry communications. The telemetry data must then be decoded to be used by the

ground software.

The current plan of basic implementation includes : the hardware platform based on EBox

2300 embedded computer equipped with Windows CE Embedded and software

implementation of a telemetry package in C#. The team is expecting to overcome the

challenges and develop a fully functioning system to demonstrate the software’s features at

the finals.

FGCU- 2

List of Figures and Tables

Figure 2.1 FOCSS Context Diagram

Table 2.2 Mil-Std 1553 Command Word

Figure 2.3 Client Flow Chart

Figure 2.4 Satellite Interface Diagram

Figure 2.5 Server Flowchart

Figure 2.6 Sample server UI showing received data and client status

Figure 2.7 Telemetry/Communication Relationship (part from figure 2.4)

Figure 2.9 . Telemetry systems overview [3].

Figure 2.10 Active Robots RF Telemetry Module[4].

Figure 2.11 Radio Transmission Example

Figure 2.12: Structure of the entire Space Packet.

Figure 2.13: Structure of the Space Packet header.

Figure 2.16 Power supply design

Figure 2.15 Schematic of Lithium Ion cell[8].

Figure2.17 System specification and main board design of EBox-2300[2].

Figure 2.18 Driver OS Interaction

Figure 2.19 – Half Wave center fed dipole pattern[14].

Figure 2.20 – A conceptual diagram of a yagi antenna.[13]

Figure 2.21 – Yagi antenna azimuth (horizontal) and elevation (vertical) radiation patterns of a yagi

antenna. [15]

Figure 2.22 unidirectional antenna[see Appendix F]

Figure 2.23 Telemetry Range

Figure 2.24 The Hall Effect[10]

Table 2.25 FGCU Funsat Expenditures 2009-2010

FGCU- 3

FLORIDA GULF COAST UNIVERSITY

Florida University Satellite Project

FOCSS Detailed Design Report

Team Leader : Jaime Zabala

Team Members : Tim Bennett, Bradd Konert, Michael Lekon

Team Mentor : Janusz Zalewski

4/21/2010

FGCU- 4

Contents

1. Introduction ................................................................................................................................. 6

2. Detailed Problem Solution .......................................................................................................... 7

2.1 Software - FGCU Orbiting Client-Server Software.............................................................. 9

2.1.1 Client Requirements and Description .......................................................................... 10

2.1.2 Server Requirements and Description ......................................................................... 13

2.2 Communication Format Solution ........................................................................................ 16

2.3 Power Supply Implementation ............................................................................................ 21

2.3.1 Solar Power .................................................................................................................. 21

2.4 Client Implementation of the EBox Controller ................................................................... 24

2.4.3 Setting up USBs, Writing and Loading Driver - ....................................................... 25

2.4.6 Hyper Terminal ............................................................................................................ 27

2.5 Hardware implementation of 900 MHz Yagi Antenna System ........................................... 29

2.5.1 Antenna Design ............................................................................................................ 32

2.5.2 Modified Yagi Implementation .................................................................................... 36

2.5.3 Results of Antenna Implementation ............................................................................. 38

2.6 Magnetic Sensor.................................................................................................................. 39

3. Finances and Budgets ............................................................................................................... 41

4. Schedule for Implementation and Team MakeUp .................................................................... 43

4.1 Current Schedule Extended................................................................................................. 43

4.2 Current Team Make-Up ...................................................................................................... 46

5. Conclusion ................................................................................................................................ 47

6. References ................................................................................................................................. 49

Appendix A Hardware Overview .................................................................................................. 51

A1. Introduction ........................................................................................................................ 51

A1.1 Definitions .................................................................................................................... 51

A2.1 USB RF Telemetry Module ......................................................................................... 52

A2.2 Phidget Magnetic Sensor (30.5mm x 30.5mm) ........................................................... 53

A2.3 Phidget Microcontroller (83.06 mm x 53.34 mm) ....................................................... 54

FGCU- 5

A2.4 EBox 2300 (115 x 115 x 35 mm / 505g ) ..................................................................... 55

Appendix B Telemetry Communication System .......................................................................... 57

B1 Telemetry Communication Concept applied to a Surveillance Magnetic Field System ..... 58

B1.1 Server Application ........................................................................................................ 58

B1.2Client Application ......................................................................................................... 60

B2 System Implementation ....................................................................................................... 63

B2.1 Software Installation .................................................................................................... 63

B3 Hardware Connectivity ....................................................................................................... 65

Appendix C Power System Design ............................................................................................... 67

C1 Power System Background ............................................................................................... 67

C2 Overview ............................................................................................................................. 67

C3 FGCU FUNSAT Power Supply Components ..................................................................... 69

Appendix C Reference .............................................................................................................. 72

Appendix D FOCSS Code ............................................................................................................ 73

Appendix E Antenna Instructions ................................................................................................. 77

Appendix F EBox USB Driver ..................................................................................................... 80

FGCU- 6

1. Introduction

The Florida University Satellite (FUNSAT) project is a competition among universities in

the state of Florida to design and construct a pico-satellite (10cm x 10cm x 10cm) with a weight

not to exceed 1 kg. The purpose of this document is to add detail to the original Concept Design

Report and lay out a clear plan for implementation. The plan laid out in the CDR is designed

around as much “off the shelf” product as possible to minimize cost, time, and to make up for

missing disciplines in our team. These components would then be incorporated together with

software designed to integrate the system. While construction of the satellite is not feasible

given the resources that Florida Gulf Coast University can bring to bear on this project, it is the

hope of the project participants to leverage the software development strengths of our

members and then incorporate the commercial systems that can be obtained to develop a

viable proof of concept. While the use of commercially available products is limiting, the use of

the hardware in the final implementation of this competition will be used as a means to

showcase the control software. With this proof of concept, FGCU plans to continue further

development of the satellite as it presents a unique learning experience for current and future

students of the university. Regardless of the outcome of the FUNSAT competition, work on the

satellite and its related technologies will serve to excite and motivate FGCU students in the

study of aerospace and low earth orbit technologies.

FGCU- 7

2. Detailed Problem Solution The problem solution as proposed in this section encompasses all aspects for a full

development of our “proof of concept” satellite.

Management of all subsystems could theoretically be implemented solely in the hardware, but

financial and technical constraints make this unreasonable. However, engineering software to

handle these tasks presents its own set of challenge. This software must:

• receive and interpret data from all subsystems

• send commands to applicable subsystems such that they allow the satellite to perform

its overall function whenever possible

• complete its computations as efficiently as the available resources will allow

• have a memory footprint small enough such that additional memory may be allocated

as needed

• not leak any resources such as memory

• handle all conceivable errors in such a way that recovery can be done in a timely

manner without any outside intervention

While the design of any artificial satellite is an impressive feat of engineering requiring the

expertise of multiple disciplines, adhering to the requirements of the picosatellite classification

generates an extra level of challenge. With a total volume no larger than 1000 cm3 and a mass

no greater than 1 kg, all components of a picosatellite must be miniaturized and optimized to

the limit of current technology and financial resources.

FGCU- 8

Figure 2.1 FOCSS Context Diagram

Figure 2.1 shows the interaction between the development sections. Since our

implementation ultimately serves as the showcasing tool for our software, the packeting of data

will be the most important task of the solution. Of the telemetry/communication process, the

actual construction of the packets from raw data will be the concentration since the actual

connection and bit transfer is taken care of by the modules. Moreover, the design follows

Military Standard 1553B which is designed for use with military avionics. This standard is

commonly used in spacecraft data handling subsystems. This standard utilizes a command word

to begin every transmission and receipt of data following table 2.2.

FGCU- 9

Remote Terminal address Receive or Transmit Location of data Num of words to expect

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Table 2.2 Mil-Std 1553 Command Word

.

2.1 Software - FGCU Orbiting Client-Server Software

The software specifications in this document describe the methods for controlling

maintaining, and analyzing a low-earth-orbiting microsatellite and its communications. This

software shall be based on a client/server relationship in which the satellite acts as the client

and a computer system on the ground acts as a server.

Communication is achieved by radio frequency telemetry units which allow for both

incoming and outgoing data to be received and transmitted. Transmitted data is in the form of

either sensor data from the client or commands from the server.

In order to make use of the data collected by the satellite as well as issue commands to the

satellite, communication signals must be transmitted back to Earth. This, however, requires that

the signal must travel hundreds of kilometers and pass through the near entirety of the

atmosphere. In doing this the communications must:

• perform reliably, losing data very infrequently at best

• consume only enough power such that the communication reaches its target

• provide some level of redundancy, error checking, and/or acknowledgement responses

• Must be controlled primarily by synchronized software

FGCU- 10

2.1.1 Client Requirements and Description The client shall:

• operate in one of two states:

o Comm mode – the client is in position to transmit data.

o No-Comm mode – the client is not in position to transmit data.

• compress and store data system data and sensor data while in No-Comm mode.

• perform a cursory analysis of the data while in No-Comm mode.

• stream data while in Comm mode, beginning with the oldest data.

• monitor and control power consumption.

• manage power consumption as needed by disabling non-critical systems.

• automatically restart in event of power loss or other critical failure.

FGCU- 11

Figure 2.3 Client Flow Chart

Due to the client’s orbit around the Earth, it cannot have line of sight with the server at

all times. For a large portion of its orbit, the client will be without communications. During these

times, valuable data may be collected, but must be saved for later transmission. In addition, the

client has a limited power supply, as it will at least occasionally be in the Earth’s shadow, making

its solar collectors ineffective. This requires that available power be managed in such a way that

the client remains functional as long as possible.

FGCU- 12

Figure 2.4 Satellite Interface Diagram

The client implements two classes: Client and PacketList.

• The PacketList class is an easily expandable data structure intended to store data

collected by the client. A singly linked list is maintained with each node (representing a

single packet) containing two arrays of equal and fixed size. One array contains the

measurements taken from the magnetic sensor, while the other contains second-

resolution timestamps of each measurement.

Methods implemented by the PacketList class:

o addData(Object dataObject) – adds the given object to the newest packet, or

creates a new packet if the previous one is full.

o removeNextPacket() – deletes and returns the first node in the list.

o getNextPacket() – returns the first node in the list without modifying the list.

o getLength() – returns the number of nodes in the list.

• The Client class contains variables which represent the status of each hardware

component as well as an instance of the PacketList class to store all of the data

collected.

Methods implemented by the Client class:

FGCU- 13

o sendNextPacket() – transmits the data of the oldest PacketList element to the

server.

o main(String args[]) – initializes the client and contains the loop in which data is

collected and communication with the server is handled.

o handleCommand(String command) – takes a text-based command received from

the server and takes the appropriate action(s).

2.1.2 Server Requirements and Description The server shall:

• take user inputs.

• verify user inputs.

• send commands to the client.

• override client in the event of hazard.

• poll client software for system information.

• connect to database using OLE or an equivalent type

• read backlogged client data

• store client data to database

• perform data analysis as soon as possible after receiving new data.

FGCU- 14

Figure 2.5 Server Flowchart

The server acts as a controller and data repository for the client. Users of the server may send

commands to the client to poll its status and to override the client software’s management of

the system. While communication with the client is possible, backlogged sensor data is received

by the server. These data are then analyzed, with the results placed in a database for long-term

storage. In addition to acting as a server to the satellite client, this system will also host a web

site from which authorized internet clients may query the database of sensor data.

The server also implements two classes: Server and PacketTree

FGCU- 15

• The PacketTree class is a simple balanced binary search tree in which each node

contains sensor data and their respective timestamps as in the PacketList class. Nodes

are ordered by their first timestamp. This class is meant for relatively long-term storage

of data.

Methods implemented by the PacketTree class:

o addPacket(Packet p) – inserts the given packet into the tree and rebalances it if

needed.

o findPackets(Timestamp low, Timestamp high) – returns a list of all packets in the

tree between the two given timestamps.

• The Server class manages communications with the client, and displays a user interface

where users may send commands to the client. Other than UI-related, and the main

methods, this class does not implement any other methods.

The server program includes a simple user interface to allow commands to be manually sent to

the client, as well as to view the status of the client and content of the received packets. A

sample of such a UI is shown in Figure 3 below.

Figure 2.6 Sample server UI showing received data and client status

FGCU- 16

2.2 Communication Format Solution In order to be able to transfer data between the satellite and the ground support

computer, we will need to have reliable and predictable communication over a standardized

platform. Our solution was the use of the Active Robots USB RF Telemetry Boards in conjunction

with FOCSS to mediate the transmittal and retrieval of data. Figure 2.7 below isolates this

telemetry board/communication relationship.

Figure 2.7 Telemetry/Communication Relationship (part from figure 2.4)

Telemetry, or the measurement of systems remotely, has been in use for over 200 years.

First used by James Watt to measure internal values of steam engines, the purpose of telemetry

has changed little. Telemetry allows for remote data collection in hostile or remote locations.

The methods used for remote measurement have changed dramatically, however, especially

during World War II and subsequently with the invention of computers. Today, the uses for

telemetry are as varied as the systems used in measuring and transmitting data. Telemetry has

grown to encompass not only reading data, but using the same data channels to provide

feedback to measuring systems and exert control, know as supervisory control and data

acquisition (SCADA).

FGCU- 17

Figure 2.9 . Telemetry systems overview [3].

Of interest to the FGCU FUNSAT project is SCADA via RF transmission. Given the distances

involved in low orbit communications, the only practical means of communicating with the

project satellite is via radio waves. The fundamental RF telemetry system model comprises

seven elements (Figure 2.4.1). The seven elements handle the data collection (part a),

transmission over the medium (part b) and receipt and decoding of the data (part c).

For the purposes of this project, budgetary and fabrication constraints limit the number

of potential transmitting devices. To interface with the EBox, the RF unit needs either a USB or

IDE interface. Most modern aerospace data transmission systems rely on Pulse-Code

Modulation (PCM). PCM samples the data in intervals to encode analog signals into discrete

values, which are then transmitted in binary format. PCM systems, however, are prohibitively

FGCU- 18

costly. For these reasons, a simpler means of communication is needed. The Active Robots

RF04 - 900 USB Radio Telemetry Module provides a USB interface that draws power from the

USB as well as a hardware driver that maps the on-board 900 MHz radio transmitter as a

standard COM port with a data rate of 19200 bps (Figure 2.10). Furthermore, the RF04 is

compact, measuring 2.5cm x 4.5cm, allowing the project to remain within the FUNSAT design

constraint of 10cm x 10cm x 10cm.

Figure 2.10 Active Robots RF Telemetry Module[4].

This method of transmission is good up to 250 meters within line of sight. Obviously, for

low earth orbit communications, at distances greater than 100 miles, this system will prove

inadequate.

These particular RF boards use settings similar to serial RS-232; 19,200 baud rate, 8 data

bits, 1 stop bit, no parity and no flow control. Our software solution will handle these

connecting settings inside the code itself as constants.

int portNameIndex;

/* baud rate of the serial ports as required * by the telemetry modules */ const int baudRate = 19200; /* Thread object which is used to initiate a new * thread. used to execute the ReadThread method * independently */ Thread t; /* loops through all available port names, attempting * to open each. when a port is successfully opened, * it is assigned to the instance vairable "sp" */ public void openPort() { numPorts = SerialPort.GetPortNames().Length;

FGCU- 19

for (int i = 0; i < numPorts; i++) { try {

sp = new SerialPort(SerialPort.GetPortNames()[i], baudRate, Parity.None, 8, StopBits.One);

Since the data transferred via the RS-232 standard is independent of the environment

at either end, the language in which the software is programmed in is irrelevant. Using this

format of RS-232 also means that there is no flow control on the boards themselves, so the flow

control needs to be implemented in the software itself.

Figure 2.11 Radio Transmission Example

Figure 2.11 shows how in the command transmission sequence both “SENT” and “RECEIVED”

are displayed, but there is no “DELIVERED.”

In order to establish a connection, both the telemetry boards need to be set the exact

same settings. Finally, they must be set in an “initiate connection” status. However there is no

sign that a connection is successful without any feedback (E.g. Receipt confirmation). FOCSS on

the server side must poll data from FOCSS on the client side. FOCSS is able to send up to 128

characters at a time, starting transmission from one board to the other when a 3 character gap

has been left. It is possible to send 1 or more characters by leaving a 3 character gap.

FGCU- 20

As a capstone to the satellite’s construction, the software utilizes and manages all the

hardware to ensure the safe and proper operation of the entire system. Since the FOCSS

software has been separated into two programs: the client and the server, the client program

executes on the satellite itself, while the server program exists on a computer on the ground.

These two programs run on different hardware and require a means of communication

to transfer data collected by the client to the server. Object oriented programming languages

were chosen for both programs. Both the client and server program, however, follow the United

States Department of Defense military standard MIL-STD-1533, particularly the “Space Packet

Protocol”. This space packet is structured as in Figures 1 and 2 below.

Figure 2.32: Structure of the entire Space Packet.

Figure 4.13: Structure of the Space Packet header.

FGCU- 21

2.3 Power Supply Implementation The design laid out in the previous paper lends itself to the development of a separate

controller that can control the overall power demands of the satellite. Figure 2.16 shows the

current design featuring the power controller. The power controller’s features include : receiving

and transmitting charge to batteries, managing power from battery packs to EBox, preventing

reversal of power flow into solar panels, controlling battery pack exchange and usage.

Given that the satellite must operate for years without physical intervention, a continual

supply of electricity must be available. A supply of batteries would likely last no more than a few

months. An array of solar energy collectors would supply power indefinitely, but only while in

direct sunlight. A solution lies in utilizing both of these systems such that:

• at least one power system may be actively supplying electricity at any given time

• the amount of power generated equals or exceeds the requirements of the hardware

• they may function reliably and efficiently for a period of several years

• power may be managed to maximize generation and minimize consumption as needed

2.3.1 Solar Power

Photovoltaic cells, commonly referred to as solar cells, convert light into electrical

current via the photovoltaic effect, whereby electrons are shifted in a particular medium

(typcially crystalline silicon) to induce a voltage differential and generate current[5]. Solar cells

are typically arranged in grids to form solar arrays. Arranging solar cells in series increases the

voltage delivered from the array, while arranging the cells in parallel increases the amount of

current available from the array [6]. The size of the arrays are limited only in the practical

limitation of maintaining electrical connections between each of the array's individual cells and

then storing that electrical energy [6]. Given the limitation of solar cells, and the need to have

many in parallel and series to generate the needed voltage and current for our control and

communication systems, a means to supplement or enhance solar power is needed.

Modern Lithium-Ion (Li-ion) batteries, that utilized a liquid or polymer lithium-ion based

solution as the battery core free of the “memory” problem[7]. Further advances Nanotube

battery technology may allow years of operation from a single lightweight battery without

charge, but for the time being we need to operate within the limited capacity of Li-ion. These

FGCU- 22

batteries are lighter in weight, smaller in size and faster to recharge (Fig. 2.3) than traditional

batteries.

Figure 2.15 Schematic of Lithium Ion cell[8].

. However, even with these advantages, the li-ion batteries suffer from shorter overall lifespans

compared to NiMH or Ni-Cad batteries and are much more expensive to manufacture[7].

FGCU- 23

Figure 2.16 Power supply design

For the purposes of the FGCU satellite project, some combination of rechargeable battery and

solar cells will power the unit. Considerations include size, cost and power delivery potential.

While there is no issue with lack of direct sunlight in low orbit, the size and number of solar cells

can be prohibitive given the 10cm3 limitation of the satellite specification. Conversely, relying

solely on battery output would require a battery well in excess of the 1kg weight limit. These

limitations, as well as a more in depth look at the requirements for the satellite, are discussed

later in this paper as it relates to the implementation of the satellite and test beds.

For our limited implementation, it will not be necessary to actually implement the

power controller. However, it is quite obvious that our design relies heavily on the power

controller in figure 2.16. This controller receives commands from FOCSS on EBox and performs

the necessary operations. In this design, the power controller would be completely hardware

and circuitry with no embedded software. The EBox sends commands in the form of bits

allowing power flow between various components of the power supply system. It would also

require diodes to prohibit the reversal of energy flow into the solar panels which could destroy

their functionality.

FGCU- 24

2.4 Client Implementation of the EBox Controller

The core of the system controller hardware needs to be compact yet robust enough to

handle communications, control and logics. These considerations, along with budgetary

constraints, suggests a thin client solution that allows most of the controlling hardware and

software to remain on the ground, providing the necessary space and weight savings. To this

end, the ebox-2300 meets these requirements [1]. The ebox-2300 contains a Vortex86 200Mhz

System-on-Chip (SoC) processer and 128MB of SDRAM[2]. The EBox system software, Windows

CE 6.0, is installed on a 256MB Flash Card that connects via an IDE interface[2]. Full

specifications are shown in Figure 2.1.1. The EBox is fan-less and designed for use in areas of

limited space with limited temperature control.

Figure2.17 System specification and main board design of EBox-2300[2].

As can be seen from the specifications, the size of the EBox at spec, is nearly within the size

limitations of the FUNSAT project, and would require minimal modifications to meet the 10cm x

10cm requirement.

FGCU- 25

2.4.1. Loading Specialty Image onto Windows CE – One special consideration using this EBox is the lack of onboard ROM. As all of the

onboard memory is RAM, the EBox requires that power be applied continuously, or the

application may be lost. However, it is possible to load a custom Operating System image file by

using Visual Studios with Windows CE Plugins. It was discovered that the small amount of

permanent storage that is on the EBox is actually wholly dedicated to storing this image file and

any files associated with it, meaning that if our application was written into the Operating

System’s “System Files” registry, it may be possible to load it every time. Customizing the image

file is straight forward, however altering the EBox to boot from it is not. First the image needs to

be written and compiled on the development PC and a copy of the file needs to be placed on a

flash drive. The flash drive is placed plugged into the EBox. The current image file needs to be

located so that it may be overwritten. It is also important to note that when this happens,

current settings on the EBox will be lost.

2.4.2 Setting up permanent storage It was also discovered during these procedures that a System file from the EBox is loaded

and re loaded every time the EBox is powered. If during the EBox operation something was

written into this file, it would be destroyed at power off and rebuilt at power on, meaning that it

is lost. However when an empty folder was created within the image that would create a folder in

the same directory in which the image is written, it became possible to have a “non volatile”

storage solution. Since this folder does not get erased every time (due to the presence of the

Operating System’s image file) we can use this as a small hard drive.

2.4.3 Setting up USBs, Writing and Loading Driver - The EBox is outfitted with 3 Universal Serial Buses version 1.1. This USB is slower than most of

the USBs in use with desktop PC but satisfactory for our implementation. The code below is the

introductory line for USB drivers written for all versions of Windows NT which refers to any

windows version after Windows 2000 inclusive.

[Version] Signature="$Windows NT$" DriverPackageType=PlugAndPlay DriverPackageDisplayName=%DESC% Class=Ports

FGCU- 26

ClassGUID={4d36e978-e325-11ce-bfc1-08002be10318} Provider=%FTDI% CatalogFile=ftdiport.cat DriverVer=10/22/2009,2.06.00

This code specifies the type of protocol (PlugAndPlay), the provider, version, and the Operating Systems the it is designed for.

2.4.4 What is a Driver Device drivers are used as a sort of users manual for the operating system. It tells whatever

system that the device is plugged into how, when, and where to talk to it. This aspect is

important because many times the driver is installed directly on the device to be installed on

the system that it is plugged in to.

Figure 2.18 Driver OS Interaction

As shown in figure 2.18, it is necessary to have the operating system understand the hardware

driver in order to properly communicate with the software that uses that hardware and the

communication device itself. Unfortunately since Windows CE is not a very widespread

operating system, it lacks the understandability of many drivers and greatly limits the number of

devices that can be used.

FGCU- 27

2.4.5 Rewriting The Driver To have the EBox understand the telemetry modules, it became necessary to rewrite the

existing driver files associated with the telemetry modules.

On a development PC that runs Windows XP, the specific driver file ftdi_ser.dll is located. Each

driver file has a .inf file which it calls for supplemental information. In this instance it is named

FTDIPORT.INF. This file tells the driver which PIDs and VIDs to load.

[FtdiHw.NTamd64] %VID_0403&PID_E548.DeviceDesc%=FtdiPort232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_E548 %VID_0403&PID_6001.DeviceDesc%=FtdiPort232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6001 %VID_0403&PID_6010.DeviceDesc%=FtdiPort2232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6010 %VID_0403&PID_6011.DeviceDesc%=FtdiPort2232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6011

Our EID was E548 and the VID 0403 which are unique numbers associated solely with our

telemetry devices. Once the .inf file and driver files are completed which is to EBox’s Windows

CE directory via a flash stick. Now it is possible to connect the telemetry modules to EBox. In

contrast to the friendlier “Plug and Play” configurations, Windows CE will pop up a prompt amd

asks the user for the driver file name.

2.4.6 Hyper Terminal

Another downside to the Window’s CE operating system is its lack of a Hyper Terminal. FOCSS

was developed using a philosophy similar to that of a hyper terminal, sending the data only

once the complete packet has been assembled and cleared. In traditional serial communication,

the two sides of communication send only 1 bit at a time. FOCSS packages these bits into

packets as described in section 2.2 and transmits the whole bit before writing or reading

anything else. However, there needs to be a platform with which the writing and reading occurs

to the actual COM port. In the Ground Host Computer this process is handled by the Hyper

Terminal Protocol which connects the processes with their respective COM ports and enables

reading and writing. A customized version of this hyper terminal must be written to enable

reading and writing from the telemetry modules to processes in the EBox.

FGCU- 28

A new layer must then be added to FOCSS to cover the serial communication within the EBox

itself. Named “Serial Communitarian” this program is takes console input and writes it to the

COM port and vice versa. It was written in C# compact .net framework 2.0, a framework which

the EBox currently supports. This new part of the program functions by getting a list of comport

names from the Operating System. It then creates an array of serial port objects listing all those

which are available and are already communicating. Serial Communitarian then opens a port

for each serial port name.

/* class constructor. configures the serial port and * begins executing the read and write components */

public SerialTest() { openPort(); ThreadStart rt = new ThreadStart(ReadThread); t = new Thread(rt); t.Start();

WriteThread(); }

Then it goes into an infinite loop which attempts to read from each serial port read buffer. This

loop is only broken on power off. The input from the console is read if there is any and any data

is written to the serial port as it is buffered for each serial port object.

/* continually reads from serial port and displays * the result on the console window. the thread is

* allowed to sleep briefly to reduce processor load */ public void ReadThread() { while (true) { Console.Write(readFromCOM()); Thread.Sleep(50); } }

/* continually checks the console window for user input.

* if the entered text is "exit", the program exits, aborting * both threads. all other text is written to the serial port's * write buffer. the thread is allowed to sleep briefly to * reduce processor load */ public void WriteThread()

{ String input = ""; while (true)

FGCU- 29

{ /* read from the console and place it in a temporary variable */

input = Console.ReadLine();

2.5 FOCSS Server Implementation Description As with the client, the FOCSS server was written in the C# programming language. With fewer

hardware and software restrictions than the client, the server can take advantage of the .NET

3.5 framework and include a wider array of features.

The current server implementation uses a command line interface (CLI), as opposed to the

previous graphical user interface. This change was made primarily to simplify development, but

the CLI aesthetic has been able to display information in a more straightforward manner.

As C# is a strongly object-oriented language, several new classes were created:

Server Class

• Instance variables (<data type> <variable name>)

o Thread t – Object representing the program primary thread

o SerialPort sp – Object which handles serial I/O

o Boolean isConnected – Flag that is set when a connection to the client has been

established

o Byte[] dataBuffer – Array of bytes to hold data temporarily as packets are being

read

• Instance methods (<return type> <method name>(<parameter type>))

o void Server(String) – Constructor for the class; instantiates object instance

variables and contains an infinite loop, acting as the user input thread

o void consoleWrite(String) – Writes the given string to a new line of the console

window along with the system’s current date and time

o void ServerThread(void) – Contains an infinite loop which handles

communications with the client

o void Main(String[]) – Entry point of the program; instantiates a Server object to

call the constructor

FGCU- 30

PacketTree Class

• Instance variables

o Packet[] data – Array containing all of the packets received

o Integer size – The number of Packet objects currently in the data array

o Integer maxSize – The maximum number of Packet objects that can currently be

placed in the data array

o File permanentStorage – Pointer to the file in which data may be stored more

permanently than in main memory

• Instance methods

o void addPacket(Packet) – Inserts the given packet at index “size” in the data

array.

o Packet findPacket(Time t) – Since all packets must be added to the data array in

chronological order, they are effectively pre-sorted with respect to their

timestamps. Beginning with the element at (size / 2), a binary search can be

performed to find the desired packet in Ο(log n) time

o void expandArray(void) – Allocates a new Packet array which is double the size of

the current array. The current array elements are copied to the new array, and

the old array is deallocated. This allows the addPacket method to run in

amortized constant time when using fixed-sized arrays

o void storeData(void) – Places the current array of packets in permanent storage

Similar to the client, the server executes two threads: user input and client communication.

The user input thread allows commands to be received from the command line interface and

processed. These commands allow the client to be manually controlled by the user. The

currently available CLI commands include:

• connect – Attempts to contact the client and establish a connection.

• status – Requests information about the client’s system, such as the available memory

and how many bytes of data are being stored.

• transmit – Initiates the transfer of the client’s available data.

FGCU- 31

• sleep client – places the client in a “sleep” mode which reduces the client’s CPU usage,

and therefore the power consumption.

• run client – Takes the client out of “sleep” mode if applicable.

• help – Displays a list of available commands.

• exit – Closes the server program entirely. If available, the client is notified that the

connection has been terminated.

The client communication thread handles the automated communication with the client. When

a transmission from the client is received successfully, a command code is included which

indicates what the client is sending. Currently, the command codes are represented by simple

ASCII character from ‘1’ to ‘6’. These codes have meanings specific to the server. The client may

receive the same values, however they have different meanings.

• ‘1’ – Connection acknowledgement. Contains no data, but when received after a

connection request, indicates that the client is available and ready to accept commands.

• ‘2’ – A data packet is being sent. When the transmission stops, the amount of data is

checked against the expected amount. If these values are equal, the last byte is checked

for the ASCII value ‘3’, which signifies the footer for the data. If the footer is present, the

transmission is deemed a success. On transmission success, the code ‘3’ is sent to the

client; on failure, the code ‘4’ is sent.

• ‘4’ – A response to a client status request is being received. If the amount of data is

equal to what is expected and the last byte is equal to the footer ‘5’, then the

transmission is deemed a success and the client’s status may be extracted. On

transmission failure, the status request code, ‘5’, is sent again.

• ‘6’ – Contains no data. Indicates that the client has no more filled Packet objects to

send.

FGCU- 32

2.6 Hardware implementation of 900 MHz Yagi Antenna System

Since in the US, the 420-450 MHz band is reserved for amateur radio use, the US version of the

board operates at 914.5 MHz. The website is a little ambiguous, as it states that the US version

operates with an “output power of 1 mW, otherwise the specification is as above.” We have

evaluated this to mean that during optimal conditions the telemetry communication is available

at up to 250 meters without any amplifiers, however at 1mW we may also establish

communication but at a much lesser distance.

The Active Robots module is a low cost telemetry board with a very small 3 cm antenna which is

limiting our communication distance. An in-depth look into the telemetry board specifications

does not cite any antenna to be used with these boards. Thus, we assume that in order to

create more distance, and depending on the final implementation, a few different antenna

designs can be made to accomplish better communication distance such that

2.6.1 Antenna Design The antenna design must take the telemetry needs into consideration. The following

configurations are specific to the telemetry modules currently in use.

• 10 user selectable frequencies between 433MHz & 434MHz

• Polarity protected input power 7.0 to 20Vdc

• User selectable power output up to 10mW

• Range up to 250m line-of-sight (not enough)

• Baud rates 2,400 to 38,400

2.6.1.1 Dipole Antenna One possible design is a half-wave center-fed dipole antenna. A half-wave center-fed

dipole has two elements, each ¼ wavelength long, that run along the same axis but

diametrically opposed, usually parallel to the ground. The half-wave center-fed dipole could be

considered a semi-directional antenna, in that the RF emitted from the antenna is strongest in

the direction perpendicular to and centered in the middle of the two radiating elements. It is

null along the axis of the radiating elements.

FGCU- 33

Figure 2.19 – Half Wave center fed dipole pattern[14].

Figure 2.19shows a conceptual diagram of a half-wave center-fed dipole radiation pattern. The

radiating elements are parallel and in line with the axis of the blue arrow.[14]

In order to calculate the size of a dipole antenna, the following formula is used:

length in feet = 468 / (frequency in MHz)

If we use this formula, we get:

length in feet = 468 / 914.5 MHz = 0.511755 feet

Or:

0.511755 * 12 = 6.141 inches

Which is approximately 6 inches and 2.256/16ths.

This means that each side of the dipole needs to be approximately 3 inches and 1/16th.

If the half-wave center-fed dipole were to be constructed, it should probably be made out of

FGCU- 34

#14 gauge solid copper wire. A connector and a few inches of spare copper wire would be

needed to connect the antenna to the connector on the board, and to space the antenna out

from the board. A typical recommendation for half-wave center-fed dipoles is that they should

be at least a half-wavelength from all (or as many as possible) obstructions on all sides,

especially large and/or flat obstructions, such as buildings, walls, and the ground. A small piece

of 50-ohm coax could also be used to connect the dipole to the board.

2.6.1.2 Yagi Antenna A Yagi-Uda antenna, or yagi for short, is a beam, or directional antenna with two or more

elements that are parallel and next to each other, in the same plane, and usually parallel to the

ground. The driven element is a half-wave center-fed dipole. The reflector element is slightly

longer than the driven element, and the director element(s) is (are) slightly shorter than the

driven element. More director elements can be added, up to a point of diminishing returns, to

increase the gain of the antenna. A side effect of this (sometimes wanted, sometimes

unwanted) is that the directionality of the antenna is increased. Therefore, this antenna design

is a good choice for a stationary base/ground station pointing at another stationary

base/ground station. It is usually used for long-distance point-to-point communication.

However, note that the curvature of the Earth (and also the height of the antenna above

average terrain) must be taken into account for an effective link.

A yagi antenna could also be used at the ground station, to communicate with the

satellite. However, it would not be a good choice to use at/on the satellite itself, as the satellite

will be rotating freely in space, and therefore be unable to maintain a directional point-to-point

communication link.

FGCU- 35

Figure 2.20 – A conceptual diagram of a yagi antenna.[13]

Figure 2.21 – Yagi antenna azimuth (horizontal) and elevation (vertical) radiation patterns of a

yagi antenna. [15]

FGCU- 36

2.6.2 Modified Yagi Implementation

Two 900 MHz yagi antennas were built using the dimensions specified in the

cheapyagi.pdf written by Kent Britain (Ham radio call sign: WASVJB) (attached as appendix x).

Construction of each antenna consisted of a boom 4 feet in length of 2 x 2 wood (actual

dimensions 1.5 inches by 1.5 inches, or 38 mm by 38 mm). All elements (reflector, driven, and

directors) were constructed out of the respective lengths of # 8 copper wire (nominal diameter

0.1285 inches / 3.2639 mm). Holes were drilled in the booms just barely larger than the diameter

of the copper wire (approximately 1/8”), at the appropriate distances. The copper wire was then

cut to length and hammered into place. This kept the copper wire in the boom without the need

for glue or other adhesives. The holes for the driven element were drilled slightly larger, in order

to facilitate easy insertion and removal, while still maintaining a firm mounting in the boom. The

driven element was soldered to one end of a 3 foot piece of RG-174/U cable, the other end of

which was attached to the Active Robots USB-to-Serial Communication board.

Figure 2.22 unidirectional antenna[see Appendix F]

The shape of the driven element is bent into a “hairpin” style, as shown in figure x.x. The corners

and body of the copper wire were sanded to remove any oxidation and impurities from the

FGCU- 37

surface of the copper. Then about ½” to 1” of the jacket is cut off both ends of the coax.

Without fully unraveling the braid, separate enough strands at the base of the braid to enable the

center conductor (and center insulator) to be carefully pulled through the braid. Once this is

done, you will have equal lengths of braid and insulated center conductor. Carefully strip the

most of the insulator off the center conductor, being sure to leave a small piece intact close to the

braid, so it is unlikely that the coax will short out between the center conductor and the braid. For

this next part, you will need a sufficiently large soldering iron. Size in this case is not only

representative of power (watts), but also of the amount of latent heat that can be stored in the

iron, also known as thermal mass. I used a Weller SP-120 120 watt soldering iron, which worked

beautifully. The larger the physical size of the iron, the more heat the iron can apply quickly and

directly to the surface being heated, in a localized area, without heating the rest of the work.

Since copper is metal, it conducts heat fairly well. For the next part, a “third-hand” tool is

strongly recommended. Some solder flux is also needed. Both ends of the coax are wrapped

around the respective pieces of the driven element (refer to appendix f). Apply a light coating of

solder flux to all surfaces to be soldered (the two points of contact between the ends of the coax

and the driven element.) Touch the soldering iron to each point of contact. As the work is heated,

the flux paste will begin to steam off. This is normal. Touch the solder to the work until the

solder flows freely into the work. Remove the iron and continue feeding solder into the joint

until the solder no longer flows. If the joint is completely covered in solder, you are finished. If

the joint is not completely covered, repeat heating the work and feeding the solder into the work

until the joint is completely covered. NEVER heat the solder and “drop” it onto the work! This is

wrong! The solder is supposed to flow freely over the work, and create a chemical, as well as

physical, bond with the work. If you “drop” the solder onto the work, it is only forming a

physical connection, and a poor one at that! Not only will your joint be guaranteed to fail

physically, it will have poor electrical properties as well.

Next, the small wire antenna in the Active Robots USB radio module needs to replaced

with the RG-174/U coax leading to the driven element. Prepare this end of the RG-174/U the

same way as the other end. You will need a de-soldering tool (typically a de-soldering iron, braid,

bulb, or suction pump) for the next part. Turn the USB board so the wire antenna is facing down.

The wire antenna is attached to the board via a through-hole mount. Find the attachment point on

the back side of the board. Apply heat to the “back” of the antenna using a smaller soldering iron

FGCU- 38

than before, ~30 watts. Anything larger can damage the components on the board. Touch the

soldering iron to the connection point. As soon as the connection becomes “liquid”, suck the

solder out of the connection using the de-soldering tool. This may need to be repeated several

times until all of the solder is successfully removed. Typically, if done correctly, the component

being de-soldered will fall right out of the board. If not, it might need to be wiggled ever-so-

slightly to coax it to come out. Very little pressure should be used. The component should not

require much force to be removed. If it does, something is wrong. Stop, back up, and try to de-

solder the component again. This whole process is repeated for the second antenna.

Since the driven element specified in the document is a hairpin-style, the coax was

soldered to the copper on the side of the driven element with the bend. That way, the driven

element could be pulled out of the boom of the yagi antenna, so the Active Robots radio could be

transported and used safely and independent of the boom. After all, 26-odd points of # 8 copper

can be fairly hazardous.

2.6.3 Results of Antenna Implementation The specification for the Active Robots telemetry modules state that a maximum distance of 250

meters is possible for connection. This distance is measured in “straight line” and with no

obstacles or reflection. Since the original configuration of the telemetry units made them omni-

directional, it would be possible to draw a circle around the telemetry unit and have

communication from any point at up to 250meter radii. The antenna modification changes the

The antennas enabled the radios to communicate over a distance of 400 meters when pointed

directly at each other. Figure 2.23 shows the communication distance between the telemetry

modules before and after antenna implementation. It can also be seen that the radius directly

around either of the antennas is greatly reduced and any benefit from the yagi antennas may

only be seen when directly aimed at each other.

FGCU- 39

Figure 2.23 Telemetry Range

2.7 Magnetic Sensor

A field of study suited to the size limitations of the satellite is observation of the earth's

magnetic field. Magnetic sensors, utilizing the Hall Effect (Figure 2.24), require no power and

measure the voltage differential across the sensor when under the presence of a magnetic field.

Figure 2.24 The Hall Effect[10]

Changes in the earth's magnetic field effects many industries and activities essential to daily life.

For example, transmission of radio waves and cellular signals depends on the health of the

ionosphere and by extension the relative strength of the magnetosphere. NASA is currently

undertaking a much more complex mission to study the earth’s magnetic fields. The

Magnetospheric Multiscale Mission or MMS is an unmanned mission planned by NASA to study

FGCU- 40

the magnetosphere using a series of synchronized satellites in tetrahedral formation. Planned to

launch in 2014 the MMS project will measure[GODDARD REFERENCE] :

• Magnetic and electric fields (100-m wire booms) • Electron and ion plasma spectrometers, 3D distribution in 1/2 spin • Energetic particles • Plasma waves • High temporal, spatial resolution • Burst event recording

The development of this project may show that it is possible to also study the magnetosphere

using much less expensive “disposable” pico satellites governed by a single controller much like

an airport air traffic controller.

FGCU- 41

3. Finances and Budgets While not a subsystem of the satellite itself, financial constraints (the budget) for constructing

the satellite can be a major concern. Due to the level of miniaturization and customization

required for many of the satellite’s components, the total cost of construction can easily reach

into the tens of thousands of dollars. This is simply not feasible for some. Instead, the available

finances must be used such that:

• the cost of all components is less than or equal to the budget

• the selected components possess the same or similar architecture and functionality of

the desired components

• a working model of the satellite can be constructed and demonstrated

• physical constraints (volume and mass of the satellite) may be stretched to allow use of

larger, cheaper components

However, FGCU’s FUNSAT project is different than other teams since we are designing and

implementing the hardware and systems for the express purpose of displaying the software.

Thus, our current design budget is restricted by our semesterly operating budget of

approximately $600 USD. Since this project has lasted the last two semesters our current

breakdown and total expenditures is as follows:

Part Qty Unit Price Total

20’ of #8 copper wire per Foot 20 $ 0.45

$ 9.00

8’ section of 2 x 2 8 $ 0.50

$ 4.00

USB 2.0 Cabling per foot 4 $ 15.00

$ 60.00

Hack saw (to cut 2x2 into two pieces) 1 $ 12.00

$ 12.00

Copper wire cutters (to cut copper wire) 1 $ 6.00

$ 6.00

3/8” reversible drill and drill bits(to drill holes into the booms) 2

$ 5.00

$ 10.00

FGCU- 42

Weller SP-120 soldering iron 1 $ 45.00

$ 45.00

Radio Shack 30-watt soldering iron 1 $ 10.00

$ 10.00

Radio Shack de-soldering bulb 1 $ 7.00

$ 7.00

Radio Shack third-hand tool 1 $ 14.00

$ 14.00

Radio Shack Solder Flux plaste 1 $ 7.00

$ 7.00

Small paint brush to apply solder flux paste to work 1 $ 2.00

$ 2.00

Radio Shack small diagonal cutters 1 $ 10.00

$ 10.00

Radio Shack 6” forceps 1 $ 10.00

$ 10.00

Ebox2300 1 $ 260.00

$ 260.00

Traveling Expenses 1 $ 150.00

$ 150.00

Active Robots 900MHz Telemetry units 4 $ 35.00

$ 140.00

Phidget Controller "PhidgetInterfaceKit 8/8/8" 1 $ 80.00

$ 80.00

Phidget Magnetic Sensor 1 $ 15.00

$ 15.00

Personal Software and Computer Equipment 2 $ 200.00

$ 400.00

TOTAL $ 1,251.00

Table 2.25 FGCU Funsat Expenditures 2009-2010

Funds estimation to continue the project will depend greatly on the purposes and extent of

continuation. To reiterate the goal of this project, FGCU is creating low cost “proof of concept”

to show case the FOCSS software all the while fulfilling the purpose of magnetosphere research.

Therefore, if the continuation of this project is to further develop the software to a point of

operability on a real “flight” unit, then the budget will be increased marginally beyond what has

already been spent other than adjustments to fit the hardware. However if the continuation of this

project becomes the development of a real pico-satellite meant for launch the budget should be

significantly increased closer to or above the $7500 suggest major budget.

FGCU- 43

4. Schedule for Implementation and Team MakeUp

4.1 Current Schedule Extended

Task Category Person Responsible Due Date

Order Telemetry Units Hardware Dr. Zalewski 7-Oct

Payroll Verification Supplemental Dr. Zalewski 14-Oct

Order Ebox Hardware Dr. Zalewski 15-Oct

Order Magnetism Sensor Hardware Jaime/Carlos 15-Oct

Introduction Paper Jay Gittings 19-Oct

Architectural Software Design (Existing Code Overview)

Design Carlos Dabouine / Michael Lekon 19-Oct

Magnetism Overview Supplemental Tim Bennett 19-Oct

Exploded View Overview Supplemental Jaime Zabala 19-Oct

Order Solar Panels Hardware Joe Voelmle 21-Oct

Meeting 2 Meeting WHOLE TEAM 21-Oct

Problem Description Halves Paper Tim Bennett / Carlos Dabouine 31-Oct

RECEIVE ALL BY Hardware Dr. Zalewski 4-Nov

Architectural Hardware Design Design Tim Bennett/Jaime Zabala 4-Nov

Meeting 3 Meeting WHOLE TEAM 4-Nov

Problem Description Paper Michael Lekon 18-Nov

Problem Solution Paper Tim Bennett 18-Nov

Solar Panel System Design Supplemental Joe Voelmle 21-Nov

GCTC Meeting MEETING WHOLE TEAM 23-Nov

Proposed Solution Editing (software) Paper Jaime Zabala 23-Nov

Hardware Design Supplemental Jaime Zabala 25-Nov

Introduction Editing Paper Jay Gittings 25-Nov

Conclusion Paper Jay Gittings 25-Nov

Rough Draft EVERYTHING DUE Paper WHOLE TEAM 25-Nov

FGCU- 44

Solar Panel Order Hardware Joe Voelmle 25-Nov

Final Editing Paper Jaime Zabala + ? 5-Dec

Final Paper Submission Paper Jaime Zabala / Janusz Zalewski 7-Dec

Hardware Exploded View Design Jaime Zabala 7-Dec

Telemetry Connectivity Hardware Michael Lekon 1-Jan

Find new Team Members Meeting Dr. Zalewski / Jaime Zabala 15-Jan

Send CDR to Team Supplemental Jaime Zabala 25-Jan

Complete Minutes and Schedule Design Jaime Zabala 25-Jan

Purchase CF card Hardware Bradd Konert 28-Jan

Decide Direction of Software Design Michael Lekon, Jaime Zabala 29-Jan

Research Windsurfer foil for antenna Supplemental Tim Bennett 29-Jan

Create Drop Box account Supplemental Jaime Zabala 29-Jan

Get total budget figures from Zalewski Paper Jaime Zabala 29-Jan

Load XP onto eBox Hardware Bradd Konert 5-Feb

Review CDR Supplemental ALL 5-Feb

Write up preliminary SRS Paper Michael Lekon 5-Feb

Research NonVolatile Ram Design Bradd Konert 5-Feb

Write summary/cost/parts for antenna Paper Tim Bennett 5-Feb

Inmplement NonValitle Ram on Ebox Hardware /

Design Bradd Konert 12-Feb

Power System Design / Order Hardware/

Design Bradd Konert 12-Feb

Preliminary development / implementation of Antenna

Hardware / Design

Tim Bennett 12-Feb

Establish Comm with Telemetry Hardware /

Coding Michael Lekon 12-Feb

Power Design (Not Implementation) Paper Jaime Zabala, Michael Lekon, Bradd

Konert 26-Feb

Write Client Side Shell Coding Michael Lekon 12-Mar

Solder Antenna to Telemetry Hardware Tim Bennett 12-Mar

Prepare Design Doc Paper Jaime Zabala 12-Mar

FGCU- 45

Power System Design Design Jaime Zabala 12-Mar

Write Server Side Shell GUI Coding Bradd Konert 12-Mar

Research EBOX connectivity Research Bradd Konert 12-Mar

Write Client Side Shell Coding Michael Lekon 12-Mar

Transfer comm to EBOX Supplemental Michael Lekon 12-Mar

Status Update Ppt Supplemental ALL 19-Mar

Implementation report draft paper ALL 26-Mar

Build OS for Ebox Coding MIKE, BRADD 2-Apr

Project Demos coding WHOLE TEAM 2-Apr

Detailed Design Report Paper WHOLE TEAM 21-Apr

POSTER PRESENTATION Paper WHOLE TEAM 23-Apr

Workshop Hardware /

Design WHOLE TEAM 7-May

Draft Hardware Assembly Design WHOLE TEAM 7-May Client Side Communication and Data

Buffering Software Michael Lekon 7-Jun Client Side Power Supply Development

Software Bradd Konert 7-Jun Draft Yagi Antenna Testing

Hardware Tim Bennett, Michael Lekon 7-Jun Client Side Testing

Software Jaime Zabala 21-Jun Large Yagi Design

Hardware Tim Bennett 21-Jun Server Side communication and

Command Buffering Software Michael Lekon 15-Jul Server and Client Interaction Testing

Software Bradd Konert 15-Aug Large Yagi Installation

Hardware WHOLE TEAM 15-Aug EBox Size Preparation

Hardware WHOLE TEAM 27-Sep Final EBox Software Installation and

Validation Software Jaime Zabala 3-Nov FOCSS Comprehensive Performance

Testing Software WHOLE TEAM 10-Nov

FGCU- 46

4.2 Current Team Make-Up

Tim Bennett – Lead Hardware Engineer currently a Senior at Florida Gulf Coast University. He

will be graduating in May 2010 with a Bachelor’s Degree in Computer Science with a

concentration in Software Engineering, and has written programs in Java, C++, and Assembly.

Tim is also a Computer Repair Technician at a local computer shop, and has been repairing

computers professionally for the last seven years. Some of Tim’s hobbies include ham radio and

welding. Tim currently plans to pursue a certification in welding.

Bradd Konert - he had a four year internship with International Software development company

Allen System Group. Background in software application development including web design and

coding. Is graduating this semester with a BS in Software Engineering Degree. Lead Telemetry

Developer.

Michael Lekon – Lead Applications Engineer. Will be graduating in December with a BS in

Computer Science. Has an AA in General Studies from Edison State College. Hobbies include

game development. Proficient in C/C++/C#/Java. Developed the presentation and participated

in FGCU’s Remote Data Acquisition and Control with LabVIEW PDA and GPIB project .

Jaime Zabala – Project Leader and chief editor. Managed meetings, organized schedules . Has

been hired for a software test engineer position at NASAs Goddard space flight center.

The schedule has been organized in such a way as to maximize the teamwork according to the

individual member’s strengths and experiences. However since this project is also meant as a

learning tool for all team members, we have each done a little bit of every section including

antenna building, C# coding, writing documentation, and design.

FGCU- 47

5. Conclusion

Pico-satellites provide unique learning opportunities in the field of aerospace. Their

small size and weight constraints create interesting limitations that require creative thinking and

the combination of many disciplines to overcome. Florida Gulf Coast University's entry for the

FUNSAT competition seeks to tackle these limitations by implementing a thin client embedded

system within the satellite that will control sensor systems to monitor low earth orbit. A thin-

client configuration affords a smaller controller package, which decreases weight and power

requirements. The project plans to create a proof of concept with the eBox 2300, a lightweight,

low-cost embedded system that runs Windows CE. A major advantage of the eBox system is the

ability to leverage existing software development expertise at FGCU. However, this decision

does not come without trade-offs, as the satellites command and control software, operating

system and all application code are held within Flash memory that require constant power to

the system. In order to meet this need, the project will employ a two tiered power solution, in

which solar panels are used to charge and lightweight battery able to meet the power needs of

the eBox system board. Both the solar arrays and battery technology will undergo significant

proof of concept testing prior to final evaluation in order to determine the configuration most

able to meet the requirements of the FGCU project.

With over four million pounds of debris in near earth orbit, the need exists to monitor

and track the largest and most threatening of these pieces in order to prevent damage to

equipment and personnel in space. A simple means of measuring this debris might utilize a

lower power series of magnetic sensors or cameras. Such an array would allow the FGCU team

to monitor debris near the satellite. Another use for the satellite is as a relay in the control of a

secondary robotics system in a remote and isolated location. Transmitting this information back

and forth to the team will require radio telemetry. Of course, this presents a challenge over

such a large distance. Before tackling the problem of distance, the team will implement a

smaller scale communication array that allows transmission up to 250 meters in order to test

the feasibility of the command and control design. Once the design is proven viable, the team

intends to explore methods that will increase the range of communications through the use of

various antennae technologies, such as dipole or Yagi-Uda antennas.

FGCU- 48

Many questions still remain for the project team to answer. Will the embedded

controller's power requirements exceed the ability of any solar array and/or battery

configuration's output to meet this need? Is there an antennae configuration available that will

allow communication via RF telemetry with the satellite in low earth orbit? Is it possible to

combine all of these components into a compact and lightweight system that meets the

requirements of the 1000cm3 and 1 kg? At the moment, FGCU has neither the expertise or

funding to answer all of these questions. However, each of these questions present wonderful

opportunities for students to learn about the challenges in aerospace engineering. Further

research into these and other questions will continue at FGCU and hopefully this interest will

drive further funding and research. Given these developments, it would appear that the

mission of the FUNSAT, to foster interest and growth of aerospace education within Florida

universities, has been a success at FGCU.

FGCU- 49

6. References

1. Daboin, Carlos. "Telemetry System." Telemetry System. 22 Nov. 2009. Florida Gulf Coast

University. 22 Nov. 2009 <http://satnet.fgcu.edu/~cedaboin/telemetry.htm>.

2. EBox 2300 Resources. <http://users.ece.gatech.edu/~hamblen/Ebox/>

3. Carden, Frank. Jedlicka, Russell P. Henry, Robert. Telemetry systems engineering. Artech

House Inc. 2002.

4. Active Robots RF04 900 MHz USB Radio Telemetry Model.

<http://www.robotshop.ca/Active Robots-rf04-900-usb-module.html>

5. Wikipedia. Photovolatic Cells. http://en.wikipedia.org/wiki/Photovoltaics

6. Gibilisco, Stan. Teach yourself electricity and electronics. McGraw Hill. 2001

7. Cyberoo. "Portable Power". HWM. May, 2005: 40.

8. Vincent, Colin Angus. Scrosati, Bruno. Modern Batteries: an introduction to

electrochemical power sources. Butterworth-Heinemann. 1984.

9. Britt, Robert Roy. "Space Junk". 19 October, 2000.

<http://www.space.com/spacewatch/space_junk.html>

10. "Hall Effect". <http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/Hall.html>

11. Arbeille, Philip. “Use of a robotic arm to perform robotic telesonography”. American

Journal of Roentgenology. 2007. 188:W317-322.

<http://www.ajronline.org/cgi/content/full/188/4/W317>

12. Image can be found at:

http://i.ehow.com/images/GlobalPhoto/Articles/5094140/VHFHWDP-main_Full.jpg

13. Image can be found at: http://patriciaray.net/Yagi3el.gif


http://www.cst.com/CMS/images/article105/CPU05_047_600_481.jpg


http://www.cisco.com/en/US/prod/collateral/wireless/ps7183/ps469/images/0900aecd

806a1a3e_null_null_null_08_07_07-11.jpg

http://books.google.com/books?id=muoDAAAAMBAJ&lpg=PA40&dq=history%20of%20rechargeable%20batteries&lr=&as_brr=1&client=firefox-a&pg=PA40#v=onepage&q=history of rechargeable batteries&f=false�

http://books.google.com/books?id=aBOC6zDGHy8C&lpg=PP1&dq=Modern%20Batteries%3A%20An%20introduction%20to%20electro-%20chemical%20power%20sources&client=firefox-a&pg=PA200#v=onepage&q=&f=false�

http://books.google.com/books?id=aBOC6zDGHy8C&lpg=PP1&dq=Modern%20Batteries%3A%20An%20introduction%20to%20electro-%20chemical%20power%20sources&client=firefox-a&pg=PA200#v=onepage&q=&f=false�

http://www.space.com/spacewatch/space_junk.html�

http://www.space.com/spacewatch/space_junk.html�

http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/Hall.html�

http://i.ehow.com/images/GlobalPhoto/Articles/5094140/VHFHWDP-main_Full.jpg�

http://patriciaray.net/Yagi3el.gif�

http://www.cst.com/CMS/images/article105/CPU05_047_600_481.jpg�

http://www.cisco.com/en/US/prod/collateral/wireless/ps7183/ps469/images/0900aecd806a1a3e_null_null_null_08_07_07-11.jpg�

http://www.cisco.com/en/US/prod/collateral/wireless/ps7183/ps469/images/0900aecd806a1a3e_null_null_null_08_07_07-11.jpg�

FGCU- 50

16. 2 RS232 RF Telemetry Module Size: 70mm x 40mm/each

http://www.active-robots.com/products/radio-solutions/radio-communication.shtml

17. 2 USB RF Telemetry Module

http://www.saelig.com/SPCL/RW016.htm

18. 1 SENSOR

http://www.phidgets.com/products.php?category=1&product_id=1108

19. 1 Microcontroller

http://www.phidgets.com/products.php?category=0&product_id=1018

20. Virtual COM Port Drivers. Ftdichip.com, 1 Nov. 2009. Web. 1 Nov. 2009.

<http://www.ftdichip.com/Drivers/VCP.htm>.

21. Phidgets Inc. - Unique and Easy to Use USB Interfaces. www.phidgets.com, 1 Nov.

2009. Web. 1 Nov. 2009. <http://www.phidgets.com/drivers.php >.

22. http://www.robotshop.ca/software/easy-radio-software-v2_03.zip. www.robotshop.ca,

1 Nov. 2009. Web. 1 Nov. 2009. <http://www.robotshop.ca/software/easy-radio-

software-v2_03.zip>.

http://www.active-robots.com/products/radio-solutions/radio-communication.shtml�

http://www.saelig.com/SPCL/RW016.htm�

http://www.phidgets.com/products.php?category=1&product_id=1108�

http://www.phidgets.com/products.php?category=0&product_id=1018�

FGCU- 51

Appendix A Hardware Overview

A1. Introduction

The hardware which has thus far been chosen for the FUNSAT competition is with the

purpose of getting the most of the least. Through limited means, our goal is to produce a

working mockup of a pico satellite, within the spirit of the competition. It is not entirely in our

budget to buy any of the recommended parts for the actual assembly of the Cubic Satellite as

suggested by the FUNSAT committee. Therefore, the decision was made by consensus to not

follow the rules to the last letter, but rather stay in the spirit of the competition with the

intention of meeting the competitions guidelines. Furthermore, our actual target for the

FUNSAT is the software design and the hardware is only meant as a reinforcement of the actual

software implementation. Having stated this, it is important to know the rules that we are

trying to follow :

Size and Weight restrictions:

10cm long x 10cm high x 10cm wide plus/minus .1cm

1.3 kg total weight for the whole satellite.

A1.1 Definitions

Linear Hall Effect - the production of a voltage difference (the Hall voltage) across an

electrical conductor, transverse to an electric current in the conductor and a magnetic

field perpendicular to the current

Magnetism - attraction for iron; associated with electric currents as well as magnets;

characterized by fields of force

Ratiometric - any system in which an output is directly proportional to an input

RF - an electromagnetic wave frequency between audio and infrared

Telemetry - automatic transmission and measurement of data from remote sources by

wire or radio or other means

USB – Universal Serial Bus

http://en.wikipedia.org/wiki/Voltage_difference�

http://en.wikipedia.org/wiki/Electrical_conductor�

http://en.wikipedia.org/wiki/Electric_current�

http://en.wikipedia.org/wiki/Magnetic_field�

http://en.wikipedia.org/wiki/Magnetic_field�

FGCU- 52

A2.1 USB RF Telemetry Module

Figure A2.1 Active Robots USB Radio Frequency Telemetry Module[17]

Hardware Included

RTM-USA USB RF Telemetry Module

Requires

Any combination of RF modules (USB/RS232/TTL) to establish a Telemetry link

USB cable

Description :

Self Powered through USB

Range up to 250m (line of sight)

User selectable radio features

Free configuration software

All of the necessary construction of packets, encoding/decoding and timing is carried out in the

module, removing any further communication overhead.

The only necessary interface is an USB port with the proper drivers installed.

FGCU- 53

The user software needs to connect to the com port and set the protocol to 19,200 baud, 8

data bits, 1 stop bit, no parity and no handshaking.

Ideally, whatever you type in one end will appear exactly the same at the other.

Up to 128 characters can be sent at a time. The actual transmission from one module to the

other takes place when a 3 character gap has been left.

Also supplied with the modules is a program specially written by Active Robots that enables the

user to select different operating frequencies, baud rates and power levels. It is necessary to

experiment with the power level to optimize the systems state as a whole.

A2.2 Phidget Magnetic Sensor (30.5mm x 30.5mm)

FigureA2.2 Phidget Magnetic Sensor[18]

Hardware included

Magnetic Sensor

Sensor Cable

2 small magnets

Requires

PhidgetInterfaceKit 8/8/8

USB Cable

FGCU- 54

Description:

Uses the Linear Hall Effect

Provides a voltage output that is proportional to the applied magnetic field.

The sensor uses ratiometric measurement.

Features Application Programming Interfaces (API) that are supported for Windows, Mac OS X,

and Linux.

Supports VB6, VB.NET, C#.NET, C, C++, Flash 9, Flex, Java, LabVIEW, Python, Max/MSP, and

Cocoa.

Anaglog Interface device.

A2.3 Phidget Microcontroller (83.06 mm x 53.34 mm)

Figure A2.3 Phidget Microcontroller Unit [19]

Comes With

3001 - 180cm USB Cable

mounting hardware kit

Requires

PhidgetInterfaceKit 8/8/8 board

http://www.phidgets.com/products.php?product_id=3001�

FGCU- 55

USB Cable

Wire

Analog Inputs

The Analog Inputs are used to measure continuous quantities, such as temperature, humidity,

position, pressure, etc. Phidgets offers a wide variety of sensors that can be plugged directly

into the board using the cable included with the sensor.

Supports Windows 2000/XP/Vista, Windows CE, Linux, and Mac OS X, VB6, VB.NET, C#.NET, C++,

Flash 9, Flex, Java, LabVIEW, Python, Max/MSP, and Cocoa.

The maximum total current consumed by all Analog Inputs should be limited to 400mA. The

analog measurement is represented in the software through the SensorValue as a value

between 0 and 1000. A sensor value of 1 unit represents a voltage of approximately 5 millivolts

In addition to Phidgets sensors, any sensor that returns a signal between 0 and 5 volts can be

easily interfaced.

A2.4 EBox 2300 (115 x 115 x 35 mm / 505g )

FigureA2.4 EBox Controller Unit[2]

Comes with

External Power Adaptor

Ebox 2300

Requires

Power supply for operation Max. 15-watts 5.0~5.25VDC @ 3A max).

FGCU- 56

SYSTEM SPECIFICATION

CPU: Vortex86 SoC (System on Chip)

Main Memory: 128MB SDRAM

BIOS : AMI BIOS

LAN : Realtek 8100B, 10/100Mbps Ethernet

Interface : Keyboard and Mouse, PS/2 Keyboard and Mouse

USB V1.1 ports x 3

Supported OS : Windows CE.NET, Windows XP Embedded, Linux

FGCU- 57

Appendix B Telemetry Communication System

The telemetry communication system is communication channel the use telemetry to

send information from point A to point B. The transmission of information is in one direction

from transmitter to receiver. The system is composed by two telemetry devices and a software

application to deconde/encodes data transmitted form telemetry devices.

The telemetry modules use radio frequency to communicate, and they past the data to

the PC using PC’S serial ports, hardware serial port, or virtual ports (USB). The system operates

by sending data from telemetry transmitter to the telemetry receiver, and the data travels over

radio frequency waves. Also, data is passed to the telemetry board by writing and reading the

PC’s serial ports.

The system uses C# programming language to reads and write data to the serial ports

then data is send/receive by the telemetry devices. The application on the transmitter side send

data, so it write data to the computer COM port, then anything written in this COM port will be

received by the receiver telemetry module. Finally, the software on the telemetry receiver will

read any data coming from serial port and displayed on graphic user interface.

The system network is comprised by two USB Telemetry Modules connected each to one

PC, one pc will act as transmitter, and the other PC will act as a receiver. The PC acting as

transmitter will acquire data from, sensor, user input, or any other device, and then it will write

this data on the COM port. Then, the Telemetry transmitter sends this data to its pier telemetry

module, so any data written in the COM port is constantly read by the PC that acts as a receiver.

The receiver PC uses the telemetry module to get the data send/write form the transmitter

COM port, and then the other PC constantly reads from its COM port. See Figure 1 to refer to

network diagram.

FGCU- 58

Figure B.1 Telemetry Communication System Network Diagram

B1 Telemetry Communication Concept applied to a Surveillance Magnetic Field System

The system is comprised by a server, and client application that communicate over radio

frequency channel to emulate a communication from a base station and a satellite. The Server

application send magnetic field changes to a client application that displays this magnetic field

changes over a GUI, graphic user interface.

B1.1 Server Application

The server is software application running in a thin client, eBox 2300, the application

communicates to a sensor to get magnetic field changes, and then the application

communicates to a virtual COM port to broadcast these readings to a client application. The

server application continually sends sensor readings using a USB transceiver that emulate a

COM port, then this transceiver send this data over an specific radio frequency to another

transceiver connected to the client application. . Refer to Figure 2 to see the flow chart of the

server application.

The server application is developed in Visual C# for smart devices, eBox 2300, so the

application only run in Windows CE operating systems that has the .NET compact frame work

installed. The libraries needed to access the sensor, and the USB telemetry modules are supply

by their manufactures, so the server is developed around these libraries functions to access and

deliver data

The server application reads magnetic field changes using a magnetic senor that is

connected to analog to digital micro controller, so every time the sensor detect changes in the

FGCU- 59

magnetic field surrounding it, it will pass this analog reading to the micro controller, then the

micro controller will convert this analog reading to digital, to allow the application to read the

stream of data coming from the USB port which is connected to the microcontroller. The server

application do not store any data internally, so it will the client application responsible to store

the magnetic field reading send if it is necessary.

The server uses a virtual serial port to send data to a client application running in a

remote computer. The virtual serial port is USB telemetry module that simulates a COM device,

and then the telemetry module sends data that has been written over the virtual COM port

using radio frequency waves. Finally, another USB telemetry module will get this reading and

display over a graphic user interface.

Server Application Flow Chart

FGCU- 60

Start

Thread Starts

Server Opens Port

Serial Port Open

Write Sensor Readings over

Serial Port

End

Error MessageN

Y

Figure B2. Server Application Flow Chart

B1.2Client Application

The client application is software application running in PC, XP/VISTA operating system,

the application communicates to a virtual COM port to read data send by the server application,

and then displays these readings over a graphic user interface. The client application continually

receives data from the server, so data readings will perform in real time. The client application is

written in Visual C# and can be run it in any Windows PC with .NET framework higher than 2.0. .

Refer to Figure 3 to see the flow chart of the client application.

FGCU- 61

The client application read any data that has written to the virtual COM port, USP port,

the device connected the virtual COM port is the USB telemetry module which links to the

telemetry module connected to the eBox 2300. Therefore, every time the server writes data

over the one link of the virtual COM port, the client is able to read using its virtual COM port

link. Finally, these data, readings, are displayed over t a user interface where the reading will

become information about the magnetic field changes that occur in the server side.

In brief, the Telemetry communication system has been chosen because this system

simulates data transmission form a satellite in space to a computer in a base station in earth.

Data will be write/read over the virtual COM ports continually, meaning data acquisition

happens in real time.

The server application is the responsible to gather data from the sensor and write the

data over a virtual serial port that sends this data to another telemetry board that is controlled

by a client application. Then, the client application is responsible to display this data.

Client Application Flow Chart

FGCU- 62

Start

Thread Start

Server Opens Port

Serial Port Open

Read Data From Serial Port

End

Error MessageN

Y

Display Data Over GUI

Figure B3. Client Application Flow Chart

FGCU- 63

B2 System Implementation

B2.1 Software Installation

Driver’s installation

Telemetry board driver

Drivers for telemetry boards need to be installed in order to allow the operating system

to see the boards as a virtual COM ports, the driver are available at

http://www.ftdichip.com/Drivers/VCP.htm [20]

Phidget sensor and micro controller board driver

Phidget framework needs to be installed in the PC/eBox 2300 that is detecting the

magnetic field changes. The framework can be downloaded at

http://www.phidgets.com/drivers.php [21]

Telemetry Board Configuration Software

The telemetry boards have to be configured to be able to communicate each other.

Download the programming boar application at http://www.robotshop.ca/software/easy-radio-

software-v2_03.zip [22]. Refer to Figure 4 for configuration settings.

Telemetry Board Programming settings

Set UART baud rate to: ER_CMD#4 (19200)

Set power level to: ER_CMD#P7

Set frequency channel number to: ER_CMD#C7 (Channel 7)

Set other settings to: ER_CMD#H2 (Handshaking OFF)

Set test mode to: ER_CMD# to: (High Side Carrier ON)

FGCU- 64

Figure B4. Easy Radio Configuration Software

C# software applications

Telemetry Transmitter (PC 1)

Download the telemetry transmitter application from

http://satnet.fgcu.edu/~cedaboin/telemetry.htm [23], and then save the executable file. Refer

to Appendix A for transmitter application source code.

Telemetry Transmitter (eBox 2300)

Download the telemetry transmitter application for the eBox 2300 from,, then save the

executable file. Refer to Appendix A for transmitter application source code.

Download the telemetry transmitter application from

http://satnet.fgcu.edu/~cedaboin/telemetry.htm [23], and then save the executable file

Telemetry Receiver (PC 2)

Download the telemetry receiver application from

http://satnet.fgcu.edu/~cedaboin/telemetry.htm [23], and then save the executable file. Refer

to Appendix B for receiver application source code.

FGCU- 65

B3 Hardware Connectivity

1. Connect the two telemetry devices, and configure with the Telemetry Board

Configuration Software, refer to software installation section.

2. Connect the 8/8/8 board to the computer, and then connect the magnetic sensor to the

8/8/8 board

System Test

Run the transmitter and receiver application on its respective PCs. Then, click the start

button in the transmitter application, refer to Figure 5. Finally, click the read button in the

receiver application, refer to Figure 6.

Figure B5. Transmitter application GUI

FGCU- 66

Figure B6. Receiver application GUI

The eBox 2300 transmitter application does not work with the USB telemetry board,

because the telemetry board driver configurations are not clear at this point, so it only works

when a serial cable is connected to its COM 1 port. Then, the other end of the serial cable

should connect to a PC’s COM port; make sure that serial port in the software application

matches the PC’s COM port.

FGCU- 67

Appendix C Power System Design

C1 Power System Background

In this section we will explore how power will be provided for the FGCU FUNSAT. The FGCU

FUNTSAT Electrical Power System (EPS) will supply sufficient power for all subsystems of the

satellite. The power supply system will consist of a photovoltaic solar array, battery system, and

the means of managing and distributing power throughout the satellite. Power for the FGCU

FUNSAT will be provided by solar cells that will also charge a battery for use during those times

when there is insufficient solar energy to provide for the satellite.

C2 Overview

Electrical power is required by all satellites to operate communications, navigational,

and experimental equipment. The sun provides a main source of power, with the sun’s rays

being harnessed by arrays of photovoltaic cells mounted on the exterior of the satellite. When

the satellite passes through the earth's shadow, solar power is unavailable. Backup power is

then provided by chemical batteries. Due to the extreme environment in which they are

deployed, as well as the inability to effect repairs once they are launched in to orbit, power

supply systems for picosatellites must be robust as well as fault tolerant. An added challenge is

the size and weight constraints. In larger satellites, fault tolerance is usually accomplished by the

use of redundant systems. The 10cm3 volume, 1 kg mass requirements of FUNSAT demands a

simpler approach to the design of the EPS. Redundant systems are not possible in picosatellites,

which mean that there is a higher probability of failure for these smaller satellites. However,

given the nature of picosatellites, in that they are mainly used by universities with limited

budgets as teaching tools, the higher risks for failure are considered acceptable.

The main objectives for the FUNSAT EPS are to maximize the power available to all

FGCU- 68

subsystems of the satellite, and to provide power with a high energy and space efficiency. The

basic architecture of the EPS is shown in figure xx. Main power will be provided by solar panels

on the exterior of the satellite. They will provide sufficient power to supply the electrical needs

of the satellite as well as charging the battery. One of the main drawbacks to having batteries on

satellites is their weight and size, which can take up a relatively large portion of the weight of

the satellite. Lithium-ion polymer batteries, or Li-Po batteries, will be used to provide power

when the earth’s shadow blocks the satellite from direct sun light. Li-Po batteries have highest

power to weight ratio than any other battery available. Li-Po battery packs have been chosen for

their high energy density and their proven usefulness in earlier space applications.

The Power Management Circuit will control how power is collected and supplied to the

subsystems of the satellite. The Power Management Circuit will electrically isolate the solar

panels from the rest of the satellite. It will monitor the power supplied by the solar panels and,

if the solar panels cannot meet the load requirements of the satellite, including the charging of

the battery, it will allow the batteries to supply the power until the solar panels are able to meet

the electrical demands. Regardless of the source of power, to efficiently supply the different

voltages required by the FUNSAT subsystems, all electrical power will be will be routed through

a DC/DC converter to properly condition and regulate the different voltages required by the

FUNSAT subsystems.

FGCU- 69

Power Management Circuit

DC-DC Converter

FUNSAT Load

FUNSAT Load

FUNSAT Load

FUNSAT Load

Solar Panels

Battery

DC-DC Converter

DC-DC Converter

DC-DC Converter

Figure C1 Overview of Electrical Power System

C3 FGCU FUNSAT Power Supply Components

For the FGCU FUNSAT, we will be utilizing the eBox 2300. The power requirements of the

eBox 2300 are 7-14 watts at 5 volts. The equation for power in watts, P=VI, where V = volts and I

= current in amps, shows that for the eBox 2300 to operate at 14 watts at 5 volts, we would

need solar cells that supply a minimum of 14/5 = 2.8 amps. A typical commercial off the shelf

solar cell is the Powerfilm MP7.2-150. This is a flexible film solar cell with dimensions (length x

width x thickness) of 253 x 150 X 0.6 mm. The MP7.2-150 has an operating voltage of 7.2 volts

and supplies 200mA. Therefore, 15 MP7.2-150 would be required to supply 3 amps to meet the

power requirements of the eBox 2300. The Powerfilm MP7.2-150 solar cell is shown in figure xx.

FGCU- 70

Figure C2 Powerfilm MP7.2-150 solar cell

The batteries used for the FGCU FUNSAT will consist of four Li-Po batteries. Since

commercially available individual Li-Po cells have a nominal voltage of 3.7 volts, two cells in

series supplying 7.4V will be necessary to provide the 5 volts required by the eBox 2300. The

typical capacity of 3.7V Li-Po batteries is 2100mAh. To supply the required 3 amps required by

the eBox 2300, we would need two Li-Po batteries in parallel to give a minimum capacity of

4200mAh, or 4.2 amps for one hour. The specification for the configuration of Li-Po battery

packs is represented by the standard xsyp naming scheme, where “x” represents the number of

cells in series and the “y” represents the number of cells wired in parallel.

A commercially available Li-Po battery pack is the Thunder Power 2100mAh 2-Cell 7.4V

LIPO16GA. Weighing 0.09 kg, it has a capacity of 2100mAh and a nominal voltage of 7.4V

supplied by two cells in a 2S configuration. Two of these packs will be wired in parallel to

provide the required capacity. The Thunder Power Li-Po pack is shown in figure xx.

FGCU- 71

Figure C3 Power 2100mAh 2-Cell 7.4V LIPO16GA

FGCU- 72

Appendix C Reference

[1] Christopher Alan Day, The Design of an Efficient, Elegant, and Cubic Pico-Satellite

Electronics System, California Polytechnic State University, Master’s Thesis, December

2004

[2] Craig S. Clark, Kevin W Hall, Power System Design and Performance on the World’s Most

Advanced In-Orbit Nanosatellite, Surrey Satellite Technology Limited, Surrey Space

Centre, University of Surrey, Guildford, Surrey, U.K.

[3] Wajid Hassan, Implementation of an Intelligent and Reliable Power supply management

system of a Small Satellite, Department of Electronic Engineering, Usman Institute of

Technology, Pakistan, http://www.slideshare.net/ieeepkhi/power-supply-management-

system-of-a-small-satellite-by-wajid-presentation

[4] E. J. Simburger, S. Liu, J. S. Halpine, D. A. Hinkley, D. L. Rumsey, J. Swenson, J. E.

Granata, H. Yoo, Pico Satellite Solar Cell Testbed (PSSC Testbed) Design, Space and

Missile Systems Center, Air Force Space Command, El Segundo, CA, September 30, 2007

[5] What Exactly are LiPo Battery Packs?, http://www.hooked-on-rc-airplanes.com/lipo-

battery-packs.html

http://www.slideshare.net/ieeepkhi/power-supply-management-system-of-a-small-satellite-by-wajid-presentation�

http://www.slideshare.net/ieeepkhi/power-supply-management-system-of-a-small-satellite-by-wajid-presentation�

http://www.hooked-on-rc-airplanes.com/lipo-battery-packs.html�

http://www.hooked-on-rc-airplanes.com/lipo-battery-packs.html�

FGCU- 73

Appendix D FOCSS Code using System; using System.Collections.Generic; using System.Text; using System.IO.Ports; using System.Threading; namespace Serial_Test { /* attempts to configure a serial port to reading and writing * and, if successful, allows user input from a console window * to be written to this serial port and allows data sent to it * to be displayed in the same console window */ class SerialTest { /* instance of the SerialPort class provided * by the .NET framework. provides methods for * reading, writing, and configuring the serial port */ SerialPort sp; /* the number of serial ports available */ int numPorts; /* an array of port names is maintained by the * operating system. this is the index of the * name of the serial port in used */ int portNameIndex; /* baud rate of the serial ports as required * by the telemetry modules */ const int baudRate = 19200; /* Thread object which is used to initiate a new * thread. used to execute the ReadThread method * independently */ Thread t; /* class constructor. configures the serial port and * begins executing the read and write components */ public SerialTest() { openPort(); ThreadStart rt = new ThreadStart(ReadThread); t = new Thread(rt); t.Start(); WriteThread(); } /* loops through all available port names, attempting * to open each. when a port is successfully opened,

FGCU- 74

* it is assigned to the instance vairable "sp" */ public void openPort() { numPorts = SerialPort.GetPortNames().Length; for (int i = 0; i < numPorts; i++) { try { sp = new SerialPort(SerialPort.GetPortNames()[i], baudRate, Parity.None, 8, StopBits.One); if (!sp.IsOpen) { Console.Write("Attempting to open COM" + i + "... "); sp.Open(); Console.Write("Success\n"); portNameIndex = i; break; } } catch (Exception e) { /* an exception occurred while opening the port */ System.Console.Write("Failed to open COM" + i + "\n"); continue; } } } /* writes the given string to the serial port "sp". * if the write fails or if the port is closed, the * openPort method is call to reinitialize it */ public void writeToCOM(String s) { if (sp.IsOpen) { try { sp.Write(s); } catch { /* an exception occurred during writing. attempt to reopen it */ Console.Write("Error writing to COM" + portNameIndex + "\nReinitializing the serial port...\n"); openPort(); } } else { /* the current serial port is not open. reopen it */ Console.Write("Port COM" + portNameIndex + " closed unexpectedly\nReinitializing the serial port...\n"); openPort(); }

FGCU- 75

} /* reads all available data from the serial port's * read buffer and returns this data as a string */ public String readFromCOM() { String output = ""; if (sp.IsOpen) { if (sp.BytesToRead > 0) { try { output = sp.ReadExisting(); } catch { /* an exception occurred while reading from the serial port. attempt to reopen it */ Console.Write("Error reading from COM" + portNameIndex + "\nReinitializing the serial port...\n"); openPort(); } } } else { /* the current serial port is not open. reopen it */ Console.Write("Port COM" + portNameIndex + " closed unexpectedly\nReinitializing the serial port...\n"); openPort(); } return output; } /* continually reads from serial port and displays * the result on the console window. the thread is * allowed to sleep briefly to reduce processor load */ public void ReadThread() { while (true) { Console.Write(readFromCOM()); Thread.Sleep(50); } } /* continually checks the console window for user input. * if the entered text is "exit", the program exits, aborting * both threads. all other text is written to the serial port's * write buffer. the thread is allowed to sleep briefly to * reduce processor load */ public void WriteThread() { String input = ""; while (true) {

FGCU- 76

/* read from the console and place it in a temporary variable */ input = Console.ReadLine(); /* abort the other thread, close the port, and return */ if (input.CompareTo("exit") == 0) { t.Abort(); if (sp.IsOpen) sp.Close(); return; } else { /* if text has been entered, write it to the serial port */ if (input.CompareTo("") != 0) { writeToCOM(input); } } Thread.Sleep(50); } } /* program entry point */ public static void Main() { /* instanciate a new SerialTest object * to execute its constructor */ new SerialTest(); } } }

FGCU- 77

Appendix E Antenna Instructions The Antennas in this article were built as the result of several discussions between Kent and a Cuban radio operator. While there are plenty of high performance antenna designs, most of the parts required to build them are not available in Cuba. There just isn't an EPO or Radio Shack available in Cuba. Kent accepted this as a challenge to design a really good antenna that could be built with little more than ground wire, coax and a wooden boom. Using the latest antenna design software, he has developed several variations for 144 thru 1296 MHz. Apparently, the designs work very well... Kent entered the 432 MHz version in a recent antenna contest and lost by 0.2 dB to a Midwest ham who had copied his design. Though disappointed in losing, it did prove to Kent that the antennas can be easily replicated with consistant performance.] If you're planning to build an EME array, don't use these antennas. But, if you want to put together a Rover station with less than $500 in the antennas or just want a good antenna for the home, read on. These antennas are relatively small, easily constructed from common materials/tools and have surprising performance. The feed method is greatly simpified by directly soldering the coax to the driven element. No baluns or gamma matches are used in this design. This simplified feed uses the structure of the antenna itself for impedance matching. The spacing of the director and reflector elements from the driven element directly affects the feed point impedance of the antenna. So, the design starts with the feed (driven element) and the elements are built around it. Typically, a high gain antenna is designed in the computer, then you try to come up with a matching arrangement for a 31.9 Ohm feed! For the cost about 0.5 dB of gain, these antennas make some design compromises for the feed impedance, use an asymmetrical feed and make trade offs for a very clean pattern. But, they allow simple measurements, have wide bandwidth, the ability to grow with the same element spacing AND... you can build these antennas for $5!!!! The booms used for these antennas is 1/2" X 3/4" wood. The elements have been made from silicon bronze welding rod, aluminum rod, hobby tubing and solid ground wire with no change in performance. Since you want to be able to solder to the driven element, silicon bronze welding rod, hobby tubing and #10 or #12 solid copper wire have been used and work fine. A drop of "Super Glue", epoxy or RTV is used to hold the elements in place. A good coat of Polyurethane should be applied to the wooden boom to protect it from the weather. A polyurethane varnished 902 MHz version has been in the air for a year now with little deterioration in performance. And now for the antenna designs. These antennas have been carefully designed to have the highest dB's/Dollar ratio of anything around They were designed with YagiMax, tweaked using NEC and the driven elements experimentally determined on the antenna range. The driven element design is the same for all frequencies except for the length (L) and separation (H). See the drawing below for details on the driven element. All dimensions are in inches. Antenna Designs By Band:

FGCU- 78

144 MHz. This antenna is peaked for 144.2 MHz but performance is still good at 146.52 (emergency use only!). Driven element dimensions are L = 38.5" and H = 1.0" Elements are 1/8" diameter.

144 MHz REF DE D1 D2 D3 D4

3 Ele Length Spac'g

41.00 0.00

8.50

37.00 20.00

4 Ele Length Spac'g

42.00 0.00

8.50

37.50 19.25

33.00 40.50

6 Ele Length Spac'g

40.50 0.00

7.50

37.50 16.50

36.50 34.00

36.50 52.00

32.75 70.00

222 MHz. This antenna is peaked for 222.1 MHz but performance barely changes at 223.5 MHz. Driven element dimensions are L = 24.5" and H = 1.0" Elements are 3/16" diameter.

222 MHz REF DE D1 D2 D3 D4

3 Ele Length Spac'g

26.00 0.00

5.50

23.75 13.50

4 Ele Length Spac'g

26.25 0.00

5.00

24.10 11.75

22.00 23.50

6 Ele Length Spac'g

26.25 0.00

5.00

24.10 10.75

23.50 22.00

23.50 33.75

21.00 45.50

432 MHz. This antenna is peaked for 432.1 MHz. At this frequency, this antenna is getting very practical and easy to build. Driven element dimensions are L = 13.0" and H = 3/8" Elements are 1/8" diameter.

432MHz REF DE D1 D2 D3 D4 D5 D6 D7 D8 D9

6 Ele Length Spac'g

13.50 0.00

2.50

12.50 5.50

12.00 11.25

12.00 17.50

11.00 24.00

8 Ele Length Spac'g

13.50 0.00

2.50

12.50 5.50

12.00 11.25

12.00 17.50

12.00 24.00

12.00 30.75

11.25 38.00

11 Ele Length Spac'g

13.50 0.00

2.50

12.50 5.50

12.00 11.25

12.00 17.50

12.00 24.00

12.00 30.75

12.00 38.00

11.75 45.50

11.75 53.00

11.00 59.50

902/903 MHz. This was the first antenna I built using the antenna to control the driven element impedance. The 2 1/2' length has proven practical, so I haven't built any other versions. Driven element dimensions are L = 5.7" and H = 1/2" Elements are 1/8" diameter.

902/3 MHz REF DE D1 D2 D3 D4 D5 D6 D7 D8

10 Ele

Length Spac'g

6.20 0.00

2.40

5.60 3.90

5.50 5.80

5.50 9.00

5.40 12.40

5.30 17.40

5.20 22.40

5.10 27.60

5.10 33.00

1296 MHz. This antenna is the veteran of several "Grid Peditions" but I have yet to actually measure the gain. Dimensions must be followed with great care. The driven element is small enough to allow 0.141 semi-rigid coax to be used instead of RG-58. Silicon Bronze welding rod was used for the elements but any material can be used. Driven element dimensions are L = 4.0" and H = 1/2" Elements are 1/8" diameter.

FGCU- 79

1296 MHz REF DE D1 D2 D3 D4 D5 D6 D7 D8

10 Ele

Length Spac'g

4.30 0.00

1.70

3.90 2.80

3.80 4.00

3.75 6.40

3.75 8.70

3.65 12.20

3.60 15.60

3.60 19.30

3.50 23.00

OTHER VERSIONS 421.25 MHz ATV. 421 MHz Vestigial Sideband video is popular in North Texas for receiving the FM video repeaters. The driven element for these antennas is designed for an impedance of 75 ohms. So RG-59, or an `F' adapter to RG-6, can be directly connected to a cable TV converter/Cable Ready TV on channel 57. Driven element dimensions are L = 13.0" and H = 1/2" Elements are 1/8" diameter. Spacing is the same for all versions.

421 MHz ATV REF DE D1 D2 D3 D4 D5 D6 D7 D8 D9

6 Ele Length 14.00 12.50 12.25 12.25 11.00 8 Ele Length 14.00 12.50 12.25 12.25 12.00 12.00 11.25


14.00 0.00

3.00

12.50 6.50

12.25 12.25

12.25 17.75

12.00 24.50

12.00 30.50

12.00 36.00

11.75 43.00

11.75 50.25

11.50 57.25

450 MHz FM. Yea, I understand it's FM, but sometimes a newcomber needs a cheap antenna to get into a repeater or give you a simplex QSO during a contest. Driven element dimensions are L = 12.0" and H = 3/8" Elements are 1/8" diameter. Spacing is the same for all versions.

450 MHz FM REF DE D1 D2 D3 D4

6 Ele Length Spac'g

13.00 0.00

2.50

12.10 5.50

11.75 11.00

11.75 18.00

10.75 28.50

435 MHz AMSAT. The larger versions have not been fully tested and I appreciate the help and motivation from KA9LNV for these antennas. Updates and performance evaluations are planned for a later edition of the AMSAT Journal. A high Front-to-Back ratio was the major design consideration for all versions. The computer predicts 30 dB F/B for the 6 element and over 40 dB for the others. NEC predicts 11.2, 12.6, 13.5 and 13.8 dBi for the 6, 8, 10 and 11 element respectively. Using 3/4" square wood makes it easy to build two antennas on the same boom for cross- polarized operation. Offset the two antennas 6 1/2" and feed in phase for Circular Polarization. Or, just build one antenna for portable operation. Driven element dimensions are L = 13.0" and H = 1/2" Elements are 1/8" diameter. Spacing is the same for all versions.

435 MHz AMSAT REF DE D1 D2 D3 D4 D5 D6 D7 D8 D9

6 Ele Length 13.40 12.40 12.00 12.00 11.00 8 Ele Length 13.40 12.40 12.00 12.00 12.00 12.00 11.10 10 Ele Length 13.40 12.40 12.00 12.00 12.00 12.00 11.75 11.75 11.10


13.40 0.00

2.50

12.40 5.50

12.00 11.25

12.00 17.50

12.00 24.00

12.00 30.50

11.75 37.75

11.75 45.00

11.75 52.00

11.10 59.50

FGCU- 80

Appendix F EBox USB Driver ; FTDIPORT.INF ; Copyright (c) 2000-2009 FTDI Ltd. ; ; USB serial port driver installation file for Windows 2000, XP, Server 2003, Vista, Server 2008, ; Windows 7 and Server 2008 R2 (x86 and x64). ; ; FTDI device drivers may be used only in conjunction with products based on FTDI parts. ; The driver may be distributed in any form as long as our license information is not modified. ; If a custom Vendor ID and/or Product ID, or description string are used, it is the responsibility of ; the product manufacturer to maintain any changes and subsequent WHQL re-certification as a result of ; making these changes. ; ; [Version] Signature="$Windows NT$" DriverPackageType=PlugAndPlay DriverPackageDisplayName=%DESC% Class=Ports ClassGUID={4d36e978-e325-11ce-bfc1-08002be10318} Provider=%FTDI% CatalogFile=ftdiport.cat DriverVer=10/22/2009,2.06.00 [SourceDisksNames] 1=%DriversDisk%,,, [SourceDisksFiles] ftser2k.sys=1,i386 ftserui2.dll=1,i386 ftcserco.dll = 1,i386 [SourceDisksFiles.amd64] ftser2k.sys=1,amd64 ftserui2.dll=1,amd64 ftcserco.dll = 1,amd64 [DestinationDirs]

FGCU- 81

FtdiPort.NT.Copy=10,system32\drivers FtdiPort.NT.CopyUI=10,system32 FtdiPort2232.NT.CopyCoInst=10,system32 [ControlFlags] ExcludeFromSelect=* [Manufacturer] %FTDI%=FtdiHw,NTamd64 [FtdiHw] %VID_0403&PID_E548.DeviceDesc%=FtdiPort232.NT,FTDIBUS\COMPORT&VID_0403&PID_E548 %VID_0403&PID_6001.DeviceDesc%=FtdiPort232.NT,FTDIBUS\COMPORT&VID_0403&PID_6001 %VID_0403&PID_6010.DeviceDesc%=FtdiPort2232.NT,FTDIBUS\COMPORT&VID_0403&PID_6010 %VID_0403&PID_6011.DeviceDesc%=FtdiPort2232.NT,FTDIBUS\COMPORT&VID_0403&PID_6011 [FtdiHw.NTamd64] %VID_0403&PID_E548.DeviceDesc%=FtdiPort232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_E548 %VID_0403&PID_6001.DeviceDesc%=FtdiPort232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6001 %VID_0403&PID_6010.DeviceDesc%=FtdiPort2232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6010 %VID_0403&PID_6011.DeviceDesc%=FtdiPort2232.NTamd64,FTDIBUS\COMPORT&VID_0403&PID_6011 [FtdiPort.NT.AddService] DisplayName = %SvcDesc% ServiceType = 1 ; SERVICE_KERNEL_DRIVER StartType = 3 ; SERVICE_DEMAND_START ErrorControl = 1 ; SERVICE_ERROR_NORMAL ServiceBinary = %10%\system32\drivers\ftser2k.sys LoadOrderGroup = Base ; -------------- Serenum Driver install section [SerEnum_AddService] DisplayName = %SerEnum.SvcDesc% ServiceType = 1 ; SERVICE_KERNEL_DRIVER StartType = 3 ; SERVICE_DEMAND_START ErrorControl = 1 ; SERVICE_ERROR_NORMAL ServiceBinary = %12%\serenum.sys LoadOrderGroup = PNP Filter

FGCU- 82

[FtdiPort.NT.AddReg] HKR,,EnumPropPages32,,"ftserui2.dll,SerialPortPropPageProvider" [FtdiPort.NT.Copy] ftser2k.sys [FtdiPort.NT.CopyUI] ftserui2.dll [FtdiPort232.NT] CopyFiles=FtdiPort.NT.Copy,FtdiPort.NT.CopyUI AddReg=FtdiPort.NT.AddReg [FtdiPort232.NTamd64] CopyFiles=FtdiPort.NT.Copy,FtdiPort.NT.CopyUI AddReg=FtdiPort.NT.AddReg [FtdiPort232.NT.HW] AddReg=FtdiPort232.NT.HW.AddReg [FtdiPort232.NTamd64.HW] AddReg=FtdiPort232.NT.HW.AddReg [FtdiPort232.NT.Services] AddService = FTSER2K, 0x00000002, FtdiPort.NT.AddService AddService = Serenum,,SerEnum_AddService DelService = FTSERIAL [FtdiPort232.NTamd64.Services] AddService = FTSER2K, 0x00000002, FtdiPort.NT.AddService AddService = Serenum,,SerEnum_AddService DelService = FTSERIAL [FtdiPort232.NT.HW.AddReg] HKR,,"UpperFilters",0x00010000,"serenum" HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,71,02,00,00,38,41,00,00,9C,80,00,00,4E,C0,00,00,34,00,00,00,1A,00,00,00,0D,00,00,00,06,40,00,00,03,80,00,00,00,00,00,00,D0,80,00,00 HKR,,"MinReadTimeout",0x00010001,0 HKR,,"MinWriteTimeout",0x00010001,0 HKR,,"LatencyTimer",0x00010001,16 ; ------------------------------------------------------------------------------ ;

FGCU- 83

; Multiple interface device section - includes FT2232C/D/L, FT2232H and FT4232H ; ; ------------------------------------------------------------------------------ [FtdiPort2232.NT] CopyFiles=FtdiPort.NT.Copy,FtdiPort.NT.CopyUI AddReg=FtdiPort.NT.AddReg [FtdiPort2232.NTamd64] CopyFiles=FtdiPort.NT.Copy,FtdiPort.NT.CopyUI AddReg=FtdiPort.NT.AddReg [FtdiPort2232.NT.HW] AddReg=FtdiPort232.NT.HW.AddReg [FtdiPort2232.NTamd64.HW] AddReg=FtdiPort232.NT.HW.AddReg [FtdiPort2232.NT.CoInstallers] AddReg=FtdiPort2232.NT.CoInstallers.AddReg CopyFiles=FtdiPort2232.NT.CopyCoInst [FtdiPort2232.NTamd64.CoInstallers] AddReg=FtdiPort2232.NT.CoInstallers.AddReg CopyFiles=FtdiPort2232.NT.CopyCoInst [FtdiPort2232.NT.Services] AddService = FTSER2K, 0x00000002, FtdiPort.NT.AddService AddService = Serenum,,SerEnum_AddService DelService = FTSERIAL [FtdiPort2232.NTamd64.Services] AddService = FTSER2K, 0x00000002, FtdiPort.NT.AddService AddService = Serenum,,SerEnum_AddService DelService = FTSERIAL [FtdiPort2232.NT.CoInstallers.AddReg] HKR,,CoInstallers32,0x00010000,"ftcserco.Dll,FTCSERCoInstaller" [FtdiPort2232.NT.CopyCoInst] ftcserco.dll ;---------------------------------------------------------------; [Strings] FTDI="FTDI"

FGCU- 84

DESC="CDM Driver Package" DriversDisk="FTDI USB Drivers Disk" PortsClassName = "Ports (COM & LPT)" VID_0403&PID_E548.DeviceDesc="USB Serial Port FOCSS" VID_0403&PID_6001.DeviceDesc="USB Serial Port" VID_0403&PID_6010.DeviceDesc="USB Serial Port" VID_0403&PID_6011.DeviceDesc="USB Serial Port" SvcDesc="USB Serial Port Driver" SerEnum.SvcDesc="Serenum Filter Driver"

florida university satellite...

Documents