Docstoc

Boston University Electrical _ Computer Engineering Project

Document Sample
Boston University Electrical _ Computer Engineering Project Powered By Docstoc
					                          Boston University
                 Electrical & Computer Engineering
                         EC463 Senior Design Project


                            Project Proposal

   Command and Data Handling Subsystem for Boston
    University Student-satellite for Applications and
                       Training

                                 Submitted to

                                  David Voss
                       Boston University ECE Department
                          Photonics Center Room 416
                             8 Saint Mary’s Street
                              Boston, MA 02215
                                617-894-3494
                                dvoss@bu.edu

                                      by

                                  Team 17
                               BUSAT – C&DH


                                Team Members

                          Peter Argue pargue@bu.edu
                         Aaron Desrosies aarond@bu.edu
                          Bandish Shah bshah@bu.edu
                         Adriel Wallick aew123@bu.edu



                        For the Period of Performance:
                       December 14, 2007 – May 2, 2008

                         Submitted: December 13, 2007


Team 17 BUSAT C&DH                                        03/17/08
Project Proposal                                                                                                                                                           ii




                                                          Table of Contents

  Executive Summary................................................................................................................................... iii
  1.0    Introduction .................................................................................................................................... 1
  2.0    Concept Development .................................................................................................................... 4
  2.1    Problem........................................................................................................................................... 4
  2.2    Conceptual Approach ..................................................................................................................... 4
  2.3    Preliminary Results......................................................................................................................... 6
  3.0    System Description ......................................................................................................................... 8
  4.0    Technical Plan ...............................................................................................................................14
  5.0    Budget Estimate .............................................................................................................................17
  6.0    Attachments ...................................................................................................................................18
  6.1    Appendix 1 – Specifications ..........................................................................................................18
  6.2    Appendix 2 – Gantt Chart ..............................................................................................................19
  6.3    Appendix3 – Additional Appendices .............................................................................................21
  6.3.1 Packet Structures ...........................................................................................................................21
  6.3.2 Power Analysis Documentation ....................................................................................................22
  6.3.3 Team Information ..........................................................................................................................23
  6.3.4 Technical References .....................................................................................................................24




Team 17 BUSAT C&DH                                                                                                                                              03/17/08
Project Proposal                                                                                 iii




                                 Executive Summary
                                      BUSAT – C&DH
                                         Team 17


The Boston University Student-satellite for Applications and Training (BUSAT) is a
College of Engineering and Center for Space Physics joint initiative. The project goal is
to produce a student constructed satellite to investigate space weather effects. Our senior
design project addresses the problem of providing control and data handling for BUSAT
instruments and subsystems.

The Command and Data Handling unit will relay commands and provide control to
BUSAT instruments and subsystems. It will also collect, appropriately process and store
data from instruments and subsystems until ground contact is confirmed and can be
transmitted.

The final deliverable will consist of a functional system consisting of microcontrollers for
subsystem control interfaced to the main single board computer over the high bandwidth,
noise resilient multiplexed data bus.




Team 17 BUSAT C&DH                                                                    03/17/08
Project Proposal                                                                                         1



1.0     Introduction

Boston University Student-satellite for Applications and Training (BUSAT) is comprised
of seven subsystems, including five instruments, which require a method of sending and
receiving commands and data throughout the satellite (Fig.1). This means of relaying
commands and data must be modular, low power, and be capable of managing all intra-
satellite communications.




                   Figure 1 – Conceptual block diagram of customer’s problem to be solved

BUSAT is participating in Nanosat-5, a competition held by the University Nanosat
Program, a joint program between the Air Force Research (AFRL), the Air Force Office
of Scientific Research (AFOSR), and the American Institute of Aeronautics and
Astronautics (AIAA). The purpose of Nanosat-5 is to educate and train students in the
area of small satellite fabrication and design through a national student satellite
competition. The competition is two years long culminating in January of 2009 with the
Flight Competition Review (FCR). The program sponsors will then judge the designs of
each of the eleven participating universities and choose a winner. The university with a
flight worthy design, or best engineering practices if there is more than one successful
project, will begin flight integration and testing, ultimately leading up to a launch
opportunity.

