Minimize EDSN

EDSN (Edison Demonstration of SmallSat Networks)

Overview    Spacecraft    Launch    Sensor Complement   Project Status    References

In 2012, NASA's OCT (Office of the Chief Technologist) initiated its first project, called Edison Demonstration of SmallSat Networks (EDSN), to demonstrate solutions to many SmallSat needs. EDSN will demonstrate a large swarm of advanced, yet affordable, consumer electronics-based nanosatellites that enable a wide array of future scientific, commercial, academic, and defense applications.

A goal of EDSN is to demonstrate advanced communications, including cross-satellite ad-hoc data communications network, for extremely flexible data correlation and distribution, simplified operations, and efficient downlink of swarm data. EDSN will support a science instrument payload capable of measuring "space weather" data that, when combined with data taken from other members of the satellite swarm, can yield spatially and temporally correlated data maps impossible to acquire from a single satellite. 1) 2) 3) 4)

EDSN is a swarm of eight 1.5U Cubesats with crosslink, downlink and science collection capabilities developed by the NASA/ARC (Ames Research Center) at Moffett Field, CA, under the SSTP (Small Spacecraft Technology Program) within the NASA STMD (Space Technology Mission Directorate). 5) 6) 7)

The project goal is to demonstrate that a swarm of satellites is capable of collecting multi-point science data and transferring the data to the ground. This is achieved through the mission objectives:

1) Flight demonstrate one-way space-to-space data transfer whereby at least 2 satellites transfer data to a third satellite, which then transfers the data to the ground.

2) Flight demonstrate a system to collect multi-point science measurements, transfer science measurements to another satellite and transfer to the ground.

3) Flight demonstrate a reaction wheel based pointing system.

4) Assess the viability of satellites built with COTS (Commercial Off The Shelf) components to operate for 60 days.

The EDSN mission is designed, after a brisk tempo development phase, to demonstrate a system-of-systems solution that satisfies all four needs discussed above and enables new kinds of science missions in a game-changing low cost/managed risk paradigm.

 


 

Space Segment:

EDSN is comprised of a swarm of CubeSat nanosatellites made of low-cost components derived from the PhoneSat 2.0 bus. Each EDSN nanosat has a smartphone on board (Nexus S), to test open source as well as custom software and investigate the viability of C&DH (Command and Data Handling) system made out of consumer-grade electronics. Also, each EDSN nanosat has a single transceiver for both on-orbit crosslinks and ground station downlinks, and each contains a science payload called the EPISEM )Energetic Particle Integrating Space Environment Monitor) procured by MSU (Montana State University).

EDSN_AutoD

Figure 1: Photo of two 1.5U CubeSats (image credit: NASA/ARC)

The EDSN satellite swarm is composed of 8 identical nanosatellites based on the CubeSat form factor, 1.5U in size (10 cm x 10 cm x 17 cm), each with a mass of ~1.7 kg. In order to support extension to larger swarm mission architectures, the EDSN spacecraft was designed to leverage low cost COTS components and inherited many design elements from the PhoneSat 2.0 architecture.

Each EDSN spacecraft (Figure 2) consists of a stack of eight PC boards and a battery pack that plug into a common printed circuit board backplane that runs the length of one 17 cm side of the spacecraft. Four rods with spacers run through the corners of the boards, providing structural support. The stack is enclosed in a machined aluminum chassis with the solar panels clamped to the exterior.

A Samsung Nexus S smartphone is used as the primary processor to perform such computationally intensive functions as attitude determination and control, orbit propagation (to determine when downlink and science collection windows occur), schedule planning, and data collection and packaging. The Nexus S controls all intersatellite and spacecraft-to-ground communications. Four Arduino (two ATMega2560 chips and two ATMega328P) microcontrollers manage the GPS receiver, science payload, various sensors and relays and interfaces to the attitude determination and control hardware. The spacecraft data bus is managed through the router board, which is built around the Parallax P8X32A Propeller chip. All commands and data moving between the various EDSN boards go through the router. A data packet system with acknowledgement messages and retransmission for critical packets transmitted between subsystems is implemented in software on the Nexus S, Arduino and router processors.

