project elsa: europa lander for science acquisitionproject elsa (europa lander for science...

Project ELSA: Europa Lander for Science Acquisition

Darren Combs, Gabe Frank, Sara Grandone, Colton Hall, Daniel JohnsonTrevor Luke, Scott Mende, Daniel Nowicki, Ben Stringer

University of Colorado, Boulder, CO, United States of America

Jupiter’s moon Europa is of great interest to the scientific community as evidence suggests theremay be a deep liquid water ocean beneath its icy surface. To investigate the surface and subsur-face, future missions to Europa will require the use of landers and/or surface probes to measuresurface characteristics and investigate the potentially unique subsurface conditions beneath the ice.Ball Aerospace has begun to explore the feasibility of conducting an exploration with several small,relatively inexpensive probes as an alternative to a large and costly lander. Our team of nine un-dergraduate students has designed and constructed a compact, low-cost, spherical probe, which cancollect, store, and transmit scientific data relevant to the study of Europa. The goal of our projectwas to develop and construct a TRL 4 prototype over the course of 8 months, while keeping the costunder $5000. The development focused on data collection, FPGA software development, and systemintegration while neglecting environmental elements, such as temperature, radiation, and shocks.Two relevant scientific instruments, a triaxial magnetometer and a Geiger counter, were selected andintegrated with an avionics package, which is centered on FPGA-based command and data handling(C&DH). The FPGA is integrated with a transceiver to communicate over RF to a ground station,simulating a Europa orbiter. In order to provide the capability to observe magnetic field and radia-tion variations during one complete orbit of Europa about Jupiter (85 Earth hours), an independentpower system was developed and integrated to sustain the probe through its entire mission of 100hours. The power system, avionics package, science instruments, and transceiver are mounted toa custom-designed structure, contained within a 25.4 centimeter diameter sphere. The prototypecollects data for a total of 100 hours, and transmits that data in 8 minute simulated passes, demon-strating the feasibility of using small, cost effective probes to explore the surface of Europa or otherplanetary bodies.

NomenclatureFPGA = Field Programmable Gate Arraybps = bits per secondTRL = Technology Readiness LevelC&DH = Command and Data HandlingUHF = Ultra High FrequencyBASiX = Binary Asteroid in-Situ ExplorerSTK = Systems Tool KitCPM = Counts Per MinuteASCII = American Standard Code for Information InterchangeSRAM = Static Random Access MemoryRAM = Random Access MemorySPI = Serial Peripheral InterfaceCR = Current/(5.2×# batteries) (unitless)

I. IntroductionEuropa, one of Jupiter’s four Galilean moons, is believed to have a sizable ocean up to 100 km below its icy

surface[1]. NASA has identified Europa as a high priority target in the search for life within our solar system, becauseof this potential ocean. Spacecraft that have already been sent through the Jovian system have revealed that Europa hasone of the smoothest surfaces in the Solar System and has few impact craters which indicates a young and geologicallyactive surface[2]. Photographs of Europa show many large streaks along its surface called lineae. These lineae aresuspected to be the result of tidal flexing on Europa’s surface as it orbits Jupiter[3]. In 2013 the Hubble Space Telescopespotted significant plumes of water spouting from the surface, which further suggests that bodies of water exist under

1 of 11

American Institute of Aeronautics and Astronautics

the ice. If an ocean does indeed exist, it would be one of the most hospitable places in our Solar System for simpleextraterrestrial life. Project ELSA (Europa Lander for Science Acquisition) will provide a stepping stone for futuremissions exploring Europa by demonstrating the feasibility of collecting relevant data from the surface of Europawithin a relatively low cost, low mass, and low volume spherical landing probe, called the NeoPod.

Figure 1. Image from orbitaround Europa

The concept of deploying these small, low cost probes to investigate thesurface of an astronomical body is rooted in other missions that have been inves-tigated by Ball Aerospace. Previous projects done in conjunction with studentsfrom the University of Colorado investigated similar spherical probe systems todeploy to the surface of an asteroid. The student-led TIRESIAS (2013-2014)project developed a fully integrated pod as a building block for the Binary As-teroid in-Situ Explorer (BASiX) mission[4]. The concept for the BASiX missionwas to deploy multiple pods to the surface of an asteroid from an orbiter. Onceon the surface, one probe carrying an explosive payload would be detonatedwhile other probes measured the vibrational effect. TIRESIAS demonstratedthat vibrational data could be collected and transmitted through their commu-nications system with a standalone pod. Ball Aerospace hopes to extend thisconcept to the study of Europa by providing an alternative to a large and expensive lander often conceived for aEuropa mission.

Figure 2. NeoPod Design Assem-bly (one hemisphere removed)

Because of their similarities, a few basic aspects of the TIRESIAS projectwere re-purposed and integrated into the NeoPod design. The NeoPod has thesame outer structure consisting of the aluminum sphere outer casing. The pre-viously developed patch antennas will also be reused in the NeoPod design.However, a significant portion of the project is new and had to be updated orredesigned to fit the Europa specific requirements or to improve flight readiness.Most significant is the payload package, which had to utilize sensors, that ifflight-grade, would be capable of collecting meaningful science from the sur-face of Europa. In the TIRESIAS project, avionics were handled using a simpleArduino micro-controller.

For this iteration, Ball Aerospace requested the use of a flight-ready avion-ics board with a Field Programmable Gate Array (FPGA). The communicationssystem architecture was improved by using a transceiver chip instead of a sep-arate transmitter and receiver package. The power system had to be overhauledto accommodate the longer mission lifetime requirements of 100 hours. Andfinally, a new internal mounting structure was developed to support the components. With the completion of thisproject, science data will be collected, processed, and transmitted from the probe, which is a critical step forward toeventually sending scientific probes to Europa.

II. Design ObjectivesThis project was driven by three key functional requirements, i) to maximize collection of scientific data relevant to

Europa, ii) to have the capability to remotely transmit the data and iii) to fit within specific mission constraints providedby the customer, such as strict weight and volume requirements. The first functional requirement comes from the needto demonstrate that high value science can be done from this kind of platform. While this probe was constructed in alab environment, future iterations will benefit from the feasibility it demonstrates by collecting scientific data similarto what would be collected on the surface of Europa. The second functional requirement comes from the need totransmit the data once it has been collected. Since the probes will not be physically collected at the end of mission,it is crucial that the NeoPod be able to communicate wirelessly to a simulated orbiter. The overall mission includes aspacecraft orbiting Europa, which is used to collect data from the NeoPod and later transmit back to Earth. As it takesEuropa 85 hours to rotate about Jupiter, the mission was designed to survive a full 100 hours. To determine how muchdata could be collected and sent from the probe from the surface of Europa during this mission, a software simulationof the Europa orbiter was created in Systems Tool Kit (STK). The mission parameters for the Europa orbiter wereprovided by JPL (95° inclination, 126 minute period, 0 eccentricity, 12° mask angle on probe). Since the orbiter isin a nearly polar orbit, different longitude locations were simulated for the NeoPod probe to rest on the surface whichinfluenced total contact time with the orbiter over 100 hours. Below is a table illustrating the simulated total amountof data that can be transmitted from each latitude of Europa.

