Firmware Development of the LAICE Instrument Interface Board (LIIB)

Transcription

1 Firmware Development of the LAICE Instrument Interface Board (LIIB) Samiksha Arora Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Gregory D. Earle, Chair Scott M. Bailey Peter M. Athanas May 4, 2017 Blacksburg, Virginia Keywords: FPGA Design, Interface Mechanism, LAICE Instrument Interface Board, Spacecraft Copyright 2017, Samiksha Arora

2 Firmware Development of the LAICE Instrument Interface Board (LIIB) Samiksha Arora (ABSTRACT) The Lower Atmosphere/Ionosphere Coupling Experiment (LAICE) CubeSat mission includes the payload instruments that generate scientific data by interacting with the flight computer. The LAICE Instrument Interface Board (LIIB) is designed to interface with the payload instruments and the flight computer for efficient operation of the LAICE. The uplink command packet contains commands for regulating power supply to the payload instruments and for interfacing the peripheral, called the thermal knife, with the science instruments. The LIIB is responsible for interpreting these commands in order to execute the associated functions. The architecture of the LIIB is designed such that it not only takes into account all the requirements of the systems and instruments on the LAICE, but also ensures smooth flight data analysis at the ground station end. The approach taken to build the design makes the entire process intuitive and easier to debug. This thesis describes the design and development of the LIIB firmware, to ensure proper functioning of the LAICE. The firmware design is presented first, by initially defining the architecture based on the system requirements and progressing eventually to its development at the system level. End-to-end testing with the payload instruments and thermal knife setup verifies the operation of the LAICE LIIB firmware and electronics, thus qualifying the instrument for deployment within the LAICE.

3 Firmware Development of the LAICE Instrument Interface Board (LIIB) Samiksha Arora (GENERAL AUDIENCE ABSTRACT) The Lower Atmosphere/Ionosphere Coupling Experiment (LAICE) is a satellite that computes and exchanges science data between the flight computer and the three payload instruments. The LAICE Instrument Interface Board (LIIB) is designed to interface the flight computer and the payload instruments, and regulate the communication between them. Additionally, the LIIB is responsible for controlling the external hardware that interacts with the payload instruments. The thesis includes the design and development of the LIIB firmware in order to perform diverse functions such as controlling the instrument communication with the flight computer, regulating the power supply to the instrument boards, interfacing with the external hardware, referred to as the thermal knife, and integrating the various modules that perform these functions in order to meet the system requirements of the LAICE.

4 Dedication To my parents, Ashu and Ashok Arora for encouraging me and always believing in me. You are my greatest strength. To my grandparents: Avinashi Lal Arora, Krishna and Sarabjit Sapra, for their inspirational and unconditional guidance. iv

5 Acknowledgments I would like to thank Dr. Greg Earle for his invaluable guidance and mentorship on this project. I would like to give special thanks to Stephen Noel for always being there to answer my questions and to Joe Kujawski for his expertise in digital electronics and firmware design. My thesis would not be possible without the contribution of all the people who are a part of the LAICE team including Namrata Kedia and Cameron Orr. Funding for this research provided by the National Science Foundation (AGS ). Unless otherwise noted, all photos by author, v

6 Contents List of Figures viii List of Tables xi 1 Introduction 1 2 Firmware Design and Development LIIB Hardware Assembly Data Flow Timing Analysis Power Sequencer Thermal Knife Command Interpreter Instrument Communication Top Level Architecture Results and Discussion Design Flow & Test Plan vi

7 3.2 Issues and Challenges Results Conclusion and Future Work 57 Bibliography 60 Appendix A LIIB Schematics 61 Appendix B Firmware Architecture Discussion 68 Appendix C Telemetry Matrix Discussion 74 vii

8 List of Figures 1.1 LAICE CubeSat LAICE Instrument Interface Board (LIIB) hardware assembly LIIB Firmware - Organization and Design Flow LIIB Timing Analysis A generic power switching circuit SPS Cover Release Mechanism Flowchart of thermal knife mechanism Flowchart of command interpreter Downlink command packet sequence Communication data flow for a single cycle Flowchart for uplink communication Dual-port RAM architecture Architecture and control flow of instrument communication Architecture at the top level viii

9 3.1 FPGA design flow Block Diagram of laboratory setup for LIIB and RPA LabVIEW output- expected no. of bytes LabVIEW output- expected no. of bytes LIIB communicating with NI VISA test panel LIIB downlink packet output- RPA data offset issue Intermediate design output - dual-port RAM replaced with flash ROM LIIB data offset error simulation LIIB data offset error correction Laboratory setup for instrument communication Three instrument communication output Uplink communication simulation waveform MUX control logic simulation Simulation waveform for command interpreter operation Simulation output for serial load operation of dual-port RAM Serial load operation logic simulation Simulation output for serial write operation of dual-port RAM Laboratory setup for thermal knife mechanism B.1 Power Sequencer.vhd B.2 Command Interpreter.vhd B.3 UARTRAMBuffer.vhd ix

10 B.4 Instrument Communication.vhd B.5 Top Level.vhd C.1 UofI to LIIB Uplink Telemetry C.2 LIIB Mode Command Defintion C.3 RPA Uplink Telemetry C.4 SNeuPI Uplink Telemetry C.5 LINAS Uplink Telemetry x

11 List of Tables 2.1 LIIB opmode selections Thermal Knife Modes Definition Uplink command packet sequence Select lines definition of 4*1 MUX Power Sequencer I Power Sequencer II Power Sequencer III Power Sequencer IV Power Sequencer V Power Sequencer VI Results of thermal knife mechanism Specification table for LIIB firmware design xi

12 List of Acronyms LAICE Lower Atmosphere/Ionosphere Coupling Experiment UI University of Illinois NSF National Science Foundation LIIB LAICE Instrument Interface Board RPA Retarding Potential Analyzer SNeuPI Swept Neutral Pressure Instrument LINAS LAICE Ionization gauge Neutral Atmosphere Sensor SPS-RM Space Pressure Sensor- Release Mechanism FPGA Field Programmable Gate Array HDL Hardware Description Language VHDL VHSIC Hardware Description Language Op-Mode Operational Mode TK Thermal Knife PPS Points Per Sweep HK HouseKeeping UART Universal Asynchronous Receiver/Transmitter RAM Random Access Memory FIFO First-In First-Out ROM Read-Only Memory xii

13 ADC Analog to Digital Converter MUX Multiplexer RTL Register Transfer Level GUI Graphical User Interface xiii

14 Chapter 1 Introduction The objective of the Lower Atmosphere/Ionosphere Coupling Experiment (LAICE) CubeSat mission is to understand the interaction of atmospheric gravity waves in the lower atmosphere with the mesosphere, lower thermosphere, and ionosphere. 1 By doing an analysis of the energy and momentum delivered by these waves, LAICE focuses on understanding the critical coupling between different atmospheric regions. LAICE is a collaborative project between Virginia Tech and University of Illinois (UI) at Urbana-Champaign. 2 Virginia Tech is responsible for the development and testing of the payload instruments and the LAICE Instrument Interface Board (LIIB). The VT payload is designed to achieve the objectives described above. It includes a Retarding Potential Analyzer (RPA), 3 the LAICE Ionization gauge Neutral Atmosphere Sensor (LINAS) and the Space Neutral Pressure Instrument (SNeuPI) 4. The system setup for LAICE is shown in Figure 1.1. The three in-situ payloads receive their power and communicate with the spacecraft via the LAICE Instrument Interface Board (LIIB). The flight computer receives uplink command packet from the ground station and sends it to the payload instruments. The payload measure the science data and sends the downlink packet back to the flight computer. This full duplex 1

15 Samiksha Arora Chapter 1. Introduction 2 communication between the flight computer and the science instruments is carried out every second and controlled via the LAICE Instrument Interface Board (LIIB). The uplink packet consists of the operation mode and command packets for each payload. Therefore, LIIB is responsible for regulating the science data communication and controlling the payload instruments based on the operation mode. LIIB also handles the Space Pressure Sensor- Release Mechanism (SPS-RM) via thermal knife operation. This mechanism is responsible for protecting the two space pressure sensors (SNeuPI and LINAS) from exposure to impurities before they are deployed in the orbit. LIIB is the hub that supplies power to in-situ payloads and coordinates their communication with the flight computer. Additionally, it controls the thermal knife mechanism. Thus, it acts as the - command, control and data interface for the LAICE instruments. This thesis addresses the above functionalities by providing details of the LIIB operation, including: 1. Firmware Design of LIIB- (a) Power Sequencer (b) Uplink and Downlink Command Packet Generator (c) Command Interpreter (d) Thermal Knife Mechanism (e) Top Level Compiler 2. Functional Verification of the Design 3. Test Plan & Hardware Validation (a) Full Bench test for instrument communication (b) Validate the thermal knife circuit for SPS-RM (c) Power Switching