The ACS (Attitude Control Subsystem) consists of three orthogonal brushless motor reaction wheels and torque coils embedded in the solar panel PCBs (Printed Circuit Boards). Attitude determination uses the smartphone gyro and magnetometer sensors combined with currents from the solar panels. The ACS two distinct modes of operation. Magnetic control is used to detumble the spacecraft and align it with the local magnetic field for GPS acquisition and downlink activities. In this mode, the Nexus S magnetometer is used for attitude determination (i.e. measuring the local magnetic field) and six torque coils embedded in the solar panel printed circuit boards (PCB's) are used for control. When the spacecraft is performing a sun-pointing demonstration, three orthogonal brushless DC motor reaction wheels control the spacecraft while the Nexus angular rate sensors and solar panel current monitors provide measures of the body rates and sun-vector, respectively. A Novatel OEMV-1 GPS receiver is used to get position, velocity and time fixes approximately once every 25 hours.

EPS (Electrical Power Subsystem): Orbit average power of ~1 watt is provided by 6 solar panels that use TASC (Triangular Advanced Solar Cells) from Spectrolab. The solar panels are mounted directly to a 1.5U solid Pumpkin chassis. A GPS and an S-band patch antenna are mounted to the 1U ends of the structure while two UHF monopole antennas extend off the 1.5U faces. Four Li-ion 18650 batteries in a COTS holder are used for combined energy storage of 5.2 Ah and bus voltage regulation. However, because a COTS battery holder provides over-charge protection for the battery, a Zener diode is needed to provide over-voltage protection for the bus. Additional voltage regulation is done at the board level to keep the system modular. The 8 PCB subassemblies and battery holder are electrically inter-connected through a single backplane PCB.

System level power management is relatively simple. If a low voltage limit of 7 V is reached, all components (excluding the low level processor) turn off. If the system is booting up or restarting, a threshold of 8 V must be reached before the main processor can be operated and activities can be executed.

When the spacecraft is not performing one of its key activities (e.g. taking science data, controlling attitude, performing a crosslink or downlink), the Nexus is turned off and the spacecraft is monitored by the EPS board Arduino, commonly referred to as the "Watchdog". The schedule maintained on the Nexus S determines when it should be turned off. At this point a timer is set on the Watchdog that turns the Nexus on again at a specific future time. This low power, or "wait" mode that is provided by the EPS is key to the efficient operation of EDSN as the solar panels provide an orbit average power of just one watt.

EDSN_AutoC

Figure 2: The elements of the EDSN satellites highlight the major components and subassemblies (image credit: NASA/ARC)

 

RF communications:

The EDSN communications subsystem uses three radios to perform three different tasks. Intersatellite communication (crosslink) is performed with an AstroDev Lithium 1 UHF transceiver, attached to a deployable tape-measure monopole antenna. Crosslink occurs at 9.6 kbit/s under the AX.25 protocol with 1 W transmitted power. The Astrodev receiver is only powered when a crosslink has been scheduled. A MicroHard MHX2420 transceiver is used for the S-band downlink to the ground station. A single S-band patch antenna is mounted to one end of the spacecraft. A StenSat UHF transmitter attached to a tape measure monopole antenna is used as a beacon, sending packets of data every sixty seconds (Ref. 6).

The EDSN innovative communication solutions include network-based inter-nanosat links that forward data to an aggregator satellite which in turn downlinks all collected data to the ground station. In this way, each pass opportunity can be used to downlink the maximum amount of data available from multiple nanosats. This approach can greatly reduce the effort to support cluster-oriented missions.

The EDSN swarm is loosely arranged – that is, although spacing between satellites is arranged by careful deployment in orbit to keep satellites in relatively close proximity (~ 20 km). The satellites will drift with time and not actively stay in the constellation (no propulsion available).

The EDSN communications network (Figure 3) is maintained and operated by a simple set of predefined rules operating independently on all eight spacecraft without direction from ground based systems. One spacecraft (the Captain) serves as a central node, requesting and collecting data from the other seven spacecraft (the Lieutenants), organizing the data and passing them to a ground station at regular intervals. The Captaincy is rotated among the spacecraft on a regular basis, providing robustness against the failure of a single spacecraft.

EDSN_AutoB

Figure 3: Schematic view of the EDSN communications concept (image credit: NASA/ARC)

Communications concept: The EDSN swarm is a hub-and-spoke network whereby one spacecraft (the "Captain") communicates with the other spacecraft (the "Lieutenants") to collect data packets from them using a single common frequency. The Captain stores these data and sends them to the ground along with its data when a downlink opportunity occurs.

The process of passing information from one Lieutenant (LT) to the Captain (CPT) is called a "transaction". A transaction begins when the CPT sends a "ping packet" to the rest of the swarm using the Lithium radio. Since the intersatellite link is omnidirectional and may be received by any LT, the ping packet includes information, designating which LT should respond. The CPT will send six pings over a period of 50 seconds to an LT. The CPT will then wait for the LT to respond with its data. While the transmit/receive antennae are omnidirectional monopoles, there are nulls in the antenna patterns. Sending six pings over 50 seconds increases the chances that the LT will "hear" the ping.

When an LT receives a ping, it first parses the command to make sure it is valid (i.e. that the packet checksum is correct) and that the ping request is for it and not for another LT. By giving each spacecraft a unique identifier (A through H), only one LT is authorized to transmit data at a time. This prevents the LTs from broadcasting simultaneously and bringing all crosslink communications to a halt. Once the LT confirms that the "ping packet" is for it, it will wait 60 seconds to allow the CPT to stop sending "pings". It then send a series of its data packets to the CPT, again using the Lithium radio. First, one SOH (State-of-Health) packet is created and sent over the intersatellite link. This is followed by all of the science packets that are stored in the LT's science packet queue, as shown in Figure 4.

EDSN_AutoA

Figure 4: Lieutenant data structure (image credit: NASA/ARC)

Once the LT has transmitted all of its data, it turns off its Lithium radio, ends its crosslink activity and deletes the SOH and science data from its crosslink queue. However, the most recent science packet is kept as part of a beacon packet to be broadcast repeatedly by the Stensat. Note that there are no Acknowledge or Negative Acknowledge messages passed between the CPT and the LT. If a data packet is not received by the CPT, it is lost. This is acceptable for EDSN since it is a demonstration of the concept of Cubesat based data networks. The system generates many more packets to pass through the network than are required to meet the mission objectives. It is anticipated that future enhancements to the architecture will provide greater guarantees of data transmission either through the implementation of an ACK/NACK system, or via delay tolerant networks.

As the CPT is receiving the data packets from the LT, it places them in a FIFO (First-In-First-Out) "transaction queue" in Nexus S memory (Figure 5). This queue is pushed onto a LIFO (Last-In-First-Out) stack of packets received from that LT. Called the "downlink stack", the CPT maintains one such stack for each LT, storing the data for downlink to the ground when a downlink opportunity occurs. It also maintains a downlink stack for itself, containing only the Captain's science packets. This system was implemented to prioritize the most recent SOH data over science data and recent packets over older packets.

The CPT collects data from an LT for a fixed period of time and ends the transaction once the allocated transaction time has elapsed. If the LT is not in range to get the ping, or is "off" due to a low battery condition, the CPT will listen for the entire transaction duration (~4 minutes) before moving to the next LT.

The CPT continues to collect data by sending a "ping" to the next LT (e.g. spacecraft B), initiating a new transaction with that LT. This process is repeated until the CPT has attempted to initiate a transaction with each LT in the swarm. The set of seven transactions is referred to as a "session".

The "Captaincy" of the EDSN swarm is rotated amongst the spacecraft in a present pattern (A-B-C-D-E-F-G-H-A) so that each spacecraft has the opportunity to be CPT. Also, the loss of any single spacecraft does not end the mission, as it would if there were only one spacecraft designated as CPT for the entirety of the mission. The time during which a spacecraft is CPT is called a "minor cycle". Prior to the start of a minor cycle, each spacecraft gets a GPS fix to determine GPS time, and its position and velocity. GPS time is compared to preloaded table of time windows given in UTC (Coordinated Universal Time) to determine which spacecraft is CPT. If a spacecraft cannot get a valid GPS time, it does not participate in the network activities of the swarm (i.e. it does not attempt to crosslink or downlink). During each minor cycle, between three and four crosslink sessions are scheduled at predetermined UTC times. One downlink activity is scheduled by the CPT per minor cycle when it predicts that it will be passing over a ground station. The LTs do not attempt to make contact with the ground station.

The downlink session is initiated by the ground station with the Microhard S-band link. The CPT sends data packets to the ground in a predefined order (Figure 6). First, the SOH packet is sent. This is followed by the "pointing packet". This contains data related to the sun pointing demonstration that is performed only by the CPT once per minor cycle. The CPT then downlinks the first data packet in each downlink stack, in order of spacecraft, starting with spacecraft A and proceeding through spacecraft H. The process of sending packets from the downlink stacks continues with the second packet in each stack and so on until all of the data in the downlink stacks are exhausted, or the link is broken. If the packets in the downlink stacks are exhausted before the link is broken, the CPT will repeat sending all of its downlink data, in the same order until the link is broken or the downlink activity times out.

EDSN_Auto9

Figure 5: Schematic view of the Captain data structure (image credit: NASA/ARC)

EDSN_Auto8

Figure 6: Downlink prioritization scheme (image credit: NASA/ARC)

The system guarantees that the most recent science and SOH data collected by the CPT and sent to the ground first, and that the SOH packets are given priority over the science data packets. Using this system, the ordering of the crosslinked packets is optimized to provide the data needed to meet the mission objectives – monitoring the health of the spacecraft through the SOH packets and collecting multipoint science data.

Each minor cycle lasts approximately 25 hours. A set of eight minor cycles where each spacecraft has been CPT once is referred to as a "major cycle". It is anticipated that two or three major cycles will occur before the spacecraft are too far apart to crosslink, although they will continue to cycle through several more major cycles before the end of the mission.

Implementation of the crosslink communications on Cubesats requires special consideration of their limited power production (approximately 1 W orbit average for EDSN). If each LT could leave its crosslink receiver on at all times, the CPT could schedule crosslink sessions based solely on its own priorities. Unfortunately, there is not sufficient power for such an implementation. The EDSN communications architecture avoids this problem by having all EDSN spacecraft schedule crosslink activities at fixed times in UTC. Knowing that the crosslink will only occur at a specific time, the LTs can use their radios efficiently and only turn the Lithium-1 on when they expect to get a message from the CPT.

Each EDSN spacecraft uses the clock on its Phone as a time reference. This clock is corrected to GPS time once per minor cycle (i.e. every 25 hours) when a GPS fix is established. Drift of this clock due to temperature and aging effects could introduce an error in local time of as much as 12 seconds, causing the LT and CPT clocks to be out of synch. All time based activities include time "buffers" at the beginning and end of the activity to account for the relative drift of the clocks on different platforms. For example, during a crosslink session, the LT will turn on its receiver 30 seconds prior to the start of the session and leave the receiver on for up to 30 seconds after the end, as defined by its clock. Figure 7 shows the sequence of events that make up a crosslink session, including the overlap of receiver on-times.

EDSN_Auto7

Figure 7: Communications timing diagram (image credit: NASA/ARC)

 

Test results and performance:

The FSW (Flight Software) release 6.5 was the final version of software loaded onto the eight EDSN spacecraft. This release was validated through a combination of unit tests at the software component level, flight software system tests at the function level and mission simulations that captured the performance of the entire EDSN system, demonstrating that the EDSN communications and FSW systems will meet the mission objectives.

The mission simulation consisted of all eight flight satellites in their flight configurations with spacecraft identifiers, and other flight parameters. This included clearing the spacecraft stored time and memory at the start of the test. The simulation was initiated as if the spacecraft were released from the launch vehicle (i.e. the footswitch interrupt circuit was released) and the simulation was run for about 11 days. This captured the 30 hour initialization of the spacecraft, nine full minor cycles of 25 hours each and a transition to the tenth minor cycle. This demonstrated operation of the EDSN network over a full major cycle with every spacecraft holding the role of Captain at least once and one spacecraft being Captain twice. A GPS simulator was not available for the mission simulation. So, during the GPS acquisition activities at the starts of minor cycles, GSE (Ground Support Equipment) was used to "spoof" the GPS packet that the processor expected from the GPS receiver. The position and velocity vectors in the GPS packets were generated using STK (Satellite Tool Kit).

Power to the spacecraft was provided by GSE power supplies and included models of the solar eclipse and expected electrical power levels produced by the solar arrays, with some margin (i.e. power available in the test was less than what is predicted for flight). The spacecraft bus voltages were monitored in real-time using GSE computers with LabView. All RF activities were monitored with GSE as well. A Microhard ground station was used to emulate the ground station at SCU (Santa Clara University) and collect spacecraft data in a flight-like condition. The Microhard was manually set to initiate contact with the spacecraft five to ten minutes after the expected scheduled contact to allow the team to collect power data during the downlink activity and to simulate the uncertainty that will exist in the timing of the ground station contact. A spare Lithium-1 radio was reconfigured to monitor the crosslink activity, but did not interact with the system. An Alinco UHF transceiver was used to monitor the spacecraft beacon messages, emulating ground stations so that the spacecraft could operate in a flight-like configuration. While the beacon is not part of the EDSN network communications system and is not needed to meet the mission objectives, it will be used in flight to provide additional data on the performance of the network. All of these data were recorded by GSE and stored for later processing. The flight-like data were used after the completion of the mission simulation to validate performance per the Mission Simulation Test Procedure and verify requirements.

The EDSN spacecraft passed all tests, clearing flight software as ready for flight in late 2014. Specifically, the spacecraft met all mission objectives, transmitting science and state-of-health data to the ground stations over both the crosslink-downlink channel and the beacon channel. Packets were collected from all eight spacecraft, even though some beacon packets were lost due to poor orientation in the laboratory relative to the ground station, or to simultaneous transmission by two or more spacecraft. Furthermore, the network behaved as expected even in the face of a missed Captain (due to a GSE failure in the GPS packet loading) and missed crosslink opportunities (due to the Captain scheduling a higher priority operation when the Lieutenants expected a crosslink to occur). In a few instances, the downlink in a minor cycle was scheduled before the Captain collected all of its science data. These data were stored until the next minor cycle and passed to the next Captain, as expected.

Other issues, not related to the operation of the EDSN network were observed, dealing primarily with the behavior of the Stensat beacon, as implemented by EDSN. It was noted that the beacon packets from some spacecraft overlapped each other, despite the system being designed with differing transmission offsets between spacecraft to prevent this from occurring. In some instances, the periodicity of the beacon packets would change when transitioning from Phone operation to the Watchdog low power mode. Finally, on a few occasions, the GPS receiver on a spacecraft detected a GPS signal from the in-lab repeater, before the "spoof" message could be uploaded from the GSE. Since the position, velocity and time did not match those of an orbital trajectory, the spacecraft flagged the GPS data as invalid and then attempted to get another GPS fix, as it was designed to do.

 

Future architecture enhancements:

The coordinated operation of many spatially distributed spacecraft will open new markets and enable new scientific breakthroughs that can only be achieved with swarms of capable, low cost spacecraft making measurements simultaneously at different locations. This will finally put smallsats on the same stage as their much larger brethren, by showing that multiple small spacecraft can perform missions that simply cannot be done with a single, traditional spacecraft, no matter how large it is.

EDSN is an important demonstration of key communications capabilities that are necessary to realize the goal of swarms of Cubesats operating in unison to create a system of systems that is truly greater than the sum of its parts. Using its simple hub-and spoke polling system, the 1.5U EDSN spacecraft will demonstrate:

• Time synchronized measurements on spatially distributed platforms

• Collection of data from all spacecraft in the swarm with a single central spacecraft

• One-way operation of the swarm (data collection) through a single spacecraft that is in periodic contact with the ground

• Autonomous operation of the swarm (i.e. without intervention from ground control)

• Redundancy in swarm operations through the simple, pre-scripted periodic hopping of the Captain.

Future missions can use the EDSN communications architecture as a basis for networking a small number of spacecraft together, provided the spacecraft do not drift beyond their crosslink communications range during the mission. Obviously, this architecture can be used for additional investigations in the Earth environment and Earth-sun interactions by flying similar spacecraft in other orbits, sampling other orbit altitudes and the Van Allen belts. An enhanced spacecraft bus would allow investigations of the Earth's Magnetopause, Magnetosheath and Magnetic Tail. These spacecraft could use the EPISEM as a payload, or fly sensitive magnetometers, Langmuir probes or electrometers.

The EDSN architecture can be enhanced to provide additional capabilities to Cubesat swarms, further expanding their utility. These include:

• Controlling the spacecraft in the swarm by routing commands from the ground through the network to individual spacecraft.

• Autonomous configuration of the network by selection of the Captain (or Captains) based on data available to the spacecraft in the swarm. For example, multiple spacecraft could "negotiate" who should be Captain at any given time based on the amount of data needed for downlink, the power state of the spacecraft or the quality of the ground station pass. This can be compared to the EDSN approach to Captain selection, which is predetermined before the mission even flies and programmed into every spacecraft.

• Precise time synchronized measurements by radio command from the Captain, whereby every LT in a swarm would take data upon receiving a command from the CPT.

• Improved synchronization of time across the swarm either by using the crosslinks to lock all clocks in the swarm to the CPT, or by providing each spacecraft with a high quality local clock (e.g. chip-scale atomic clock) to improve time knowledge between GPS updates.

• Collection of GPS pseudo-range and carrier phase data for precision position and swarm geometry knowledge via differential GPS.

• Mapping of network topology to determine which spacecraft can communicate with which spacecraft.

• Routing of packets through the network by multiple hops based on the network topology map so that spacecraft not in direct contact with the CPT can still pass their data to the ground.

• Allowing multiple Captains to take advantage of more ground pass opportunities to get more data from the swarm to the ground.

• Passing of large data files between spacecraft (e.g. image files).

• Prioritization of data messages by the Captain or Lieutenant for downlink.

• Addition of ACKnowledge/NACKnowledge protocol during crosslink and downlink transactions to increase the probability that data packets pass through the network and are not dropped.

• Scheduling of downlinks to multiple ground stations to increase data throughput.

• Addition of a standard network layer to the system to take advantage of COTS software and protocols.

• Interlinking of multiple Captains to create a "cluster of clusters".

The extension of the EDSN communications architecture through a series of small satellite demonstrations will enhance the capabilities of swarms of Cubesats to perform vital, cutting edge research and to open new commercial markets (Ref. 6).

EDSN_Auto6

Figure 8: Photo of the EDSN CubeSat swarm of eight flight units and one flight spare (image credit: NASA/ARC)

 

Launch: The EDSN swarm was launched as a secondary payload assembly on Nov. 4, 2015 (03:45:00 UTC) on the ORS-4 (Operationally Responsive Space-4) mission of DoD. A Super Strypi launch vehicle (LV) will deliver the HawaiiSat-1 payload and multiple secondary CubeSat payloads into orbit. The Super Strypi is a rocket developed by Sandia National Laboratories with assistance from the University of Hawaii, Aerojet and the U.S. Defense Department. The launch site is PMRF (Pacific Missile Range Facility) Barking Sands of the US Navy, located on the Hawaiian island of Kauai. 8) 9) 10)Unfortunately, the Super Strypi launch vehicle experienced a launch failure about 1 minute into the flight. 11) 12)

