PhoneSat is a technology demonstration mission, picosatellites of NASA/ARC (Ames Research Center) based on a 1U CubeSat form factor, developed through the agency's Small Spacecraft Technology Program . The project started in summer 2009 as a student-led collaborative project between the Ames Research Center and the International Space University. The objective of the project is to use a commercial mobile telephone (smartphone) as an avionics system in a nanosatellite. The overall goals are to: 1)2)3)4)

• Increase on-orbit processor capability by a factor of 10-100

• Decrease the cost by a factor of 10-1000

• Free up the CubeSat volume for additional payload through avionics miniaturization

In April 2013, the first three PhoneSat satellites were sent to space and successfully accomplished their mission of staying alive. Figure 2 shows a project time line of the events that have taken place in the PhoneSat project. 5)

Preliminary ground testing: In order to evaluate the survivability of the smartphone in a space environment, a set of tests were conducted using a HTC Nexus One phone. The first test exposed the phone to a vacuum level of 2 x 10-6 Torr and thermal extremes of -35ºC and +60ºC. Under these conditions, no anomalies in the performance of the smartphone were observed. Along with the smartphone, an Arduino board was tested and showed no evidence of deterioration.

As a next step in the testing process, a smartphone was flown as a payload in a sounding rocket that reached 10 km in altitude. The payload was also equipped with an IMU (Inertial Measurement Unit). During the flight, the accelerometer and magnetometer data from the phone and IMU were collected and stored in the phone’s SD-card. Despite the accelerometer saturating at about 2G, the test was successful since the smartphone was proven to survive the launch environment conditions (Ref. 5).

The objective of the two PhoneSat-1.0 units is to demonstrate the use of Nexus S smartphone, the flight avionics for a small satellite (1U CubeSat). The two PhoneSat-1.0 CubeSats are battery-powered (lithium-ion battery). They are required to stay alive in space for only a short period and send back health and picture data. Communications is provided by a radio beacon and a watchdog circuit. The latter provides simple monitoring of the systems and reboots the phone if radio packets stop being sent.

Figure 3 shows an overview of the hardware architecture of PhoneSat-1.0. The Nexus One phone is embedded in the satellite with its battery removed. In place of the battery is a set of 12 Li-ion batteries mounted in a 3D printed battery holder and connected in parallel to provide power to the spacecraft for about 10 days of operations. The phone interfaces to the Atmel ATmega 328 that runs Arduino software (used as a watchdog) and the StenSat beacon radio via the phone USB connector converted to a serial port. The watchdog is in charge of making sure that the phone functions properly and reboots it if misbehavior is detected (Ref. 5).

PhoneSat uses a StenSat beacon radio, a commercial-off-the-shelf radio in the amateur band, to downlink data to the ground. The StenSat beacon transmits packets of data at 1200 bit/s AFSK at an RF output power of 1W. PhoneSat-1.0 uses this radio at a frequency of 437.425 MHz with a piece of tape measure trimmed at the right length as an antenna.

PhoneSat-1.0 collects data from the accelerometer and magnetometer sensors built into the phone and from two additional temperature sensors located in two different locations in the spacecraft. This data is stored in the phone’s memory. The phone camera is also used to take pictures of its surroundings.

Software architecture: The software of PhoneSat-1.0 is built on top of the Android 2.2 framework. The app developed consists of a few activities and modules that are interconnected as shown in Figure 4.

The package phonesat.service is in charge of handling the Android execution flow of the app. It has two classes: the autostart receiver that is responsible for starting the app and the command receiver that is in charge of calling the phonesat.executive. The Phonesat.executive contains the command module service that acts as a scheduler.

There are four activities that can be run: (1) the camera activity takes 1 picture every time it’s called, (2) the sensor data service collects sensor data from the phone and the external sensors, (3) the image analyzer is in charge of selecting the best image among the pictures taken according to a pre-defined criteria and (4) the image processor is responsible for analyzing and decomposing into tiles the picture selected.

At the phonesat.hardware level, the IO service contains all of the hardware drivers. The phonesat.packet module is responsible for packetizing both the sensor data and the images so they can be sent through the beacon radio.

The smartphone chooses the best picture over the 100 selected. The best picture captured by PhoneSat-1.0 is defined as the one that has a higher edginess, indicating pixels that are more different from the contiguous pixels within the same picture. Once the best picture has been selected, the software decomposes it into tiles of three different resolutions: background, medium and high. Every tile is contained in an image packet. For each resolution, the number of tiles in which the picture is divided is shown below.