16 Samiksha Arora Chapter 1. Introduction 3 Figure 1.1: LAICE CubeSat. Representation of the LAICE CubeSat. Picture courtesy: Stephen Noel Overview- Chapter 2 describes the LIIB Firmware Design at a system level. It details the FPGA code development of LIIB in various stages. Chapter 3 discusses the functional verification and validation of the design described in Chapter 2 through test benches and simulations. The chapter focuses on the test procedure for hardware testing of the design, initially using LABVIEW and progressing eventually to include the full complement of the LAICE electronics. It describes the challenges faced during testing and explains the approach taken for rectification of various issues.

17 Chapter 2 Firmware Design and Development 2.1 LIIB Hardware Assembly Figure 2.1 gives a pictorial view of the electronics assembly of the LIIB board. The detailed electrical schematics are shown in Appendix A. At the heart of the system is an Actel based IGLOO AGLN250 Field Programmable Gate Array (FPGA) that controls the operation of the system. The main advantage of using an FPGA is the ultra-low power consumption and its ability to be reprogrammed. Custom ICs are expensive and time-consuming so they are most useful when produced in bulk amounts. Since the objective of the work described here is to create the design as per the CubeSat requirements, 5 which are limited in both power consumption and size, an FPGA is therefore an ideal choice for the application. The LIIB FPGA operates in a synchronous manner and receives the clock input from a 10MHz crystal oscillator. It handles appropriate power distribution from the satellite bus power to the instrument boards- RPA, SNEUPI and LINAS, through on-board DC-DC converters. It communicates with the instruments through IL3222 transceivers via UART using RS-422 protocol. The RS-422 protocol is chosen because it has better noise immunity than the RS-232 protocol. The protocol uses separate transmit and receive pairs that make it noise resistant, thus allowing for higher transmission rates. The FPGA communicates with the 4

18 Samiksha Arora Chapter 2. Firmware Design 5 spacecraft and payload instruments at a standardized baud rate of 115,200. It also performs other critical functions such as housekeeping data collection and interfacing with the thermal knife to implement the Space Pressure Sensor- Release Mechanism (SPS-RM). Figure 2.1: LAICE Instrument Interface Board (LIIB) hardware assembly. The figure shows the top view of the board assembly of LAICE Instrument Interface Board (LIIB). Photograph taken by Stephen Noel. Figure 2.2 gives a detailed view of the design organization with the data flow among various modules. The design allows the FPGA to communicate with the instrument boards and control the thermal knife operation and power supply to external hardware. Using various sub-modules, the LIIB UART controls the data transfer between ground station and payload, regulates the control switches that change ON/OFF state of instruments, activate the thermal knife and collect its housekeeping data by interfacing with the on-board electronics. A hierarchical approach is taken to build the design architecture. The FPGA is the interface to all the science instruments, and it also communicates with the flight computer and thermal knife. As such it is a vital part of the overall mission, and must be carefully designed to

19 Samiksha Arora Chapter 2. Firmware Design 6 meet the experiment objectives. The diverse functions performed by the FPGA increase the complexity of the architecture. Therefore, the design is an integration of schematic blocks, Hardware Description Language (HDL), and state machines, interacting with one another to accomplish the above tasks. For example, the instrument communication involves schematic blocks to visualize the entire design at the system level instead of describing the low-level behavior of logic blocks. Similarly, an algorithmic approach is taken to design the series of states in the thermal knife, so, the design is a combination of HDL and state machines. The HDL used to program the design is VHSIC Hardware Description Language (VHDL). The design is decomposed into a number of modules that are interconnected together to achieve the required functionalities. Each module performs a unique task, and simultaneously coordinates with the other modules to comply with the system requirements and design timing.

20 Samiksha Arora Chapter 2. Firmware Design 7 Figure 2.2: LIIB Firmware - Organization and Design Flow. The figure depicts the main files that contribute to the firmware architecture of LIIB. Together this architecture meets the design specifications for LAICE.

21 Samiksha Arora Chapter 2. Firmware Design Data Flow Timing Analysis The operations performed by the LIIB are at a cadence of one second. This means that the instrument communication, power switching, and housekeeping data collection are part of a recurring cycle that has the duration of one second. For every single cycle, the LIIB communicates with the payload instruments, collects the housekeeping data, and regulates power supply to the science instruments. One exception to this cycle is the thermal knife mechanism that happens once, before the satellite is deployed in the orbit. Figure 2.3 shows the timing analysis of the functions performed by the LIIB at one-second cadence between t=0s and t=1s. The data flow is triggered when the LIIB receives the uplink command packet from the flight computer. The next events are setting the ON/OFF switching state of the instruments based on the op-mode and sending the uplink commands to the respective instruments. The instruments, on receiving the respective uplink commands, compute the science data. The time taken by RPA, SNeuPI, and LINAS to measure the science data is 830ms, 700ms, and 750ms respectively. 6 They transmit their downlink data back to the LIIB, which in turn relays it to the flight computer. The downlink packet of the current second is sent to the flight computer by the LIIB in the next second. For example, in Figure 2.3, LIIB sends the downlink data packet of t= -1s to the flight computer in t=0s.

22 Samiksha Arora Chapter 2. Firmware Design 9 Figure 2.3: LIIB Timing Analysis. The figure depicts the timing diagram of various functions performed by LIIB during the one-second cadence. 2.3 Power Sequencer The power sequencer module is responsible for power switching. As shown in Figure 2.3, the power sequencer is triggered when LIIB receives the op-mode from the flight computer. The red margin in the figure indicates the time at which the LIIB receives the op-mode byte. LIIB controls power distribution to the payload instruments through the onboard DC-DC converters for which the control lines are driven by MOSFET switches. The FPGA controls each of the switches through a dedicated I/O pin for each switch. Figure 2.4 shows a typical circuit used to interconnect the FPGA I/O pin to the DC-DC converter. The control pin from FPGA turns the switch ON/OFF depending on whether the I/O pin is logic high or low. The MOSFET switch drives the output of the converter and regulates power supply to the payload instruments. Every instrument has 2 operation modes- ON/OFF and as there are 3 science instruments,

23 Samiksha Arora Chapter 2. Firmware Design 10 Figure 2.4: A generic power switching circuit. The figure depicts a representative MOSFET circuit used to control the switching status of a DC-DC converter. LAICE operates in 8 op-modes. The telemetry operational-modes (op-modes) for power distribution at the system level are depicted in Table 2.1. For every uplink packet LIIB receives from the flight computer, the 3 least significant bits in the 2nd byte constitute the op-mode. For example, if the 2nd byte in the uplink packet is x13, the op-mode is 011. Referencing Table 2.1, LINAS and SNEUPI will be ON and RPA will be OFF in this mode.

24 Samiksha Arora Chapter 2. Firmware Design 11 Table 2.1: LIIB op-mode selections The LIIB op-mode selections are shown in this table. Op-mode Instrument Status 000 All Instruments OFF 001 RPA OFF, LINAS OFF, SNeuPI ON 010 RPA OFF, LINAS ON, SNeuPI OFF 011 RPA OFF, LINAS ON, SNeuPI ON 100 RPA ON, LINAS OFF, SNeuPI OFF 101 RPA ON, LINAS OFF, SNeuPI ON 110 RPA ON, LINAS ON, SNeuPI OFF 111 All Instruments ON 2.4 Thermal Knife The SPS release mechanism protects the two space pressure sensors (SNeuPI and LINAS) from exposure to dust, water vapor, and oxidizing gases prior to deployment in orbit. The release mechanism is shown in the open position in Figure 2.5. LIIB interfaces with the thermal knife to enable LAICE to perform Space Pressure Sensor- Release Mechanism functionality (SPS-RM). The SPS cap is in closed position while the instruments are in a chamber filled with inert gas. Once the spacecraft is in orbit, the mechanism releases the cap and the accommodation chamber outgases over a period of days. When closed, the release mechanism is held shut with a series of 4 spring loaded latches. To open the cap a nichrome wire thermal knife burns through the line and releases the spring loaded latches. When the latches are open, a leaf spring supplies the necessary force to remove the cap from the accommodation chamber. The leaf spring also keeps the cap attached to meet the CubeSat operational requirements. In addition to the primary filament, there is a redundant thermal knife filament in case the primary filament fails to burn through the Dyneema line. LIIB is responsible for controlling the release mechanism and the operation of the thermal knife. It monitors the position of the four latches and sends the status to the flight computer every second as part of the housekeeping data. LIIB operates either in normal mode or one of

