Skip to content
eoPortal

Satellite Missions Catalogue

NODES (Network & Operation Demonstration Satellite)

Sep 23, 2016

Non-EO

|

NASA

|

ARC

Quick facts

Overview

Mission typeNon-EO
AgencyNASA, ARC
Launch date06 Dec 2015
End of life date02 Jun 2016

NODES (Network & Operation Demonstration Satellite) Mission

Overview   Spacecraft   RF communications concept   Launch    Mission Status   Sensor Complement
References

NODES is a pair of 1.5U CubeSats developed by NASA/ARC (Ames Research Center) under the SSTP (Small Spacecraft Technology Program) within STMD (NASA Space Technology Mission Directorate). The objective of the NODES mission is to expand the utility of small spacecraft networks and to explore issues related to the command and control of swarms of multiple spacecraft making synchronized, multipoint scientific measurements. Networked swarms of small spacecraft will have capabilities to make spatially distributed measurements of time varying systems and provide large apertures that cannot be achieved using traditional, large single spacecraft. While these swarms have great potential, they create new challenges to the CubeSat community related to managing large numbers of spacecraft in close proximity. 1) 2) 3)

The NODES mission addresses these challenges through three primary technology demonstration objectives. The NODES spacecraft will autonomously self-organize, selecting which spacecraft will lead the swarm, collect data and pass those data to the ground, all based on the states of the spacecraft. It will also demonstrate the commanding of spacecraft in a swarm, from the ground and through the network. Finally, NODES will make synchronized, multi-point science measurements of the Earth's charged particle environment.

Networked swarms of these small spacecraft will open new horizons in astronomy, Earth observations and solar physics. Their range of applications include the formation of synthetic aperture radars for Earth sensing systems, large aperture observatories for next generation telescopes, and the collection of spatially distributed measurements of time varying systems, probing the Earth's magnetosphere, Earth-Sun interactions and the Earth's geopotential. Similar swarms can be used to explore the properties of other planets, comets and near-earth asteroids. 4)

Not only do swarms of small, relatively low cost spacecraft enable missions that simply cannot be performed with single, large spacecraft, these swarms are inherently robust against random failures. If properly designed, the swarms can be regularly updated with improved technologies and different payloads by simply launching new spacecraft to join an existing swarm, providing continuous improvements to the mission.

To field swarms of tens or hundreds of small spacecraft, new communications concepts will need to be developed to control the movement of data within the swarm and with the ground, pass commands between spacecraft and generally manage the swarm.

NODES mission: The NODES communications network (Figure 1) is maintained and operated by a simple set of predefined rules operating independently on both spacecraft without direction from ground based systems. One spacecraft (the Captain) serves as a central node, requesting and collecting data from the other spacecraft (the Lieutenant), organizing the data and passing them to a ground station at regular intervals. The Captaincy at the start of each cycle is rotated between the spacecraft on a regular basis, demonstrating robustness against the failure of a single spacecraft.

The goal of the NODES mission is to demonstrate the operations of spacecraft swarms, while also showing that a swarm of satellites can make spatially distributed, time correlated science measurements and transfer the data to the ground (Ref. 4). This includes the following 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 the ability to control a swarm of spacecraft by routing commands from the ground through the space network

4) Flight demonstrate the ability of a swarm of spacecraft to self-configure.

In addition, NODES will contribute to the understanding of the charged particle environment in LEO (Low Earth Orbit) by making multiple, simultaneous measurements of the charged particle event rate at each spacecraft, distributed tens to one hundred kilometers apart.

Figure 1: NODES communications concept (image credit: NASA/ARC)
Figure 1: NODES communications concept (image credit: NASA/ARC)

 

Spacecraft

The NODES "swarm" mission consists of two 1.5U nanosatellites each with a mass of 1.7 kg and measuring 10 cm 10 cm x 17 cm. The NODES spacecraft are based on the hardware and software developed for the EDSN (Edison Demonstration of SmallSat Networks)mission, a swarm of eight spacecraft, using extra hardware from the EDSN build. The design was modified to meet the requirements of launch from the International Space Station using the NanoRacks deployer. This included modifications to the battery charging circuit, extra testing of the Li-ion batteries and the installation of two rail switches to prevent spacecraft power-on before deployment.