BUSAT aims to create a satellite that will perform measurements of the precipitating
energetic electron fluxes from Low Earth Orbit (LEO) over the high latitude auroral
zones and simultaneously image the auroral emissions caused by these electrons1. It is
currently in the first year of the Nanosat-5 competition and our senior design team will be
participating until May 2008. By this time, we will have created a working prototype of
the Command and Data Handling (C&DH) system that will be presented at the
Conceptual Design Review (CDR) and Proto-Qualification Review (PQR). It is
imperative that we keep detailed and meticulous documentation as we will graduate
before the FCR and will have to pass the project on to a new group of students.




Team 17 BUSAT C&DH                                                                            03/17/08
Project Proposal                                                                                   2


The C&DH system will facilitate communication between the seven subsystems and the
ground station while utilizing the high level of modularity that the BUSAT requires. This
will be accomplished by dividing the C&DH into two distinct layers; the microcontroller
layer and the Single Board Computer (SBC) layer. The SBC layer (Fig. 2) will consist of
an SBC that will interface with a central routing module, an Auroral Imager, and a
communication system. The microcontroller layer (Fig. 3) will consist of voltage relays
and a microcontroller. The microcontroller layer will connect to each respective
subsystem via a subsystem interface board. Each subsystem managed by the C&DH
(except for the Auroral Imager and communication system, which require separate serial
buses) will be routed through a central routing module. This module will utilize an FPGA
to route the commands to the appropriate subsystem.




                   Figure 2 -Conceptual block diagram of Single Board Computer module




                     Figure 3 – Conceptual block diagram of Microcontroller Module

To further facilitate the modularity of BUSAT, a standard format for the data and
command packets has been created. Using a standard packet format simplifies the
software the SBC layer will use to send commands to the subsystems. Utilizing a
standardized data packet format will create a simpler method of storing data until the
communications system is able to transmit to the ground station.

This design promotes modularity and utilizes components which satisfy the
communication requirements (Requirements: Appendix 6.1) while still consuming less
Team 17 BUSAT C&DH                                                                      03/17/08
Project Proposal                                                                            3


than 5W of power (Power Analysis: Appendix 6.3.2). The two main design features that
facilitate the modularity of BUSAT are the standardized packet structures and the
separation of the C&DH into two separate layers. By splitting the C&DH into two layers
and mapping all communication through a routing module, neither layer requires a
specialized interface.




Team 17 BUSAT C&DH                                                               03/17/08
Project Proposal                                                                                    4




2.0     Concept Development
        2.1        Problem
        BUSAT requires a method of controlling satellite operation and communication,
        both among subsystems and with the ground station. Additionally, this system is
        required to make use of a modular design to allow for rapid development of future
        space missions as well as integration of legacy instruments.

        In order to meet the requirements, the C&DH subsystem must collect and store
        science and housekeeping data collected by each subsystem. Once data is
        collected, there must be a method of communicating the data to the ground station
        for analysis and receiving new instructions and updates from the command center
        at Boston University. Finally, the C&DH system must be able to relay the new
        information to the appropriate subsystems.

        2.2        Conceptual Approach
        The conceptual approach employed in the design revolves around simplicity and
        modularity; allowing for a robust system that facilitates the rapid integration of
        new and legacy subsystems. Additionally, simplification makes it possible for a
        small group of inexperienced engineering undergraduates to design, test and
        construct a flight-worthy nanosatellite.

        Modularity is one of the primary design motivations behind the BUSAT project
        and is evident in the designs of all of the subsystems responsible for providing
        system wide interfaces: C&DH, Subsystem Cubes, Power, Thermal, and Ground
        Support Equipment. This design methodology allows for an easier testing process
        transitioning from unit tests to full system integration testing. It also simplifies the
        physical integration of subsystems that may have very different form factors.

        In the C&DH subsystem, modularity is accomplished by utilizing standardized
        interfaces and components. These interfaces can be broken down into layers of
        abstraction: component layer, module layer, communication layer and the system
        layer.

        2.2.1 Component Layer
        All components used for the C&DH system will be commercial-off-the-shelf
        (COTS) parts, which are cost effective, universally available and standardized as
        well as easy to implement. These standardized components include the
        microprocessors/FPGAs, communication transceivers, board connectors, and the