25 Samiksha Arora Chapter 2. Firmware Design 12 Figure 2.5: SPS Cover Release Mechanism. The figure shows the cap in open position connected to the plate via the leaf spring. The highlighted circular dyneema line path holds the four latches in position. When LAICE enters one of the thermal knife modes, the loop is cut and the respective latches are released. Figure courtesy: Robbie Robertson the other defined thermal knife modes. The thermal knife mode is a special mode activated only once when the CubeSat is placed in the orbit. The LIIB mode (normal or thermal) is represented by the 5 most significant bits in the 2nd byte in the uplink packet. The bit strings corresponding to each LIIB mode are given in Table 2.2. There are five thermal knife modes and a normal mode that can be the input to LIIB mode. The thermal knife mechanism is disabled during the normal mode and the LAICE operates in a standard way by measuring science data for each communication cycle. When one of the thermal knife modes is enabled, there is no science data measurement. There are two identical thermal knife circuits in the

26 Samiksha Arora Chapter 2. Firmware Design 13 Table 2.2: Thermal Knife Modes Definition. The normal mode and the various thermal knife modes in which LAICE can operate are shown in this table. LIIB MODE BIT STATUS NORMAL MODE TK1 CHARGE TK1 DISCHARGE TK2 CHARGE TK2 DISCHARGE TK OVERRIDE accomodation chamber. The TK1 charge and TK1 discharge modes are used to charge and discharge the capacitors respectively on the first circuit. Similarly, the TK2 charge and TK2 discharge modes charge and discharge the capacitors respectively in the second circuit. The TK override mode is a double check on the status of the thermal knife. The status of the override mode is monitored by an override flag that is toggled whenever there is a change in the status of TK modes in the thermal knife circuit. The process flow for the thermal knife mechanism is shown in Figure 2.6. LIIB receives the mode as input from the flight computer. If the LIIB is in TK Override mode, it toggles the override signal and leaves the four latches in their previous state. The TK Override mode is a double check on the status of thermal knife when the latch signals read open. If LIIB is not in TK Override mode, the status of the override flag is checked. If it is 0, then latch out flag is set to the value denoted in the flowchart, i.e., TKSIG1 nor TKSIG2 nor TKSIG3 nor TKSIG4. Once the value of the latch out flag is set, it is used to check the LIIB mode if the value is 1. If latch out is 0, the control is transferred to main module. If override flag is 1, then the status of LIIB mode is checked. The values of the latch signals are set depending on the TK mode LIIB is in. If the input received from flight computer is an invalid mode, the control goes back to the main module with the override and latch flag status as outputs.

27 Samiksha Arora Chapter 2. Firmware Design 14 Figure 2.6: Flowchart of thermal knife mechanism. The flowchart represents the algorithm used to perform the thermal knife mechanism. The sequence of operations followed when LAICE operates in one of the thermal knife modes is depicted in this figure. The thermal knife module receives the LIIB mode input from the command interpreter, described in the following section. 2.5 Command Interpreter The uplink packet LIIB receives from the flight computer contains the commands that trigger the thermal knife mechanism and regulate power supply to the payload instruments. The command interpreter is responsible for sending the input commands to power sequencer and thermal knife modules to start these mechanisms. The command interpreter latches the input command for the power sequencer and thermal knife from the fixed length uplink command packet. The input command for the power sequencer is generated from the 3 least significant

28 Samiksha Arora Chapter 2. Firmware Design 15 bits in the 2nd byte of the uplink packet, and the input command for the thermal knife are the 5 most significant bits in the 2nd byte. Figure 2.7 shows the flowchart that explains the logic used to implement this functionality. The uplink counter is used to keep track of the number of bytes in the uplink packet that the LIIB has received from the flight computer. When LIIB is receiving the uplink packet from the flight computer, the uplink counter increments at every byte received. The counter is reset when it reaches the size of the uplink packet (12 bytes). This ensures that the counter is set to 0 when the LIIB receives the uplink command packet for the next cycle from the flight computer. When the counter is 2, the LIIB has received the byte that contains the op-mode and the LIIB mode. The command interpreter latches the second byte to feed into the power sequencer and thermal knife. The 5 most significant bits in the latched byte are fed as input to the thermal knife and the 3 least significant bits are fed as input to the power sequencer. For example, if the second byte in uplink packet is x02, then thermal knife receives x00 and power sequencer receives x02 as input.

29 Samiksha Arora Chapter 2. Firmware Design 16 Figure 2.7: Flowchart of command interpreter. The flowchart represents the algorithm to generate input commands required to initiate power sequencer and thermal knife mechanism. The input for command interpreter is included in the uplink command packet received from the flight computer.

30 Samiksha Arora Chapter 2. Firmware Design Instrument Communication The primary function of LIIB is to send and receive science data between the flight computer and the Virginia Tech payload. It receives the uplink command packet from the flight computer and the downlink packet from three of the payload instruments every second. Since this full duplex operation is controlled via the FPGA, timing is a significant characteristic that must be rigidly adhered to in executing various aspects of the communication. The mode of communication that the LIIB uses to communicate with the science instruments is serial communication. A Universal Asynchronous Receiver/Transmitter (UART) is used to perform this functionality. A UART uses serial communication to send and receive data asynchronously by using RS-422, RS-232, etc. as the standard protocol. The UART on the LIIB board is labelled in Figure 2.1. The LIIB UART does serial communication with the UARTs on the science instruments by using RS-422 as the standard protocol. Uplink Commands and Sequence of Operations: The uplink command is a 12-byte packet that begins with an 8-bit start word. It contains the payload commands for the instruments as well as the command to initiate power switching and control the thermal knife mechanism. Table 2.3 provides a detailed explanation of the uplink packet in order of byte number. The first byte is a start byte, and the second byte contains the command mode for power switching and thermal knife. Bytes 3-7 contain the RPA uplink packet, bytes 8-9 contain the SNeuPI uplink packet and bytes contain the uplink command packet for LINAS. Downlink Commands and Sequence of Operations: The LIIB downlink packet is a 373-byte long packet that consists of LIIB's command echo, all of the housekeeping and status data and data from the payload instruments. Figure 2.8 lists the details of the downlink data bytes along with the number of bytes for every instrument. Every instrument, including LIIB, echoes back its uplink packet to avoid ambiguity in flight data analysis. The order in which the data are communicated back by the instruments is

31 Samiksha Arora Chapter 2. Firmware Design 18 Table 2.3: Uplink command packet sequence. The sequence for uplink command packet is shown in this table. The Points Per Sweep for RPA is defaulted to 64 for the LAICE mission. same as the order in which flight computer sends the uplink packet, i.e. LIIB followed by RPA, followed by SNeuPI and LINAS. The LIIB echo is followed by housekeeping data that contains measurements from the temperature, current, and voltage monitors on LIIB, which is then followed by the science data from payload instruments. Figure 2.8: Downlink command packet sequence. The sequence of downlink command packet is shown in this figure. The downlink packet should follow the given sequence and should be of fixed length for every cycle.

32 Samiksha Arora Chapter 2. Firmware Design 19 System Requirements & Timing Constraints: For every uplink packet LIIB receives from the flight computer, it sends a downlink packet back to the flight computer. Figure 2.9 shows a high level data flow diagram of instrument communication in one cycle. The uplink command is relayed to the LIIB via the flight computer. LIIB unpacks the uplink command and sends the sub-packets to the respective science instruments. The instruments, on receiving the uplink command via LIIB, create their respective housekeeping and science data. In the meantime, LIIB assembles its housekeeping data. The science data from the three instruments is received as three separate downlink sub-packets. LIIB arranges the sub-packets and the housekeeping data to comply with the sequence shown in Figure 2.8. It sends the downlink data packet back to the flight computer. There are a few constraints imposed on the firmware design in terms of system requirements and timing: 1. Every downlink packet LIIB sends to the flight computer should be of fixed length. 2. The data in the downlink packet should follow the order described in Figure The downlink packet length should not be affected if one or more instruments are OFF. 4. The RPA can normally operate in three modes depending on the Points Per Sweep (PPS) - 32 PPS, 64 PPS, and 128 PPS. The LAICE restricts the RPA to operate in 64 Points Per Sweep mode. Although the RPA is allowed to operate in this specific mode, it may enter one of the other two modes during the flight which can affect RPA's downlink data packet. LIIB should be able to take charge of this constraint so that the downlink data are not corrupted. 5. In addition to the aforementioned system requirements, LIIB should comply with the timing constraints within which the LAICE system operates. The upper time limit for one communication cycle is 1 second. Within this interval, the flight computer should send uplink data to LIIB, LIIB should forward the uplink sub-packets to the

33 Samiksha Arora Chapter 2. Firmware Design 20 science instruments, the instruments should compute science data and send it back to LIIB, and LIIB should send the downlink data packet to the flight computer. Since the downlink packet has a fixed data format, the LIIB FPGA must be able to assess and properly time the communication with each payload instrument.

34 Samiksha Arora Chapter 2. Firmware Design 21 Figure 2.9: Communication data flow for a single cycle. The flowchart depicts the high-level data flow for full-duplex communication with the instruments and the flight computer.

35 Samiksha Arora Chapter 2. Firmware Design 22 Firmware for Instrument Communication: The firmware for the communication module is developed in several stages. The uplink and downlink wings of communication are designed separately and then integrated together in one module. Since the uplink communication is short (12 bytes) and occurs at the beginning of every second, it doesn't have severe timing constraints. Downlink communication, on the other hand, is dependent on when each payload instrument is ready to direct its data packet to the LIIB. This packet is much longer, so the firmware for data transfer from the payload instruments to the flight computer via LIIB involves more resources. Uplink Communication The process flow for uplink communication is shown in Figure The flight computer sends the uplink packet to the LIIB at the beginning of every second. As the uplink packet contains commands for the payload instruments, LIIB sub-packetizes the commands and relays them to the RPA, SNeuPI and LINAS. The uplink communication uses byte by byte mode of transfer via RS422 protocols instead of allocating memory to the sub-packets, because the number of bytes is small as compared to the downlink data packet. Additionally, this methodology optimizes the uplink communication as it consumes less time and resources.

36 Samiksha Arora Chapter 2. Firmware Design 23 Figure 2.10: Flowchart for uplink communication. The figure depicts the algorithm for uplink communication for a representative interval of one communication cycle.

37 Samiksha Arora Chapter 2. Firmware Design 24 Downlink Communication The science data from the payload instruments contain 338 bytes bytes from the RPA, 35 bytes from the SNeuPI and 24 LINAS data bytes. The instruments do not send the entire data packet in one sequence. For example, the RPA downlink packet has 279 bytes, but it does not send all the bytes together to the LIIB. Instead, it sends the data in separate segments: the command echo comes first, then the housekeeping, and then the science data. Additionally, there are 3 instruments that send data to the LIIB, one of these operates at a baud rate different from the other two. The RPA and SNeuPI instruments have a baud rate of 115,200 bps but the LINAS instrument has a baud rate of 111,111 bps. The magnitude of the packet and the time required for assembling science data mandates that the system must have distinct memory blocks for intermediate storage of each instrument data packet. Whenever a payload instrument is in the process of computing the science data and is ready to send some data out, it places the data in the allocated memory from which LIIB will read the data. Thus the memory block allocated for each instrument acts as its medium of communication with LIIB. Since the memory cells will be written and read by the payload instrument and LIIB respectively, the memory chosen should be able to read and write different memory cells simultaneously at different addresses. A dual-port RAM is therefore implemented in the FPGA design to realize the above functionality. This approach optimizes the resources and makes the process intuitive. As there are three instruments, there must be three dual-port RAM blocks. This makes the design for the communication module symmetrical and easier to debug. The architecture for a single RAM buffer for one representative instrument is shown in Figure The dual-port RAM receives the data input from the instrument UART. The memory addresses of the two ports are controlled by two counters: DataIn Counter and DataOut Counter. The The DataIn Counter keeps a record of the current address at which the data are written into the RAM. Similarly, the DataOut Counter keeps track of the address in the memory from which data are currently read out of the RAM. The two counters control

38 Samiksha Arora Chapter 2. Firmware Design 25 the dual-port RAM such that the data that comes into the RAM first goes out of the RAM first. So the dual port RAM operates like a First-In First-Out (FIFO) memory. The shared clock of the two ports run at a frequency of 10 MHz, which is the same frequency at which the FPGA operates. A handshaking mechanism is the logic behind consecutive read-write operation in the dual-port RAM. For every byte written into the memory, the DataIn counter increments by 1 (through the counter enable signal from the UART module). For every byte read from the memory, the DataOut counter increments by 1 (through the enable signal coming from LIIB UART). The byte read from the memory is fed to LIIB which subsequently transmits the data to the flight computer. A critical aspect of this mechanism is controlling the read and write pointers to the memory. For example, it is not desirable that the read pointer references data from a memory address that has not yet been written to by the payload instrument UART. This would give junk data in the downlink packet that LIIB delivers. In order to avoid such cases, it is important to regulate the boundary conditions in the read-write pointers, such as when the FIFO is full, when it is empty, when the counters have to be reset, etc. A detailed description of the boundary conditions is given below: 1. The FIFO is empty when the read and write pointers are both equal. This condition happens when both pointers are reset to zero during a reset operation, or when the read pointer catches up to the write pointer, having read the last word from the FIFO. 2. A FIFO is full when the pointers are again equal, that is, when the write pointer has wrapped around and caught up to the read pointer. This is a problem. The FIFO is either empty or full when the pointers are equal, but this is ambiguous. 3. The write pointer always points to the next word to be written; therefore, on reset, both pointers are set to zero, which also happens to be the next FIFO word location to be written. Similarly, the read pointer always points to the next FIFO word to be read. The first condition is met with by giving a synchronous reset to both the counters. When the

39 Samiksha Arora Chapter 2. Firmware Design 26 LIIB receives the uplink packet for the next cycle from the flight computer, both counters are reset. This ensures that the two counters are reset to zero before the next instrument communication cycle begins. The second boundary condition is handled by checking when the FIFO is full. This is done by comparing the read and write counters to the size of the downlink packet for the respective instrument. For example, the FIFO for the RPA is full when the two counters are equal to 279. The size of the RPA downlink packet is 279 bytes as shown in Figure 2.8. The third condition is met by using the handshaking mechanism to drive the enable signal for the read and write counters. Each data byte being transferred from the RPA to the LIIB is accompanied by a control signal that indicates the presence of data in the bus. The LIIB responds with another control signal to acknowledge receipt of the data. These control signals are used to drive the two counters. The simulation for the operation of the RAM buffer is shown in the following chapter. Figure 2.11: Dual-port RAM architecture. The figure depicts the block diagram of the architecture of dual-port RAM and its interfacing with the UARTs. The system-level design for this figure is given in Appendix B. The design of the communication module at the system level is shown in Figure The RAM buffer module is instantiated three times in the communication module - once for each instrument. On receiving the uplink packet from the flight computer, the LIIB UART sub-packetizes the 12-byte command as per Table 2.3 and transmits the commands to the

40 Samiksha Arora Chapter 2. Firmware Design 27 3 instruments. While the instruments generate their respective science data, the FPGA evaluates the housekeeping data by interfacing with the MUX and ADC that reside on the LIIB. The housekeeping block is responsible for reading LIIB's status data, which include representing the temperature, voltage, and current monitors plus the thermal knife status. The downlink packet is divided into 4 parts- housekeeping data (it consists of LIIB echo and status data), RPA downlink data, SNeuPI data and LINAS data. These 4 sub-packets should be sent to LIIB in the order shown in Figure 2.8. To achieve this functionality, we need a logic block that takes multiple inputs and sends them out as the output, one at a time, in the required order. A multiplexer (MUX) is used to implement this operation. A multiplexer is a combinational logic circuit designed to switch one of the several input lines through to a single output line by the application of a control signal, called select lines. A multiplexer circuit with 2n inputs has n select lines. Since there are 4 inputs in our application, there are 2 select lines. Hence, a 4*1 MUX is sufficient for this operation. Table 2.4 shows the logic states of the select lines for the MUX. The inputs for the MUX come from the dual port RAM and the select lines for the MUX come from a counter that is driven by the finish signals (shown in Figure 2.11) of the four data blocks. As shown in Figure 2.8, the housekeeping data are first in the sequence, so the first finish signal to the counter occurs when the LIIB has read the data from its RAM. This finish signal increments the counter to 1. The select lines under this condition are equivalent to S1S0 = 01, which causes the MUX to switch to the RPA. When all the data are read from the RPA dual port RAM, it sends out a finish signal that increments the counter to 2, causing the select lines to become S1S0 = 10. This process continues to read in the data from the SNeuPI and LINAS instruments. The LINAS RAM sends a finish signal to the MUX when the data has been read from its RAM. This finish signal is used to reset the counter and set S1S0 = 00, signifying that the downlink packet for the current cycle has been sent to the LIIB. This signal also marks the end of the downlink data packet for that interval. Appendix B shows the firmware design that implements the multiplexer logic.

