D rag and A tmospheric N eutral D ensity E xplorer (DANDE) C ommand and D ata H andling (CDH)...

Drag and Atmospheric Neutral Density Explorer

(DANDE)

Command and Data Handling(CDH)

Preliminary Design ReviewSeptember 13th, 2007

Brandon Gilles (EE)James Gorman (ECE)Eric McIntyre (ECE)Gabe Thatcher (EE)

DANDE CDH PDR ECEN 4610 Capstone Laboratory

Program Schedule

Spring 07

Summer 07

Fall 07

Spring 08

Summer 08

Fall 08

SCR ♦Prelim. Design & Breadboard

♦

PDR ♦Flat-sat Build ♦EDU & Vibe Test ♦CDR ♦Proto Qualification Build ♦PQR ♦Proto Qualification Testing ♦FCR →

Concept Design, Requirements Definition

Design Documentation, Analysis, Breadboard Verification

EDU, Analysis, Flat Sat, Verification at 50%

Proto-Qualification Unit at 80%, Verification at 90%

Proto-Qualification Unit at 100%, Verification at 100%, as-built documentation

Detailed Schedule

Electrically equivalent satellite on a lab bench


Responsibilities of CDH

• Monitor and manage health of satellite.• Record and pre-process data from science

subsystems.• Provide command and control functionality.• Manage the operating modes of satellite.

– Science– Safe– Separation– Spin-up

3


Scope of Implementation

• Developing the Flat Satellite version of the CDH system– Full Hardware and software functionality– Boards do not have size constraints– Standard practice for satellite development

• Size constrained boards come after Flat-Sat completion

4

• The CDH portion of the DANDE Flat-Sat is the scope of this capstone project

http://web.usna.navy.mil/~bruninga/pcsat.html

Here is the Flat-Sat of the Naval Academy’s ‘Pcsat’


Outline of Approach

5

• Distributed architecture– Main “Flight Computer”

• 32-bit Atmel AVR• Linux 2.6 Kernel

– Subsystem microcontrollers• 8-bit Atmel AVRs


CDH Block Diagram

6


Subsystem and Instrument Interfaces

• Interfaces to the satellite are all through the subsystem microcontrollers– Subsystem microcontrollers are responsible for collecting and buffering

salient science and health data from the subsystem instruments.– The Flight Computer polls the subsystem microcontrollers periodically

for data

• Extent of Subsystem Development– The CDH team shall provide an AVR reference design to the subsystem

designer• AVR hardware reference design• AVR driver package (in C)

– Beyond this reference design, no further subsystem development is in the scope of this project

7


Division of Labor

• Brandon Gilles– Project Manager– REA - 32-bit Hardware– REA - Linux Kernel

• James Gorman– REA - 8-bit Hardware and Software

Reference Design– REA - Watch Dog and Long Dog

Circuitry– 32-bit Hardware

8

• Across the board– 32-bit Software Analysis, Design and Implementation

• Eric McIntyre– REA - 32-bit Software

– Architecture– Analysis and Design– Implementation

• Gabriel Thatcher– REA - Memory Voting Logic– REA - Subsystem Hardware

Interfacing

REA - Responsible Engineering Authority


Implementation, Schedules, and Risk Assessment

• High-Level Systems Software• Flight Computer Hardware and Drivers• Subsystem Computer Hardware and Drivers

9


High-Level Systems Software

10


Implementation

The following methods will ensure successful implementation:

• Adherence to the rational process• Detailed documentation during all workflows including

requirements, analysis, and design• Object-oriented design for applicable systems• Coding during the implementation workflow will be

performed in development environments provided by the chip manufacturer.

11


Schedule

12


Schedule

13


Risk Assessment

• Risk: Failure to define requirements.– Consequences: Interfaces may not be clear or specified to

users. Software may require rework, patches, or be unusable.– Mitigation: Following the rational process, meeting regularly

with users, documenting, and holding regular reviews with the other subsystem leads

• Risk: Failure to build compatible software with specified hardware.– Consequences: Software will be unusable.– Mitigation: When defining implementation iterations each

build will be tested on target hardware, which is available, to be considered usable.

14


Flight Computer Hardware

15


Flight Computer: Implementation

• The flight computer needs to be able to process large amounts of data

• It also needs to have support for high level code.– This is so the other systems can write algorithms in an easy to use

object-oriented language– This is also so that there is protected memory so a bug in one

piece of code does not wipe out everything else

16



• The AVR32 processor will be used– This is a 32 bit RISC processor– High performance

• Pipelined with superscalar out-of-order execution• Instruction and data cache

– Internal DRAM controller– Fully supported in the Linux 2.6 kernel– Extensive integrated peripherals

17



• The Linux operating system needs to be loaded out of a non-volatile memory which can be rewritten during flight– This can either be a parallel access NAND Flash chip or a SPI NAND Flash device

• 64 MB of non-volatile memory is required for science mission data– This will be in the form of an SD card

• This system requires RAM for the same reasons a PC requires RAM– Needs a place to execute code out of– Needs a place to store variables

• Either SRAM or DRAM will be used– Decision will be made based on amount of RAM required and ease of

implementation– Other factors such as radiation tolerance may affect decision

18


Flight Computer: Risk Assessment

• Make or Buy Decision for flight computer:– Make:

• Getting a processor with external memory running is a very difficult task

• In addition the processor is only available in a 256 pin BGA package

• Processor speed requires board design with signal integrity in mind (150MHz max)

– Buy:• Prevents Radiation Mitigation Techniques

– Memory Voting Circuit