Team 17 BUSAT C&DH                                                                       03/17/08
Project Proposal                                                                               5


        SBC. By using COTS, the design is easier to implement, since the components are
        already available, and also easy to reuse again in the future.

        2.2.2 Module Layer
        Each subsystem, with the exception of the Communications, Auroral Imager and
        Deployables subsystems, will have an interface board in their respective cube that
        will serve as the communications portal to the rest of the satellite. Those
        subsystems that do not have an interface board have special requirements and this
        design provides a means of accommodating for them by specifying the protocol
        they use for communication.

        Each interface board, also known as a Microcontroller Module, is identical and
        contains all of the necessary components to manage the data and commands for
        the individual subsystem. It also provides a means of communication with the rest
        of the satellite. The Microcontroller Module is responsible for relaying
        information to and from the subsystem and maintaining system variables such as
        elapsed mission time and communication housekeeping data.

        2.2.3 Communication Layer
        In order to create a truly modular system, the means of communication between
        each node must be carefully designed. Over the course of the preliminary design
        phase, several options were considered.

        First, we considered wireless communication between the subsystems. This
        preliminary design was appealing because it did not require any form of physical
        connection, and the technology involved was cheap and readily available. Some
        wireless technologies use very small amounts of power (~1mW for Zigbee) and
        they all provide sufficient bandwidth. However, wireless technology has never
        been fully tested in a space environment, and since BUSAT’s primary mission
        objective is science research, an added experimental variable is an unnecessary
        risk to the success of the mission.

        The second approach was multipoint communication. Although it seemed to be a
        modular solution, it lacked the simplicity that was desired. Using a multipoint
        communication bus required that we either create a collision detection scheme
        and handle the bus arbitration, or use a standard protocol that would add
        unnecessary overhead to the system. Additionally, multipoint typically consumes
        more power since the data signals are sent along every communication line in the
        satellite.



Team 17 BUSAT C&DH                                                                  03/17/08
Project Proposal                                                                                  6


        Ultimately, we decided to use a point-to-point method with a multiplexed
        communication bus. Collisions are avoided by adopting the master-slave
        relationship between the SBC Module and the Microcontroller Modules
        respectively. The point-to-point method also simplifies the data collection
        procedure by giving the SBC Module full control over when data will be received.
        Additionally, point-to-point makes the system more robust by making it possible
        to completely isolate a subsystem that is not functioning properly.
        In addition to the physical medium of the communication bus, our design uses
        standardized command and data packets to carry and store the information. These
        standard formats allow for simple reusable packet creation and parsing algorithms
        and simplify data analysis by the scientists at the ground station.

        2.2.4 System Layer
        On the system level, the design must provide a means of maintaining satellite
        operation, collecting science and housekeeping data and transmitting all of the
        information to the ground station. In order to accomplish these tasks, the system
        must have a method to inform each subsystem of the necessary action that should
        be taken. As a result, we have created a series of standard commands that must be
        implemented by every subsystem. These commands represent operations include
        turning on/off, performing diagnostic tests, and sending data. In addition to these
        system commands, each subsystem will specify a set of custom commands
        specific to their needs. To handle the complexity that will inevitably arise from all
        seven subsystems running concurrently, we have opted to use a scheduler in
        conjunction with a command lookup table, also known as the Orbital Profile. This
        greatly simplifies the process by placing the responsibility of scheduling in the
        hands of the scientists at the ground station. The C&DH system must only follow
        the predetermined list and send out command packets at the associated time.

        2.3        Preliminary Results
        Our preliminary tests have been promising. We have implemented the point-to-
        point communication multiplexer on Xilinx Spartan 3 FPGA and run simulations
        in ModelSim SE verifying its functionality. The simulations have demonstrated
        the transfer of data through the multiplexer with path chosen by a set of select
        lines; our proof of concept implemented a 8x1 multiplexor for microcontroller to
        SBC communications and a 3x8 demultiplexor for SBC to microcontroller
        communication.

        We have also tested the power consumption of the Arcom Viper which will be
        used in the SBC Module. The test consisted of software to simulate maximum
        load on the computer by outputting data on the communication lines that will be
        used and also moving data around in memory. Data was also collected during