• Background: 1 packet

• Medium resolution: 64 packets

• High resolution: 256 packets.

The packets are sent depending on the day of the mission, with priority given to the low-resolution packets during the first days and to the higher resolution during the rest of the mission and on the relevance of information on the picture.

Concept of operations:

Initialization: Immediately after the spacecraft has been ejected from the launch vehicle, the watchdog powers on. The smartphone is turned on by the watchdog 45 minutes after deployment.

Phase 1: After the initialization phase, the phone is in phase 1 in which it performs a health check. During this phase, each sensor and subsystem is checked and data is compiled into a standard health packet, stored in the smartphone’s SD card and transmitted over the beacon radio at a regular interval of 30 seconds. The last 10 health packets are stored in the SD card. After every 10 packets sent, the beacon radio is rebooted. This phase happens during the first 24 hours of the mission. The mission time is kept in the phone throughout the mission so that a system reboot during this phase does not reset the 24 hour countdown A health packet consists of: Satellite_ID, restart counter, reboot counter, Phase 1 count, Phase 2 count, time, battery voltage, temp 1, temp 2, accel X, accel Y, accel Z, Mag X, Mag Y, Mag Z, text “hello from the avcs”.

Phase 2: This phase starts once a full system health check has been performed. During this phase, image packets and health packets are sent to Earth through the beacon radio. A health packet is sent once for every 9 image packets downlinked.

This phase can be divided in 3 sub-phases:

• Health Data Measurements: Health data is measured and the 10 most recent samples are stored in the SD card.

• Health Data Downlink: Once 9 packets have been sent through the beacon containing image information, the 10th one is reserved for a health packet.

• Image Sequence: One picture is taken every minute until 100 pictures are taken and stored to the SD card. Pictures are then analyzed and the top image is selected. This image is packetized and compiled into standard image packets. These image packets are transmitted over the beacon radio coupled with health packets in the ratio explained above.

Safe Mode: If the watchdog detects that the phone is not sending any data to the radio for a certain period of time, the spacecraft functionality is reduced to the bare minimum. In this condition, the spacecraft only transmits health data containing the last 10 sensor data values stored in the SD card prior to failure. This mode lasts for 90 minutes. After this period, the spacecraft resumes its normal operations. A safe mode packet consists of: Satellite_ID, last 10 voltage values, last 10 temperature sensor 1 values, last 10 temperature sensor 2 values, text “SAFEMODE”.

Testing:

To validate the design, PhoneSat-1.0 was tested extensively. A radio range test was conducted over 37 km straight line-of-sight distance in order to validate the communications link. This showed that the link was strong enough to receive data from the satellite if it were placed in a 500 km altitude orbit. Next, the spacecraft passed a week-long test to prove the robustness of the system and the stability of the software. To prove the flight readiness of the system and the team, PhoneSat-1.0 was lifted in a balloon up to 30 km altitude while performing operations described in the previous section. This test served to expose PhoneSat-1.0 to temperature extremes (during the test, temperatures below -5ºC were recorded) and to test the communications system in a more dynamic manner. The analysis of the test results showed that the system performed as expected.

Subsequently, PhoneSat-1.0 underwent environmental qualification and acceptance testing at NASA/ARC. PhoneSat-1.0 was first placed into a bell jar Thermal Vacuum chamber and successfully underwent days of Day in the Life test to simulate on orbit operations. To help qualify the satellite for severe and harsh launch environment, the satellite then underwent Random Vibration and Mechanical Shock testing to launch provider-prescribed levels. After satisfying these requirements, the satellite was placed into the Bell Jar again for Thermal Vacuum Bakeout at 60°C over 6 hours in order to outgas all parts.

After successfully qualifying PhoneSat-1.0, multiple units were assembled, baked out in a vacuum chamber and thermally cycled in an oven between -5°C and 45°C for approximately 12 hours. Then, two PhoneSat-1.0s were selected to be combined with a PhoneSat-2.0 beta in a flight-like ISIPOD for acceptance vibration testing (Ref. 5).

PhoneSat-2.0

A beta version of PhoneSat-2.0 joins the two battery-powered PhoneSat-1.0 spacecraft. PhoneSat-2.0 is built around an updated Nexus S smartphone made by Samsung Electronics which runs Google's Android 2.3.3 operating system to provide a faster core processor, avionics and gyroscopes. The objective of the one 1U PhoneSat-2.0 unit is to demonstrate the smartphone as the flight avionics, a low cost reaction wheel-based attitude control system, and solar cell power (to enable a longer duration mission).