Note: The swarm of 8 EDSN nanosatellites was launched as secondary payloads on Nov. 4, 2015 on the ORS-4 (Operationally Responsive Space-4) mission of DoD on the Super Strypi vehicle from the PMRF (Pacific Missile Range Facility) Barking Sands of the US Navy, located on the Hawaiian island of Kauai. Unfortunately, the Super Strypi launch vehicle experienced a launch failure about 1 minute into the flight.

The EDSN/NODES spacecraft design leverages COTS (Commercial off-the-Shelf) components where possible to keep the recurring bus costs down, providing a basis for future multispacecraft missions. Furthermore, this approach allowed the EDSN and NODES teams to use some existing test equipment and software, reducing the amount of custom GSE (Ground Support Equipment) that might otherwise have had to be developed for the program. Some key subsystems of the NODES spacecraft use existing PhoneSat 2.0 hardware and software (e.g. the Nexus S processor board) further reducing cost by using existing, proven hardware and software. Both the NODES spacecraft and the PhoneSat 2.0 hardware were developed by NASA/ARC (Ames Research Center).

Each spacecraft (Figure 2) consists of a stack of eight PCBs (Printed Circuit Boards) and a battery pack that plug into a common PCB 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.

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

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 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 NODES 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.

EPS (Electrical Power Subsystem): 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 NODES as the solar panels provide an orbit average power of just one watt. Solar power is provided by six solar panels that use Spectrolab TASC (Triangular Advanced Solar Cells). Electrical energy storage of 5.2 Ah is provided by four lithium-ion 18650 batteries in a COTS holder. The COTS battery holder provides for battery control, battery overcharge protection and bus voltage regulation. A Zener diode is needed to provide over-voltage protection for the bus. The EPS board operates the solid state relays and provides power to onboard systems. When the battery voltage falls below seven volts, all non-essential subsystem are turned off and the spacecraft goes into its low-power "wait" mode. The spacecraft remains in "wait" mode until the battery voltage exceeds eight volts.

ACS (Attitude Control Subsystem): The ACS uses magnetic control 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 PCBs (Printed Circuit Boards) are used for control. A NovAtel OEMV-1 GPS receiver is used to get position, velocity and time fixes approximately once every 25 hours.

RF communications: The NODES communications subsystem uses three radios to perform three different tasks. Intersatellite communication (crosslink) is performed with an Astrodev (Astronautical Development, LLC) Lithium 1 UHF transceiver, attached to a deployable tape-measure monopole antenna. Crosslink occurs at 1200 bit/s under the AX.25 protocol with 1W transmitted power. The Astrodev receiver is only powered when a crosslink has been scheduled. A MicroHard MHX2420 transceiver is used for S-band downlink to the ground. 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.

 


 

RF Communications Concept

NODES builds on the simple EDSN command/response concept for its intersatellite and space-to-ground communications network. The protocol ensures that only one spacecraft utilizes the channel at a time and that packets are validated upon reception. Using this protocol, the sender sends commands to the receiver and the receiver responds with either an acknowledgement or data. If the receiver does not receive a command from the sender it will continue to wait until a valid command is received. If the sender does not receive a response before the timeout, the sender will retransmit the packet. This command/response protocol is used to send network commands and request data within the network. 5)

In order to implement swarm communications, a custom protocol was designed specifically for the operation of multi-spacecraft swarms when subject to the constraints typical of CubeSat buses and programs. The EDSN/NODES communications system 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. For the NODES mission, there are two spacecraft, so the Captain collects data from just one Lieutenant.

The process of passing information from the Lieutenant (LT) to the Captain (CPT) is called a "transaction". A transaction is separated into two sections, network commanding and network data transfer. Network commands start at the ground station and are uplinked to the CPT using the command/response communication protocol until the captain responds with an acknowledgement. The acknowledgement indicates the successful reception of the command by the captain. Once the command is received, the command will be saved in a queue and will be forwarded to the LT during the next crosslink activity using the Lithium crosslink radio. If there are commands stored in the queue at the start of the network commanding transaction section, then each command will be forwarded to the LT over the crosslink until a valid acknowledgment is received or the packet time out is reached. When the command is received by the LT, the LT will acknowledge the receipt of the command, execute the command and generate a command status packet.

