2.0 Command and Data Handling Subsystem The Command and Data Handling Subsystem is the ‘brain’ of the whole autonomous CubeSat. The C&DH system consists of an Onboard Computer, OBC, which controls the operation of the CanSat. The OBC has software installed that manages the programs written to handle various tasks; for example, a program whose function is to create a telemetry stream will read the status of the payload sensors and then encode the telemetry stream. The same program can further control the flow of the data from sensors to the temporary memories inside the microcontroller in the event of communication restrictions, such as the blocking of communication signals between the CubeSat and the ground station. This section begins with a discussion of the C&DH Subsystem of the previous CanSat group. Further subsections discuss the requirements and constraints for the CubeSat followed by the choice and evaluation of microcontrollers. The last subsection discusses the modifications made to the hardware and software of the previous CanSat. 2.1 Background The previous CanSat had an OBC for C&DH. The primary component of the OBC was the microcontroller, AT90S4433. The secondary components were EPROM and RAM. These components were used for storing the software and were built-in to the microcontroller. The software was written in C language that performed only one loop to run all subsystems. A separate function was written in C language to make the OBC accept commands from the ground station and to override any operating function duringthe falling phase of the CubeSat. All programming was done with the help of an STK 500 programming board, shown in Figure 1. Figure 1: STK 500 AT89S/AT90S Series Flash Microcontroller Starter Kit [“Compass Lab,” 2003]. The following paragraphs discuss the advantageous as well as the flawed C&DH design considerations of the previous CanSat. Advantageous Design Considerations:  Control of Payload Sensors  Control of Communication Subsystem  Ability to transmit Telemetry Stream to the ground station during the falling phase of the CanSat Provision to store data from the accelerometer sensor during the ascending phase of the CanSat in RAM, so that data can be retrieved later (this provision failed and no data was stored).  Control of quartz clocks that assisted in timing the data collection from temperature, pressure, and accelerometer sensors. Flawed Design Considerations:  Wiring between the OBC and other subsystems, see Figure 2.  No repairing provisions.  No additional Input and Output ports for additional payload sensors. Overall, the design of the C&DH subsystem was very impressive, as it was simple in design and had about a 95 % success during the final field test. Figure 2: Wiring for connecting different Subsystems in Previous CanSat [Campbell and others, 2003]. Wire Connection2.2 Requirements and Constraints The objective of the C&DH subsystem is to provide the CubeSat with operation sequences to various subsystems. Because of the size restrictions of the CubeSat, the C&DH subsystem needs to be efficient, small, lightweight, and easy to integrate with all of the other subsystems in CubeSat. This subsystem should be able to perform several tasks, as listed below:  Subsystems control  Communication with the ground station  Data and software storage in allocated memories  Fault detection and management  Telemetry stream generation  Data uplink and downlink feature. In addition to the aforementioned objectives expected of the CubeSat, the Satellite Solutions group tried to meet additional design constraints, as listed below:  Easy installation and repair provisions  Provisions for additional subsystems for future work  Efficient programming of the microcontroller (multiple loops instead of single loop code). Each of the above requirements has different demands concerning the OBC and is also critical for efficient operation of the CubeSat. Hence, the proper evaluation of all options available for components that make up the OBC was necessary and are discussed in the next section.2.3 Options and Evaluation The OBC is made up of several components, such as microcontrollers, capacitors, resisters, voltage regulators, LEDs, memories (RAM, EEPROM, and ROM), and timers. Out of all of these components, memories, timers, and microcontrollers are the most important. Cost and ease of fabrication of these electronic components are the major factors that result in various configurations in which an OBC can be designed. The requirements restrained our team to choose components that result in a small and light-weight C&DH subsystem. We chose a microcontroller that has built-in memories and timers; this makes the microcontroller the most critical component in C&DH subsystem. To assist in selecting the right microcontroller (processor) and to meet the requirements of the OBC, a set of minimum specifications was developed and is listed below:  Data and Nonvolatile Program Memory: • EEPROM (Electrically Erasable Programmable Read Only Memory) – min. 8 kB • Flash - minimum 512 bytes • SRAM (Static Read Only Memory) - minimum 512 bytes  Desirable features • High processing speed – more then 4 MHz • In-built Analog/Digital Converters • Programmable UART (Universal Asynchronous Receiver-Transmitter) • Master/Slave SPI Serial Interface • Controllable I/O pins • Programmable timers, especially the watch-dog timer • Minimum 16 bit architecture • Avoid Ball-grid-array (BGA) microcontrollers (difficult to solder)  Low Power consumption – less then 10 mA and voltage less then 5 volts  Size – should fit on a 5 cm x 5 cm Printed Circuit Board C compiler - must be available for the processor (microcontroller)  Operable in temperature range 0 – 40° C; however, wider range is preferable. Next, several microcontrollers were investigated that best met the specifications set above. Table 1 below lists the microcontrollers (that meet the minimum specifications) that were examined along with the reason that they were rejected or selected. Table 1: Microcontrollers list and the reason for their rejection. Company Reason for Rejection or Selection Motorola Hard to solder because of BMG configuration Hitachi Programming skills very limited Intel High power consumption Microchip Nothing wrong PIC Nothing wrong ATMEL