PhoneSat-2.0 βcontains more complex hardware than PhoneSat-1.0. The hardware architecture, focusing on providing more subsystems for bus functionality whilst maintaining the 1U form factor, supports a new EPS (Electric Power System) architecture, second radio for two-way communications, an attitude determination and control system (ADCS), distributed network of sensors throughout the spacecraft and new smartphone model as well as data interface architecture (Ref. 5).

In terms of the EPS, the system uses high-efficiency, multijunction TASC solar cells that populate all six external faces of the spacecraft. These solar cells are used to charge 4 Li-Ion batteries, similar to the models used in PhoneSat-1.0, arranged with two in series and two in parallel to provide a 7.4 nominal bus voltage. The unregulated power from the batteries is down converted for each subsystem as needed. PhoneSat -2.0 retains the ATmega 328 microcontroller that PhoneSat-1.0 uses as a watchdog, modified for added power management functionality.

For the communications subsystem, PhoneSat-2.0 keeps the same StenSat beacon radio and the tape measure antenna from PhoneSat-1.0. Additionally, the Microhard MHX-2420 radio operating on 2.4 GHz ISM band at 1 W output power, is used for two-way communications. A patch antenna designed by Astronautical Development, LLC is used for this radio.

The attitude determination utilizes the Nexus S smartphone built-in magnetometer and gyro as well as current sensors for the solar panel as a coarse sun sensor. For attitude control, PhoneSat-2.0 has magnetic coils on all six faces of the CubeSat and three brushless DC motors that are used as reactions wheels to orient the spacecraft.

PhoneSat has a set of sensors across the satellite that measure current and temperature as well as monitor the state of the battery. This data is used primarily for sate of health monitoring.

The data architecture of PhoneSat-2.0 is centered on the serial-converted USB port of the smartphone and a serial router. This architecture enables multiple devices to talk to each other as well as the smartphone. Figure 5 and Figure 6 show a power and data diagram, respectively, of the PhoneSat-2.0 bus.

Software architecture: Following the expansion from a single smartphone in space for PhoneSat-1.0 to a capable bus for PhoneSat-2.0, the Software architecture expanded and made use of a more modular design. The software is organized in different layers that interface with the Android framework. Figure 7 shows a diagram of the software architecture, followed by a detailed description of each section.

phonesat.app: This software package contains the applicative. It handles the execution of the Concept of Operations.

• Stabilize: This activity is run after the deployment of the spacecraft to stabilize it. This is performed by using magnetic coils.

• MagneticAlignment: This activity is a variant of Stabilize. It uses the magnetic coils to stabilize the spacecraft, but also apply a constant magnetic field in order to align one specific axis of the spacecraft to the magnetic field of the Earth. This activity is run prior to a ground communication.

• PointingDemo: This activity is controlling the reaction wheels of the spacecraft to point to a designated target. It is either used to take pictures of the moon or to align the S-band antenna to the ground station.

• AlignmentDownlink: This activity is running the same ADCS algorithm as MagneticAlignment, plus turning the S-band radio ON to establish ground-to-space communication. The MagneticAlignment allows a better communication link by aligning the S-band antenna.

phonesat.service: This package contains the code needed to handle the Android execution flow of the App.

• PhoneSatService: This is the generic Android service managing the flight application. It handles the initialization of the system.

• PhoneSatReceiver: This is a generic Android broadcast receiver. It receives various phone internal events from Android and passes them to the flight application.

phonesat.adcs: This package contains the ADCS algorithms.

• AdcsManager: This class is running the ADCS algorithms in a dedicated low-latency thread. It listens for activities (phonesat.app) to determine which algorithms to use, executes these algorithms and controls the magnetic coils and reaction wheels.

phonesat.executive: This package contains the code to schedule and execute the mission activities.

• ExecutiveThread: This class holds a single thread of execution where the mission activities are posted. This is a simple queue (first in – first out) of pending activities.

• Scheduler: The activities to execute are written in a text file on the phone file system. This file contains the start time and the name of the activities to execute. This file is written by the ground station every time a link is established. The Scheduler class is responsible for reading this file and pushing the pending activities to the ExecutiveThread.

phonesat.packet: This package contains the code to encode beacon packets.

• PacketEncoder: This class encodes the beacon packets.

phonesat.hardware: This package contains the device drivers for the PhoneSat hardware.

• Watchdog: This class is the driver for the Watchdog device.