2 of 11


Transmitted Mission Data at Different Latitudes Over 100 Hour PeriodLatitudeLocation

(deg South)

Total PassTime (s)

Transmit Rate(kbps)

MaximumData (MB)

Maximum Transmittable Data Including25% Margin (MB)

0 2198 128 40 3020 2094 128 38 2945 3010 128 55 4160 4146 128 76 5775 10149 128 186 13990 21942 128 401 301

Table 1. STK Scenario Data Return

Since the total amount of data return is maximized when the probe is placed at the poles of Europa, the teamchose to use this scenario as a design driver. Placing the NeoPod at the poles also functions as a worst case scenariofor the power subsystem as the avionics and communications subsystems will perform more computations and tasksover the mission lifetime. The team took these restrictions into mind when designing the communications timelinefor the mission by including a realistic, limited window in which it is possible to transmit data. The final two keyderived requirements, which flowed from the use of the orbiter, were that the NeoPod shall have a maximum datarate of 128 kbps and that upon command, the NeoPod will begin sending stored data. The team has designed a smallEarth-based ground station to simulate this orbiter, which will be used for all testing. The final functional requirementwas that the NeoPod needed to fit within existing mission architecture previously designed by Ball Aerospace. Theseinclude having a total mass of less than 10 kg, and the ability to completely enclose the entire system within a 25cm diameter sphere. They also include the use and integration of a Ball Aerospace-designed field programmable gatearray (FPGA) in the system to regulate sensor input, store received data, and handle commands and integration with thecommunications system. The communications system in turn must include a Ball Aerospace-provided patch antennawhich lays flush with the exterior of the spherical probe.