Status report from NASA/ARC: On November 3, 2015, the eight small satellites of the Edison Demonstration of Smallsat Networks (EDSN) mission were lost in the failure of the launch vehicle during the U.S. Air Force-led Operationally Responsive Space (ORS) Office's ORS-4 mission that was carrying them to orbit as secondary payloads. 13)

The launch provider issued the following statement yesterday: "The ORS-4 mission on an experimental Super Strypi launch vehicle failed in mid-flight shortly after liftoff at 5:45 p.m. Hawaii Standard Time (7:45 p.m. PST; 10:45 p.m. EST) today from the Pacific Missile Range Facility off Barking Sands, Kauai, Hawaii. Additional information will be released as it becomes available."

 

The secondary payloads on the ORS-4 mission, within NASA's ELaNa-VII, were:

• Argus, a 2U CubeSat of SLU (Saint Louis University), Saint Louis, MO, and ISDE (Institute for Defense and Space Electronics) at Vanderbilt University (VU) in Nashville, Tennessee (2 kg). A collaborative nanosatellite radiation mission.

• EDSN (Edison Demonstration of Smallsat Networks). The EDSN mission of NASA/ARC (Ames Research Center) consists of a swarm of 8 1.5 U CubeSats, each with a mass of ~ 2kg. The EDSN project aims to demonstrate cross-satellite data communications for flexible data correlation and distribution as well as simplified satellite operations and data downlink. Being a constellation of satellites outfitted with space weather sensors, EDSN can deliver spatially and temporarily correlated data sets that can not be acquired from single satellite missions.