• SensorInterface: This class is the driver for the sensor interface. It receives the sensor data external to the phone, such as temperature sensors and current sensors.

• Acs: This class is the driver for the ACS device. The ACS device controls the magnetic coils and the reaction wheels.

• StenSat: This class is the driver for the StenSat beacon radio.

• Microhard: This class is the driver for the Microhard radio (Ref. 5).

Concept of operations:

Because the PhoneSat-2.0 spacecrafts do not have onboard GPS, the mission schedule is determined on the ground and uploaded to the spacecraft. The possible activities that can be programmed are described in the software architecture (package phonesat.app).

When no schedule has been uploaded yet or when the current schedule has been fully executed, the spacecraft enters a ground listening mode described below.

Initialization - Deployment sequence: Once PhoneSat-2.0 is deployed from the launch vehicle, the watchdog turns on and starts a counter. After 50 minutes, the smartphone starts the Stabilize activity for 5 hours in order to detumble the spacecraft. Once this activity is completed, it starts the MagneticAlignment activity for 1 hour.

Ground listening mode: When in this mode, the smartphone will align the spacecraft to the Earth’s magnetic field and listen for ground commands over the Michrohard radio. The chances of establishing a ground link depends on the duration to charge the batteries - the shorter the better.

Scheduler mode: When the phone has a valid time and schedule file with one or more pending activities to execute, it will wake-up to execute these activities. The phone will be sleeping the rest of the time, keeping the maximum battery power for the scheduled activities.

Sleeping mode: In this mode, the phone is off and the only microcontroller powered on is the Watchdog that transmits a health packet every 2.5 minutes.

Testing:

Similar to PhoneSat-1.0, all instantiations of PhoneSat-2.0 (PhoneSat-2.0 β, PhoneSat-2.4, and PhoneSat-2.5) were extensively tested. PhoneSat-2.0 β, the trailblazer for PhoneSat-2.4 and PhoneSat-2.5, tested successfully in two suborbital flights, UpAero’s SL6 launch in April 2012 and Garvey Spacecraft Corporation’s (GSC) P-19 rocket in December, 2012. The UpAero launch exposed the satellite hardware to extreme environments up to 117 km, providing confidence that the satellite hardware could survive a harsh and severe orbital launch. The GSC launch verified the on board radios’ ability to close the link to a ground station.

Following the successful completion of these suborbital flights, PhoneSat- 2.0 β underwent qualification testing. First, the satellite was baked out at 50°C for 12 hours in the bell jar. Then the satellite was power tested under vacuum between 12°C and -20°C for more than 18 hours. Finally, the satellite was performing on orbit operations while thermally cycled under vacuum to between on orbit predicted temperatures. PhoneSat-2.0 β then successfully passed the Mechanical Shock test at launch provider-prescribed levels. The satellite was then tested at qualification Random Vibration levels.

After this unit was qualified, PhoneSat-2.4 and PhoneSat-2.5 were subjected to similar tests with levels adjusted to meet each launch provider’s requirements (Ref. 5).

Launch: Three NASA PhoneSat systems (two PhoneSat-1.0's CubeSats and one PhoneSat-2.0 β CubeSat) were launched on April 21, 2013 on the maiden flight of the Antares-110 vehicle of OSC (Antares is the renamed Taurus-2 launch vehicle of OSC for medium-class payloads). The launch site was the Wallops Flight Facility, Wallops Island, VA. 6)7)8)9)

For launch, the three CubeSats were integrated into an ISIPOD CubeSat deployer built by ISIS (Innovative Solutions in Space) of Delft, The Netherlands. On pod release from Antares, the CubeSats were deployed individually. All 3 spacecraft had corner reflectors to assess the laser communications potential for CubeSats. The mass of each CubeSat was ~ 1.2 kg.

The PhoneSats were named “Alexander”, “Graham” and “Bell” in honor of Alexander Graham Bell the inventor of the first telephone. “Graham” and “Bell” were two full PhoneSat 1.0 versions, “Alexander” was PhoneSat 2.0 β, which included the power and data architecture of PhoneSat 2.0. All three spacecraft achieved more than 100% of the mission objectives.

The primary payload on this test flight was a Cygnus capsule mass simulator of ~3800 kg (of Orbital Sciences/NASA), a heavily instrumented payload to gather data on the launch environment aboard Antares. The launch was funded under the NASA COTS (Commercial Orbital Transportation Services) program. 11)

Ten minutes after liftoff, the rocket released its payload, a simulated Cygnus spacecraft and several smallsats, into low Earth orbit, ending a successful mission.