41 Samiksha Arora Chapter 2. Firmware Design 28 Table 2.4: Select lines definition of 4*1 MUX. This table represents the select lines definition of the 4*1 MUX to comply with the control sequence in Figure 2.8. Figure 2.12 shows that there is an op-mode interface logic block for every instrument between the respective memory block and the MUX. As mentioned, the data coming out of the three instruments depend on the switching state of the instrument. If an instrument is ON, then its downlink packet consists of science data. If an instrument is OFF, then the data from the instrument will repeat the data of the previous second for the sequence. The instrument will give junk data in the consecutive seconds if the instrument continues to be in the OFF state. This approach creates ambiguity because it is not clear whether the last data word is a valid new sample or simply a repetition of the previous sample. To avoid the misinterpretation of data at the flight computer we implement op-mode interface logic. The op-mode interface logic ensures that whenever an instrument is OFF, its downlink packet consists of all high bytes (xff). For example, if the op-mode is 010, referencing Table 2.1, the RPA and the SNeuPI will be OFF. From the op-mode interface logic, the downlink packet will containhousekeeping data, RPA data with all 279 bytes set to high (xff), SNeuPI data with all 35 bytes set to high (xff), and valid LINAS data. This approach ensures that the ground-based processing software can correctly identify the end of the sequence of valid data samples for each instrument. As discussed previously, LIIB receives a new uplink command string from the flight computer

42 Samiksha Arora Chapter 2. Firmware Design 29 once per second. A valid command sequence always begins with the LIIB start word. If a command does not begin with the designated start word, it is considered to be invalid and is discarded by LIIB. As per the telemetry matrix in Appendix C, the valid start word for LIIB is x43. From the above description, it should be clear that the LIIB communication firmware meets all the system requirements and timing constraints. The operation of the MUX guarantees that the downlink packet the LIIB sends to the flight computer is of fixed length. Additionally, the order in which the select lines for the MUX are set up (as shown in Table 2.4) ensures that the downlink packet follows the sequence shown in Figure 2.8. The op-mode interface logic ensures that the length of the downlink packet is constant and independent of the operation mode. Moreover, the design ensures that the downlink packet does not get corrupted even if the RPA enters into 32 PPS or 128 PPS mode. It can be observed from the telemetry matrix that these two modes only add more science data to the RPA downlink packet while keeping the required data bytes constant. The RPA RAM buffer guarantees that the RPA downlink sequence is of constant length by adding a comparator that checks for the length of the data packet. When the RPA sequence reaches 279 bytes, it issues a finish signal to indicate that RPA has finished buffering the data. This transfers the control of the MUX select line from the RPA to SNeuPI, thus rendering the extra bytes obsolete while maintaining the correctness of the downlink data packet. The timing diagram for communication between the LIIB and the instruments is shown in Figure 2.3. It can be seen that the time taken to finish one communication cycle is well within 1 second, therefore, the design conforms to the system timing constraints. Simulations results for the various functions performed by the module are shown in the following chapter.

43 Samiksha Arora Chapter 2. Firmware Design 30 Figure 2.12: Architecture and control flow of instrument communication. The architecture of full-duplex communication at the block level is depicted in this figure. The various blocks represent the respective functions performed by them. 2.7 Top Level Architecture The top level module instantiates the above modules and integrates them to complete the LIIB firmware. It logically links together the power sequencer, command interpreter, thermal knife, and communication module. This hierarchical approach makes the system architecture more manageable by reducing complexity and introducing a rational partitioning in the design processes. The robustness of the hierarchical approach provides multiple possibilities for avoiding design errors, simplifies design corrections and modifications, and reduces the overall design time and cost. Since the sub-blocks of the firmware are designed first and then linked together in the top level, the methodology used here is bottom-up design methodology. The sub-blocks must be interconnected in the top level module because each block has inputs coming from a block and outputs feeding to the inputs of other blocks. For example, the input command for the command interpreter comes from the communication module and the output feeds into the power sequencer and thermal knife module.

44 Samiksha Arora Chapter 2. Firmware Design 31 The architecture of the top level module is shown in Figure The figure shows the interfacing among various modules to achieve the required functionality. The modules have a synchronous reset and a shared clock that runs at 10 MHz. The instrument communication module has the clock, reset and the uplink packet from the flight computer as the primary inputs. The intermediate inputs to the module come from the command interpreter and the thermal knife module. As discussed previously, the instrument communication goes into a standby mode when one of the thermal knife modes from Table 2.2 is activated. The thermal knife module sends a Comm Enable signal to the communication module that indicates whether the LIIB is operating in normal mode or in one of the thermal knife modes. The command interpreter feeds the op-mode to the communication module that is required to implement the op-mode interface logic. Additionally, the command interpreter feeds the op-mode and the LIIB mode to the power sequencer and thermal knife modules respectively. The inputs to the command interpreter to latch the op-mode and LIIB mode come from the communication module. The primary outputs include the downlink data packet sent to the flight computer, the latch signals for the thermal knife circuit, and the power for the science instruments.

45 Samiksha Arora Chapter 2. Firmware Design 32 Figure 2.13: Architecture at the top level. This figure depicts the integration and interconnection of design modules to facilitate the LIIB operation. Together this architecture meets the design requirements of the LIIB.

46 Chapter 3 Results and Discussion This chapter describes the test procedure for the validation of the LIIB firmware design. It provides details on the issues encountered during the hardware-software testing of the design and the methodology used to mitigate these issues. The results for various functions performed by the design are included as simulated output as well as LabVIEW output. 3.1 Design Flow & Test Plan A necessary next step after firmware development is design validation. After the design is developed, it is synthesized and verified functionally via simulation, followed by hardware validation. Figure 3.1 shows the step by step procedure followed to verify the design. The first stage in the process is the development of a firmware design. A detailed description of the LIIB firmware has been given in the previous chapter. Once the design is developed, it is synthesized, thus, the second stage is design synthesis. Before proceeding to the next stage, design verification is done. The approach chosen for design verification is behavioral simulation (RTL Simulation). This simulation is performed before synthesis to verify the Register Transfer Level (RTL) code and to confirm that the design functions as intended. The stimulus is given by an HDL test 33

47 Samiksha Arora Chapter 3. Results and Discussion 34 Figure 3.1: FPGA design flow. The primary stages of design flow to enable the LIIB operation are shown in this figure. bench that connects the design-under-test (DUT) with the internally generated stimulus to drive the DUT inputs and observe the intermediate process variables and outputs. Design verification is further followed by synthesis. Design synthesis is the process of converting the Register Transfer Level (RTL) description of the design in terms of logic gates. This stage typically involves translation of the HDL code into gate-level netlist format. A netlist is a list of logical elements (gates, flip-flops, etc.) and a list of connections describing how these elements are wired together. The synthesis process checks the code syntax and analyzes the hierarchy of the design to ensure that the design is optimized for the architecture. A cyclic process links design development, design verification, and design synthesis, as shown in Figure 3.1. This cycle represents iterative debugging of the design. For example, when the firmware for a module is simulated and the results do not match the requirements, it is necessary to debug the design to obtain correct outputs before

48 Samiksha Arora Chapter 3. Results and Discussion 35 proceeding on to design synthesis. The next stage after design synthesis is implementation. Implementation is the process of converting gate-level netlist into FPGA-specific pattern. The main phase of the implementation stage is place and route. Place and route includes physically placing the netlist elements and mapping them to the FPGA physical resources (such as logic cells and connection wires). For example, the inputs and outputs in the top level module are mapped, placed and routed onto the FPGA as input and output pins. The last stage is device programming, that involves converting the placed and routed design to a format that FPGA will understand. The programming file loaded on the FPGA is generated in this stage. The first and second stages in the design flow, together with design verification are the significant phases in developing the accurate design. The third and fourth stages are essentially automated by the software tools. Once the device is programmed, we proceed onto hardware validation. The equipment for laboratory setup includes the LIIB, the payload instruments, and a LabVIEW GUI that mimics the flight computer. The testing is done in stages as the design is developed. For example, the instrument communication with a single representative instrument is designed first. Once that is validated, the three-instrument communication is designed. This modular approach makes the firmware design process easier and simplifies the downlink data validation at the flight computer end. The procedure is rigorous and involves moving back and forth between the stages of the design flow depending on the errors and issues encountered. The following section gives a brief explanation of the challenges faced and the approach taken to solve them. 3.2 Issues and Challenges In the early stages of instrument communication, we diagnosed a place and route fault in routing the clock and the reset signals in the design with the FPGA I/O pins. A place and route fault occurs when there is an error in placing and interconnecting the