• PrintSat, a 1U CubeSat of MSU (Montana State University). PrintSat is a technology demonstration to assess the effectiveness of additive manufacturing (i.e. 3D printing) and the Windform XT material for use as a material for space structures. 14)

• Argus, a 2U CubeSat of St. Louis University and Vanderbilt University. Argus uses a platform named SCARAB and a research payload named Independence, which will be used to update models of how electronics behave when exposed to radiation in the space environment.

• STACEM, a 3U CubeSat designed, built and operated by the SDL (Space Dynamics Laboratory) of USU (Utah State University). The satellite demonstrates a miniaturized multi-spectral payload for the acquisition of imagery in the visible and near infrared wavelengths and hyperspectral channels. Imagery is to be used in environmental monitoring. The launch of STACEM on the SPARK launch vehicle is financed by the U.S. National Reconnaissance Office.

• Supernova-Beta, a 6U prototype CubeSat of Pumpkin Inc. Supernova is a satellite platform designed to be highly configurable for a rapid integration of enhanced CubeSat missions, offering a payload volume of 7000 cm3. The Supernova chassis has a mass of 1.64 kg and the total allowable mass of the satellite is specified as 12 kg by Pumpkin.

The NLAS (Nanosatellite Launch Adapter System) of NASA is manifested on the ORS-4 mission. The NLAS deployer includes adapter, 6U dispenser, and sequencer. The adaptor prototype design was provided by NASA/ARC, the final design, fabrication and test was provided by Moog CSA Engineering. A single NLAS provides the capability to deploy 24U of CubeSats. The system is designed to accommodate satellites measuring 1U, 1.5U, 2U, 3U and 6U sizes for deployment into orbit. 15) 16)

Orbit: Near-elliptical orbit, altitude of 430 x 505 km, inclination = 94.8º, period of ~ 90 minutes.

 


 

Sensor complement: (EPISEM)

EPISEM (Energetic Particle Integrating Space Environment Monitor)