Team 17 BUSAT C&DH                                                                     03/17/08
Project Proposal                                                                                7


        startup and idle times to get a more complete picture of the power characteristics
        we can expect from the SBC Module during operation. The results suggest that
        the power consumption will fall within the acceptable range outlined by our
        requirements specification (Requirements: Appendix 6.1).
        Additionally, we have written software to output data via the UARTs on both the
        SBC and the microcontroller and receive the data for verification in MATLAB.




Team 17 BUSAT C&DH                                                                   03/17/08
Project Proposal                                                                                         8


3.0     System Description
The C&DH subsystem acts as a master controller for the instruments of the satellite. It
commands the instruments and stores their data until it can be transmitted to the ground
station. It also ensures smooth overall operation of the satellite by monitoring the health
of all subsystems.

The C&DH subsystem will send commands to subsystems on the satellite, receive and
process science and housekeeping data from these systems, and store the data until the
transmission link to the ground station is available. The system will communicate with
six instruments (Imaging Electron Spectrometer, Attitude, Magnetometer, Educational,
Deployables, and Power) using UART over the Low Voltage Differential Signaling
(LVDS) protocol. An FPGA in the Central Routing Module acts as a multiplexer to
perform the routing of intra-satellite packets to each instrument. The SBC and
microcontrollers are set up in a Master/Slave configuration.

The SBC uses an on-board lookup table to send instrument commands at fixed intervals.
An initial lookup table is loaded into memory before launch. After launch, users at the
ground station will upload updated lookup tables to the satellite as necessary. An
interrupt is triggered when an event in the lookup table is reached, and the SBC initiates
contact with the instrument. Once contact is made, the command(s) are sent to the
selected instrument.

The Auroral Imager captures images, and therefore needs a considerably higher data
transfer rate than the other instruments. Consequently, the SBC communicates with the
Auroral Imager using a USB version 1.1 interface. The SBC will extract the relevant
information and compress these images using lossless compression in order to save
memory space.

The C&DH system will communicate with the ground through a dedicated
communication subsystem. It will format the data into standardized telemetry packets and
then send the packets to the Communication subsystem over an RS-485 serial line. The
system will also receive standardized packets containing updated commands from ground
through this Communication subsystem.

The system will be capable of detecting and correcting up to 1-bit errors in data
transmission through an error detection and correction algorithm. Command codes in the
SBC and microcontrollers’ command sets will be chosen to ensure a single event upset
cannot result in an incorrect command execution. Also, each command packet contains a
checksum to verify that the command is transmitted correctly. The system will be reset




Team 17 BUSAT C&DH                                                                            03/17/08
Project Proposal                                                                            9
by the SBC’s watchdog timer if an instrument exhibits abnormal behavior, such as not
responding to commands.




Team 17 BUSAT C&DH                                                               03/17/08
Project Proposal                                                  10




                     Figure 4 – System Block Diagram




Team 17 BUSAT C&DH                                     03/17/08
Project Proposal                                                                                  11


A summary of the three major modules:

The SBC Module’s functions (Fig.5):
   • Form commands according to a standardized command packet protocol (Appendix
      6.3.1 Fig.11 )
   • Issue commands to the instruments over a multiplexed LVDS serial line
   • Receive data from the instruments over a multiplexed LVDS serial line
   • Provide the FPGA in the central routing module with a 3 bit select line for
      multiplexing the LVDS serial line
   • Command instruments as specified by the on-board lookup table
   • Update the lookup table upon reception of a new table from the ground station
   • Form packets from collected data according to a standardized telemetry packet
      protocol (Appendix 6.3.1 Fig.10)
   • Receive information from the Ground Station through the Communications
      subsystem over a dedicated RS-485 Line
   • Provide instrument Microcontroller Modules with a 1Hz clock signal, transmitted
      over LVDS, to synchronize data the mission clock among all subsystems
   • Issue commands and receive data from the Auroral Imager subsystem over a
      dedicated USB v1.1 Line
   • Process images received from the Auroral Imager
   • Operate via a 5v power source




                          Figure 5 – SBC Module block diagram