The network data section of a transaction begins when the CPT sends a "ping packet" to the rest of the swarm (in this case just the other NODES spacecraft) 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 12 pings over a period of 110 seconds to the 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 12 pings over 110 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. By giving each spacecraft a unique identifier (J and K), only one LT is authorized to transmit data at a time. This prevents the LT's 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 120 seconds to allow the CPT to stop sending "pings". It then sends 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 and command status packets that are stored in the LT's queue, as shown in Figure 3. Once the LT has transmitted all of its data, it turns off its Lithium radio, ends its crosslink activity and deletes the state-of-health 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 during the data exchange. If a data packet is not received by the CPT, it is lost. This is acceptable for NODES 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. As will be discussed below, 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 delay tolerant networks. 6)

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

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 4). 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.

The default "Captaincy" of the NODES swarm is rotated amongst the spacecraft in a present pattern (J-K-J-K-.....) so that each spacecraft has the opportunity to be CPT. 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. The GPS time is compared to preloaded table of time windows given in UTC (Coordinated Universal Time) to determine which spacecraft is the default 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, negotiation or science data collection).

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

The Captaincy for the minor cycle is then negotiated between spacecraft in the swarm based on a predefined set of metrics. These metrics include the amount of data to downlink, the battery voltage, and the ground pass duration. At the start of each minor cycle a default CPT is selected. The default CPT will execute the negotiation activity during the first crosslink of the minor cycle. The CPT will request the metric from the LT and compare the received metric to its own metric. If the LT's metric is better, the CPT will send a promote command to the LT. When the LT receives the promote command, the current LT will beacon the CPT and the current CPT will be demoted to LT.

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 5). First, the SOH (State-of-Health) 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 J and proceeding through all other spacecraft. 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.

Figure 5: Communications timing diagram (image credit: NASA/ARC)
Figure 5: Communications timing diagram (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 one watt orbit average for NODES). 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 NODES communications architecture avoids this problem by having all NODES 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 NODES 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 6 shows the sequence of events that make up a crosslink session, including the overlap of receiver on-times.

 

Figure 6: Negotiation process diagram (image credit: NASA/ARC)
Figure 6: Negotiation process diagram (image credit: NASA/ARC)

At some point in every minor cycle, before the crosslink sessions are scheduled, a negotiation activity is initiated by the default Captain with the Lieutenant spacecraft using the Lithium crosslink radios. The purpose of this activity is to determine which spacecraft is best suited to be Captain during the minor cycle. The default Captaincy is defined before launch based on time and changes every 25 hours. The sequence of events that make up the negotiation activity are shown in Figure 7.

First, the default Captain sends a "request" to the Lieutenant for negotiation data: the number of data packets ready for download and the spacecraft battery voltage. When the Lieutenant received the request, it responds with a packet of negotiation data. If the Captain does not receive a response, it will continue to send requests until it times out, at which point the negotiation will be deemed "failed" and the default Captain will remain Captain for the duration of the minor cycle. If the negotiation data are received, the default Captain will compare the spacecraft states to determine which spacecraft should be Captain. If the Lieutenant has more data to be sent to the ground, or the same amount of data, but a higher battery voltage, the Captain will "promote" the Lieutenant to Captain by sending a "promote" message. Upon receiving the message, the Lieutenant will take over duties as Captain and respond with an acknowledgement. Upon receiving the acknowledgment, the default Captain demotes itself and performs the duties of the Lieutenant for the duration of the minor cycle. If the Captain does not receive an acknowledgement, it will continue to send the "promote" message until the session times out. If it does not receive an acknowledgement message, it will assume that the Lieutenant never received the "promote" message and continue on as Captain. The Captain/Lieutenant status is reported in the beacon packets as well as in the downlinked SOH packets.

Figure 7: Groundlink command diagram (image credit: NASA/ARC)
Figure 7: Groundlink command diagram (image credit: NASA/ARC)

The NODES spacecraft have the ability to pass spacecraft commands from the ground, through one spacecraft to the target spacecraft, as shown in Figure 8. A spacecraft command for the Lieutenant spacecraft is sent from the ground to the Captain. The Captain places the command in a buffer and acknowledges command receipt back to the ground. At the next available crosslink session, the Captain will send all commands in its buffer to the Lieutenant. It will continue to send the commands until it receives an acknowledgement, or the crosslink session times out. When the Lieutenant receives the command, it responds to the Captain with an acknowledgement message and then executes the command, increments some internal counters for the beacon and state-of-health messages and creates a data packet with the results of the executed command.