The highest levels of success map directly to these key functional and derived requirements. The top level successfor payload was to have two distinct sensors that generate data sent to the avionics board for storage and transmission.For the avionics to be successful, it must be able to handle and store data from sensors. It must also be able to begintransmission of data upon command reception from the ground station for a total of 8 minutes. The communicationssystem, which includes the ground station, must be able to receive commands over RF as well as transmit data in apacketized form at a maximum of 128 kbps. The ground station must be able to receive this data and then store itin such a way that it can be accessed post-mission. The power system must supply 3.3 V and 5 V lines to the entiresystem for the entire 100 hour mission and must be contained within the small, spherical probe. Finally the structureitself must be designed to integrate all NeoPod components and must not exceed 10 kg and a 25 cm diameter. As anoverall system, the top level of success was to demonstrate the full 100 hour mission with a fully integrated sphere ina lab environment.

The most critical project elements (CPEs) to achieve these levels of success were the avionics hardware integra-tion and FPGA software development; two-way communication between NeoPod and ground station while sendingmultiple data types; designing a lightweight, small power system that can supply power for 100 hours; and integratingthe entire system into a 25 centimeter diameter spherical shell. The first CPE, related to FPGA hardware and softwaredevelopment, was the biggest challenge for the project, as none of the team had FPGA experience before beginning theproject, and thus had to learn how to code an FPGA, as well as develop software needed for the project in an incrediblylimited schedule with little margin. The communication system was difficult, because the team did not have significantexperience in RF, and had to develop a ground station before any communications testing could be accomplished. Thepower system was difficult due to the limited space in the sphere itself, and a custom printed circuit board (PCB) aswell as circuit design had to be developed in order to provide adequate power for the 100 hour mission. The team wasalso concerned about fully integrating into the sphere, as the mass and volume requirements were very strict, and forfull system success, the NeoPod had to operate as a closed-sphere contained system.

III. Design MethodologyA. Payload

A trade study was conducted early in the project to identify relevant and realistic sensors for the payload package.While the sensors were not required to be flight grade components, it was important for the fidelity of the data collec-

3 of 11


tion, storage, and transmission path that the sensors collect data relevant to the study of Europa. Research showed thatthere were several categories of science exploration worth investigating from the surface: Ice Shell and Ocean Charac-terization, Surface Environment and Composition Characterization, and Surface Geology [5]. Within these categorieswere anywhere between 1 and 6 different sensor options. A trade study was used to decide upon a sensor that wouldbest fit the needs of mission. Each sensor type was evaluated on its science value, cost , availability, complexity, size,and mass. Extra weight was given to complexity, because the project focus was on the data path and not on the datafrom the sensor itself, and size, which was important in fitting within the small structure.

The full trade study resulted in the selection of a magnetometer and Geiger counter as the sensors of choice forthis mission. Each had their own advantages that led to the decision to use them, but one of the major factors for bothsensors was their availability from a local electronics supplier, Sparkfun. The magnetometer was chosen because in areal Europa mission, observations of the change in the magnetic field during a full orbit would either confirm or rejectthe hypothesis of a large ocean beneath the surface. If it exists, the ocean would generate a specific magnetic signatureas Europa moves through Jupiters orbit that would not be there otherwise. The magnetometer was also one of thesmallest sensors investigated and uses a simple I2C interface for the integration with the Avionics Board.

Sensor Sensitivity Range ResolutionMagnetometer 1370 LSb/Gauss ±8 Gauss 0.73 mG/LSbGeiger Counter 18 cps/mR/hr 100 cpm 1 cpm

Table 2. Sensor Specifications

a) Sparkfun Triaxial Magnetometer. This inexpen-sive magnetometer uses an I2C interface when con-nected with the Avionics System. It is capable ofrecording 3 axis magnetic field values at .75 - 75 HZ

b) Sparkfun Geiger Counter. The Geiger counter candetect alpha, beta, and gamma radiation. It registersa single count every time one of the particles interactswith the Geiger tube the counter will output a singlebit high voltage, which is read by the Avionics System

Figure 3. Scientific Instruments Chosen as the Payload