Team 17 BUSAT C&DH                                                                     03/17/08
Project Proposal                                                                         12
The Microcontroller Module’s functions (Fig.6):
   • Relay commands received from the SBC Module to the host instrument
   • Collect data in a shared memory location
   • Packetize collected data according to a standardized data packet protocol
      (Appendix 6.3.1 Fig.11)
   • Use the available 1Hz clock signal to timestamp data and packets
   • Send packetized data to the SBC Module over the communication bus upon
      request
   • Provide a 16 channel 10 bit ADC for incoming signals from the host instrument
   • Provide a 2x1 channel 8 bit DAC for outgoing signals to the host instrument
   • Operate via a 5v power source
   • Forward a 5v, 12v, or -12v power line to the instrument being controlled




                      Figure 6 – Microcontroller module block diagram




Team 17 BUSAT C&DH                                                            03/17/08
Project Proposal                                                                            13
The Central Routing Module’s functions (Fig.7):
   • Use an FPGA to provide bus selection
   • Route data from the SBC Module according to select lines
   • Operate via a 5v power source
   • Distribute a 1Hz clock signal from the SBC Module to each Microcontroller
      Module




                      Figure 7 – Central routing module block diagram




Team 17 BUSAT C&DH                                                               03/17/08
Project Proposal                                                                                       14


4.0     Technical Plan
In order to accomplish the technical challenge associated with this project, we have
divided tasks amongst the team members according to individual strengths in particular
topics. These strengths were determined during summer 2007 when we conducted
research for the BUSAT project in order to devise a preliminary design for an AFRL
Preliminary Design Review. The strengths each team member exhibited were taken into
account and the tasks were distributed accordingly.

In response to developing the proposed solution, we have divided the system into
hardware and software categories. These categories are divided further until we reached
the component level ensuring that all tiers of our proposed solution are addressed. The
two Computer System Engineering majors on the team are responsible for developing
and testing software while the two Electrical Engineering majors are responsible for
developing and testing hardware. The figure below outlines the overall system breakup.




                          Figure 8 – Breakdown of engineering flow

Hardware is broken into three subcategories corresponding to the SBC Module, the
subsystem level Microcontroller Module and the central routing module. The SBC
hardware is comprised of the SBC interface module and the SBC itself. The interface
module will house all the communications hardware responsible for allowing the SBC to
communicate over the LVDS data bus. The Microcontroller Module houses a
microcontroller for subsystem level control, a communications module to be able to
converse with the SBC and relays to control subsystem power. The central routing
module contains an FPGA multiplexer; thus Hardware Description Language (HDL)
code will have to be written for this component.

Software for the C&DH unit is divided in terms of software for the SBC and
microcontrollers. The software for each is then further divided to the level of
communications drivers for creating data packets and using the proper protocol to
communicate over the data bus. Software for the SBC is divided further still to the level



Team 17 BUSAT C&DH                                                                          03/17/08
Project Proposal                                                                                 15
of administering system level control and also polling software which is responsible for
communicating to each Microcontroller Module.

The development period for our project is broken up into four stages. First is the design
stage where hardware Printed Circuit Board (PCB) schematics and layouts will be
produced and software drivers will be created on development kits. Next, the PCB
population stage where the prototypes will be constructed, this stage is followed by the
Testing Phase where the functionality of the prototypes is verified and the developed
software is tested on the prototype hardware. Following individual unit testing, we will
enter the full system integration and verification stage where we connect all
independently developed components together and evaluate the functionality of the
integrated system. More information on these three stages can be found on our project
Gantt chart in Appendix 6.2

4.1     Tasks

Task 1           Hardware Schematics and PCB Layouts
Schematics for the Microcontroller Module and the SBC interface module shall be
drafted in Cadence Capture CIS and these designs must be sent out to the manufacturer
for fabrication.
Lead: Bandish Shah

Task 2          Breadboarding
Once the PCBs have been fabricated and received, they shall be populated with
components and physically tested for functionality. This task is dependent upon the
timely of arrival of ordered components.
Lead: Bandish Shah

Task 3        Unit Testing
After breadboard populating is complete and physical functionality has been verified, the
developed units will be tested for proper unit functionality with verification provided by
Labview.
Lead: Adriel Wallick