19


Subsystems Hardware and Drivers

20


Implementation

• Most of the subsystems need a way to interface their hardware to the central processor/ data bus

• An Atmel AVR 8-bit microcontroller will be used• The microcontroller requires little hardware support for

external circuitry• Many I/O pins and peripheral hardware available for

interfacing to subsystems

21


Implementation

• Each subsystem will need to be able to write their own software to interface to their hardware

• This requires that low level drive be written to handle the following operations:– Manipulate digital I/O pins– Communicate using the UART or SPI module– Sample analog signals using the internal converter– Use the timers to sample data at the proper rate– React to commands from the central processor– Transmit data back to the main computer

22


Flight Computer: Risk Assessment

• The hardware system involves very few risks• The software risks involves writing the software in an

extensible and easy to use way– Ther e is no protected memory so all other code can cause faults in the system– The proper libraries may not be provided.

• Libraries Currently Planned– Real Time Clock– Timer– UART– SPI– Analog Input

23


Schedule

24


Backup Slides

25


DANDE Background Information

• Drag and Atmospheric Neutral Density Explorer– A Low-Cost Small-Satellite Program for Neutral Density, Wind, and Composition

Research with Applications Space Weather Models– DANDE measures atmospheric density variations– DANDE will also provide coefficient of drag data– DANDE weighs 110 lb (50 kg), and is 18” (0.46 m) in diameter.– DANDE spins at 10 RPM to provide gyroscopic stability for instrument pointing, and ease of

attitude determination and control.– DANDE uses the aluminum shell halves of its structure as a receive antenna, and a piano

wire embedded in Delrin as a transmit antenna.– DANDE will use a novel aerobraking mechanism to quickly descend from a common 310-

370 miles (500-600 km) orbit to its science orbit at 220 miles (350 km)

26


Exploded View

27


Communications Analysis

• Data volume:

• Communications passes:– Average pass length: 247 seconds ( @ start of mission)– ~2 passes per day at Boulder CO (40°N)– At 9600bps, we can downlink ~1,968,000 bits per pass– Takes ~4 passes to downlink one day’s data

• Communications trade studies (in-progress):– Adding ground stations

• Space Grant Colleges in Hawaii, Puerto Rico• Can downlink all data using 3 ground stations

– Microwave (2.4GHz) communications equipment• Currently increasing TRL at home institution

– Potential use of local high-gain antenna facility• 2 x 60’ steerable dishes (http://www.deep-space.org/)

bits/sample sample rate samples / day bits / dayNMS (Neutral Mass Spectrometer) 4,192 bits 0.01667 Hz 1,440 6,036,480 bitsACC (Accelerometer) 32 bits 0.2 Hz 17,280 552,960 bitsPRS (Pressure Sensor) 32 bits 0.2 Hz 17,280 552,960 bitsHealth and Status (Engineering) data 4,096 bits 0.00028 Hz 24 98,304 bits

TOTAL DATA / DAY 7,240,704 bits

DANDE CDH PDR ECEN 4610 Capstone Laboratory 29

Functional Block Diagram

ACC

Control

AccAcc

Acc

Acc

AccAcc

THM

Control

Coatings, Insulation

Sensors

InstrumentNMS

Control

Instrument

FOV32° x 1°

Instrument

FOV 32° x 1°

CDH

I2C I/O

CPUAVR32

RAM TBD

SSDTBDRTC

SFTOS

Scheduling

Comm

ADCS

Science

Serial I/O

Wiring Harness

SEP

Mech1

Mech2

Control

Ligh

tban

d as

sy.

ABS

EPS Photovoltaics 30W

BatteryB

14.4V 4AH

Regulation Control

FOV360°

Inhibit

Inhibit

x4

x4

Battery A14.4V 4AH

LV e

lect

rical

in

terfa

ceSa

tellit

e Se

p Pl

ane

(SSP

) COM

Tx AntRx Ant

FOV90°

FOV90°

Tx70cm

38.4kbps

Rx2m

9.6kbps

TNC

ACC

Control

AccAcc

Acc

Acc

AccAcc

ADC

Control

Horizon Crossin

g Sensor

Torquerod A

Horizon Crossin

g Sensor

Torquerod AMag (3-

axis)

FOV 2°FOV 2°

InstrumentNMS

Control

Instrument

FOV32° x 1°

Instrument

FOV 32° x 1°

ADC

Control

Horizon Crossin

g Sensor

Torquerod A

Horizon Crossin

g Sensor

Torquerod AMag (3-

axis)

FOV 2°FOV 2°

THM

Control

Coatings, Insulation

Sensors

CDH

I2C I/O

CPUAVR32

RAM TBD

SSDTBDRTC

SFTOS

Scheduling

Comm

ADCS

Science

Serial I/O

EPS Photovoltaics 30W

BatteryB

14.4V 4AH

Regulation Control

FOV360°

Inhibit

Inhibit

x4

x4

Battery A14.4V 4AH

LV e

lect

rical

in

terfa

ceSa

tellit

e Se

p Pl

ane

(SSP

) COM

Tx AntRx Ant

FOV90°

FOV90°

Tx70cm

38.4kbps

Rx2m

9.6kbps

TNC

SEP

Mech1

Mech2

Control

Ligh

tban

d as

sy.

ABS

D rag and A tmospheric N eutral D ensity E xplorer (DANDE) C ommand and D ata H andling (CDH)...

Documents

Transcript of D rag and A tmospheric N eutral D ensity E xplorer (DANDE) C ommand and D ata H andling (CDH)...