Figure 8: NODES communications data structures (image credit: NASA/ARC)
Figure 8: NODES communications data structures (image credit: NASA/ARC)

Software implementation: The NODES software was implemented on three processors on the spacecraft. Code on the Arduino microcontrollers perform low-level tasks such as interfacing with hardware and monitoring the battery voltage. Special software on the Propeller chip provides data packet routing services on the spacecraft bus. The most critical software, in terms of the implementation of the NODES communications architecture, resides on the Nexus S processor – the "Phone". This software is an autonomous application built on top of the Android operating system. Leveraging the Android software tools and development base helped to simplify the design and decrease development time.

The NODES spacecraft operate autonomously and do not require intervention from the ground to function properly. The only commands that can be sent from the ground are a radio disable command that turns off all transmissions from the spacecraft (required by the FCC and is not part of normal operations) and the network command that is routed from the CPT to the LT as one of the mission objectives.

The NODES application creates a schedule of "activities" with start times and durations. It then executes those activities through the PhoneSat Executive, its main thread. The Executive also determines when the phone should be off, passing control of the spacecraft and a time to turn the phone back on to the EPS Watchdog.

There are several key activities that NODES uses to implement the communication system. These include science data collection, downlink, crosslink, GPS acquisition, and planning.

The downlink and crosslink activities are discussed in detail above. Central to the operation of the downlink and crosslink activities are a set of data structures (stacks and queues) that store the data packets sent through the network. These were implemented as shown in Figure 7 and are described above in greater detail.

Prior to the start of a minor cycle, a GPS acquisition activity will have been scheduled. After the Executive runs that activity, the GPS state (position, velocity and time) will fed into an orbit propagator that will predict the position of the spacecraft as a function of time over the next two minor cycles (roughly 50 hours). Using the propagated orbit the satellite is able to schedule a set of activities based on predefined metrics and a priority list. Some activities are scheduled based on time while others are scheduled based on the time at which the spacecraft is predicted to be at a particular position. The crosslink activity is a time based activity and occurs at a fixed time offset from the beginning of the minor cycle. On the other hand, the downlink and science collection activities are position based activities.

For each activity the satellite generates a table of opportunity windows that state when it is possible for a particular activity to take place. Then based on priority of the activity, the activities are scheduled such that their opportunity windows do not overlap. Once the schedule is generated the executive starts and stops the activities based on the schedule.

 


 

Launch

The two NODES nanosatellites were launched as secondary payloads on the Cygnus Orbital ATK CRS-4 mission on December 6, 2015 (21:44:57 UTC) from KSC (Kennedy Space Center), Cape Canaveral, FL. The ‘Return to Flight' mission, dubbed OA-4 (Orbital ATK-4, CRS-4, Deke Slayton 2), fulfils Orbital ATK's commitment to meet the cargo requirements to NASA under the CRS (Commercial Resupply Services) contract. 7) 8)

In order to get the Cygnus logistics spacecraft back into service for NASA as quickly as possible, Orbital switched rockets and the vessel will be carried to orbit for the first time by a ULA (United Launch Alliance) Atlas-5 rocket. The enhanced Cygnus variant – flying for the first time in its longest configuration – is jam packed with the heaviest load ever heading to the space station, due to a combination of the loftier lift capabilities of ULA's Atlas booster and the lengthier cargo module. The enhanced longer Cygnus variant, consisting of the SM (Service Module) and PCM (Pressurized Cargo Module), is able to go from 2700 kg [with Antares] to 3500 kg of cargo [with Atlas-5]. The total payload packed on board is 3513 kg, including science investigations, crew supplies, vehicle hardware, spacewalk equipment and computer resources.

Secondary Payloads

- Flock-2e, 12 3U CubeSats of Planet Labs

- CADRE, a 3U CubeSat technology mission of the University of Michigan

- MinXSS-1, a 3U CubeSat solar physics mission of the CU (University of Colorado) at Boulder, CO

- NODES (Network & Operation Demonstration Satellite), two 1.5 CubeSats of NASA