First, the magnetometer was selected for its large relevance to the dynamic magnetic field on Europa. Thesechanges come from a variety of factors such as Europa’s movement through Jupiter’s Van Allen Belts and inducedfields caused by the conductivity of Europa’s interior. By taking measurements of this variable magnetic field environ-ment, researchers would be able to more accurately characterize Europa’s interior, which has long been suspected ofcontaining a large ocean. Magnetic field fluctuations from this induction are expected to be around 2.5 mG, which, fora table-top version of the mission could be detected by the 0.73 mG/LSb resolution of the selected sensor[6]. However,in reality, a different sensor would be selected to survive space environmental conditions.

The Geiger counter was chosen because of the value of having radiation measurements from the surface. Theradiation environment on the surface will be intense and poses a hazard for future manned or unmanned explorationmissions. This environment consists of largely electron radiation, also known as Beta particles, which the selectedGeiger counter is able to detect. Having radiation measurements on the surface would improve knowledge of con-ditions there, making the success of future missions more likely. The specific Geiger counter that was chosen cameready for connection and has a simple interface. Anytime the Geiger counter is hit by a radioactive particle the sensoroutputs a single bit that can be read by the Avionics Board. The data can be collected and put out in counts per minute(CPM).

4 of 11


Two other sensors, temperature and pressure sensors, also scored well in the trade study but were ultimately ruledout. They would have been easier to integrate into the payload, but would have provided significantly less scientificvalue than the magnetometer and Geiger counter.

B. AvionicsThe avionics subsystem serves as the connective glue between each of the subsystems. It provides processing and

data storage for the sensor packages. Additionally, it responds to commands and initiates data transmission periods.Because of the desire to further the technology readiness of the mission concept, an FPGA driven avionics boardwas provided by Ball Aerospace. During design, the Ball avionics board was a long lead item. In order to reducethis risk, an FPGA development board with the same family of FPGA was procured (donated by Microsemi). Thisboard served as a learning aid in the development phase, as well as a contingency plan in the event the Ball board wasdefective or behind schedule. Because FPGA programming was new to the ELSA team, this became a critical projectelement. Designing for an FPGA is drastically different than designing software for a microcontroller. An FPGA is amethod of describing logic hardware, where everything executes in parallel rather than sequentially as is the case withmicroprocessors. With this difference in mind, there are three main tasks that the avionics system must accomplish.First, data must be collected from the sensor packages and processed into a data format. Second, the data must bewritten to and read from memory. Third, data must be passed to and from the communication system. All FPGAsoftware was written Verilog HDL. A high level flowchart of the software design is shown below in Figure 4.

Figure 4. High level flowchart of Verilog software modules contained in FPGA design. Data from the instru-ments is packaged into a uniquely identifiable 10 byte data point in the sample control modules. The datapoints are passed to the memory controller to be saved in SRAM. The SPI interface and mode control modulesconfigure the transceiver to the correct state, as well as respond to commands. Upon receiving the transmitcommand, data is read from memory and sent to the transceiver.

While all of the software functions are executed in parallel, it is most natural to follow the path of data as it comesinto the system. The Geiger counter outputs one logic line that would go high when a radiation event was detected.The FPGA simply monitors this line to count the number of radiation events. Every minute the number of counts isoutput to be stored in memory. The magnetometer outputs 3 vectors of twos complement data. For both the Geigercounter and magnetometer, a 10-byte data packet is formed for each unique data point. Each point consists of an 8-bitASCII identifier (’G’ for Geiger, ’M’ for Magnetometer), a 24-bit timestamp, and 48 bits of data. A 24-bit timestampwas chosen as opposed to a standard 32-bit timestamp to reduce the total amount of data transmission. A timestampresolution of 10 Hz was sufficient and would be encapsulated by 24 bits over the 100-hour mission timeline.

In order to save data for later transmission, an SRAM interface was developed. Additionally, a memory controllerwas developed to handle the scheduling of simultaneous read and write requests, as well as to keep track of read andwrite addresses. The use of SRAM allowed for small read and write times that would not limit the data rate of thecommunications system. However, due to the volatile nature of RAM, the system is required to remain powered at alltimes.

5 of 11


The avionics system also controls the transceiver over an SPI interface. Upon power up, the FPGA configuresthe transceiver to the proper communications protocol and puts it into a continuous receive state. Upon receiving anASCII ’T’ from the ground station, an 8 minute pass timer begins. The transceiver is put into transmit mode whiledata is read from memory and sent to the transceiver. When the 8 minute timer expires, the transceiver is sent backinto continuous receive mode. This cycle repeats throughout the entire mission lifetime, and is simultaneous to thedata processing and storage modules.

C. Communications and Ground StationThe communication system serves to initiate and complete the data transmission cycle, effectively wrapping around

the entire mission concept. The communication system operates wirelessly via RF and is split into two separate sub-systems: Ground Station & NeoPod. The Ground Station acts as an analog to an orbiting satellite and does not haveany weight or volume restrictions. In order to fit within the mission architecture the Ground Station must receive andsave data as well as transmit commands via RF to the NeoPod. Due to the unique spherical shape of the Neopod, itrequires a non-traditional antenna that can function in many orientations. Ball Aerospace provided the shell structurewith a low-profile patch antenna mounted to it, and the antenna had been tested and proven to work in two separatebands with center frequencies of 437.5 and 401.5 MHz. Along with having frequency restrictions, the NeoPod portionof the communication system is required to operate on very little power in order to reduce the strain on the powersystem requirement to operate for 100 hours. The Texas Instruments CC1101 transceiver was identified as a capableelement to include in the design because its power draw is on the order of milliamps and has heritage with Universityof Colorado Aerospace Engineering Sciences department faculty. The CC1101 is configurable and has the ability tochange its center frequency in increments of slightly more than 400 Hz allowing it to be set near the center frequencyof 437.5 MHz. Within the mission architecture the transceiver is responsible for packetizing and wirelessly transmit-ting data from the NeoPod to the Ground Station. Inside the NeoPod, the CC1101 is commanded, configured and sentdata by the Avionics system via the SPI interface. On start up the internal registers of the transceiver are configuredto the correct center frequency, channel width, data rate, and packet structure. The Ground Station transceiver usesa program called SmartRF Studio to configure the correct registers on the CC1101. SmartRF Studio has Perl script-ing functionality that interfaces with all SmartRF Studio commands. Test scripts were written in order to automatecommand and data reception periods. In the test scripts that simulate a normal satellite pass, the Ground Station firstswitches from an idle state to transmit mode then transmits an ASCII ”T” to the NeoPod, signaling that the NeoPodneeds to switch to transmit mode. The Ground Station switches to ’receive’ mode and the NeoPod begins transmittingits stored data at 100 kbps in 50 byte packets. Once data has been received from the Ground Station, the data packetsare passed to another software developed by Ball Aerospace called COSMOS. The data is routed from the Perl scriptdirectly to COSMOS via TCP/IP connection. The COSMOS software allows for easy packet decomposition and realtime data display which is the motivation behind using the program. COSMOS looks for ”G” or ”M” headers in thedata packets to identify unique data points based on the data point structure discussed above. Once a 50 byte packetis parsed, COSMOS stores and plots the data in real time. After data has been sent for 8 minutes, the avionics systemswitches back to receive mode and awaits another command from the Ground Station which will be sent at the start ofthe next pass. The process repeats until all passes are completed.

D. PowerOne of the requirements of the system is that the NeoPod must be able to record data for one orbital period of

Europa around Jupiter. Based on this, it was determined that the mission timeline would be 100 hours. This wouldprovide enough time to record all of the necessary data and transmit it up to the orbiter. First it was determined whatpower source should be used. Many spacecraft and rovers use solar panels to collect and store energy; however, sinceJupiter 5.2 AU from the sun, the solar power available is less than 4% that at the Earth or just over 50 Watts per squaremeter, not enough for solar panels to be a viable option. Another possible option was a radioisotope thermoelectricgenerator such as those used by deep space vehicles such as those in the Voyager program. However, these systemsare too heavy and take up too much space to fit within the mission parameters of a small probe. Additionally, theradioactive fuel needed to power these systems is extremely dangerous, expensive, and difficult to obtain. For thesereasons, it was decided to use batteries as the power source for the project.

Since volume and mass are limited in the design, it was important that the batteries be as efficient as possible. Itwas decided that lithium polymer (Lipo), 11.1 V batteries with a capacity of 5.2 Amp-hours (Ah) were the best choicebecause they are rechargeable, efficient, and relatively easy to obtain. There is an increased level of risk in using Lipobatteries, as they can be unstable and dangerous if they are not treated with care. In order to mitigate these risks, stepswere taken to characterize the behavior of these batteries in order to create accurate models. For example, the voltage