The launch was a major success for both Orbital and NASA. For Orbital, Antares represented not only the largest rocket the company had ever built, but also a major bet on the company’s future. Orbital hopes Antares can launch not just Cygnus cargo missions, but other satellites, for the US government in particular, that previously flew on the Delta II, a medium-class rocket that will be retired in the next few years. Antares will provide “right-size and right-price” launch services, as the company terms it, for such payloads, a subtle reference to the fact that such satellites now have to use the larger, and more expensive, EELV-class Atlas V and Delta IV. - For NASA, the launch was another vindication of its approach to turn to the commercial sector to launch cargo and, eventually, crews to the ISS. 12)

The Antares picture perfect liftoff marked the first step in a PPP (Public/Private Partnership) between NASA and Orbital Sciences to restart cargo delivery services to the ISS that were lost following the forced retirement of NASA’s space shuttle orbiters.

The four small satellites were deployed from two ISIPODs (ISIS Payload Orbital Dispensers) that were integrated with the mass simulator. 14)

Figure 10: Photo of the Cygnus mass simulator capsule after its separation from the Antares rocket (image credit: OSC) 15)

Legend to Figure 10: The image was taken by a camera onboard the upper stage of the Antares rocket. Both the mass simulator and upper stage of the Antares vehicle are expected to stay in orbit for several months before their orbits degrade and they reenter and burn up in the atmosphere before reaching Earth's surface.

Vision: The current vision beyond PhoneSat-2.0 is twofold: (1) to start using the PhoneSat-2.0 bus to do science and exploration missions — i.e. start utilizing the benefits of PhoneSat and (2) to continue to push forward breakthrough technologies that enable (a) an increase in capabilities and (b) a decrease in cost.

There are several directions that each could take: dispersed sensor heliophysics missions, missions to do space qualification of components, debris or NEO (Near Earth Orbit) tracking, low cost Earth observation, Lunar and other exploration missions, add GPS, foldable design. These can all lead to significant new performance. The GPS receiver could enable an array of missions not possible without. The foldable design would entail compacting the PhoneSat bus into a smaller volume which folds out. This would enable multiple satellites to be launched per 1U size and since launch costs dominate, a lower overall mission cost. The PhoneSat 2 year milestone is to have iterated through several designs to produce a PhoneSat 3.0 which supports the vision beyond PhoneSat-2.0 with a primary focus on (a) dispersed sensors mission support and (b) a foldable design. The vision is to continue to “decrease” the cost AND “increase” the capability. Pursue both vectors simultaneously. 16)

PhoneSat mission status on Antares maiden flight:

Some in-flight results (Ref. 5): “Graham” and “Bell” collected battery voltage data, accelerometer and magnetometer data from the sensors built into the smartphone and temperature from two external sensors placed at different locations of the spacecraft. Figure 11 shows the battery voltage depleting their batteries at a similar rate over time for both spacecrafts.

Legend to Figure 11: The red markers represents data from “Graham”, while the blue markers represents data from “Bell”.

Figure 12 and Figure 13 show the accelerometer and magnetometer data from “Graham,” respectively. Similar data was received from “Bell.” This acceleration is a product of noise, no flight calibration and the sensor’s location away from the center of mass. The magnetometer data shows a magnetic field module value time varying and greater than the field for this orbit due to a parasitic magnetic field in the satellite.

Legend to Figure 12: The red markers show the acceleration X-axis, the blue markers show the acceleration Y-axis, and the green markers show the Z-axis accelerations; the x markers show the values of the acceleration module.

Legend to Figure 13: The red markers show the magnetic field X-axis, the blue markers show the magnetic field Y-axis, the green markers show the magnetic field Z-axis, the x markers show the values of the magnetic field module.

Figure 14 shows the temperature recorded by the sensors for both spacecrafts ranged from -10ºC to +30ºC approximately.

Legend to Figure 15: The red markers show temperature sensor 1 values of “Graham”, the blue markers show temperature sensor 2 values of “Graham”. The orange line represents the time under sunlight and the black line the time in eclipse.

In terms of the phone’s survivability in the space environment, one phone reboot was observed in “Graham” and four in “Bell” during the five-day mission. The radio signal strength was not an issue as packets were decoded consistently from both spacecrafts (Ref. 5).

PhoneSat 2.0 β data:

PhoneSat 2.0 β collected compass, gyro and accelerometer data using smartphone sensors. Along with subsystem current consumption and solar panel current generation, the satellite also measured and recorded temperature on eleven different locations of the spacecraft. The recorded temperatures ranged from -1ºC to 27ºC for the interior of the spacecraft and -20ºC to +40ºC for the exterior. Counters on the smartphone and Arduinos showed zero reboots. The obtained gyroscope data from the smartphone is shown in Figure 16. A waiver was obtained with the LSP to eliminate the burn-wire for the deployable tape measure antenna. Hence, the antenna deployed against the ejection module, creating the spacecraft’s high initial spin rate.

• May 2, 2013: For about one week, engineers at NASA/ARC, Moffett Field, CA, and amateur radio operators around the world collaborated to reconstruct an image of Earth sent to them from three smartphones in orbit. The joint effort was part of NASA's nanosatellite mission, called PhoneSat, which launched on Sunday, April 21, 2013 aboard the Antares rocket from NASA's Wallops Island Flight Facility in Virginia. 17)

Although the ultimate goal of the PhoneSat mission was to determine whether a consumer-grade smartphone can be used as the main flight avionics for a satellite in space, the three miniature satellites used their smartphone cameras to take pictures of Earth and transmitted these "image-data packets" to multiple ground stations. Every packet held a small piece of "the big picture." As the data became available, the PhoneSat Team and multiple amateur ham radio operators, who call themselves "hams," pieced together a high-resolution photograph from the tiny data packets.

Piecing together the photo was a very successful collaboration between NASA's PhoneSat team and volunteer amateur ham radio operators around the world. NASA researchers and hams working together was an excellent example of Citizen Science, or crowd-sourced science, which is scientific research conducted, in whole or in part, by amateur or nonprofessional scientists. On the second day of the mission, the Ames team had received over 200 packets from amateur radio operators.

Figure 18 is such a reconstructed image from packets received by amateur radio operators (image credit: NASA).

- Over the course of five days in space the trio of PhoneSats operated as planned, according to NASA. The spacecraft could prove to be the lowest-cost satellites ever flown in space, NASA researchers say. 18)

Figure 18: Photo of Earth transmitted from PhoneSat "Alexander" (PhoneSat-1.0) and reconstructed from packets received by amateur radio operators (image credit: NASA)

• The orbital analysis of the PhoneSat team indicates that the PhoneSats have deorbited on April 27, 2013 and have burned up in Earth's atmosphere as predicted. No one has been able to hear from the satellites since, which confirms the predictions. The mission is considered a success. - The PhoneSat team will continue to develop the PhoneSats using consumer technology to greatly increase the capability of the satellite whilst developing with a low cost. 19)20)

• April 22, 2013: Transmissions from all three PhoneSats have been received at multiple ground stations on Earth, indicating they are operating normally. The PhoneSat team at the Ames Research Center in Moffett Field, CA, will continue to monitor the satellites in the coming days. The satellites are expected to remain in orbit for as long as two weeks. 21)22)

PhoneSat is an iterative effort that has continued beyond the Antares flight. Two PhoneSat-2.4 versions of 1U CubeSats were delivered for the ORS-3 Minotaur 1 (launch Nov. 20, 2013) and two PhoneSat-2.5’s were on the SpaceX CRS-3 flight (launch April 18, 2014). The CubeSats (PhoneSat-2.4) on ORS-3 successfully accomplished its mission. Additionally, the KickSat nanosatellite mission of Cornell University (launch April 18, 2014), was using the PhoneSat-2.5 bus.

EDSN (Edison Demonstration of SmallSat Networks), a swarm of eight 1.5U CubeSats designed at NASA/ARC ( Ames Research Center), is an extension of the PhoneSat-2.0 bus designed for space communication networks. The EDSN mission is scheduled to launch by the end of 2014. The PhoneSat team is currently working on new concepts for PhoneSat 3.0 and beyond.

So far, the PhoneSat Project has successfully demonstrated the use of consumer technology, namely the smartphone, to supplement traditional space hardware to drastically reduce cost. In addition, agile development has been successfully employed in order to maximize technological advancement over time. With satellite bus functionality now possible for consumer technology prices, a substantial number of missions for science, education, technology and commercial applications are now economically viable. A large thank you to the innovative co-PIs that formed the foundation for this project: Drs. Chris Boshuizen and Will Marshall, in addition to the team that gave this project its initial success.

The information compiled and edited in this article was provided byHerbert J. Kramer from his documentation of: ”Observation of the Earth and Its Environment: Survey of Missions and Sensors” (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates (herb.kramer@gmx.net).