The ability to simultaneously monitor spatial and temporal variations in penetrating radiation above the atmosphere is important for understanding both the near Earth radiation environment and as input for developing more accurate space weather models. Due to the high variability of the ionosphere and radiation belts, producing such a data product must be done using high density multi-point measurements. The most recent solar and space physics decadal survey states that these measurement densities have the potential to be provided by CubeSat constellations. The primary scientific purpose of the Edison Demonstration of Smallsat Networks (EDSN) mission is to demonstrate that capability by launching and deploying a fleet of eight CubeSats into a loose formation approximately 500 km above Earth. 17)

NASA selected (through a competitive procurement process) the EPISEM instrument of MSU (Montana State University) to demonstrate the utility of the EDSN swarm as a platform for multipoint space weather measurements.

EPISEM, of HRBE mission heritage (formerly E1P-2), is a space physics instrument for EDSN that provides for multipoint space physics measurements within size, weight, and power budgets allocated to the payload. It complements the EDSN technology demonstration by providing penetrating radiation measurements on each spacecraft for correlation with and analysis of any single event upsets or radiation-induced latch-ups that might occur in the spacecraft controller or other bus subsystems.

The EPISEM card consists of a Geiger-Mueller tube mounted on a PCB (Printed Circuit Board) and is designed to consume approximately 100 mW during operation. The GPS card enables time- and location-correlation of the EPISEM science data. By combining EPISEM data and position/time information, it is possible to characterize the variability of penetrating high-energy protons at a much smaller scale than previously accomplished.

Multipoint measurements of the penetrating radiation environment to be observed by the EPISEM detectors in LEO, will provide characterization of the spatial distribution and temporal variability of penetrating electrons and high-energy protons. The co-temporally measured spatial distribution of energetic charged particles across the evolving dimensions of the EDSN array will provide first measurements of spatial coherence. In addition, temporal variations between successive measurements will characterize intensity variations of more than an order of magnitude that are known to occur in the radiation field over periods as short as minutes to hours. Together the ability to characterize both spatial and temporal variations allows spatial-temporal variations to be unraveled. The expected outcome would be a worldwide, low-latitude radiation map. Customary measures of solar activity, such as sun-spot number, flares, or CME's are poor predictors of the radiation environment above the atmosphere. Even geomagnetic storm activity is an unreliable indicator of the penetrating radiation intensity. Thus, the EPISEM instrument will measure in-situ radiation intensity instantaneously at the location of each spacecraft.

Specific mission objectives: The EPISEM will measure the omnidirectional integral flux concurrently at the spacecraft to answer questions like: What are the fundamental exposure rates of spacecraft avionics to radiation from penetrating electrons and high-energy protons in LEO ?

• EPISEM provides constant radiation measurements for each identical spacecraft

• SEUs (Single Event Upsets) on all or each spacecraft may be correlated to the radiation flux measured by each EPISEM

• 54% in the SAA (South Atlantic Anomaly)

• 26% in the Polar Regions

• 20% Galactic Cosmic Rays

• What are the temporal dependencies?

• What are the small scale spatial dependencies?

EDSN_Auto5

Figure 9: Illustration of SEUs in the MOPITT instrument on NASA's Terra spacecraft (image credit: University of Colorado)

 

Instrument design:

• EPISEM employs an thin-walled Geiger-Mueller tube located inside the spacecraft structure.

• Detects penetrating beta/gamma radiation from energetic particles above a certain energy threshold.

• Specific energy threshold is different for electrons and protons.

EDSN_Auto4

Figure 10: Schematic view of interactions in the Geiger-Mueller tube of the EPISEM (image credit: MSU)

• Incoming radiation knocks electron off of the Neon fill gas.

• Neon becomes Ne+ and free electron avalanches toward anode.

EDSN_Auto3

Figure 11: Photo of the EPISEM instrument (image credit: MSU)

Development status: In 2013, all EPISEM devices were delivered to NASA/ARC.

 


 

Project development status and lessons learned

In August 2013 the project went through a rebaseline and was scoped to the mission goals and objectives presented in the earlier section (Ref. 1). The satellite development went from concept to completion in 8 months. The Flight satellites were completed in March of 2014 and are currently in long-term storage until launch in late 2014 (Ref. 5).

The EDSN mission is unique in that it has a technology demonstration that includes multiple satellites using low cost consumer grade COTS components with some custom parts needed to increase performance or due to packaging constraints. The EDSN mission uses a risk posture comprised of decoupled objectives, multiple attempts at technology demonstration, redundancy through a number of units and the focus on systematic failures versus any and all failures. Consequently, the constellation was designed to operate even with the loss of a single or multiple satellites without affecting mission success. Examples of this approach include multiple data paths for science and SOH (State of Health) data, the ability to miss ground station contacts and designing the inter-satellite data transfer architecture where the goals was to demonstrate the ability rather than focus on high performance or efficiency.

The EDSN project used concurrent engineering, multiple development paths, additional processes and increased the number of EDUs (Engineering Development Units) to reduce the development time over a traditional CubeSat flight project. To achieve the development of the 8 final Flight units, a total of 12 Flight units, 4 EDUs, 2 Flatsats, 2 DevSats and spare components/subassemblies were produced. The multitude of units allowed for concurrent developments in all areas including hardware, software, procedures, integration and testing. The EDSN project also took some development risks including reduced design analysis versus early testing, postponing the majority of environmental testing to the system level and single batch fabrication of printed circuit boards PCB rather than the traditional multiple spins.

Processes adopted by EDSN to facilitate the production, tracking and testing of the components and subassemblies for each of the Flight, EDU and Flatsat units included; procuring units in large (>20) quantities with spares, major components/subassemblies having individual travellers, assignment of components based on performance, inventory tracking and a process flow that was available to all team members and continuously updated daily. To manage the amount of units and staff a detailed schedule was developed and updated daily with conflicts addressed in 15 minute daily tag ups or handled in real time by the Systems Engineering and Management team.

The Systems Engineering and Management team reviewed the schedule daily for both short and long term milestones addressing long lead, facility or resource conflicts early before impact to the daily project progress. Leads for key areas: communications, electrical, software, mechanical, systems engineering, GSE (Ground Support Equipment) and I&T (Integration & Testing) were responsible and accountable for their areas, tasks and staff. All leads provided notification of possible impacts to their work and new resource needs in the daily tags with a weekly meeting used to address upcoming tasks and milestones. Late task or impacts had to be negotiated with affected areas/team members and a recovery plan identified and implemented with Management and Systems Engineering concurrence. While issues still arose throughout the project due to conflicts, anomalies or unanticipated tasks, these processes were effective at reducing their impact to the project schedule.