6 of 11


output by Lipo batteries gradually decreases over time, before dropping off sharply at the end of the batteries’ lifespan.If the battery voltage drops below 9 V, the potential for critical failure increases greatly. In order to avoid this, a marginwas applied that ensured the battery voltage does not fall below 10.5 V. Based off these models, it was found that thisoccurs at about 85% of the battery capacity so we used this as our working capacity moving forward.

In order to determine the number of batteries needed, a power budget was developed for the entire 100-hourmission. Each system was assumed to operate at maximum power for the duration of the mission. Margin was appliedin addition to this. It was determined that 15 batteries would be needed to ensure that all systems would be powered.All of these batteries are connected in parallel to form a single power source. This ensures that no system will runout of power before the others. The voltage from the batteries is conditioned using a series of switching DC voltageconverters to efficiently, at 90%, step the voltage down to 5 V and 3.3 V sources. These regulators are designed tooutput constant voltage with low ripple effects through a range of input voltages. Additionally, a low voltage cutoffswitch is used to protect the batteries from dipping below 9.5V. Together, the power system is capable of providingappropriate voltage and current values to all other systems for the duration of the mission.

E. StructureThe NeoPod structure is used to house all components in a single assembly to increase the flight readiness of the

system. In order to determine how the physical structure would need to be designed, the requirements surroundingthe physical integration needed to be examined. These requirements specify that the entire system must be containedwithin a sphere with a diameter of 25 cm or less and have a mass less than 10 kg in order to fit within the missionparameters (physical size and mass restrictions of orbiter). Due to the timeline of this project, the structural design didnot have any requirements to fulfill regarding load testing or modeling surviving an impact on Europa.

In order to fit all circuit boards, science instruments and batteries into the NeoPod, the team designed a simpleinternal structure to house all of these components within the sphere. The design consists of two circular shelveswith four clips on each shelf, mounted parallel to one another within the sphere. This design allows for all subsystemcircuit boards and science payloads to be mounted to exterior of the plates while leaving a substantial amount of roombetween the plates for batteries. The circular plates also include cut outs in order to distribute wires throughout thesystem Figure 5a is a visual of the internal structure.

The team was also given two halves of an existing external shell from the TIRESIAS project (25.4 cm externaldiameter) which was used in the structural design. Another consideration for the internal structure was the necessityfor housing the Lipo batteries contained in the center of the NeoPod. To reduce weight and manufacturing time, a 3Dprinted structure enclosed on all sides was created to meet this need. The 3D printed structure screws into both the topand bottom plates, making the shelves and the battery case one integrated unit. All subsystems and components weremodeled in SolidWorks to verify that this system would fit within a sphere of this size. Figure 5b is a representation ofthe NeoPod with one side of the sphere hidden showing how all components and internal structure physically integratetogether.

a) NeoPod Internal Structure b) NeoPod Assembly, one side of thesphere is hidden to allow a view of theinternal assembly

Figure 5. NeoPod Structural Assembly

Another function of the physical structure was to dissipate heat generated by the entire system. In order to de-termine the extent of the thermal dissipation needed, a worst case thermal model was developed in which all power

7 of 11


supplied to a component was treated as heat output. In Solidworks, a transient thermal simulation was run to steadystate which provided an initial estimate of temperatures predicted throughout the mission lifetime. Temperatures of thebatteries and temperatures on most subsystem circuit boards were monitored over time and it was discovered that allcomponents stayed under their maximum operating temperatures even at steady state. Figure 6 is a graph that showsthe SolidWorks Simulation results. The margin represented by the green portion of the bars, is the difference betweenthe modeled temperature and the maximum temperature provided by the component specification sheets.

Figure 6. Thermal Modeling Results. The height of the bar signifies the maximum operating temperature foreach subsystem while blue signifies the modeled temperature

As better estimates of current draw and power consumption are known, the thermal model will be updated toreflect these changes. Currently, the FPGA is modeled to be using all logic gates and running at full power which isnot realistic. Better software and hardware estimates should further reduce the steady state temperatures predicted inthis model.

IV. Design Testing and ResultA. System Design