49 Samiksha Arora Chapter 3. Results and Discussion 36 logical elements on the FPGA grid. The clock and reset signals are primary inputs and they have to be routed to establish a connection with the I/O pins. The FPGA schematic shows that the two pins are placed next to each other. The issue was that we were able to route only one of the two inputs in the design with the respective FPGA pin. We suspected that the fault could be due to the inconsistency between the schematic and the layout of the LIIB. Another hypothesis was that the clock and reset pins were grouped together and configured as two parts of a differential input. In this case, they would use the same resources. To diagnose the fault, we first confirmed that the connections for the clock and reset pins in the schematic and the layout were consistent. To test the second hypothesis, we analyzed the I/O attributes of the two inputs and recognized that the two pins were in fact in the same pin group. Since the design was modular and had multiple interconnections, it had a lot of high fanout control signals. These control signals needed an internal driver to drive them and meet the area and performance goals of the circuit. So, there was need of individual drivers for clock and reset signal, but because they were grouped together, only one of them could utilize the driver, thus causing the routing error for the other. There were two solutions proposed for this problem: 1. Modifying the hardware so that the clock and reset pins were on different pin groupings; 2. Creating a buffer in the design for the reset and using the internal buffer for the clock. This would give individual drivers to both clock and reset and they would then be able to control the high fanout clock and reset. Since the first method involved hardware changes, we chose the latter approach due to ease of design modification. Using the internal buffer for the clock and the externally generated buffer in the design for the reset eliminated the issue, thus giving a successfully placed and routed design ready to be programmed onto the device.

50 Samiksha Arora Chapter 3. Results and Discussion 37 Another issue that we discovered was a malfunction in the instrument communication for a single representative instrument. The test plan includes getting the LIIB to communicate with only the RPA hooked up first, and then with the three instruments altogether. In testing the communication with a single instrument, we use the LabVIEW GUI to emulate the flight computer. A high level block diagram of the test setup is shown in Figure 3.2. The GUI sends the uplink command to the LIIB, LIIB relays it to the RPA board, the RPA generate the science data and sends it to the LIIB, which further transmits the downlink data to the LAbVIEW GUI. Figure 3.2: Block Diagram of laboratory setup for LIIB and RPA. While performing hardware validation of the design, we observed that the downlink data packet received by the GUI consisted of all high (xff) bytes, no matter how many bytes the GUI was allowed to receive. Figure 2.8 shows that the RPA downlink packet sequence should always comprise 279 bytes. Whether the GUI was allowed to receive 279 bytes or more, the downlink packet sequence consisted of xff irrespective of the uplink command from GUI. Figure 3.3 and Figure 3.4 show the downlink packet sequence received by the GUI when the expected number of bytes were set to 279 and 1000 respectively. To test whether the issue was with the LIIB or the GUI, we bypassed the LabVIEW interface GUI and sent sample commands directly from the National Instruments-Virtual Instrument Software Architecture (NI-VISA) test panel to the LIIB. The results of this test can be seen in Figure 3.5. The downlink packet sequence did not change. This confirmed that the LabVIEW GUI was functional and correctly interfaced with the LIIB.

51 Samiksha Arora Chapter 3. Results and Discussion 38 Figure 3.3: LabVIEW output- expected no. of bytes 279. The GUI receives 279 bytes (all high) from the LIIB with the expected byte count set to 279 in the GUI. Figure courtesy: Stephen Noel. The results led to the assumption that the LIIB output pin may not be powered and could be OFF and thus always high, therefore giving xff as output. To test this hypothesis, we confirmed the status of the 5V converter that was used to power the output pin. The instrument transceivers that power the communication cable received power supply from the

52 Samiksha Arora Chapter 3. Results and Discussion 39 Figure 3.4: LabVIEW output- expected no. of bytes When the expected byte count is set to 1000, the GUI receives 1000 bytes (all high) from the LIIB, indicating that the issue could be with the LIIB or with the GUI. Figure courtesy: Stephen Noel. LIIB. If the 5V DC-DC converter was not powering up, then the transceiver driver circuit that enabled the instrument communication would be in OFF state, therefore, there would be no communication with the instruments. When tested, the converter was in fact in OFF state. However, when powered ON, the issue still remained. This led to the theory that the RPA may not be receiving the uplink command at all. In that case, there would be no

53 Samiksha Arora Chapter 3. Results and Discussion 40 data measurements and the output data stream would contain all HIGH bytes. To test this hypothesis, we probed the output pin that sent uplink command from the LIIB to the RPA and observed that the RPA was not receiving the correct command packet. This confirmed the hypothesis and the fact that the handshaking mechanism between the two instruments was not functioning correctly. Therefore, we went back to the design and performed rigorous checks via test bench simulations. The issue was that the read and write enable signals for the LIIB and the RPA UART were not synchronized, thus giving corrupted data at the LabVIEW GUI end. The signals were synchronized by fixing the bug in the handshaking mechanism for the data transfer between the LIIB and the RPA UART. The issue observed on the GUI was successfully replicated by the test bench. The simulation results for working design of the LIIB- RPA communication are shown in Figure 3.15 and Figure Figure 3.5: LIIB communicating with NI VISA test panel. The LIIB communicates with the NI VISA test panel to eliminate the hypothesis that the issue could be with the GUI. When the read operation is performed, the LIIB returns all high bytes irrespective of the expected byte count (see bullet 2: Read Operation in this figure) indicating that the GUI is error free. Figure courtesy: Stephen Noel.

54 Samiksha Arora Chapter 3. Results and Discussion 41 After validating the communication between the LIIB and the RPA, the firmware was expanded and designed to allow the LIIB to communicate with all three instruments. While validating the three-instrument communication we detected unusual behavior in the downlink data packet. When the LIIB was commanded OFF ON OFF ON (where OFF means all instruments OFF and ON means all instruments ON), the first OFF ON transition contained valid data. But when the op-mode changed from OFF ON the second time the data were invalid and continued to be invalid for the next OFF ON transitions. Analysis revealed that the invalid data was in fact valid downlink data offset from its normal position in the LIIB downlink data packet. To narrow down the issue, we analyzed each instrument s downlink data packet and observed that the offset was in the RPA s downlink data packet. So we focused on the RPA and observed the behavior of RPA uplink echo. The downlink data packet with this defect is shown in Figure 3.6. Each row in the figure signifies one communication cycle, i.e. one second. The instruments are OFF for the first two communication cycles (Rows 2-3), so the downlink packet contains xff, which is correct. The RPA uplink echo signal comprises the first four bytes and should be (40, 0, 40,0). For the first OFF ON transition, the downlink data are valid for most cycles. This can be seen from rows The first two rows contain uninitialized data, which is fine because the RAM has not been initialized yet. Row 6 has an extra byte corrupting the data packet in this cycle. Rows 7-11 contain a valid downlink packet. Next, when the op-mode is 000 (all instruments OFF), the downlink packet contains xff, as expected. The issue begins when the instruments are turned on again, i.e. on the second OFF ON transition. This can be seen in rows The data packet has a constant offset in these rows. Moreover, the uplink echo does not match the correct echo bytes. The same issue is observed in rows as well. Basically, each time the RPA was power cycled and turned ON again, we got a one-byte

55 Samiksha Arora Chapter 3. Results and Discussion 42 shift in the RPA data packet and the first byte in the RPA packet got overwritten with the last byte from the previously sent packet. Figure 3.6: LIIB downlink packet output- RPA data offset issue. Each row is the output of a single representative communication cycle. The reception of invalid data begins from the second OFF ON transition. Rows 4-11 indicate that the data are valid during the very first OFF ON transition. Rows 15-21, 25-29, and show the invalid data for the consecutive OFF ON transitions. Figure courtesy: Stephen Noel. There were two ways in which the data could be corrupted. Either the problem was occurring during the load of serial data into the LIIB, or during serial write of the data from the LIIB to the GUI. In order to narrow down the issue, an intermediate design that had pre-defined downlink packet in a flash ROM was built. Instead of transmitting the downlink packet obtained from the serial load, the LIIB transmitted the downlink packet in the flash ROM.

56 Samiksha Arora Chapter 3. Results and Discussion 43 The number of bytes for this test was reduced to small numbers to make the debugging convenient. For example, the RPA has 279 bytes in the downlink packet but the number of bytes was reduced to 15 for this test. The RPA downlink packet in the flash ROM had 15 pre-defined bytes, numbered 1-F. The results obtained from the hardware validation of this intermediate design are shown in Figure 3.7. Figure 3.7: Intermediate design output - dual-port RAM replaced with flash ROM. One communication cycle is represented by a single row. Rows 5-8, 12-14, 18-20, and are the outputs of the first, second, third and fourth OFF ON transitions respectively. It can be observed that there is no offset in the data for any OFF ON transition. Figure courtesy: Stephen Noel. The data in the figure show that there is no offset in the downlink data packet from the RPA each time it is power cycled. For example, when it powered OFF ON the second time, the bytes remain in the right place with no data being offset or corrupted. The conclusion was that the load of serial data into the LIIB causes the offset and data corruption. In order to resolve this issue, we conducted a more detailed study of the RPA. 6 The assumption was that the RPA would not send the downlink data to the LIIB unless it had received its entire uplink command packet of 5 bytes (refer Table 2.3). However, it was a false assumption. The RPA sent science data to the LIIB whenever it had a segment of data computed, even while receiving data packet from the LIIB. The design had not taken this requirement into