The multitude of units and concurrent development paths required a flexible staff loading where part time labor was leveraged from other work areas at NASA/ARC. An example of this was the increase in staff during the PCB testing. Each satellite consists of 6 solar panel PCBs and 9 internal PCBs that are mated to other components, such as the radios and reaction wheels, to make up 10 subassemblies. For the development of the Flight Units, EDUs, Flatsats and spares a total of 24 or more boards were fabricated for each of the 15 different PCBs, resulting in more than 360 boards, that were each individually inspected and tested. To facilitate testing on this scale for spaceflight, procedures were developed and GSE acquired to allow testing by multiple teams concurrently.

The EDSN satellite uses a variety of readily available consumer grade COTS processors combined with a Nexus S phone. During development, the project was able to buy low cost developer kits for each processor that could be quickly wired together similarly to the satellites. These units were called DevSats (Development Satellites) and an example is shown in Figure 12. DevSats provided opportunities for early FSW (Flight Software) prototyping, development and testing prior to EDU or Flight units being available. Since the same processor set and interfaces were being used, the amount of modifications to the FSW was extremely limited when switching to the actual hardware configuration.

EDSN_Auto2

Figure 12: The EDSN DevSat during early flight software development and testing; note the Nexus S phone and consumer grade developer boards (image credit: NASA/ARC)

During the EDSN development, the PCBs were limited to one production run which meant that all boards were identical excluding minor tracked revisions. This meant that the boards in the Flight units were the same as the EDUs and Flatsats. This approach added risk to the development, but also provided a benefit to the EDUs and Flatsats, ensuring a consistent configuration and operation when performing hardware, software and functional testing.

The Flatsats were developed to test the large amount of boards and enable probing of the data lines that would normally be inaccessible in the densely integrated EDUs or Flight units. The satellite backplane PCB was replaced with a custom Flatsat PCB that enables connection of PCB and subassemblies using the same data paths, the large green PCB shown in Figure 13. In addition data and power can be enabled, disabled and probed for electrical and software testing. The Flatsats were instrumental in FSW testing including anomaly resolution, off-nominal conditions and regression testing for FSW releases. The Flatsats also allowed for detailed electrical checkouts and proof/over testing of one set of PCBs prior to Flight unit integration. An example was a quick swap of payload boards that allowed the team to troubleshoot bad command timing issues with the EPISEM interface.

EDSN_Auto1

Figure 13: The EDSN FlatSat interfaced to numerous EDSN PCBs used during electrical checkout and flight software testing. A partial EDSN DevSat is also shown in the rear left (image credit: NASA/ARC)

The EDUs are almost identical to the Flight units, excluding minor configuration revisions. EDUs 1&2 also lacked antennas, and instead used RF cabling and attenuators to enable direct connections to the transceivers for RF (Radio Frequency) testing. The EDUs served multiple purposes during the project development, including fit check, early system testing, test procedure maturation for Flight units, GSE interface, system checks and early mission simulations, while the Flight units were undergoing integration and testing. Early in the project, numerous competing resources were identified, especially related to the EDUs. Consequently, the number of EDUs was increased to 4 units. The EDUs underwent early fit checks, interface checkout and environmental testing with issues addressed prior to the integration of the Flight unit subassemblies. In addition, the EDUs provide a method for testing flight software releases and mission simulation operation prior to FSW releases and integration with the Flight units.

The Flight units incorporated minor revisions based on the lessons learned from the development of the Flatsats and EDUs. Twelve Flight units were developed to provide flight spares and allowed the selection of the highest performing units for flight. Although identical, very minor production and workmanship effects resulted in slight increases in performance for the transceivers, power generation and the attitude control system. Originally ,the later EDUs were to be used as qualification units, but as issues and anomalies were identified, there were increased needs for additional EDUs. Flight units 1 & 2 were developed first and performed qualification testing prior to the completion of Flight units 3 through 12.

 

Lessons Learned:

The unique and compressed development of EDSN resulted in many lessons learned including things to avoid and items that can be beneficial to future projects. Procedures provided both of these attributes. With a large team involved and substantial part time labor, procedures were required to perform testing of the PCBs, subassemblies and integrated satellites. However, the time and consequently cost required to develop the procedure sometimes caused delays to the project. Procedures for key tests were essential, especially for functional and environmental testing. However, procedure writing needs to be balanced against the amount of effort to perform the test or integration task. Procedures were used heavily for Flight units but there were numerous tests of engineering units that were outlined, performed and documented with a test report. In the case of EDSN, often the designer was not able to perform testing of all the components. This required greater procedural detail than if the designer was performing the test himself. Review at the system level of the procedures also provided benefits as missed verification items and tasks needed for other technical areas were caught before the tests were conducted, reducing the amount of retest.

Future projects with this many components and units should consider implementing automated testing processes as there is a large potential benefit from the reduction of time and consistency in test results.

EDSN_Auto0

Figure 14: The 8 EDSN Flight units combined with flight spares and EDUs (Engineering Development Units), image credit: NASA/ARC

To track the large amount of components, subassemblies and units, travellers were used for all major elements and incorporated into the higher level traveller at the various integration steps. The travellers included information on tasks, date performed, task executor, firmware/software loads, if any issues arose during testing or anomalies and workmanship problems were identified. The travellers were extremely useful for tracking the hardware elements especially when selecting elements for the Flight units. The travellers were documented on paper and were difficult to track at the system level. A configuration matrix was used for checking in and out items and process flow checklist were used to ensure steps in the I&T process were not missed.

Future projects should consider using an electronic inventory system that provides more realtime data without additional manual data entry overhead. Systems to consider include barcodes, QR (Quick Response) code, RFID (Radio Frequency Identification) tags and/or future AIDC (Automatic Identification and Data Capture) technologies.

During project development, multiple descope options were evaluated throughout the project cycle and communicated with stakeholders prior to implementation. Examples of descopes considered for EDSN include; reducing the number of spare units, flying EDUs, tailoring of the test plan, early environmental tests versus detailed design analysis, limited environmental testing at the component and subassembly levels, single tests for an EDU versus all units, reduced performance, elimination of objectives, reduction in minimum success criteria and elimination/re-ordering of development tasks.

Not all these descopes were implemented, but having a detailed schedule as a daily tool and these options enabled the management and Systems Engineering team to make tough decisions based on current and accurate data. Descopes that were implemented include; tailoring of the test plan, early environmental tests versus detailed design analysis, limited environmental testing at the component and subassembly levels, single tests for an EDU versus all units and re-ordering of activities such as the first Flight units becoming qualification units for environmental testing. It is highly recommended that projects identify credible descopes and engage stakeholders for input early in the project before they are required so when issues arise the project can recover and there are no surprises for stakeholders.

Updating documentation in real time was difficult due to the fast project pace. This required other communication efforts and a large amount of time from systems and interface personnel to ensure team members were on same page. This sometimes resulted in missed or misinterpreted information and repeated discussion on the same topic. The project addressed these issues as they developed by co-location of the team, positioning engineering and testing facilities together and providing area leads with responsibility to communicate changes or issues to their sub-teams.

During the project, there was a significant need for GSE (Ground Support Equipment) used for integration and testing of the many units. Standard test equipment such as multi-meters and power supplies were in high demand throughout the project. Rather than buy a large amount of equipment for short durations, it was more economical to rent, especially in the case of the complex test equipment such as signal analyzers, that are expensive but only needed for short periods of time. In addition emphasis should be placed on planning for GSE cables, computes, connectors, software licenses and other minor items. For these inexpensive items, it is recommended that projects buy with margin in many cases twice as much as you think you will need as the lost time far exceeds the small procurement costs. Many of these items can also be repurposed for future projects.

To reduce the development schedule to 8 months, the EDSN project borrowed heavily from the design architecture of the Phonesat project. This had the benefit of reducing the amount of needed design time, but it also inherited the design issues and introduced new issues from extending the architecture not originally intended for the more complex mission and satellite interactions. In addition, the functional decomposition and requirements development process was abbreviated and incomplete, resulting in difficulties during test planning, verification and validation. The project focused on functional testing and relied heavily on the mission simulations that occurred late in the project development for verification and performance evaluation.

Software maturation issues combined with late testing anomalies resulted in a late FSW build after the completion of environmental testing. FSW regression testing and an additional long duration (~12 day) mission simulation test were conducted on the Flight units, to ensure verification and performance and reduce the risk of new errors introduced by the late flight software changes. During development, some lower level tests were never linked to higher-level requirements, and as a result, the team collected test data that was not useful. An example of this is that a lot of the battery pack test procedure was not helpful in evaluating the actual battery performance and additional retests had to be performed later in the project. Future projects should focus on collecting data linked to higher level requirements to further streamline the integration and test process.

A key component to a fast paced and compressed duration project is to ensure all stakeholders are well informed, consulted and able to assist with resources if needed. EDSN used an inchstone schedule, with weekly milestones, that were reported currently to stakeholders at a single weekly meeting. The weekly meetings included: a schedule overview, major accomplishments, weekly progress of milestones, next week milestones, resolution of any missed milestones and identification of any higher level issues. A combined weekly meeting with stakeholders ensured information, decisions and issues could be coordinated and addressed without the delaying of communicating with multiple parties. This ensured efficient and timely decision making and also reduced the over project reporting requirements.

Early in the development, multiple competing critical paths were identified including the flight software and PCB developments. To reduce the schedule, several items were implemented including leveraging the Phonesat architecture, multiple EDUs, Flatsats and a risk posture of a single production run of the PCBs without the usual multiple board spins. PCB production had each type of board fabricated in a single lot, then one of the boards was fully assembled and inspected prior to assembly of the remaining boards. The PCB designers took this risk into account and reviewed the designs prior to fabrication and also provided descope opportunities in the design, where areas or functionality in the circuits could be reduced or eliminated by the removal of simple components without requiring a new PCB production or cutting of traces.

This worked effectively when combined with early Flatsat and EDU testing to identify issues and perform configuration revision prior to Flight unit builds. However, the rework and revisions required to the flight boards consumed significant resources of the project and delayed integration and testing activities. Although this single production run approach reduced the schedule in comparison to multiple board productions, it was not optimal and some non-critical functionality was lost. Other issues required work-arounds in software or accepting known issues. Future projects should evaluate the test and rebuild trade-off early in the project planning phase.

It is recommended that future projects plan for functional and environmental testing early in the process, including interfaces and functionality that is required on the satellite for I&T, but not necessary for flight. The EDSN project had incorporated many aspects in the design for testing, including LEDs for visualization, test points, and FSW that enabled interfacing with the various processors and the ability to change firmware if necessary. However, an oversight in environmental testing meant there was not an easy way to electrically deactivate the satellite during thermal vacuum testing. This resulted in a late design kludge before the production of the Flight units and required additional GSE workarounds that caused an impact to the project schedule.

Another example was that GSE software was necessary to perform integration and testing activities, but the FSW became the project critical path and so the resources intended to develop GSE software were consumed with FSW development tasks. A consequence of this was that numerous anomalies were observed during testing that had to be investigated and resolved, with several of them related to GSE software operations that were not exhaustively tested prior to hardware testing.

 

Anomalies and resolutions:

During any project there are always issues and anomalies that occur and EDSN was no exception. Several EDSN anomalies and resolutions are presented here to advise future projects and raise awareness for future Cubesat and multiple satellite missions.

With hardware based projects, there is the possibility of workmanship issues that can arise during fabrication and integration. EDSN had a few issues including incorrect part placement, polarity switches and cable shorts. EDSN took a proactive approach to the workmanship processes and included a quality and mission assurance program including training, review before production, receipt inspections of components, functional tests at multiple steps of the test flow, procurement of spare/replacement components, use of procedures and a two person system for testing of Flight units. These actions meant, that issues were identified early in process and could be rectified before satellite integration or environmental testing where they would cause major schedule impacts to the project. The spare parts also enabled failed components to be swapped out with minor impact.

EDSN made use of a large amount of low cost consumer grade COTS components to enable rapid and cost effective development, but this also caused its own type of issues. A particular example on EDSN was the issues relating to the male and female connector used between the PCB, cables and backplane. The connectors sometimes had intermittent contact, or alignment issues, that required rework. Future projects should consider using higher-grade (automotive or industrial) components that undergo more rigorous testing and batch inspection. Although there is an increased cost per component and in sometimes leadtime, these are offset by the high cost of schedule impacts that can potentially be incurred due to team down time. Another process used by EDSN that was successful, was full testing/screening of critical components/subassemblies prior to integration at the system level.

The EDSN satellites use a diagnostic port that allows for data interface and battery charging during I&T activities. The port is cycled numerous times during the test flow and during the EDU test program, it was identified that one of the ports was beginning to separate the mechanical ground connectors from the PCB. To alleviate these issues and protect the access port, a strain relief connector saver was implemented for the Flight units to significantly reduce the number of mate/demate cycles for the diagnostic port. With the compact nature of Cubesats, it is not always possible to implement connector savers, but future projects should consider their implementation for external access ports.

During the testing of PCBs, the project was having issues with MOSFETs, that were used for switching of power and data lines. During testing, the team was finding several failures >1%, where it would normally expect failures in the parts per million. These component failures were so prevalent in the design and a systematic issue, that a decision was made to replace these components with a different part from a known reliable vendor with internal ESD protection. The root cause was never determined and no further issues were observed after the change in component. Future projects should be careful to ensure, the components meet the requirements including worst case specifications, include ESD protection, or other similar attributes and most importantly are sourced from reputable known vendor that has previous flight heritage.

During the rapid development of the design, some assumptions were made on the hardware, that were not communicated to the FSW team, that resulted in unused connections and/or undefined inputs/outputs. EDSN resolved this issue by eliminating unnecessary connections and ensuring, that there were no floating or undefined values in the software. Future projects should ensure that hardware designs and software implementation assumptions are communicated, and where appropriate, reviewed by an engineer with both software and hardware experience. This is especially true, if the project is inheriting an existing software or hardware architecture.

Similar to any software project bugs and unintended features were encountered during testing. EDSN concurrently developed the hardware and software and used several processes successfully to reduce the impact of FSW bugs and unintended features. JIRA was used by the FSW development team for tasks, bug tracking and included custom fields for unit and system testing. In addition, static analysis tools and peer reviews were performed on flight software against the requirements, to identify poor coding practices and ensure system functionality. Early prototyping and testing on relevant hardware, including the DevSats, Flatsats and EDUs, also reduced the instances of bugs and development time. A central repository with subversion tracking and virtual machines were used to ensure consistent and concurrent software development.

As new software releases became available, processes for loading, verifying and tracking the versions became necessary. EDSN successfully used travellers and procedures to accomplish these processes. In addition, a set of regression tests, tied to low-level functional requirements, was used to ensure the performance prior to a software release.

 

During the development, a Zener diode was implemented to prevent an over voltage condition to the bus. To charge the satellite, a diagnostic port is used that feeds power through the Zener diode that clamps at a set voltage and dissipates excess energy when the battery is full. During TVAC (Thermal Vacuum) testing, the satellites used external power supplies in combination with batteries, as there was not a system available to provide solar flux and therefore power through the solar panels. The Zener diode was not accounted for during TVAC test planning and during test operations, there was an additional thermal load that was being provided by the Zener diode. EDSN had used test predicted values and observations of the key components, to enable early identification of problems during the test, and were able to provide a work around in real time, rather than having to rerun the test. Future projects should ensure for key tests, that predicted performance is known before the test commences, accounts for GSE interactions and that late design changes are considered for impact, not only to the flight system, but also testing (Ref. 5).

 


1) Jim Cockrell, Richard Alena, David Mayer, Hugo Sanchez, Tom Luzod, Bruce Yost, D. M. Klumpar, "EDSN: A Large Swarm of Advanced Yet Very Affordable, COTS-based NanoSats that Enable Multipoint Physics and Open Source Apps," Proceedings of the 26th Annual AIAA/USU Conference on Small Satellites, Logan, Utah, USA, August 13-16, 2012, paper: SSC12-I-5, URL of paper: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=1095&context=smallsat, URL of presentation: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?filename=0&article=1095&context=smallsat&type=additional

2) "Small Spacecraft Technology," NASA Town Hall Meeting, 2012 Small Satellite Conference, Utah State University, August 13, 2012, URL: http://www.nasa.gov/pdf/675932main_SmallSat_presentation_8_2012_Petro.pdf

3) "Edison Demonstration of Smallsat Networks Mission - A Swarm of Advanced, Affordable, COTS-based Nanosatellites that Enable Cross-Link Communication and Multipoint Physics," NASAFactsheet, URL: http://www.nasa.gov/sites/default/files/files/EDSN_FactSheet_031014.pdf

4) "Edison Demonstration of Smallsat Networks (EDSN)," NASA, May 3, 2013, URL: http://www.nasa.gov/directorates/spacetech/small_spacecraft/edsn.html-#.U4grK3bwUkA

5) James Chartres, Hugo Sanchez, John Hanson, "EDSN Development Lessons Learned," Proceedings of the AIAA/USU Conference on Small Satellites, Logan, Utah, USA, August 2-7, 2014, paper: SSC14-VI-7, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=3106&context=smallsat

6) John Hanson, James Chartres, Hugo Sanchez, Ken Oyadomari, "The EDSN Intersatellite Communications Architecture," Proceedings of the AIAA/USU Pre-Conference: CubeSat Developers' Workshop, Logan, Utah, USA, August 2-3, 2014, paper: SSC14-WK-2, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=3003&context=smallsat

7) Robert F. Coker, "Thermal Modeling in Support of the Edison Demonstration of Smallsat Networks Project," 2013, URL: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20140002606.pdf

8) Stephen Clark, "Debut flight of rail-guided space launcher slips to October," Spaceflight Now, March 23, 2015, URL: http://spaceflightnow.com/2015/03/2-3/debut-flight-of-rail-guided-space-launcher-slips-to-october/

9) Mike Gruss, "Despite Uncertain Future, ORS Office Has Missions To Work On," Space News, April 28, 2014, URL: http://spacenews.com/40368military-space-quarterly-despite-uncertain-future-ors-office-has/

10) Doug Messier, "ORS, University of Hawaii Team Up on New Small Satellite Launcher," Jan. 26, 2013, URL: http://www.parabolicarc.com/2013/01/26/ors-university-of-hawaii-team-up-on-new-small-satellite-launcher/

11) Mike Gruss, "Rail-launched Super Strypi Rocket Packed with Cubesats Fails in Debut ," Space News, Nov. 4, 2015, URL: http://spacenews.com/rail-launched-super-strypi-rocket-packed-with-cubesats-fails-after-liftoff/

12) Patrick Blau, "Debut Launch of Super Strypi Rocket fails during First Stage Flight," Spaceflight 101, November 4, 2015, URL: http://spaceflight101.com/debut-flight-of-super-strypi-rocket/

13) "Update on Launch of Edison Demonstration of Smallsat Networks (EDSN)," NASA7ARC, Nov. 4, 2015, URL: http://www.spaceref.com/news/viewsr.html?pid=-48074

14) https://ssel.montana.edu/printsat.html

15) Joe Maly, "CubeSat Payload Accommodations and Propulsive Adapters," Proceedings of the 11th Annual CubeSat Developers' Workshop - The Edge of Exploration," San Luis Obispo, CA, USA, April 23-25, 2014, URL: http://www.cubesat.org/images/cubesat/presentations/DevelopersWorkshop2014
/Maly_CubeSat_Payload_Accommodations.pdf

16) "Nanosatellite Launch Adapter System (NLAS)," NASA, August 30, 2013, URL: http://www.nasa.gov/centers/ames/engineering/projects/nlas.html#.U3HimHaegZM

17) Adam Gunderson, David Klumpar, Matthew Handley, Andrew Crawford, Keith Mashburn, Ehson Mosleh,Larry Springer, James Cockrell, Hugo Sanchez,Harrison Smith,"Simultaneous Multi-Point Space Weather Measurements using the Low Cost EDSN CubeSat Constellation," Proceedings of the 27th Annual AIAA/USU SmallSat Conference, August 29, 2013, , paper: SSC13-WK-41, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?filename=0&article=2904&context=smallsat&type=additional
 


The information compiled and edited in this article was provided by Herbert 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).

Overview    Spacecraft    Launch    Sensor Complement   Project Status    References    Back to top