- STMSat-1 (Saint Thomas More School Satellite), Arlington, VA, 1U CubeSat.

- SIMPL (Satlet Initial-Mission Proofs and Lessons), a microsatellite of NanoRacks. SIMPL is a modular, hyper integrated satellite designed to provide complete satellite functionality in a nanosatellite scale. It will be the first NanoRacks microsatellite deployed from the space station and the first propulsion-capable satellite deployed from the NanoRacks MicroSat Deployer, known as Kaber. The commercial deployer system aims to address the growing market of customers wanting to deploy microsatellites from the ISS orbit. SIMPL will be the first NanoRacks microsatellite deployed through the Kaber facility.

Figure 9: Artist's rendition of Orbital ATK's Cygnus spacecraft in orbit (image credit: Orbital ATK)
Figure 9: Artist's rendition of Orbital ATK's Cygnus spacecraft in orbit (image credit: Orbital ATK)

 


 

Mission Status

Flight results and performance (Ref. 1): In summary, the NODES spacecraft have successfully completed their mission, exceeding all mission objectives. The NODES spacecraft accomplished several "firsts" for CubeSats, including:

- The first demonstration of coordinated spatially distributed multipoint scientific measurements from multiple spacecraft

- The first commanding of a CubeSat through a space network by routing of the command through one spacecraft to the target spacecraft

- The first crosslinking of data from one CubeSat to another for downlink to the ground

- The first autonomous self-configuration of a space-network.

The EDSN/NODES communications architecture provides a robust, low cost and simple system that can be implemented on CubeSat-class spacecraft, with their need for low-power, COTS solutions. As such, this architecture can be the basis of swarm missions in the immediate future and for missions requiring incremental improvements.

• June 2, 2016: Over the course of three weeks, the NODES spacecraft achieved all of their mission requirements:

- Collection of at least five (5) sets of science data and downlink them to the ground

- Perform at least five (5) space-to-ground data transmissions

- Transfer at least one (1) command from the ground, through a relay spacecraft to the target spacecraft and have that command executed

- Perform at least two (2) Captaincy negotiations and notify the ground system of the result

- Monitor spacecraft state-of-health for at least twenty (20) days.

As of June 2, 2016, a total of six (6) S-band contacts had been made successfully by SCU. These contacts will continue to be available at daily intervals until the spacecraft re-enter about six months into the mission.

Between 2016-05-18 and 2016-06-02 (the period in which the primary mission objectives were met), 470 science packets were created and of those packets, 356 packets were successfully downlinked. Spacecraft-K generated 180 packets and downlinked 145 packets either through a crosslink to Spacecraft-J, with subsequent downlinking to the ground, or by directly downlinking the spacecraft to the ground. Spacecraft-J generated 290 science packets, of which 211 packets were eventually received on the ground.

The first negotiation between NODES-J and NODES-K occurred on May 18 when the default Captain, NODES-J, requested and received information from NODES-K as to its data storage and battery state-of-health. Because NODES-J had a higher battery voltage, it remained Captain. During a later negotiation session, on May 20, Spacecraft-K was promoted from Lieutenant to Captain due to it having more data in storage for downlink. From May 18 to May 24, the NODES spacecraft successfully conducted five (5) negotiation sessions, with the Lieutenant being promoted to Captain one time.

Between May 18 and May 27, 19 ground commands were uploaded to NODES-K and 25 to NODES-J. Over this time, there were four successful crosslink sessions in which commands were sent from the Captain to the Lieutenant. Over this time, 106 commands were received and executed by NODES- J and 59 were received and executed by NODES-K. This large number of commands executed is a result of an asymmetric crosslink in which the link was stronger from NODES-K to NODES-J than it was from NODES-J to NODES-K. In some cases, the same command would be sent multiple times by the Captain to the Lieutenant and successfully received and executed. However, the acknowledgement of the command receipt transmitted by the Lieutenant would not be received by the Captain, leading the Captain to retransmit the same command multiple times.

The last successful crosslink session occurred on May 25, 2016, at which point the spacecraft were approximately 100 km apart. As the spacecraft continued to drift apart, the link margin for crosslink between the Lithium radio deteriorated and no more crosslink sessions occurred. A total of 12 crosslink sessions were performed between the spacecraft, over which time 435 science and SOH packets were transmitted and 154 received.

Over the course of its 20 day mission, the NODES spacecraft performed almost exactly as expected and as simulated in pre-launch Mission Simulations. There were one unexpected class of events and one off-nominal condition that occurred during the mission.

The unexpected class of events was due a strong asymmetry in the crosslink where it was easier to send data from Spacecraft-K to -J, than from -J to -K. This is likely due to a combination of higher transmission power on Spacecraft-K and/or a lower noise receiver on Spacecraft-J. This asymmetry resulted in some unexpected behavior. During crosslinks, packets sent from NODES-J to NODES-K were more likely to be dropped when NODES-J would receive the "transmit ping" and then transmit its data to NODES-K. The poor link from - J to -K would cause these packets to be lost in transmission. Since the system did not require an acknowledgement of receipt, the packets were lost. As previously discussed, the asymmetric link also caused NODES-K to send the same command to NODES-J multiple times. The off-nominal events occurred when a spacecraft did not acquire a GPS solution in time to participate in the minor cycle. These events were handled as expected and full operations re-established during the next minor cycle.

On May 16, 2016, the two NODES spacecraft were deployed by NanoRacks from the ISS (International Space Station). SCU (Santa Clara University) of Santa Clara, CA, began tracking, monitoring and operating the spacecraft immediately. Both spacecraft began transmitting "beacon" packets 30 minutes after deployment from ISS, indicating that they were in working order. Magnetic detumble was completed as planned in less than the 30 hours allocated. Santa Clara University made its first S-band two-way contact with NODES-K on May 18 and with NODES-J on May 19, 2016 (Ref. 1).

Figure 10: Students support the Santa Clara University ground station during the NODES mission (image credit: Santa Clara University)
Figure 10: Students support the Santa Clara University ground station during the NODES mission (image credit: Santa Clara University)

 


 

Sensor Complement

EPISEM (Energetic Particle Integrating Space Environment Monitor)

The EPISEM, developed by MSU (Montana State University), is a Geiger-Müller tube that detects penetrating beta/gamma radiation from energetic particles above a certain energy threshold.

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. 9)

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?

Figure 11: Illustration of SEUs in the MOPITT instrument on NASA's Terra spacecraft (image credit: University of Colorado)
Figure 11: 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.

Figure 12: Schematic view of interactions in the Geiger-Mueller tube of the EPISEM (image credit: MSU)
Figure 12: 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.

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

 


References

1) John Hanson, Ali Guarneros Luna, Rodolphe DeRosee, Ken Oyadomari, Jasper Wolfe, Watson Attai, Cedric Prical, " Proceedings of the 30th Annual AIAA/USU SmallSat Conference, Logan UT, USA, August 6-11, 2016, paper: SSC16-WK-09, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=3439&context=smallsat

2) "Nodes – Network & Operation Demonstration Satellite," NASA Fact Sheet, July 2014, URL: http://www.nasa.gov/sites/default/files/files/Nodes-Fact_Sheet-23July14%281%29.pdf

3) "Nodes – Network & Operation Demonstration Satellite," NASA, Feb. 13, 2015, URL: http://www.nasa.gov/centers/ames/engineering/projects/nodes.html

4) 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

5) 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

6) Wiil Ivancic, Wesley M. Eddy, Lloyd Wood, Dave Stewart, Chris Jackson, James Northam, Alex da Silva Curiel, "Delay/Disruption-Tolerant Network Testing Using a LEO Satellite". Proceedings of the NASA Earth Science Technology Conference, June 24-26, 2008, Paper A4P2, URL: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/uk-dmc-dtn-saratoga-testing-estc-2008.pdf

7) "Oribital ATK CRS-4 Mision Overview," URL: http://www.nasa.gov/sites/default/files/atoms/files/orbital_atk_crs-4_mission_overview-2.pdf

8) Ken Kremer, "Spectacular Blastoff of Atlas Cygnus Ignites Restart of American Cargo Missions to ISS," Universe Today, Dec. 6, 2015, URL: http://www.universetoday.com/123734/spectacular-blastoff-of-atlas-cygnus-ignites-restart-of-american-cargo-missions-to-iss/

9) 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 (eoportal@symbios.space).

Overview   Spacecraft   RF communications concept   Launch   Mission Status   Sensor Complement
References   Back to top