NASA Ames Suborbital Flight Communication
| SCUBEE | |
|---|---|
 | |
| Sponsors | ISGC, NASA Ames Research Center |
| Team Name | SCUBEE: Space Communication Utilizing Backbone Existing nEtworks |
| Duration | Fall 2018 - Spring 2019 |
| Faculty Advisors |
|
| Mentor |
|
| Clients |
|
| Team Members |
|
While the barriers to space flight have been reduced due to the privatization of launch vehicles, two large hurdles remain for those seeking to conduct research in space: orbit-to-ground communication, and reentry recovery. Our work seeks to reduce these barriers through research in these two areas.
Communication costs can be reduced by using consumer satellite phone modems, specifically the Iridium Core 9523, to give satellites in low Earth orbit (LEO) access to a constant internet connection. Satellites and other devices operating at or below LEO and equipped with such a module would be able to stream data to Earth without the need for users to apply for frequency licenses, while also eliminating the need for prohibitively expensive radio equipment.
Additionally, our research looks to solve the current lack of recoverability of small satellites. Through the development of a Tube Deployed Reentry Vehicle (TDRV), we will allow satellites a means of surviving reentry so that equipment can be reused, or physical samples collected and returned to Earth.
Continuing work started by the Technical Education Satellite (TechEdSat) research group led by Marcus Murbach at NASA-ARC, we are utilizing the Iridium satellite constellation to communicate with satellites in LEO. The TechEdSat team has demonstrated that Iridium modules such as the 9602 Short Burst Data (SBD) transceiver are fully functional in orbit and are able to communicate with the Iridium constellation. The next step in this research is to develop a carrier module for the Iridium Core 9523 modem that adapts the core for use in a cube satellite. The Iridium Core supports a 2.4 kbit/s data stream compared to the 9602’s 340-byte packets. The 9523 is currently used in NASA’s Reentry Breakup Recorder (REBR) to transmit reentry data while falling at sub-sonic velocity post-reentry. As such, we believe the 9523 shall also operate normally in LEO and provide a stable data connection.
The NASA-ARC TechEdSat group has also been working to develop a three-stage Small Payload Quick Return (SPQR) device designed to return small payloads from the ISS back to Earth in a temperature and pressure-controlled environment. The middle stage of this device is developed under this project and consists of the TDRV.
Project Background[edit | edit source]
A multi-year project, the goals of this research team have been incrementally furthered by each successive design team over the course of nearly five years. Due to the highly ambitious nature of this project, it is likely this project will be continued for several years into the future before it is flight-ready. This section outlines the prior work done by past senior design teams and NASA.
NASA Ames TechEdSat Group[edit | edit source]
Led by Marcus Murbach at NASA Ames Research Center, the Technology Education Satellite (TechEdSat) research group seeks to develop and test technologies to help increase access to space research, and to enable the reentry recovery of small satellites and payloads. Their main goals are to test and improve use of Iridium Communications modules in low Earth orbit (LEO) to reduce communication costs, and the development of a Small Payload Quick Return (SPQR) device under their Sub-Orbital Aerodynamic Re-entry Experiments (SOREX) flight series. Ultimately, the group seeks to 'evaluate, demonstrate, and validate new technologies' before they are used on a larger scale in space. The TechEdSat group has had a longstanding relationship with the University of Idaho, traditionally hosting UI student interns and sponsoring a Capstone design project each year.
SPQR Device[edit | edit source]
The SPQR device consists of three primary stages designed to allow the recovery of small payloads or satellites from orbit. The current goal for the SPQR is to allow sample return from the ISS, with eventual use being geared towards landing small probes and rovers on Mars. The TechEdSat group is currently testing the first stage of the SPQR, the Exo-Brake drag device. Several TES satellites have been equipped with various Exo-Brake designs to test their de-orbiting abilities. Work on the latter stages of the device has been passed to teams at various universities such as the University of Idaho and San Jose State University.
The SPQR first stage consists of an Exo-Brake equipped vehicle that is released from either the ISS or a larger satellite. At a pre-determined point, or upon receiving a de-orbit command, the Exo-Brake is deployed, slowing the vehicle and guiding reentry over a specified location. Once thermal reentry begins, the Exo-Brake stage is complete, and the TDRV is released. The TDRV then uses a conical drag device to withstand hypersonic reentry and to slow its descent. Low-altitude testing and design of the TDRV has been the focus of the University of Idaho student groups. After reentry is completed, a guided parafoil is deployed which actively guides the payload to a target landing site.
Iridium Flight Testing[edit | edit source]
Iridium Communications maintains what is currently the largest consumer satellite communication constellation in a 100-minute orbit around Earth. These satellites communicate with an assortment of consumer devices and modules on the L-band spectrum. The satellites then use a 20-30GHz back-haul to communicate with one of four Iridium ground stations, which relay messages from individual devices to the internet. The end result is global, pre-licensed data coverage. As the ISS deploys research satellites at a lower 90-minute orbit, such satellites can hypothetically use consumer Iridium modules to communicate as they are under the orbit of the Iridium constellation. The TechEdSat group has shown not only is this possible, but they have proven that Short Burst Data (SBD) over the Iridium network can be sent from satellites in LEO to a server on the ground reliably.
The next step in their research is to switch from using Iridium's relatively simple 960X series modules to the Core 9523. Unlike the 960X, the 9523 can support a full dial-up internet connection, in addition to RUDICS, allowing for a live, streaming internet connection rather than short data bursts. Achieving a live data stream from a satellite would vastly improve data collection and allow for the possibility of active control from a ground computer. However, no orbital tests of the 9523 have been conducted as no platform currently exists for integrating a Core 9523 into a cube satellite.
Team GPS (Guided Parafoil System) 2014-2015[edit | edit source]
One of the most successful groups to date, team GPS successfully built and tested a working guided parafoil system capable of steering itself to a programmed GPS coordinate location during descent. Team GPS has been the only team tasked with developing the final stage of the SPQR system to date, however their designs have yet to be replicated onto any latter team's TDRV. Team GPS was also the only team to actively use both Iridium and XBee modules in their electronics system.
Team Rocket 2016-2017[edit | edit source]
In 2016, Team Rocket focused on the development of a carrier module for the Iridium 9523 Core to allow for its eventual integration into a cube satellite. Their primary objectives were as follows:
Rocket was ultimately only able to accomplish a few of their goals, primarily the creation of a prototype carrier board. Their notes and SCUBEE testing indicate their PCB is not functional and does not properly interface with the 9523. However, team Rocket made significant progress with software development, creating the base for what team ACOM would use the following year.
Team ACOM (Advanced Communication Device) 2017-2018[edit | edit source]
In 2017, Team ACOM was tasked with several goals aimed at advancing several aspects of the SPQR device and associated projects. Their primary objectives were as follows:
ACOM was ultimately only able to accomplish a few of their goals, primarily the creation of a prototype TDRV and initial testing of basic software for the Iridium 9523. The TDRV prototype was 3-D printed using PLA plastic and drop-tested in the ASUI Kibbie Dome. Reports indicate the Iridium had difficulty sustaining satellite contact was was never able to initiate a dial-up connection. However, it appears short-burst-data (SBD) messages were able to be sent. No electrical hardware was created.
Project Goals[edit | edit source]
Picking up where teams ACOM and Rocket left off, this project was split into two primary directives: the development of a carrier module for the Core 9523 for use in a cube satellite, and the further testing and development of the TDRV. As per the SCUBEE System Requirements document, the main project objectives were precisely defined as:
TDRV Development[edit | edit source]
The primary goal of the SCUBEE mechanical design group was to develop a fully functional tube deployed reentry vehicle (TDRV). The TDRV serves to deliver payloads from space to Earth, surviving the harsh conditions experienced upon reentry. TDRV design, although sparsely investigated, must meet several criteria for optimal performance. The reentry vehicle must be designed to deploy from tube dispensers similar to those found on the International Space Station (ISS), and, once deployed, must fall to Earth and survive reentry conditions up to Mach-5 (hypersonic flow). Once reentry is complete, the TDRV must self-stabilize and fall orthogonal to the Earth’s surface. Successful completion of all criteria illustrates optimal conditions for small payload return to Earth. A finished prototype and production-ready design could become instrumental to small satellite research as well as interplanetary exploration. However, due to the massive costs associated with the materials and testing required to build re-entry devices, the SCUBEE TDRV was to be a functional aerodynamic model for high-altitude balloon testing only.
Existing Design Analysis[edit | edit source]
While team ACOM's work validated the use of descent arrestors for drag force breaking, their design did not provide adequate stabilization during descent, and successful arrestor deployment was highly dependent on the drop orientation of the TDRV. These were the two problems our team set out to solve.
ACOM TDRV Head-on
ACOM TDRV Side
ACOM TDRV End
ACOM TDRV Body
ACOM TDRV Nose
ACOM TDRV Arrestors
Based on the test performance of the ACOM TDRV, the following design changes were proposed based on general aerodynamic assumptions:
Additional changes were proposed to improve ease of construction, usability, and aerodynamics, as detailed in the following diagram:
Revision and Simulation[edit | edit source]
Re-design of the TDRV began by creating a new CAD model in Solidworks based on the existing ACOM files. The new design files use global variables to define critical dimensions, allowing for the TDRV design to be easily scaled so it may be sized for each return payload or launcher system. This also allows for rapid simulation of design variations to determine the aerodynamic impact of changing key angles and dimensions.
CFD Modeling[edit | edit source]
Computational Fluid Dynamics modeling (CFD) was used to simulate the TDRV in free fall in atmosphere after thermal reentry at sub-sonic speeds. ANSYS software was used in conjunction with Solidworks models to determine the centers of pressure and mass for each TDRV design along with the the drag coefficient of each design. To be stable, the center of mass must be ahead of the center of pressure, with stability being proportional to the distance between the centers. A low drag coefficient was also desired to reduce heating. Ultimately, ANSYS was used to simulate the effect of different descent arrestor angles on the TDRV terminal velocity and center of pressure. To facilitate timely simulation, the TDRV model and fluid velocity were scaled by 90% to reduce computational load.
Zero-Degree Arrestor Modeling[edit | edit source]
CFD pressure streamlines
CFD Pressure Vectors
CFD Pressure Map
CFD Fluid Velocity Isosurface
To test the effect of increasing the arrestor surface area, the arrestor was modeled at a deployment angle of zero-degrees, or perpendicular to the body of the TDRV. The above images show the presence of a high-pressure/low-velocity region on the surface of the arrestor, indicative of aerodynamic instability and greatly increased drag. Instability can be determined by seeing the lack of a confined low-pressure zone behind the descent arrestor. This model suggested a less aggressive angle of attack needed to be used.
Twenty-Degree Arrestor Modeling[edit | edit source]
CFD pressure streamlines
CFD Pressure Vectors
CFD Pressure Map
CFD Fluid Velocity Isosurface
While team ACOM's design of an approximate thirty-degree angle of attack worked, it was desired to increase the terminal velocity of the TDRV to improve stability. As such, a twenty-degree model was simulated. The above images show the formation of a teardrop shaped low-pressure zone behind the descent arrestor, indicating a stable design. Additionally, the high-pressure region in front of the arrestor was reduced, further increasing stability. Based on this simulation, it was decided to begin testing a twenty degree design alongside thirty and zero degree designs to verify the ANSYS models.
Control System Development[edit | edit source]
The control system designed by team ACOM to track and control the TDRV used a Raspberry Pi single board computer (SBC) to log GPS data and interface with the Iridium 9523 NAL A3LA-RS module to report data. A backup tracking system with a stand alone APRS radio module and integrated GPS and battery would be attached to the balloon. While this design offered a surplus of computational power, there were several drawbacks to this system:
A conversation with NASA determined that a re-design was needed in order to facilitate better tracking and flight data logging of TDRV test flights and to include the Iridium 9523 at a later date once it was fully functional on the ground. The proposed system had the following requirements:
Based on these criteria, the above block diagram was created outlining the major components and functional blocks of the proposed controller. Rather than being controlled by a Raspberry Pi, the controller is centered around a Teensy 3.5 microcontroller as the TechEdSat group is experienced with its use. Additionally it offers the required computational power to process and store live data as it is a ARM Cortex-M4 microcontroller operating at 120MHz. The Teensy 3.5 board is also 5V and 3.3V I/O signal compatible and has a built-in micro SD card holder, satisfying the data storage requirement. A 7.4V LiPo battery was selected to replicate the battery system used in the TES satellites. To ease assembly and reduce design complexity, Sparkfun breakout boards were selected to meet the sensing requirements of the controller. The following sensors and devices were selected to satisfy the mission requirements:
A design block consisting of motor drivers and feedback mechanisms was also included in the block diagram to allow for the control of the servos and linear actuators required to deploy the TDRV and other drag devices. This portion of the design was never fully flushed-out as detailed in the 'Test Variant' section. The key idea behind this design as a whole was to allow for the eventual integration of the Iridium 9523 Carrier into the TDRV and to allow for additional sensors and actuators to be connected to the module as needed. As such, mating connectors to the 9523 Carrier board are specified, and all the sensors are able to share a single I2C bus. A serial bus allows data to be sent to the Iridium from the Teensy, emulating the TES satellite infrastructure.
Test Variant[edit | edit source]
Due to time constraints and TDRV delays, a test variant of the TDRV control system was designed and constructed, rather than the full system. The key differences between the test variant and original design are as follows:
A two-layer PCB was designed and professionally manufactured after initial breadboard development and testing. However, this PCB did not function and was replaced with simple milled PCB made at UI. The final control system was capable of sending sensor and GPS readings to a connected computer, but not standalone data logging. Further software development is required to enable data logging to the built-in micro SD card.
TDRV Construction[edit | edit source]
The new TDRV design was built using 4" diameter 1/4" wall aluminum stock tube, which was professionally milled down to an 1/8" wall thickness to reduce weight. The nosecone, end cap, and strut ring were then 3-D printed out of PLA. Multiple strut rings were printed to test each of the simulated angles of attack, and multiple replacement nosecones were also created. All pieces were friction-fit together and secured with an exterior band of electrical tape. The drag device was a piece of cut rip-stop nylon sewn to aluminum spars bolted to the plastic strut ring. The only payload was a personal GoPro camera which was used to record flight video and basic velocity and acceleration measurements. The GoPro was fit into the nosecone of the TDRV. No external tie-points were included to allow the connection of the TDRV to a launch vehicle.
TDRV Breakdown:
Testing[edit | edit source]
Two test sessions in the University of Idaho Kibbie Dome were conducted during the final weeks of the project to match the testing conducted by team ACOM. No other tests were conducted. During the tests, the TDRV was fitted with a GoPro camera and was hand-dropped from the maintenance catwalks in the Kibbie Dome. Not all components were replaced between tests, and the drop height was only approximated. From the GoPro data, velocity and acceleration graphs were produced from each drop trial. Prior to testing, the terminal velocity of the TDRV was estimated using basic area calculations in SolidWorks. Before the test, the terminal velocity for the twenty-degree descent arrestor was estimated to be 15 m/s. The final test velocity was measured to be 17.5 m/s, validating the SolidWorks model.
Zero AoA Trial
Ten-Degree AoA Trial 1
Ten-Degree AoA Trial 2
Twenty-Degree AoA Trial 1
Twenty-Degree AoA Trial 2
Future Work[edit | edit source]
The final design of the TDRV must be able to survive hypersonic reentry through Earth's atmosphere, which requires materials and techniques that simply exceed the ability and budget of the university, let alone a senior design team. The TDRV would need to be made of a shell thousandths of an inch thick from exotic alloys to reduce weight and improve heat conductance. The nose cone would need to be made of ablative heat-shielding materials, and the descent arrestor would be made of carbon fabrics with composite struts to survive the extreme heat of reenty. As such, the future role of this team's successors is to design and prove the aerodynamic model though constructing and testing low-cost test models using high-altitude balloons and high-speed wind tunnels to prove that an expensive flight-ready TDRV would be successful. These models will also allow for integration and testing of any control electronics, which unlike the TDRV itself could be fully designed and built by a senior design team, then integrated into a NASA-built TDRV.
To meet this goal, future teams will need to adapt the current TDRV design to accept a drop device to allow for high-altitude testing. Additionally, the control electronics must be completed with some sort of remote data transmission system in place to enable tracking and recovery. Due to the cost of an Iridium modem, it is recommended the 9523 Core not be flown until multiple tests are conducted with consistent data indicating a high probability of survival and recovery. To increase survival, a late-deployment parachute would need to be added to the TDRV. This parachute would consist of some type of deployment mechanism, controlled by the TDRV control electronics, ejecting a parachute from the rear of the TDRV after it has passed a set altitude. Future teams should collaborate with or consist in part of VAST team members to facilitate high-altitude balloon testing.
In short, the main focus of the 2019-2020 senior design team regarding the TDRV should be to complete the work started by team SCUBEE by designing a drop mechanism for the TDRV, and building and testing the originally designed control electronics. Once this is completed, a parachute can be added to the TDRV, and its physical design can begin to be optimized. Later teams can then work on repeatedly testing the TDRV using sounding rockets or balloons in collaboration with NASA and integrating the Core 9523 Iridium Modem.
Iridium 9523 Development[edit | edit source]
The primary goal of the SCUBEE electrical and software design group was to develop a carrier module for the Iridium 9523 Core satellite communications modem to allow for the core to be integrated into the existing standardized electronics payload used on each TechEdSat cube satellite. Such a carrier module would allow for a dramatic improvement in bandwidth by swapping the satellite from 340-byte short burst data (SBD) packets to a full 2.4 kbit/s data stream. However, the reason this has not been done already is the enormous leap in technical complexity the 9523 requires compared the currently used Iridium 9502 modem. As the Core 9523 can sustain a live internet connection, it requires much more power at various voltages compared to the 9502's single 5V input, in addition to a full 9-wire RS-232 interface to a microcontroller that must host a full TCP/IP stack. While prior teams had worked to develop hardware and software to achieve this goal, none had yet been fully successful at either creating a working carrier module or the code to run such a device. SCUBEE was the first team to fully develop a working carrier module in hardware, but was unable to complete and test a working software library to control the Core 9523.
Existing Design Analysis[edit | edit source]
According to team ACOM and Rocket's final reports, the existing breakout board successfully powered the 9523 core, but was unable to allow for communication with the module. A diagram of the breakout PCB's main components is shown to the left. While analyzing the board, several questionable features were found found that seemed to serve no purpose:
In the course of researching existing Iridium breakout and test assemblies, a schematic identical to that of team Rocket's was found, which included the superfluous components. The schematic was that of a professional Iridium breakout board, and was clearly not a complete schematic of the full breakout board, which is pictured below. It was determined that team Rocket's board was an incomplete attempted copy of this commercial breakout board, and as such lacked critical connections and components detailed in the 9523 data sheet that are required to allow communication between the Iridium and a connected device. However, they did successfully create a complete part file for the Iridium 9523, laying-out the complex board footprint of the Core 9523 perfectly for future use.
Team Rocket's PCB Schematic
Page one of dev kit schematic
Professional Iridium development board
Redesign[edit | edit source]
The redesign of the Core 9523 carrier began by discussing the requirements the module would need to conform to with the TechEdSat team. They desired a module that could be easily integrated into their existing electronics that would be fully compatible with the power and communication buses already in place. However, we knew ground-testing and software development would be greatly aided by focusing more on a development-board style carrier rather than a finalized satellite module. It was decided to combine these two high-level requirements to create the first draft of a block diagram detailing the overall function of the carrier module.
The initial plan was to power the module from the TES 5-volt power bus, and to integrate the module with the rest of the satellite via a serial communication protocol to be specified later. An on-board microcontroller would interface the 9523 to the satellite communication bus and handle power management and core configuration tasks. A boost converter would then provide the approximately 30 watts required by the Iridium RF transmitter. However, it was feared this single-supply design would tax the regulators on the TES satellite too greatly. After discussing this complication with TechEdSat, it was decided a direct feed from the satellites batteries could be used to provide an 8-volt supply to reduce the instantaneous current needed when transmitting. This led to the second and final revision of the block diagram.
Power System Design[edit | edit source]
The Iridium 9523 is unique among Iridium modules in that it requires two power inputs; one to supply the logic power, and one to supply the RF transmitter. As shown by the below chart from the Iridium user guide, the 9523 requires 30-watts of instantaneous power when transmitting. For standard consumer devices, this power is supplied by slowly charging a bank of capacitors built into the 9523 which then discharge when the 9523 transmits.
However, the capacitors on the 9523 are aluminum electrolytic capacitors, which have a tendency to fail when introduced to the freezing vacuum of space as they contain non-solid materials. To overcome this, it was decided the carrier board must be able to supply the full instantaneous power required by the Iridium should the built-in capacitors fail. The converter needed to be small and efficient and ideally not utilize a transformer to reduce RF noise generated by the converter. A standard boost topology was selected, and multiple driver ICs were simulated before it was decided to use the LT3959 as the driver IC for the boost converter. The simulation details are explained in the following subsection.
Additionally, the carrier needed the ability to isolate itself from the rest of the TES satellite should a fault occur, and to monitor its own power consumption. A pair of PMICs on the board enable and disable both power supplies to the Iridium and are able to monitor current flow in addition to protecting the 9523 from loss of ground, reverse polarity, and other supply failures. The entire board is enabled by enabling the 3.3V regulator, which in turn supplies power to the microcontroller, which then switches on the PMICs.
Simulation[edit | edit source]
LTSpice was used to simulate the various ICs possibly suited for use on the carrier board. After eliminating all but two driver ICs, the LT3959 was simulated extensively to determine component values and to ensure the boost converter would operate properly in all circumstances. The converter passed simulation testing when both capacitor de-rating and a depleted battery supply were simulated simultaneously.
Microcontroller Design[edit | edit source]
As the current TES satellite and TechEdSat team uses Arduino microntrollers, it was decided to use an Arduino-compatible MCU to increase the ease of use of the module. The Microchip SAMD21 was selected for its speed, memory, and processing power. The SAMD21 is a 32-bit, 48Mhz ARM Cortex-M0+ and is the same chip used by the Arduino Zero board. Programming is facilitated using a native USB port or the debugging header. Both boards produced by SCUBEE have been burned with the Sparkfun Electronics SAMD21 bootloaders, making them easily programmable via the Arduino IDE. As additional I/O pins were needed to control the Iridium, an I2C expansion IC is present on the board to increase the available I/O pins.
RF and Layout Considerations[edit | edit source]
Due to the RF nature of the Iridium and the possibility of noise interference between various components on the carrier module, several layout considerations were taken into account when designing the carrier PCBs:
Final Design[edit | edit source]
File:Iridium Carrier Schematic.pdf
File:Iridium 9523 Carrier User Guide.pdf
After selecting key components and functional requirements, a finalized detailed block diagram was created. From this diagram, a full circuit schematic was created in Autodesk EAGLE from which a PCB was generated. As this was considered to be more of a test bed for the 9523 rather than a flight module, the PCB is not the Cube-Sat PC-104 standard form factor. However, all the components used are rated for the conditions of LEO, and the connectors used match those used by the TES satellite. This was done to facilitate testing of the module on high-altitude weather balloons should it be desired. 3-D models of the assembled PCB were generated using EAGLE and Autodesk Fusion.
The PCBs are of a two-layer design made with standard 1oz copper with an immersion gold finish. The carrier is 150mm by 70mm and is mounted using #4 bolts centered 5mm from each corner. Each board is populated by 136 discrete components, all of which are rated for near-space conditions. The standard passive package size used is 0605. To facilitate testing and debugging, the board has 22 test points, 15 LEDs, and 6 configuration jumpers.
Support and Testing Boards[edit | edit source]
To facilitate testing of the carrier board, and to protect the Iridium 9523, two additional PCBs were designed and built.
9523 Simulator[edit | edit source]
To ensure the carrier board pinouts and power supplies were within the requirements of the Iridium Core, a 9523 simulator board was created. The board is designed to break out the primary connections between the 9523 and the carrier, and ensures the supply voltages and signal lines are in the correct place and of the correct voltage level. The simulator also allows for signals normally generated by the 9523 to be injected into the carrier to verify correct operation. In essence, the simulator's job is to prevent the accidental destruction of a Core 9523.
On the board are two push buttons which can be pressed to generate the GPS flag and boost enable signals. LEDs indicate the status of the power signals to the 9523, while a row of headers allow connection to each individual signal. A screw terminal allows an external 30-ohm 30W resistor to be attached to simulate the load of the 9523 while transmitting on the boost converter. The load is enabled via an on-board MOSFET, which can be fed a signal from a function generator to mimic power waveform of the 9523.
TES Bus USB adapter[edit | edit source]
File:TES Bus USB Adapter SCH.pdf
As the TES satellite would communicate with the carrier module via TTL Serial UART, an adapter was created to allow the carrier to be connected to a USB port and to be partially powered by a secondary USB port. The TES Bus USB Adapter does this by using an FTDI chip to convert the TTL serial signals from the carrier module to USB and acts as a USB serial port. A secondary USB connector powers the carrier module's 5V bus, allowing for full functionality except for transmission from the Core 9523. The adapter connects to the carrier via the TES bus port. On the adapter is a small switch which enables or disables the carrier. LEDs indicate the enable status of the carrier, and if the 9523 is transmitting. Additional LEDs indicate USB data activity and what aspects of the adapter are currently active. As this module is not connected to the microcontroller's programming or debug ports, it cannot be used for such purposes. It is purely designed to simulate and verify communication between the carrier module and the rest of the satellite. When connected to the TES bus connector, the connector must be set in 3.3V mode to prevent damage to the adapter.
Assembly[edit | edit source]
The boards were assembled by hand using soldering and hot-air techniques. ESD precautions such as ESD grounded mats, wrist-straps, and clothing were used in addition to ESD-safe tools. Assembly of each support board took approximately 4 hours, and each carrier board took approximately 8 hours to populate. Two of each board were assembled, with a spare PCB for each left un-populated. The boards were progressively built and tested to ensure proper functionality and to troubleshoot errors. Both support boards were built prior to the carrier to facilitate testing.
TES Bus Adapter Assembly
Iridium Simulator Assembly
Carrier Assembly
Testing[edit | edit source]
Due to time constraints and software hurdles, only preliminary functionality tests were preformed on the carrier module. This included testing the hardware components of the carrier, and basic software functionality to ensure serial communication and power management feedback performed as expected. From this testing, several bugs were found in the carrier PCB which are listed below. Any bugs that affected performance were fixed, with the fix being noted. Suggested modifications to future revisions are also listed.
Known PCB Design Errors
Recommended Improvements
Software Development[edit | edit source]
Software to control the 9523 was developed in two stages. The first stage was the development of a code library designed for PC use that would interface with an Iridium 9523 housed in a module created by NAL. Such a module was used by prior teams, who had created a basic cable to convert the module's RS-232 signal to USB. However, this adapter cable was extremely basic and was easily able to short out as it had no shielding. A new adapter was built, enabling PC software testing to take place. However, we were ultimately completely unsuccessful at ever using the 9523, being able to only initialize and configure the module. We were never able to transmit or receive data, and had great difficulty maintaining an Iridium signal. It was later determined we were sent a defective Iridium antenna by NASA, who had inadvertently sent us their reject. Weather also impacted testing, as testing could only take place outdoors, and the 2018-2019 winter was rather severe.
Software for the carrier module was started but never reached the testing phase. It is known that NASA's Reentry Breakup Recorder (REBR) device uses the 9523 module, but the team behind the REBR could never be reached for consultation. Other professional development teams were unable to help due to the proprietary nature of their devices. The current code library uses a simple command/response packet system and has four modes of operation. In 'OFF' mode, the modem is disabled and cannot communicate. In 'RAW' mode, packets are sent directly to the modem to facilitate direct testing. No data conversion takes place, and data must be formatted manually as per the Iridium development guide. In 'SBD' mode, the 9523 operates in SBD mode and transmits small data packets. Incoming data is parsed into packets and sent to the 9523 for transmission. Finally, 'TCP' mode enables a streaming data connection via TCP/IP. All data packets are converted and sent to the 9523 for transmission. The PC version of the library is designed to facilitate debugging and hardware development, and to interface with the NAL module. The microcontroller version is designed to take as little memory as possible at the expense of debugging and features.
Future Work[edit | edit source]
The primary goal of future teams should be to develop the software required to operate the existing carrier module, and, if successful, re-design the carrier to fit the PC104 form factor used by the TES satellites. Ideally only small modifications will need to be made to the existing schematic, which can then be used to generate the new PCB. To be compatible with future upgrades to the TES satellite, the flight module should be completely stand-alone and require only one power input of 7.5-12VDC in addition to the existing communication lines. RS-422, CAN, or other differential signal should be used in place of serial. Additional care will need to be taken to ensure all components are flight-certified, and flight-proven components are used when feasible. A stretch goal would be to design the flight module for automated assembly, which could be carried out by NASA.
Team Members[edit | edit source]
Left to Right:
Hunter Barnett
Major: Computer Science
Biography: Hunter Barnett is a computer science student from southern California. His interests include writing software for embedded devices and retro consoles.
Avery Brock
Major: Electrical Engineering
Biography: Avery Brock is an electrical engineering student from the Seattle area. When not busy with classes he enjoys developing his own projects ranging from Jacob's ladders to IoT devices. His primary interests are aerospace and robotics and hopes to pursue those topics for his master's degree.
Yi Yang
Major: Electrical Engineering
Biography: Yi Yang is an electrical engineering student. She is from China.
Hunter Kanniainen
Major: Mechanical Engineering
Biography: Coming from Vancouver, Washington, Hunter Kanniainen is a mechanical engineering student with a strong focus on design and analysis. Hunter has designed robotic components for Dr. Joel Perry’s BLUE SABINO project as well as completing an internship at NASA’s Ames Research Center. At NASA, Hunter designed test components for small satellites and used FEA analysis to determine their effectiveness in application. Hunter is returning to NASA to work full time after graduation in 2019.
Tim White
Major: Mechanical Engineering
Biography: Tim is a mechanical engineering student at the University of Idaho and has a passion for prototyping, problem solving and intersecting business and engineering products. He plans on getting his MBA after his undergraduate program.
Presentations[edit | edit source]
Presentations: