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

1. Drag and Atmospheric NeutralDensity Explorer (DANDE) CommandandDataHandling (CDH) Preliminary Design Review September 13th, 2007 Brandon Gilles (EE) James Gorman (ECE) Eric McIntyre (ECE) Gabe Thatcher (EE)

2. Program Schedule Concept Design, Requirements Definition Design Documentation, Analysis, Breadboard Verification 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 EDU, Analysis, Flat Sat, Verification at 50%

3. 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

4. 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 • The CDH portion of the DANDE Flat-Sat is the scope of this capstone project Here is the Flat-Sat of the Naval Academy’s ‘Pcsat’ http://web.usna.navy.mil/~bruninga/pcsat.html

5. Outline of Approach • Distributed architecture • Main “Flight Computer” • 32-bit Atmel AVR • Linux 2.6 Kernel • Subsystem microcontrollers • 8-bit Atmel AVRs

6. CDH Block Diagram

7. 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

8. 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 • Eric McIntyre • REA - 32-bit Software • Architecture • Analysis and Design • Implementation • Gabriel Thatcher • REA - Memory Voting Logic • REA - Subsystem Hardware Interfacing • Across the board • 32-bit Software Analysis, Design and Implementation REA - Responsible Engineering Authority

9. Implementation, Schedules, and Risk Assessment • High-Level Systems Software • Flight Computer Hardware and Drivers • Subsystem Computer Hardware and Drivers

10. High-Level Systems Software

11. 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.

12. Schedule

13. Schedule

14. 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.

15. Flight Computer Hardware

16. 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

17. Flight Computer: Implementation • 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

18. Flight Computer: Implementation • 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

19. 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

20. Subsystems Hardware and Drivers

21. 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

22. 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

23. 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

24. Schedule

25. Backup Slides

26. 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

27. Exploded View

28. 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/)

29. Functional Block Diagram Wiring Harness FOV360° FOV360° Acc Acc EPS EPS Photovoltaics 30W Photovoltaics 30W CDH CDH SFT SFT ACC ACC Acc Acc Acc Acc x4 x4 I2C I/O I2C I/O RAM TBD RAM TBD OS OS Battery A 14.4V 4AH Battery A 14.4V 4AH Battery B 14.4V 4AH Battery B 14.4V 4AH Inhibit Inhibit Scheduling Comm ADCS Science Scheduling Comm ADCS Science Control Control CPU AVR32 CPU AVR32 LV electrical interface LV electrical interface x4 x4 Acc Acc Acc Acc Inhibit Inhibit ABS ABS Serial I/O Serial I/O Regulation Regulation Control Control Acc Acc SSDTBD SSDTBD SEP SEP NMS NMS Instrument Instrument Mech1 Mech1 RTC RTC Instrument Instrument Lightband assy. Lightband assy. Control Control FOV32° x 1° FOV32° x 1° THM THM Coatings, Insulation Coatings, Insulation Mech2 Mech2 Control Control Sensors Sensors Control Control COM COM ADC ADC Torquerod A Torquerod A Tx Ant Tx Ant Tx 70cm 38.4kbps Tx 70cm 38.4kbps FOV90° FOV90° Control Control Torquerod A Torquerod A Instrument Instrument Mag (3-axis) Mag (3-axis) Satellite Sep Plane (SSP) Satellite Sep Plane (SSP) TNC TNC FOV 32° x 1° FOV 32° x 1° Rx 2m 9.6kbps Rx 2m 9.6kbps Rx Ant Rx Ant FOV90° FOV90° Horizon Crossing Sensor Horizon Crossing Sensor Horizon Crossing Sensor Horizon Crossing Sensor FOV 2° FOV 2° FOV 2° FOV 2° 29