Figure 7. NeoPod System Functional Block Diagram. The system consists of four key subsystems, payload,avionics, communications, and a power distribution system. There is also an manufactured internal structure,mounted to an external shell provided by Ball Aerospace. The Ground Station is separate from the system, andwill be used for testing in a lab environment.

Figure 7 is a functional block diagram representative of the entire NeoPod system. As seen the NeoPod is brokeninto four key subsystems: payload, avionics, communications, and a power system, each of which are contained

8 of 11


within the ball. The payload sensors are mounted on team designed printed circuit boards, which also contains a step-down voltage converter for the Geiger counter for integration with the avionics system. The avionics system consistsof an FPGA mounted on a board, which was provided by Microsemi and uses SRAM as its storage method. Theteam developed all software needed for the board to function correctly. The communications subsystem consists of aCC1101 transceiver chip, purchased from Texas Instruments, and a curved patch antenna, mounted to the exterior ofthe sphere, both provided by Ball Aerospace. The communications system handles the majority of the packetizationfor the data. The avionics and communications subsystem are integrated using an SPI interface. The system is poweredusing fifteen lithium-ion batteries connected in parallel at 11 volts. A team designed power distribution board allowsfor all components in the system to be powered at either 3.3 or 5 volts. These subsystems are mounted to two circularshelves, which use brackets to mount to the external sphere. The batteries are located in a 3-D printed battery case,which is mounted between the two shelves. The 25 centimeter external shell is then closed, and all subsystems arecontained. The ground station consists of a second CC1101 transceiver chip, as well as the included development kit,both provided by Texas Instruments. This is connected over USB to a laptop computer, which uses COSMOS, a dataprocessing software, to send commands and save data.

B. System Testing and Expected ResultsThe NeoPod design is currently being tested for functionality and performance. The testing process consists of 3

testing stages:1) Individual subsystem testing2) Avionics subsystem testing3) System integration testing

The first stage is individual subsystem testing. The individual subsystem tests consists of binary component tests and acommunication RF link test. These tests have been successfully completed. The purpose of the binary component testswas to verify that purchased components, such as the Geiger counter and magnetometer, function as specified, andfor the team to gain experience in their operation. The purpose of the communication RF link test was to evaluate thesignal strength and packet error rate when transmitting data packets over varying distances. This test was performedin a lab environment, using combinations of additional attenuations to simulate distance. Over the course of the test,ten differing attenuations representing distance were tested, with three trials of 1000 packets sent at each attenuation.The results of the RF link test, shown in Figure 8b, shown that while the curve of the test results matched the modelquite well. However, there was a 10 dB offset consistently over the course of the test. The team believes the reason forthis to be the environment of the lab, and unknown constant degradation of the signal during the test. In the operatingzone of 0 to 3.8 meters, there were 3 packet errors out of 21000 10-bit packets sent. This equates to a 0.0001 percentpacket error rate within the operating test environment. Once outside this environment the packet error rate jumped upto almost 100 percent loss.

a) Link Budget Test Results b) Packet Error Rate Test Results

Figure 8. Results from RF Link Test, compared to model and shown with measured packet error rate. The firstgraph shows received signal strength over distance, simulated by increasing attenuation. During the test it wasdiscovered that the operating zone in the lab environment was 0 to 3.8 meters, resulting in a 0.0001 % PER.

9 of 11


The second stage is avionics integration testing. The avionics integration tests consist of binary tests wherein thepower board, payload sensors, and communications subsystem are each individually tested in conjunction with theavionics board to make sure that the avionics system interfaces correctly with the other subsystems. At the time ofwriting, the NeoPod is undergoing this stage of testing.

An example of one of these tests is the integration of the Geiger counter with the avionics subsystem. The singledigital line between the two systems was connected and both were powered to desired voltages. The number ofradiation counts outputted from the avionics system was compared to the number of counts seen on the Geiger counter,which were observed by an on-board LED, and confirmed to match. Furthermore, the overhead identifier byte (ASCII’G’), and time-stamp bytes were present as expected.

Once the avionics integration tests are complete, the NeoPod will enter the third testing stage, system integrationtesting. The system integration tests consist of two flat-sat tests and a fully integrated test. The first flat-sat test will bea two-hour binary test of all subsystems minus the structure and batteries; a power supply will be used in place of thebatteries. The purpose of this test is to verify that all subsystems work together to produce a complete data path fromthe payload sensors to the ground station.