Task 4          Communications Drivers
A communications protocol shall be designed for the communications system for
BUSAT. Software drivers for the Microcontroller Module and SBC Module shall be
written to packetize data and commands according the designed communications protocol
and be able to operate at a data rate of 38,500bps. Upon completion of the development
stage, the drivers shall be tested on the development platform as well as the custom
designed hardware.
Lead: Peter Argue

Team 17 BUSAT C&DH                                                                    03/17/08
Project Proposal                                                                                 16


Task 5          Polling and Data Handling software
A data handling and polling manager shall be written for use on the SBC. This software
shall be required to poll the instruments over the multiplexed data bus, collect data over
USB, generate a real-time clock signal, and process data. Upon completion of
development, this software shall be tested on custom developed hardware.
Lead: Aaron Desrosiers

Task 6           System Integration, Verification and Testing
Once the development of individual system modules is completed and their functionality
is verified, the system shall be connected for integration. Functionality of components
with each other shall be tested. Operational conditions with appropriate test vectors shall
be tested.
Lead: Aaron Desrosiers, Adriel Wallick




Team 17 BUSAT C&DH                                                                    03/17/08
Project Proposal                                                                                      17


5.0     Budget Estimate
        BUSAT has been given a budget of $110k through the Nanosat-5 competition. Of
        this amount, the C&DH subsystem is allocated $5000 for development and
        prototyping costs. Below is the expected cost of development.

 Item       Description                                                            Cost
   1        Arcom Viper and Development Kit                                       $1400
   2        MC9S12E evaluation board                                               $250
   3        HCS12 programmer/debugger                                              $100
   4        Microcontroller Module Breadboard PCB                                  $100
   5        Central Routing Module Breadboard PCB                                  $100
   6        SBC Module Breadboard PCB                                              $100
   7        Breadboard components (capacitors, resistors, etc.)                     $50
   8        FPGA (Actel AX250)                                                      $40
   9        Microcontrollers (MC9S12E256)                                           $40
   10       Sockets (microcontrollers, transceivers, FPGA)                         $300
   11       PCB Enclosures                                                          $60
   12       LVDS Transceivers                                                      $100
   13       Microcontroller Module Prototype PCB                                   $200
   14       Central Routing Module Prototype PCB                                   $200
   15       SBC Module Prototype PCB                                               $200
            Total Cost                                                            $3240

        The Arcom Viper and development kit has already been purchased; everything
        below this item is money that will be spent during the remainder of the project.
        We hope to receive an Actel FPGA from the LCI project at Boston University,
        and plan to take use sample microcontrollers for our development purposes. All
        other items will need to be purchased for use on the C&DH system.




Team 17 BUSAT C&DH                                                                         03/17/08
   Project Proposal                                                                                      18



   6.0       Attachments

             6.1      Appendix 1 – Specifications

   Team #17                 Team Name: BUSAT – S&DH

   Project Name: BUSAT – C&DH

Specification                                 Value, range, tolerance, units
                         Modular hardware and software communication interface between all
                         subsystems as defined by the BUSAT project
System Level
                         Maintain simultaneous operation of 2 test instruments
                         < 5W of power for SBC module and Central Routing Module combined
Electrical               <500mW of Power for each Microcontroller Module
                         5V regulated power supply
                         Issue commands to the subsystems originating both locally and remotely
Computing                Provide data packet formatting for instruments
                         Collect and store up to 5MB per ~90 minute orbit of data from the
                         instruments
                         Communicate commands and data between the subsystems at a rate of
Communications           38,400 bps
                         Format data into standardized packets for transmission
                         SBC module fits within a 3.75” X 3.75” X 7.00” cubes.
                         Each individual subsystem shall house its own microcontroller board
Mechanical               comprised of a microcontroller and a communication transceiver.
                         The C&DH subsystem shall interface the subsystems in the satellite via a
                         25-pin connector.
Thermal                  Operational temperature range of -20 °C and +50 °C.
Environmental            Lasts for one year in Low-Earth Orbit (LEO)




   Team 17 BUSAT C&DH                                                                         03/17/08
Project Proposal                                                           19

        6.2        Appendix 2 – Gantt Chart




                                              Gantt chart, part 1




Team 17 BUSAT C&DH                                              03/17/08
Project Proposal                                  20




                     Gantt chart – part 2




Team 17 BUSAT C&DH                     03/17/08
Project Proposal                                                                                  21

        6.3        Appendix3 – Additional Appendices

                   6.3.1 Packet Structures




                                 Figure 9 – Intra-satellite command packet structure




                                       Figure 10 – Telemetry packet structure
Team 17 BUSAT C&DH                                                                     03/17/08
Project Proposal                                                                                           22




                                        Figure 11 – Intra-satellite data packet structure


                   6.3.2 Power Analysis Documentation
                   Test Summary
                   The purpose of this test was to acquire a solid estimation for power consumption of the SBC.
                   We developed software to simulate various operational states that the SBC will encounter.
                             • RS-232 serial line simulating data transmission
                             • RS-485 serial line simulating communication with the communication system,
                             • General I/O simulating the clock.
                   We then measured the power consumption during OS boot up, the above programs running
                   simultaneously, and during an idle period.

                   Results
                   Uncompressing Linux => I = 500 mA, V = 4.69 V, P = 2.35 W
                   Majority of Boot Script => I = 300-400 mA, V = 4.8 V, P = 1.44-1.92 W
                   Readings at Login Prompt => I = 230 mA, V = 4.8 V, P = 1.10 W

                   Conclusions
                   As suggested by the results, the SBC’s power consumption during test operation is only 250 mW
                   greater than while in its idle state. The highest power consumption occurs during restart, when
                   the SBC consumes 2.35 W; however, we are still under our allocated power consumption of 5W.
                   Moreover, the SBC will not restart while other instruments are in operation, thus, there is little
                   cause for power concerns during this situation. Assuming the LVDS transceivers draw a
                   maximum of 200 mW for both, we are under our maximum




Team 17 BUSAT C&DH                                                                          03/17/08
Project Proposal                                                                                     23

                   6.3.3 Team Information
Peter Argue
       Peter is working towards his Bachelors of Science in Computer Systems Engineering at Boston
       University. He worked as a researcher/developer for BUSAT over the summer of 2007 through the
       Center for Space Physics. His primary area of interest is software development. Relevant coursework
       includes Object Oriented Paradigms, Software Design, Computer Organization and Design and
       Microprocessors.

        Contact info:
        Cell:         (603) 401-0370
        Email:        pargue@bu.edu

Aaron Desrosies
      Aaron Desrosiers has been a member of the BUSAT project since March 2007. He attends Boston
      University and will graduate in May 2007 with a BS in Computer Engineering. Relevant coursework
      includes C# Software Design, Computer Organization and Design, Microprocessors, and Introduction to
      Computer Science II.

        Contact info:
        Phone:         (508) 496-1134
        Email:        aarond@bu.edu

Bandish Shah
      Bandish is pursuing an undergraduate degree in Electrical Engineering at Boston University. He has
      worked on the BUSAT project since March of 2007 and was a Research Assistant for the Center for
      Space Physics over for the summer in 2007 for BUSAT. His main area of interest is computer
      organization and architecture. Relevant coursework includes Computer Organization, Advanced Digital
      Design in Verilog and Microprocessors. Upon graduation, Bandish will be working for Sun
      Microsystems.

        Contact info:
        Phone:          (860) 944-1938
        Email:          bshah@bu.edu

Adriel Wallick
       Adriel is currently working towards her undergraduate degree in Electrical Engineering and will
       graduate in May of 2008. She has been a part of BUSAT since March 2007 and worked as a research
       assistant and developer for the center for space physics over the summer of 2007. Her main interest is
       software oriented but the nature of her major has also given her a solid hardware background. Her
       Relevant coursework includes Computer Organization, Microprocessors, Software Design, and
       Computer Organization and Design.

        Contact info
        Phone:          (617) 894-2640
        Email:          aew123@bu.edu




Team 17 BUSAT C&DH                                                                       03/17/08
Project Proposal                                                                                          24
                   6.3.4 Technical References

        1.         Fritz, Theodore A. "A Proposal to the Air Force Office of Scientific Research University
                     Nanosat Program." Center for Space Physics. Boston University. 2006.
        2.         University Nanosat-5 Program. “Nanosat-5User’s Guide”. University Nanosat Program Office,
                    2007




Team 17 BUSAT C&DH                                                                     03/17/08

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:2/28/2012
language:
pages:27