57 Samiksha Arora Chapter 3. Results and Discussion 44 account. Once the issue was identified, it was replicated in the simulation via test bench. The results can be seen in Figure 3.8. A constant byte offset for the RPA downlink packet was reproduced by forcing the RPA downlink data transmission to begin in the middle of RPA uplink command packet. In the figure, RPA Tx indicates the uplink command packet sent to the RPA instrument board, RPA Rx is the downlink packet LIIB received from the RPA. The highlighted RPA DATAINCOUNT Q 2 is the counter that keeps track of the address of the byte loaded in the memory. It can be observed that the counter does not get reset when the communication cycle begins. Instead, it is reset somewhere in between when the LIIB receives the downlink packet. Thus, the cause of this issue was the incorrect logic used to reset the load counter. Figure 3.8: LIIB data offset error simulation. The waveform depicts the replication of downlink data offset error in the simulation. The waveform shows the case when RPA sends the downlink data to LIIB while it is receiving the uplink command packet. The RPA DATAINCOUNT Q 2 does not reset when a new uplink command is received, leading serial load to begin at an intermediate memory location, thus causing offset in the data. To resolve the issue, the logic for the reset signal for the load counter was modified. The counter was made to reset when the LIIB begins to receive the uplink command packet from the fight computer. The START signal that indicated the beginning of uplink packet received by the LIIB from the flight computer was used to reset the load counter. The simulation results that show the output of the modified logic are shown in Figure 3.9. It can be seen that the DATAINCOUNT Q 2 counter resets to 0 at the start of the uplink packet received by the LIIB.

58 Samiksha Arora Chapter 3. Results and Discussion 45 Figure 3.9: LIIB data offset error correction. The RPA DATAINCOUNT Q 2 is now reset when LIIB starts to receive a new uplink command packet. There is no data offset even when RPA sends the downlink data to LIIB while it is receiving the uplink command packet. The simulation waveform shows the corrected sequence of RPA DATAINCOUNT Q 2, thus eliminating the issue. 3.3 Results Instrument Communication: The laboratory setup for three-instrument communication is shown in Figure The LIIB is connected to the RPA, SNeuPI, and LINAS instrument boards using UART ports via COMM-9 cable. The LabVIEW GUI is used to mimic the flight computer. Figure 3.10: Laboratory setup for instrument communication. Figure courtesy: Stephen Noel.

59 Samiksha Arora Chapter 3. Results and Discussion 46 Figure 3.11 shows the downlink data packet for one communication cycle that the LabVIEW GUI received from the LIIB. The expected count and the returned count of the number of bytes from the LIIB are same, thus indicating that the downlink packet is of correct length. The first four bytes in LIIB Data Out match the RPA uplink echo, implying that there is no offset or data corruption. Figure 3.11: Stephen Noel. Three instrument communication output. Figure courtesy: Figure 3.12 shows the simulation results for the uplink data flow. LIIB DATAOUT indicates the bytes received by the LIIB from the flight computer. The LIIB unpacks these bytes and sends the uplink commands to the respective instruments as per Table 2.3. When the packet enable signal of an instrument is high, the byte is latched to that instrument. For example, the RPA packetenable signal gives high pulses for bytes 3-7, so these bytes are latched to the RPA. The RPA Tx indicates the serial communication of the bit stream for bytes 3-7 to the RPA instrument. Similarly, the SNeuPI packetenable signal gives high pulses for bytes 8-9, so these bytes are latched to the SNeuPI. The SNeuPI Tx shows the serial communication of the bit stream for bytes 8-9 to the SNeuPI. The LINAS packetenable signal gives high

60 Samiksha Arora Chapter 3. Results and Discussion 47 pulses for bytes 10-12, so these bytes are latched to the LINAS. The LINAS Tx shows the serial communication of the bit stream for bytes to the LINAS instrument. Figure 3.12: Uplink communication simulation waveform. Figure 3.13 shows the operation of the 4*1 MUX that is responsible for the downlink data flow. The finish signals from the housekeeping module and the three dual-port RAMs feed into an active low enable counter that drives the select lines of the MUX. The HK Done is the finish signal from the housekeeping module. Whenever HK Done, RPA Done, or SNeuPI Done goes low, the SelectLine Counter gets incremented. The counter is reset to 0 when the LINAS Done signal goes low. The downlink data flow from the instruments follows the sequence mentioned in Table 4. Figure 3.13: MUX control logic simulation. Figure 3.14 shows the operation of the command interpreter. LIIB DATAOUT is the byte received by the LIIB from the flight computer. UplinkCounter is the counter that increments when a byte is received. The enable signal is triggered to a high pulse when UplinkCounter becomes 2. Byte2 is the byte latched from the uplink data packet. LINAS CNTRL, RPA CNTRL, SNeuPI CNTRL are the op-mode bits, LIIB MODE net 0 is the LIIB mode.

61 Samiksha Arora Chapter 3. Results and Discussion 48 Figure 3.14: Simulation waveform for command interpreter operation. Figure 3.15 shows the operation of the dual-port RAM for a single representative instrument. The figure shows serial load operation of the downlink data packet from the science instrument in the dual-port RAM for the respective instrument. Asserting BLKA Enable loads the data into the RAM. SNeuPI DATAINCount is the counter that records the current address at which the data is loaded into the memory. SNeuPI DataInCount Enable is the enable signal that drives the counter. The SNeuPI RAMDataIn is the data loaded in the RAM at the memory address given by SNeuPI DATAINCount. Figure 3.15: Simulation output for serial load operation of dual-port RAM. Figure 3.16 shows how the signals in Figure 3.15 are triggered at the positive edge of the clock. Figure 3.16: Serial load operation logic simulation. Figure 3.17 shows the serial write operation of the downlink data packet from the LIIB to the flight computer. SNeuPI DATAOutCount is the counter that records the current address from which the data are read from the memory. SNeuPI DataOutCount Enable is the enable signal that drives the counter. The SNeuPI RAMDataOut is the data read from the RAM at the memory address given by SNeuPI DATAOutCount. SNeuPI DATAINCount,

62 Samiksha Arora Chapter 3. Results and Discussion 49 SNeuPI DataInCount Enable, SNeuPI RAMDataIn, and BLKA Enable are constant in the waveform indicating that the entire data packet has been loaded into the memory. Figure 3.17: RAM. Simulation output for serial write operation of dual-port Power Sequencer: The laboratory setup for hardware validation of power sequencer is shown in Figure The MOSFET switches control the DC-DC converters (shown in Figure 2.1) which in turn control the switching state of the payload instruments. The DC-DC converters included the single output converters that generate- 3.3 V, and 12 V, and dual output converters that generate- ±5 V, ±15 V. The single output converter (3.3 V) and both dual output converters are used to power the RPA and SNeuPI instruments. The LINAS instrument is powered by the 12 V single output converter. To validate the functionality of the power sequencer, end-to-end testing was done by probing the control pins to the MOSFET switches for each op-mode. Table 3.1 shows the voltage and current readings obtained at the test points for each converter for every op-mode. For example, when LINAS is ON, only the 12 V converter reads 12 V. When all the instruments are ON, the 12 V, 3.3 V, ±5 V, and ±15 V are also high. Table 3.2 shows the voltage read at the secondary switches. Although these control pins do not switch with the change in op-mode, they are a check on whether the LIIB is functioning correctly. Tables are an expansion of Table 3.1. They list the voltage read from each pin in the power switching circuit for each DC-DC converter and for every op-mode.

63 Samiksha Arora Chapter 3. Results and Discussion 50 Table 3.1: Power Sequencer I. The table shows the voltage and current values monitored at the control pins of DC-DC converters for every opmode. Measurements taken by Stephen Noel. Table 3.2: Power Sequencer II. The voltage and current output values obtained at the secondary switches are given in this table. Measurements taken by Stephen Noel.

64 Samiksha Arora Chapter 3. Results and Discussion 51 Table 3.3: Power Sequencer III. The table lists the voltage output at each pin for op-mode 000 and 001 (refer Table 2.1).Measurements taken by Stephen Noel.

65 Samiksha Arora Chapter 3. Results and Discussion 52 Table 3.4: Power Sequencer IV.The table lists the voltage output at each pin for op-mode 010 and 011 (refer Table 2.1).Measurements taken by Stephen Noel.

66 Samiksha Arora Chapter 3. Results and Discussion 53 Table 3.5: Power Sequencer V.The table lists the voltage output at each pin for op-mode 100 and 101 (refer Table 2.1).Measurements taken by Stephen Noel.

67 Samiksha Arora Chapter 3. Results and Discussion 54 Table 3.6: Power Sequencer VI.The table lists the voltage output at each pin for op-mode 110 and 111 (refer Table 2.1).Measurements taken by Stephen Noel.

68 Samiksha Arora Chapter 3. Results and Discussion 55 Thermal Knife: Figure 3.18 shows the laboratory setup for the thermal knife. The figure shows the cap release mechanism when the thermal knife latch circuit is connected to the LIIB. The thermal knife circuit is tested for all the modes given in Table 2.4. Figure 3.18: Laboratory setup for thermal knife mechanism. An annotated view of the laboratory setup for thermal knife operation is shown in this figure. The thermal knife hardware is connected to the multimeter that monitors the voltages on latch sensors. The output voltages obtained from this test are shown in Table 3.7. Figure courtesy: Stephen Noel.

69 Samiksha Arora Chapter 3. Results and Discussion 56 Table 3.7: Results of thermal knife mechanism. The table lists the voltage outputs at the control pins of latch sensors for various LIIB modes. Measurements taken by Stephen Noel. The output control pins were probed to verify the functionality of the design for every mode. The results that validate the operation of thermal knife mechanism are shown in Table 3.7.

70 Chapter 4 Conclusion and Future Work This thesis details the principle and firmware design of the interface board for use in the LAICE CubeSat. The functionality of the LIIB has been validated through end-to-end testing with the components of the LAICE. The primary objectives were to make the design optimized, modular, and flawless in order to ease the downlink data analysis at the flight computer end. The design meets all the system requirements and specifications of the LAICE as listed in Table 4.1. The architectural framework of the firmware design makes it adaptable for use in the succeeding LAICE CubeSat missions. A detailed view of all the major specifications met by the LAICE LIIB firmware for its efficient operation in the flight is given in Table

71 Samiksha Arora Chapter 6. Conclusion 58 Specification Sub-sections Status Details Power Regulate power to Section 2.4 Switching the payload instruments Space Pressure Sensor- Thermal Knife Release Mechanism (SPS-RM) Section 2.3 Standby instrument communication on TK activation Command Command to initiate power switching Section 2.5 Interpreter and thermal knife Full-duplex communication with the payload and flight computer Instrument Simplify downlink data Section 2.6 Communication analysis Comply with system requirements and timing constraints Fixed data sequence Chapter 2 & packet size One-Second Data flow timing analysis Section 2.2 Cadence Design flow and test procedure Design Simulation and bench-testing Chapter 3 Validation to make the LIIB flight-ready Table 4.1: Specification table for LIIB firmware design. This table outlines the primary and the sub-specifications of LIIB operation and the status of completion of these specifications. The section of the thesis that details the respective specification is mentioned alongside. Future Work: There are various techniques that can be implemented to enhance the robustness of the firmware architecture of LIIB for the LAICE CubeSat mission. For instance: 1. The validity of the uplink packet that LIIB receives from the flight computer relies upon the correct start word. The architecture can be made more robust by inclusion of parity check bits for the payload commands embedded in the uplink packet. This is an addition to the architecture that is not really necessary since no uplink command can damage the LIIB instrument.

72 Samiksha Arora Chapter 6. Conclusion The reliability of the LAICE CubeSat on LIIB for its primary functions can be made more secure by giving the FPGA the ability to be remotely reprogrammed, even during the mission. 3. The architecture can be simplified by using alternative memory blocks since each port in dual-port RAM is used to either read or write the data. Since we are not exploiting the advantages of dual-port RAM, the use of a simplified memory block can optimize the firmware architecture. These additional tasks can increase the robustness and reliability of the LIIB architecture and therefore, make the LAICE CubeSat mission more successful.

73 Bibliography 1 J. Westerhoff et al. Laice cubesat mission for gravity wave studies. Advances in Space Research, (ASR-D R1), Alexander Ghosh, Stephen Noel, Bindu Jagannatha, Greg Earle, Gary Swenson, Kevin Bassett, Victoria Coverstone, Rebecca Bishop, Ryan Davidson, Lucy Fanelli, Chad Fish, Patrick Haddox, Zachary Harlow, Zhe Ji, Erik Kroeker, Tony Mangognia, Peter Marquis, Daniel Martin, Cameron Orr, Robert Robertson, Shimeng Wang, and John Westerhoff. Increasing cubesat form factor to 6u: the lower atmosphere/ionosphere coupling experiment. In 21st IAA SYMPOSIUM ON SMALL SATELLITE MISSIONS, volume IAC-14,B4,4,10,x IAC, L. Fanelli, S. Noel, et al. A versatile retarding potential analyzer for nano-satellite platforms. Review of Scientific Instruments, Manuscript submitted for publication. 4 Vidur Garg. Swept neutral pressure instrument (sneupi): Investigating gravity waves in the ionosphere. Master s thesis, Virginia Tech, Therese Moretto. Cubesat mission to investigate ionospheric irregularities. Vol. 6, S11002, doi: /2008sw000441, November Lucy Katharine Fanelli. Electronics for a versatile and robust retarding potential analyzer for nano-satellite platforms. Master s thesis, Virginia Tech,

74 Appendix A LIIB Schematics Appendix A contains schematics for the LIIB. All schematics appended in this chapter are attributed to Cameron Orr. They are included here for reference only. 61

75 Samiksha Arora Appendix A. LIIB Schematics 62

76 Samiksha Arora Appendix A. LIIB Schematics 63

77 Samiksha Arora Appendix A. LIIB Schematics 64

78 Samiksha Arora Appendix A. LIIB Schematics 65

79 Samiksha Arora Appendix A. LIIB Schematics 66

80 Samiksha Arora Appendix A. LIIB Schematics 67

81 Appendix B Firmware Architecture Discussion The architecture for the firmware discussed in Chapter 2 are given here. PowerSequencer.vhd is the file that takes the op-mode as input and assigns the output state to the control switches based on the op-mode. UARTRamBuffer.vhd file links the instrument UART and the dualport RAM for a single representative instrument. LIIB Comm.vhd describes the system level architecture for the instrument communication. TopLevel.vhd is the top level module that integrates the previous modules. 68

82 Samiksha Arora Appendix B. Firmware Architecture Discussion 69 Figure B.1: Power Sequencer.vhd

83 Samiksha Arora Appendix B. Firmware Architecture Discussion 70 Figure B.2: Command Interpreter.vhd

84 Samiksha Arora Appendix B. Firmware Architecture Discussion 71 Figure B.3: UARTRAMBuffer.vhd

85 Samiksha Arora Appendix B. Firmware Architecture Discussion 72 Figure B.4: Instrument Communication.vhd

86 Samiksha Arora Appendix B. Firmware Architecture Discussion 73 Figure B.5: Top Level.vhd

87 Appendix C Telemetry Matrix Discussion Appendix C contains a detailed view of the uplink telemetry for the LAICE. The downlink telemetry details have been excluded from this chapter because of its size for convenience. All figures appended in this chapter are attributed to Stephen Noel. They are included here for reference only. 74

88 Samiksha Arora Appendix C. Telemetry Matrix Discussion 75 Figure C.1: UofI to LIIB Uplink Telemetry. The figure depicts a detailed view of the LIIB uplink telemetry for the command packet LIIB receives from the flight computer. The University of Illinois team is responsible for sending the uplink command packet to the CubeSat.

89 Samiksha Arora Appendix C. Telemetry Matrix Discussion 76 Figure C.2: LIIB Mode Command Defintion. A comprehensive list of the opmodes and the LIIB modes that the LAICE can operate in is given in this figure. The valid start word for the LIIB uplink command packet is x43. Figure C.3: RPA Uplink Telemetry. The figure shows the detailed view of the RPA uplink telemetry. The Points Per Sweep value is set to 64 points per sweep for the LAICE CubeSat mission.

90 Samiksha Arora Appendix C. Telemetry Matrix Discussion 77 Figure C.4: SNeuPI Uplink Telemetry. The figure shows a comprehensive listing of the SNeuPI telemetry in the uplink command packet.the standard baud rate at which SNeuPI operates is 115,200 bps. Figure C.5: LINAS Uplink Telemetry. The figure depicts a detailed view of the LINAS telemetry in the uplink command packet. The baud rate at which LINAS operates is 111,111 bps.