The second flat-sat test will be a 6-hour test that incorporates the batteries. The purpose of this test is to evaluatebattery performance and to increase confidence that the batteries will sustain the system for at least a 100 hour missionlifetime. Battery voltage and current readings will be logged throughout the test at 5 minute intervals and 1 secondintervals respectively. The current measurements will be used to confirm the 0.6 Amp estimate that was used todevelop the battery discharge model, and the voltage measurements will be compared against the power model (shownin Figure 9) to evaluate initial battery performance.

Figure 9. Voltage curves for the one and two battery discharge tests (parallel battery test), as well as the pre-dicted discharge curve for the final test. The one and two battery discharge curves were obtained by dischargingthe batteries at 0.38CR 0.19CR respectively. The discharge curves were then expanded horizontally accordingto our expected current draw and battery capacity for the final test. The model discharge curve for the finaltest, which is expected to have a current discharge at 0.0077CR, was obtained by: 1) analyzing change in Volt-age vs. change in CR for our batteries and for other well characterized Lipo batteries, 2) determining the ratioof voltage change of our batteries compared to the well characterized batteries, 3) extrapolating the ratio ofexpected voltage change from .19CR to .0077CR, and 4) applying the ratio of voltage change to the parallelbattery discharge profile.

Following the flat-sat test with batteries, the full NeoPod system will be integrated. The purpose of the fullintegration test is to validate the power requirement that the system will function for a 100 hour mission lifetime andto validate structure requirements that the NeoPod will weigh less than 10 kg and be contained within a 25 cm diametersphere. The final battery voltage is expected to be 11.35 +/- .2 Volts (see Figure 9). At the completion of this test, allrequirements will have been verified and the project will be completed. This test is expected to run for a total of 100hours, and incorporates 47 simulated communications passes over the course of the test, one every 120 minutes.

10 of 11


V. ConclusionUpon successful completion of the testing plan, the ELSA team will have shown that the NeoPod is capable of

collecting, storing, and transmitting data for the entirety of the 100-hour mission. These were the key objectives thatneeded to be demonstrated by the completed system. Important to this is the verification of the communication andbattery life models and validation of all the requirements. As seen above, the communications test results are quiteclose to the model, other than a slight offset, and demonstrate that data can be sent with a minimal packet error rate of0.0001 percent. The power model, once tested over 100 hours, will show the capability of keeping a system this smallpowered without any recharge for a full 100 hours. If these probes are to collect data on the surface of Europa theymust be able to operate for that long. The fully integrated system test will show how closely the design matched thesemodels to fulfill requirements.

It is by meeting or exceeding these objectives that the overall concept of sending small and inexpensive probes toEuropa is further validated and future teams can build on the progress to improve the system and advance its maturityand viability for a real Europa mission. This can potentially present a unique and novel alternative to the large landersin use today.

References[1] ”Europa: Facts About Jupiter’s Icy Moon and Its Ocean.” Weblog post. Ed. Space.com. N.p., 9 Feb. 2015. Web.

12 Sept. 2015. <http://www.space.com/15498-europa-sdcmp.html.>.

[2] Greenberg, Richard J., Europa–the Ocean Moon: Search for an Alien Biosphere. Berlin: Springer, 2005. Print.

[3] Pappalardo, Robert T., William B. McKinnon, and K. Khurana, Europa. Tucson: U of Arizona, 2009. Print.

[4] Anderson, Robert C., Daniel Scheeres, and Steven Chesley. ”Binary Asteroid In-situ Explorer Mission (BASiX): AMission Concept to Explore a Binary Near Earth Asteroid System.” 45th Lunar and Planetary Science Conference(2014): n. pag. Web, 01 Sept 2015.

[5] ”NASA’s Europa Mission Begins with Selection of Science Instruments.” NASA. Ed. Karen Northon. NASA,26 May 2015. Web. 12 Sept. 2015. <https://www.nasa.gov/press-release/nasa-s-europa-mission-begins-with-selection-of-science-instruments/>.

[6] Khurana, K., Kivelson, M., Hand, K., and Russell, C., Electromagnetic Induction from Europas Ocean and theDeep Interior, Europa, 2009, pp. 571-586.

11 of 11


project elsa: europa lander for science acquisitionproject elsa (europa lander for science...

Documents