STRaND-1 (Surrey Training, Research and Nanosatellite Demonstrator)
STRaND-1 is a cooperative low-cost nanosatellite designed and developed in a project team of SSTL (Surrey Satellite Technology Limited) and the USSC (University of Surrey Space Centre), Guildford, UK. The overall objective is to demonstrate new technologies - including a mobile phone – that will feed in to the 'Mission Concepts' study on a smaller SSTL platform. STRaND-1 represents the world's first smartphone on a nanosatellite. The smartphone will be used as the operating system of the nanosatellite. 1) 2) 3) 4) 5) 6)
The spacecraft is being built in engineer's free time (volunteer manpower) on a rapid timescale and using advanced commercial off-the-shelf components, which fits perfectly with SSTL's innovation and low-cost philosophies. The engineers are motivated to be involved in STRaND-1 for their own education and the opportunity to ‘own’ and build a mission of significance. The funding of hardware and additional support is provided by SSTL/USSC to help guarantee mission success.
Background: STRaND-1 started out as a feasibility study and mission requirement exercise in the Mission Concepts team at SSTL in February of 2010. A first call for volunteers went out in the summer of 2010, and an overwhelming response from staff at both SSTL and SSC was received. By January 2011 the team had finalized the payload selection, finalized all the make/buy decisions, made some initial procurements, completed a first draft of the 3D design and started detailed design work on the subsystems to be developed in-house.
Figure 1: Artist's view of the deployed nanosatellite (image credit: SSTL, USSC) 7)
The STRaND-1 nanosatellite uses a Pumpkin 3U solid-walled chassis with Surrey-built deployable solar panels to provide increased mission power. The panels hinge along the long edges of the satellite and can be considered “wings” given their nominal orientation to the flight direction. The deployable panels have a secondary function at the end of life, when the satellite’s orientation is changed to increase the satellite’s ballistic co-efficient to increase atmospheric drag and to aid in the de-orbiting of the satellite.
The nanosatellite features a 3U CubeSat form factor with a size of 10 cm x 10 cm x 34 cm and a mass of ~ 3.5 kg.
Figure 2: STRaND-1 satellite without the main structural chassis (left) and the nadir panel and both deployable solar panels in their deployed state (right), image credit: SSTL, USSC
The block diagram in Figure 3 shows the key subsystems and buses on STRaND-1. Given the adoption of I2C by existing CubeSat COTS modules, most of the STRaND-1’s subsystems operate as slaves, only responding to requests from bus masters. The primary bus master is the GomSpace A712 OBC (On Board Computer), but the OBC itself may operate as a slave to upload new binaries or for fault recovery. The transceiver radio module can send a watchdog interrupt signal using a dedicated UART (Universal Asynchronous Receiver/Transmitter) to the OBC to reset it to a slave mode where a recovery or new binary can be uploaded, known as a bootloader mode. To return back, the transceiver can send a reset to master command where the standard mode of operation is returned.
Additionally, when the mobile phone performance and susceptibility to SEUs (Single Event Upsets) has been characterized to a satisfactory level, the I2C bus shall be switched again to make the mobile phone the bus master, and so it can act as the OBC of the satellite.
Figure 3: Block diagram of the STRaND-1 nanosatellite (image credit: SSTL, USSC)
The following COTS (Commercial off-the-Shelf) systems/subsystems are part of the STRaND-1 nanosatellite:
• Pumpkin CubeSat solid wall structure
• EPS (Electrical Power Subsystem) of ClydeSpace including the daughter battery module
• GomSpace A712 OBC
• SGR-05 (Space GPS Receiver-05) of SSTL
• Digi-Wi9C module.
These units were chosen to reduce development time of STRaND-1 where building an equivalent unit in-house would have driven the schedule, or where the cost benefit was such that it costs less to make the purchase than develop in-house, even when using voluntary effort.
EPS: Over a single orbit the spacecraft can raise 10 W of peak power and 3 W OAP (Orbit Average Power). OAP can be increased by operating the satellite in sun-pointing mode, where the orientation of the satellite is fixed with respect to the sun, which increases the OAP to 5.8 W. The peak power demand could be as high as ~24 W, occurring when all systems are operated at the maximum operating power rating. The 20 Whr daughter battery module permits ~1.25 hr of continuous peak demand operations in eclipse and ~1.40 hr with solar power averaged over the orbit.
The satellite can regulate power flow from the solar panels, to the battery, and to various payloads. There are two 30 x 10 cm solar panels, a smaller tertiary dorsal panel and a smaller panel facing Earth. The largest panels will provide 6.9 V at 0.86 A with 6 triple-junction 4 cm x 7 cm 27.5% efficiency solar cells, reduced to 26.5% due loss of area, diode leakage, and covering. Both EPS and battery modules are addressable I2C nodes which can send status bytes on module temperatures and currents.
OBC: The system is an off-the-shelf GomSpace A712 “Nanomind” computer which includes a 40MHz ARM7 processor, 2 MB RAM, 8 MB Flash, I2C controller, three-axis magnetometer and 3 reversible PWM outputs for driving magnetorquers. The unit is in the PC104 form factor and thus forms part of the spacecraft's core system stack.
During normal operations the GomSpace OBC controls the overall operation of the spacecraft. The intention is that experiments on the phone will demonstrate its utility as the spacecraft's primary OBC, at which point the GomSpace unit’s role will be kept to a minimum: just enough to keep the spacecraft flying in a state that will catch the sun and allow the smartphone camera to image the Earth and other targets, and allow the imagery to be transferred to the ground. In order that such activities can be orchestrated from the ground, the OBC system also relays commands and telemetry between the hardware attached to the I2C bus on the spacecraft, and the ground, effectively making itself transparent in this respect.
The OBC is loaded with a FreeRTOS-based minimal operating system supported by a “newlib” C library which, together with some functions furnished by a GomSpace-supplied library, provides enough functionality to read the magnetometers and drive the magnetorquers and I2C bus. It is left to the STRaND-1 developers to add tasks to this system which operate the STRaND-1 spacecraft as required.
To achieve maximum reliability while providing a suitably flexible operating environment for the varied experiments that might be conducted on board, the STRaND-1 operating system (which sits on top of FreeRTOS, newlib, and the GomSpace library) is a very small kernel just capable enough to sequentially (round-robin) execute modules of code loaded in memory; two such modules are pre-loaded and provide the means to upload new modules and to manipulate the module execution list. Upload is completed through a custom “Strandatoga” protocol allowing the OBC to reverse-acknowledge reception, allowing the system to re-request missing or corrupted fragments. With those in place further such modules can be pre-loaded or retrospectively actively loaded to take care of all the requirements of the OBC.
The lowest-level requirement of the OBC is to master the I2C bus and to provide timely access to it by the ADCS (Attitude Determination and Control Subsystem) which also runs on this computer. This in fact dictates the main operation of the OBC: all modules are executed in a round-robin fashion up to the top of each second, when the ADCS is allowed to run. This also means that the ADCS has full mastery of the I2C bus when it runs, and thus can perform its operations with implicit reliability and timeliness. The ADCS will operate the rest of the spacecraft using the same telemetry and telecommands and interfaces.
The system provides access from the ground to all the physical telemetry points on the I2C bus, and allows telecommands to be relayed to those nodes. The OBC itself also provides soft nodes which allow the ground station access to the operating system's, and ADCS's, internals, and these can be utilized as intelligent I2C nodes which operate other items on the spacecraft with more high-level semantics. To ensure that all eventualities can (theoretically) be dealt with, the underlying principle that has been followed in designing the OBC's own telemetry points is that all internal variables can be accessed and modified live. This is accomplished by mapping nodes onto modules, and channels to offsets into structures in which each module keeps all of its data. Access to these data is through a shadow application on the ground which is compiled using exactly the same source code headers as the onboard software, so that it knows exactly how the various variables in all the modules are packed into the structures and relate to the telemetry and telecommand “nodes” and “channels”.
To perform mission tasks, the OBC will itself execute telecommands at given times. Schedule files (“skeds'”; lists of telecommands and requisite times) are uploaded using the same mechanism as for uploading modules, and then the top item on the sked will be inspected frequently and a telecommand issued if the time is right.
The highest-level task the OBC must carry out is the marshalling of images from the smartphone, via the HPC (High Performance Computer) to the transmitter, so that they can be received at the ground. The Strandatoga protocol is available for ground-based negative acknowledgement (allowing the ground to indicate parts of images which must be re-transmitted due to drop-out) if required, though probably in the case of images, this facility would not be used with the occasional drop-out of some image pixels being tolerated by the operators.
RF communications subsystem: Early on in the mission it was decided, that the whole radio chain from antenna to analog radio to digital section to bus would be developed in-house. Given the historical strength of SSTL in space-worthy radio communication systems, it was felt this provided the best learning opportunities, and opportunities to tap existing expertise in the company. Therefore, a team of engineers with limited RF design experience designed the RF section of the STRaND-1 satellite under supervision from some of the most experienced engineers in the company.
Antenna assembly: STRaND-1 has two monopole antennas; one for the 2 m-band (VHF) uplink and one for the 70 cm-band (UHF) downlink. The requirements for the antennas were to:
- Be low-mass and deployable
- Have a fail-safe to ensure the antennas get deployed in case of deployment electronic failure
- Fit the limited volume available
- Have a sufficient gain for the link budget.
The antennas are based on the standard UHF/VHF whip antennas used by SSTL on their early commercial satellites, and are influenced by the Delphi-C3 antenna deployment mechanism. The design is different from the Delphi-C3 solution in that the box geometry is different; antennas are mounted to deploy out of the side of the spacecraft instead of the top, which saves volume to allow more modules in the CubeSat stack.
Radio receiver: The RF transceiver provides the following key functions:
- Activates the antenna deployment mechanism
- Receives and decodes data from the ground
- Encodes and transmits data to the ground
- Transmits a beacon
- Transmits and receives data to/from the OBC via the spacecraft’s I2C bus
- Includes the ability to reconfigure the OBC via a dedicated UART interface.
The frequency allocation for the downlink is 437.575 MHz, and 145.860 MHz for uplink. The RF subsystem as a whole is centered on inexpensive and readily available single chip UHF transceivers. Two of these devices are used; one for transmit and one for receive.
The transceivers are controlled by the PIC24 microcontroller. Since the downlink frequency is the same as that outputted from the transmitting IC, the RF output from the transceiver is passed directly to a GaAs HPA (High Power Amplifier) and then to the transmit antenna. The HPA will provide nominal RF output power of 1 W, which can be increased to 1.5 W if required. When operating in beacon / CW mode, the RF output power will be reduced to 0.25 W. On the uplink, the UHF input from the receive antenna is first amplified by a low noise MMIC amplifier and then upconverted to UHF frequency before being passed to the receiving IC.
Figure 4: Breadboard components for the analog front end of the STRaND-1 radio transceiver (image credit: SSTL)
The digital section is centered on an inexpensive and readily available PIC24 microprocessor. The transceiver ICs are configured on power on by the microprocessor via an SPI interface. Data is transmitted to/from the microprocessor via a separate serial line. The microprocessor performs AX.25 decoding/encoding of received and transmitted data respectively. The primary method of communication with the rest of the spacecraft is via the I2C bus; telecommands, telemetry and data are all sent via this bus. It is also possible for the ground station to communicate directly with the RF transceiver via a limited command set and a dedicated serial link to the OBC is also provided. These combine to allow the OBC to be reconfigured in the event of a fault, or if a software update is required.
BPS (Butane Propulsion Subsystem): The propulsion module on STRaND-1 is split into two parts; the SSTL butane resistojet (based on the heritage SSTL resistojet), and the USSC PPT (Pulsed Plasma Thruster). The BPS is baselined to have a warm gas butane propulsion system on board to enable orbital maneuvers. The system builds on the extensive SSTL heritage with the design and operation of butane propulsion systems, while testing out new processes and hardware to reduce the system size and cost. These two points are critical to enable the system to be viable for a CubeSat. The propulsion system must fit in a space smaller than 75 mm x 75 x 21 mm, and had to be completed on a stringent budget. Typical space-rated components were ruled out for these reasons.
The system is designed to provide 2 m/s ΔV to the STRaND-1 nanosatellite. A basic schematic for the system is shown in Figure 5. It should be noted that no redundancy exists, and this is the accepted approach for this mission. The ΔV capability would also be reduced if a redundancy was required – the tank volume would be reduced to allow space for the redundant components.
Figure 5: Schematic view of the BPS (image credit: SSTL, USSC)
The BPS is loaded with propellant through a fill/drain valve. For this, a Lee check valve is utilized with a special ground half coupling manufactured to allow the valve to be opened mechanically. The valve is incredibly small and affordable making it ideal for this application.
The propellant is stored in a tank, constructed from two aluminum billets and welded together. Butane is a liquefied gas so stores under its own vapor pressure (~2.1 bar at 20ºC). The tank is designed to survive a burst test of > 4 times MEOP (Maximum Expected Operating Pressure) to prove it is safe for launch. MEOP has been defined as 4 bar, and so the burst pressure will be in excess of 16 bars. A temperature sensor is attached to the tank – this will allow the pressure in the tank to be estimated.
A Lee solenoid valve is employed as a flow control valve in the system. The small size again made it ideal. All internal materials are compatible with the propellant and test gases. - The resistojet itself is manufactured by SSTL. It is a simple design consisting of a resistive wire wound round a mandrel. The gas is forced to spiral down the resistojet to increase the travel path and thus the heat transfer. The resistojet acts as a vaporizer to ensure no liquid propellant is expelled, as well as increasing the specific impulse of the system.
Figure 6: SSTL-heritage resistojet embedded in a custom propellant tank (image credit: SSTL)
PPT (Pulsed plasma Thruster): The PPT is an electric propulsion system that operates in a non steady (i.e. pulsed) fashion. Energy is drawn from the satellite bus and stored in the thrusters’ capacitors (two parallel CR09 ceramic chip capacitors per thruster). The electrodes of each capacitor act as the propellant source. When the electrodes are shorted, large currents form that pass through the electrodes eroding them. In the case of STRaND-1, the shorting mechanism is a contact trigger actuated by an external initiation device. This contrasts to other PPTs where initiation is nominally by a spark plug. 8)
The material released in this erosion forms plasma. A Lorentz-force (J x B) is produced from the interaction between the high flowing current and the subsequent induced magnetic field. This µN force propels the plasma out of the nozzle to generate thrust. Once the PPT capacitor discharges completely, the plasma is extinguished and the process begins anew, leading to a discrete set of impulse packets that can be used for maneuvering.
Figure 7: Illustration of STRaND-1 components (image credit: SSTL, USSC)
The STRaND pulsed plasma propulsion system is made from three PC104 boards. Two boards house four PPTs each and the third acts as the PPU (Pulsed Power Unit). The PPTs are two CR09 chip capacitors, placed in parallel to provide a total capacitance of 0.76 µF.
The capacitors are charged to 800 V, supplied by the PPU. The PPU uses a set of six parallel high voltage DC-DC convertors taking the 5 V CubeSat bus voltage to 800 V. Single chip power filters are used to minimize ripple effects on the power lines and a set of diodes and high voltage resistors are used to ensure correct thruster firing and to limit spot welding. The predicted performance of the PPT module from models generated by USSC suggest that the specific impulse of the technology should be around 320 s with a total ΔV of around 2.7 m/s. However, with a slight simple modification to the electrode design in future versions of the design, this should increase to around 76.3 m/s.
If STRaND-1 is successful this will be the first EP thruster to operate successfully on a nanosatellite platform.
ADCS (Attitude Determination and Control Subsystem): The CubeSense module, developed at the University of Stellenbosch, South Africa, is an integrated sun and nadir sensor for CubeSat attitude sensing. It makes use of two CMOS cameras – one dedicated to sun sensing and another for horizon detection – mounted on a PC104-sized PCB (Printed Circuit Board). 9)
Figure 8: Photo of the CubeSense sun- and nadir sensor module (image credit: University of Stellenbosch)
The sun sensor has a neutral density filter included in the optics to ensure that only the sun will be visible in the image. Both cameras have wide field-of-view optics (180º) for increased operating range. The primary outputs of the sensor are the measured sun vector and nadir vector in the sensor’s coordinate frame. The measured vectors are output as azimuth/elevation angles relative to the camera bore-sight. The measurement error of the sun sensor is < 0.5º (1σ) for sun angles below 40º. For larger angles the error increases to 1.8º. The sun sensor is capable of measuring sun angles up to 90 degrees from the sensor bore-sight. The nadir sensor has an accuracy of 0.18º (1σ) when the Earth is entirely visible in the FOV (Field-of-View). The CubeSense module can also be used as a camera.
Actuators: Three reaction wheels are used in an orthogonal configuration to provide three-axis control, augmented by the magnetorquers for desaturation; they are also used as momentum wheels for the commissioning phase. Due to volume constraints, two differently sized wheels are used. Fortunately, due to the non symmetrical nature of STRaND-1, both wheel sizes have been designed to meet the same performance.
The reaction wheels are capable of slew rate of 90º in 60 s at a maximum wheel speed of 5000 rpm. Each wheel is an independent I2C node consisting of a microcontroller that handles the communication, motor commutation and control loop. The brushless DC motor is driven by three half H-bridges made from discrete components. A PID control loop is used with a maximum error of ±5 rpm over the full speed range. The nano reaction wheel and the RWA (Reaction Wheel Assembly) are shown in Figure 9.
Figure 9: Photo of the nano reaction wheel (left) and the RWA (SSTL)
External torque is provided by three orthogonally mounted magnetorquers, each comprising a 6.35 mm diameter, 74 mm long rod of Supra50 Iron-Nickel alloy, with ~32 m of 30 SWG (0.315 mm diameter) enamelled copper wire, giving a resistance of approximately 8 ohm (i.e. limiting the current to ~625 mA at 5 V). There are 172 turns per layer and 7 layers giving ~1200 turns and a total diameter of ~11 mm. The expected magnetic moment is between ±0.4 and ±0.8 Am2. The torquers are controlled by a NanoMind A712B computer board, which provides three 5 V PWM (Pulse-Width Modulated) bi-directional H-bridge drivers, which can each source up to 3A, with a total current capability also of 3A. The combined current draw of the three magnetorquers is < 2A.
Attitude control methodology: The STRaND-1 nanosatellite will employ various control modes throughout its operation. The first detumbling control mode will engage automatically after being released from the launch vehicle. Initially the satellite will be tumbling at an unknown rate. The purpose of the detumbling controller is to limit the angular rotation of the satellite ultimately resulting in a rotation only about the Y-axis, where the rotation rate is controlled to a reference value (typically 2º/s). Additionally, the satellite Y-axis will be aligned with the orbit anti-normal. This is achieved with combined B-dot and Y-Thomson control laws.
The controller requires knowledge about the current attitude rate. A Kalman filter rate estimator, that makes use of successive magnetometer measurements, will provide this information. The estimator does not require any orbit information and is robust against modelling errors. -Another advantage of this control mode is that it requires attitude sensing information from only the 3-axis magnetometer, and control is achieved using only the torquer rods. The mode can thus be implemented using only the NanoMind processor and its peripherals.
After the solar panels have deployed, the control mode will change to a sun-seeking precession controller. The STRaND-1 nanosatellite has its main solar panels facing in the +Y body direction. In the previous detumbling control, the satellite Y-axis (and thus also the solar panel normal vector) will be angled away from the sun direction. The sun-seeking precession controller will make use of measurements from the sun sensor of the CubeSense module to precess the solar panel normal vector to the sun vector. All the while the satellite will still be tumbling about its Y-axis and during eclipse, the controller will fall back to the Y-Thomson mode to control the spin rate to 2º/s.
The remaining control modes will make use of the reaction wheels. The first mode will use the Y-axis aligned reaction wheel as a momentum wheel to absorb the angular momentum of the spinning satellite and bring it to an approximate nadir pointing attitude. It will also continue to align the spacecraft body Y-axis with the sun vector for optimal power generation, and damp the nutation rates about the body X- and Z-axes. In eclipse the satellite will remain nadir pointing.
From the Y-momentum mode, the 3-axis controller can be activated. In 3-axis control mode all three reaction wheels will be used to control the attitude to some reference attitude and the torquer rods will be used to manage the reaction wheel momentum (momentum dumping). During eclipse the reference attitude will be the nominal attitude (zero roll, pitch and yaw) and in sunlit parts of the orbit the reference attitude will be calculated so that the body Y-axis points toward the sun. Additional commands from the ground can be sent to change the reference attitude temporarily so that specific pointing maneuvers can be performed.
Figure 10: Body-fixed axis definition of STRaND-1 (image credit: SSTL)
The Y-momentum and 3-axis control modes requires both attitude and attitude rate information. This will be provided by a full-state EKF (Extended Kalman Filter). The EKF makes use of sensor measurements from all the available sensors (magnetometer, sun and nadir sensors) and corresponding modelled vectors for each of these to estimate the current attitude quaternion and also the orbit referenced angular rates. The modelled vectors are obtained from a sun orbit model and IGRF (International Geomagnetic Reference Field) model, running on the OBC. The modelled vectors also depend on the current satellite position. This will be provided by an SGP4 (Simplified General Perturbation-4) orbit propagator running on the OBC, initialized with a two-line element set that will be uploaded from ground once this becomes available.
HPC (High Performance Computer): The HPC is based on a modified Digi-Wi9C processor. The primary uses are to provide I2C interfaces and communications between the smartphone and spacecraft bus, as well as additional services for monitoring the Nexus-One. These services include:
• Basic control (on/off) using GPIO (General Purpose Input/Output) and USB (Universal Serial Bus) ports. This is achieved by an application on the smartphone and a switch between the smartphone’s battery and the smartphone itself.
• Wireless control (on/off) using a WiFi interface. If the USB fails, then WiFi access is possible using a virtual terminal and mounting of the SD-card in Linux.
• Upload/download code using any port or interface. This may include operating system, user, data, or application installations to various partition areas on the smartphone.
• Telemetry handling. Converting data and metadata to I2C formats. Both the Digi-Wi9C and Nexus-One are experimental payload computers and use separate addresses, handled using a separate PIC microcontroller.
The HPC board monitors the smartphone using USB as the primary link and the WiFi as the secondary link, with the capability to operate at the same time for limited experimental periods. An additional VGA (Video Graphics Array) camera is mounted close to the smartphone and can provide visual access should both USB and WiFi links fail as shown in Figure 11.
Figure 11: HPC internal configuration showing the VGA camera and the mobile phone (image credit: SSTL)
Launch: The STRaND-1 nanosatellite was launched as a secondary payload on Feb. 25, 2013 from SDSC-SHAR (Sriharikota, India) on the PSLV-C20 launcher of ISRO. The primary payload on this flight was SARAL, a minisatellite and a collaborative mission of ISRO and CNES. 10) 11) 12)
Orbit: Sun-synchronous near-circular dawn-dusk orbit, altitude of ~ 786 km, inclination of 98.55º, orbital period of 100.6 minutes, LTAN (Local Time on Ascending Node) = 6:00 hours.
The six secondary payloads manifested on this flight are:
• BRITE-Austria (CanX-3b) and UniBRITE (CanX-3a), both of Austria. UniBRITE and BRITE-Austria are part of the BRITE Constellation, short for "BRIght-star Target Explorer Constellation", a group of 6.5 kg, 20 cm x 20 cm x 20 cm nanosatellites whose purpose is to photometrically measure low-level oscillations and temperature variations in the sky's 286 stars brighter than visual magnitude 3.5.
• Sapphire (Space Surveillance Mission of Canada), a minisatellite with a mass of 148 kg.
• NEOSSat (Near-Earth Object Surveillance Satellite), a microsatellite of Canada with a mass of ~74 kg.
• AAUSat-3 (Aalborg University CubeSat-3), a student-developed nanosatellite (1U CubeSat) of AAU, Aalborg, Denmark. The project is sponsored by DaMSA (Danish Maritime Safety Organization).
• STRaND-1 (Surrey Training, Research and Nanosatellite Demonstrator), a 3U CubeSat (nanosatellite) of SSTL (Surrey Satellite Technology Limited) and the USSC (University of Surrey Space Centre), Guildford, UK. STRaND-1 has a mass of ~ 4.3 kg.
The STRaND-1 nanosatellite was deployed with the ISIPOD (ISIS Payload Orbital Dispenser), a CubeSat dispenser of ISIS (Innovative Solutions In Space).
• On March 30, 2013, STRaND-1 nanosatellite stopped communications with the ground segment. 13)
As the OBC had been running fully for over 27 consecutive days and satisfied that debugging the ground station would be an on-going issue to work through, it was unfortunate that a geomagnetic storm arrived at Earth and caused STRaND-1 to stop communicating. It was briefly recovered after transmitting reset commands but went silent after 24 hours. The last three days of STRaND-1 are shown in Figures 12 a-c (Ref. 13).
Figure 12: a) Battery voltage, b) Array current, c) Magnetometer readings (image credit: SSTL)
All three plots indicated no serious problem. The battery voltage is shown to drop and was still far above safety limits. The solar array currents showed that we were still in the stowed configuration. And finally the magnetometer readings showed there was still an operational AOCS with (interfering) magnetorquer firings.
The total data downloaded was approximately 274 kB over 65 k packets. AMSAT and ham-radio members contributed greatly, especially during commissioning and although 43 kB of data was decoded, an estimated 55 kB in 13.9 k packets was not time-stamped for display in Figure 13. This totals to 372 kB in 5 weeks and 1 day.
Figure 13: Total data downloaded from STRaND-1 (image credit: SSTL, SSC)
• During commissioning, it was found that there were problems with the ground segment operated from the Surrey Space Centre's ground station at the University of Surrey. The ground station was developed under the GENSO project in 2007 and has been used for reception of satellite signals only and given the short time-scale of the project, was not tested sufficiently with the STRaND-1 flight model. As a consequence, the STRaND-1 uplink was not optimal during the first two weeks. The key factors in the uplink being received by STRaND-1 were the chosen software and old desktop PCs and better TLEs.
• The satellite successfully separated from the PSLV launcher of ISRO after its orbit injection on February 25, 2013, and a first contact with STRaND-1 was made on its second pass over the Guildford ground station (Ref. 13).
Experiment complement: (MPS)
MPS (Mobile Phone System):
The smart phone was chosen after an extensive trade study as part of the initial feasibility study. The smartphone chosen was the Google Nexus-One and has been integrated into the STRaND-1 nanosatellite with the initial aim of providing the main imaging payload, but with the ultimate intention to assess the opportunity to assess the smartphone’s capabilities to perform the primary on-board computer role. With the limited project timescale, the focus is on finding 'fit-for-purpose' rather than technically superior solutions. In-orbit updates will be used where possible to improve the software capabilities.
The Nexus-One phone will connect to satellite subsystems over USB using the HPC which will allow a Linux platform to operate a reduced ADB (Android Debug Bridge). This ADB will facilitate the control over flashing boot kernels, restarting the phone and installation of new applications (or ‘apps’). The ADK (Android Development Kit) is also under investigation as a more advanced interface library. The Nexus-One’s flash memory acts as a shared space between the HPC and Nexus-One for telemetry, telecommand, payload acquisition, processing schedules, and payload imagery managed by both systems. Each of these 'components' will consist of a metadata file and a data file. However, to address possible SD Card corruption due to SEEs (Single Event Effects), etc., both the metadata and data files will be triplicated. As any usage of the 'data' component will need to manage read/writing with these three files, the HPC and phone will operate an abstracted layer to control these interactions. Both, the phone and the HPC, will be responsible for their management of these metadata and main data files and will use the metadata header and data table to ensure seamless synchronized shared usage of the data; e.g., marking up a block when the device is writing to it, etc.
Uploads of new software (kernels, apps, etc.) will be managed by file control messages with the files being directly stored on the SD Card rather than through this metadata/data mechanism, as usage and management of these will be through other tools such as Fastboot and ADB on the HPC. The phone itself will autostart the prime schedule and status management tool that is responsible for managing the execution of phone apps, telecommand handling, output of critical telemetry, and the interaction with the component metadata/data files on the SD Card.
The Linux kernel is a reduced version (2.6.32) with GPS functionality removed amongst other minor changes to produce a smaller memory footprint. The Xconfig tool supports the production of kernels but is a challenging and unintuitive tool to create a compatible kernel on both the HPC and Nexus-One. For the payload, there are multiple resolutions supported by imaging schedule files and the system will default to the maximum image size of 2592 x 1944 pixels with image data saved as lossy-JPEG with tailored compression.
Development of applications and software is currently (fall 2011) ongoing, with the aim to support STRaND-1 Facebook Apps. The Linux kernel and Android kernel are both fully compiled and tested as shown in Figure 14. The smartphone itself is also under rigorous testing and is also shown in Figure 14 in the holding tray.
Figure 14: Nexus-One software information and Nexus-One payload in STRaND-1 payload-tray (image credit: SSTL)
Concept of operations:
The objective is to achieve an accelerated commissioning phase once the nanosatellite is deployed on-orbit. The estimated duration is 2 days as a goal (1 week is planned). The operation mode is manual in this phase.
This stage requires intensive use of the OBC and the AOCS and manual control from the USSC ground station and other ground stations. It is estimated that approximately 5 to 10 minutes of communications with the ground stations will be available on each pass. This time shall be used efficiently; a full system health check will be required as start. Subsequent overpasses should allow progressive commissioning and a basic set of diagnostics for analysis without too much communications overhead. After separation with the rocket launcher, STRaND-1 is required to:
1) Autonomously acquire its attitude
2) Promptly maneuver to reach a stable pointing
3) Deployment of the solar panels.
This will ensure a thermally and power-safe initial state to continue with the mission. In a worst-case scenario, the uncontrolled tumble of the spacecraft can only guarantee a maximum of 3 hrs of battery power before battery degradation occurs, and 10 hrs before the battery is 100% depleted. This corresponds to 2 orbits and 6 orbits, respectively. The satellite will be thermally safe in the tumbling mode before deployment of the solar panels.
The GPS receiver will acquire the spacecraft position while built-in magnetometers on the OBC will be used to measure both direction and magnitude of the Earth's magnetic field on 3-axis. The comparison of these observations with a vector model of the magnetic field will determine the magnitude and polarity for the magnetorquer's firings to control the spacecraft's orientation. The initial tumbling rates expected are likely to be less than the 30º/s experienced by the SNAP-1 (Surrey Nanosatellite Applications Program) nanosatellite (launch June 28, 2000), as the CubeSat deployer uses guide rails.
Once the spacecraft has reached a safe state, a full system check is required. The communications system allows a direct link to the OBC flash memory to enable loading or reloading of OBC software without OBC involvement, but ultimately the OBC is required to log the essential telemetry: magnetometer vectors, temperature sensors, solar array voltage / current, battery voltage. The minimum refresh rate is TBC and will define the minimum downlink data rate required.
A higher sampling rate is expected during the initial stages but as the mission continues and increases confidence on each subsystem’s operation, then the sampling rates of the magnetorquers can change to one or two samples per orbit.
The extreme capability of the mobile phone electronics suite allows for a number of interesting experiments that make use of the advanced COTS technologies.
• Intra-satellite link: The nominal data link between the phone payload and the platform is a USB cable. One experiment to be conducted early on in the mission is to deactivate the USB link and operate the mobile phone using the WiFi link to the HPC only, perhaps demonstrating a distributed processing task at the same time. - Demonstrating the use of a COTS wireless link is a proof of concept for physically and electronically distributed space systems acting as a single logical unit.
• Touchscreen-based random number generator: The capacitive touchscreen of the mobile phone is the focus of this experiment. It is hoped that SEEs will manifest themselves as detectable events using the Android-provided touchscreen API (Application Programming Interface). Depending on the location of the detected effect, a number is generated and logged. The number generation log is then downlinked and analysed for true randomness.
• WiFi (Wireless Fidelity) downlink: Using an existing SSTL-owned S-band dish, this experiment would aim to receive data transmitted from the mobile phone IEEE 802.11g antenna on the ground.
This experiment is currently undergoing feasibility analysis, looking at link budgets, Doppler effects, and any gain-increasing design changes such as the introduction of a slot antenna. If such a technique is feasible and can be demonstrated as viable, it would dramatically increase the volume of data that can be downlinked from STRaND-1.
• Phone control of satellite: This experiment is a key goal of the mission, and demonstrating that an Android mobile phone is capable of operating a satellite has potential to revolutionize the nanosatellite (and particularly the CubeSat) field. The experiment will be graduated in that first it will merely mimic the scheduling and control functionality of the nominal OBC. Then, greater functionality (such as AOCS control) will be migrated to the phone unit, followed by a brief period running only on phone-resident sensors such as the camera, magnetometer and accelerometers. If the latter can be achieved with some reliability demonstrated by the phone then the result will provide strong evidence that nanosatellites and CubeSats in particular can miniaturize their systems even further and increase their capability further still whilst keeping the low cost advantage.
• CCSDS SM&C: In partnership with Logica’s Space division, STRaND-1 will demonstrate the use of the CCSDS SM&C (Consultative Committee for Space Data Systems - Spacecraft Monitoring & Control) protocol in conjunction with the open source Hummingbird  mission control system.
• PPTs (Pulsed Plasma Thrusters): The PPT bank is a novel and highly efficient electric propulsion system. Long term use of the thrusters on STRaND-1 will allow for in-orbit characterizations to be made and compared against current theoretical models and vacuum tests conducted at the University of Stuttgart, whilst also making observations about any adverse effects on the rest of the satellite system (e.g. power ripples, transients etc.).
If demonstrated to be a reliable propulsion system, the technology has the potential to be the propulsion system of choice for CubeSats due to its low power draw and solid propellant – thus, avoiding the pressure limits in the CubeSat standards.
• Outreach activities: The combination of mobile phone technology and space technology has already been shown to spark the interest of the greater public and mainstream media. Outreach seen as a core duty of the STRaND program, and is seen as a useful tool in inspiring future engineers to join the industry.
• App competition: In the summer of 2011, SSTL and USSC launched the first SpaceApp competition. Members of the UK public were invited to submit ideas on Facebook for Apps that could be run on the mobile phone once in orbit. Submitters were expected to write the app themselves and deliver them to the STRaND-1 project by the end of 2011. Conditions of the competition included that the applicant must be a UK resident and the app must be written as an open source project to be uploaded on to s-android. - Four winners were selected from the entries, including app ideas in:
- telemetry trend analysis
- plasma physics
- outreach – including a) an experiment testing the assertion that “in space, no one can hear you scream”, and b) an outreach app described as “Postcards from Space”.
Table 1: The Apps on board STRaND-1 were developed by winners of a facebook competition
• AIC (Artificial Intelligence Chatbot): The combination of the very capable processor along with the inherent Java support provided by the Android platform, and the history of the Amateur Satellite community using satellites to communicate, has resulted in the concept to run an Artificial Intelligence “Chatbot” – or more specifically an “Alicebot” on the mobile phone. Alicebots are AI routines specifically designed for communicating with humans in an instant-messaging environment. The aim of this experiment is to allow amateur radio operators all over the world to interact directly with the satellite, and also allow non-technical people the chance to interact with the satellite in a meaningful way, for example in school sessions.
• Test philosophy: The test philosophy is similar to the development philosophy in that a subset of the normal SSTL test approach is taken, with great emphasis on using system end-to-end tests. Indeed, all new subsystems will be only be vibration tested or thermally tested for the first time during the system-level vibration and thermal tests. For STRaND-1, SSTL and USSC maintain a flexible approach to the sequence of AIT (Assembly, Integration and Test) in an attempt to make the best use of any available hardware and facilities at any given time. This is to ensure that the maximum progress is made irrespective of the order in which the flight units become available for AIT. The distributed TTC (Tracking Telemetry and Command) system used on STRaND-1 accommodates this approach.
• Test Plan: The modular nature of STRaND-1 allows initial electrical integration to take place in any order provided core systems (e.g. power subsystem, harness) are available. - As unit interfaces are not available once the spacecraft is integrated, all data is obtained via the following CubeSat system connections and umbilicals:
- Data umbilical (primary and secondary TTC bus)
- RF uplink
- RF downlink
- Power from the solar simulator
- Safe / Arm connection (allows remote activation of the spacecraft).
Spacecraft configurations, voltages and temperatures are obtained via the spacecraft telemetry subsystem. The EGSE (Electrical Ground Support Equipment) hardware and software will be based on the ground station design; this reduces compatibility issues to a minimum and allows verification and test of the TTC database and software.
• Platform pre-integration: All units and subsystems arriving in the AIT clean room for integration into the STRaND-1 platform are to be bench and performance tested. All modules and subsystems will have completed and passed a ‘Module Readiness Review’ prior to integration.
All modules shall be visually inspected before integration. Special attention is given to connectors to check for contamination and damaged pins. The flight harness is inspected and checked against the harness manufacturing instructions and will be electrically tested.
• Platform soft and hard stack: Initial integration of the platform subsystems is in a soft stack configuration. The aim of the soft stack is to perform an initial check on each of the individually tested modules to verify that each one fits and functions with the harness.
Initial soft stack provides an early opportunity to test interfaces between the platform and the payloads using available breadboards and/or EM models. Full soft stack requires stacking and bolting the platform together using all flight modules and parts. It uses flight fasteners, but the fasteners are not necessarily torqued and adhesives are not used. A full soft stack spacecraft can be handled safely for thermal cycling etc., but can also be taken apart easily if any rework is required. - ‘Hard stack’ assembles the whole platform into its flight configuration. The platform fixings will be at the correct torque levels; staking glue or RTV will be applied to all nuts and bolts. The flight harness will be attached to support locations; all connector fixings will be torqued and staked. - Following hard stack integration, a series of functional tests on the platform are repeated to confirm that all data and power interfaces are mated correctly.
• Vibration testing: A comparison between the GSFC-7000 standard random vibration spectrum that is commonly used for CubeSats and the in-house SSTL Spectrum C random vibration spectrum will be conducted, and STRaND-1 will be tested as a fully integrated system to the worst spectrum at SSTL’s facilities.
• Thermal testing: The fully integrated system will be tested in a thermal vacuum chamber on USSC premises. The fully integrated system will be subjected to the normal SSTL thermal cycle. A schedule decision will be taken before testing whether to conduct a 7-day burn-in test as well.
• EMC (Electromagnetic Compatibility) testing: Before the integration of the whole system, units with EMC considerations such as the RF transceiver and the pulse plasma thrusters will have some basic EMC characterization tests, then the fully integrated satellite system will be placed in an anechoic chamber either at USSC or SSTL premises and the EMC environments around the satellite measured.
• TTC end-to-end tests: System tests will use hardwired connections to the spacecraft TTC transmitters and the data umbilical will be connected; a wireless connection will be made from the EGSE to the Core Spacecraft Transmitted.
A wireless TTC end-to-end test is performed using the ground station antenna. Commanding the spacecraft through the receiver is confirmed, and then telemetry reception from the transmitter is confirmed. OBC code upload tests are performed through all receiver and transmitter combinations.
• FRR (Flight Readiness Review): The FRR is the final review of the spacecraft integration and test campaign. This review will:
- Confirm that all the tests have been completed as per the test plans
- Confirm all the results have been reviewed and accepted
- Confirm that all anomalies have been resolved
- Confirm that the required shipping and export documentation and clearances are in place.
The FRR will be at a much reduced scope compared to a commercial SSTL mission.
STRaND-1 is a testament to the enthusiasm of space engineers in Surrey, in that they are willing to spend their own time developing a nanosatellite of significance. By maintaining the close ties with the University of Surrey with the STRaND program, SSTL benefits from the continuous pioneering and advanced technological research projects at the Space Centre, and the University benefits from regular opportunities for practical demonstrations of new technologies (Ref. 4).
Table 2: Comparison of some CubeSat missions
1) “Science & Exploration - STRaND-1 Smartphone Nanosatellite,” URL: http://www.sstl.co.uk/divisions/earth-observation-science/science-missions/strand-nanosatellite
2) Jonathan Amos, “Mobile phone to blast into orbit,” BBC News Science & Environment, Jan. 24, 2011, URL: http://www.bbc.co.uk/news/science-environment-12253228
3) Mike Isaac, “Smartphone-Powered Satellites Are Destined for Space Travel,” Jan. 24, 2011, URL: http://www.wired.com/gadgetlab/2011/01/android-smartphone-space/
4) Shaun Kenyon, Christopher Bridges, Doug Liddle, Bob Dyer, James Parsons, Mark Pollard, David Feltham, Rupert Taylor, Dale Mellor, Andrew Schofield, Rosie Linehan, Richard Long, Juan Fernandez, Haval Kadhem, Phil Davies, Jonathan Gebbie, Nick Holt, “STRaND-1: Use of a $500 Smartphone as the central avionics of a nanosatellite,” Proceedings of IAC 2011 (62nd International Astronautical Congress), Cape Town, South Africa, Oct. 3-7, 2011, paper: IAC-11-B4.6B.8, URL: http://www.sstl.co.uk/Divisions/Earth-Observation---Science/Science---Exploration/STRaND-nanosatellite/IAC11-Kenyon-STRaND-1-B4-6B-8
5) C. Bridges, S. Kenyon, C. Underwood, V. Lappas, “STRaND-1: The world's first smartphone nanosatellite,” International Conference on Space Technology (ICST), Athens, Greece, Sept. 15-17, 2011
6) C. P. Bridges, S. Kenyon, C. I. Underwwod, M. N. Sweeting, “STRaND: Surrey Training Research and Nanosatellite Demonstrator,” 1st IAA Conference on University Satellite Mission and CubeSat Workshop, Rome, Italy, Jan. 24-29, 2011, URL: http://epubs.surrey.ac.uk/26829/8/IAA-Bridges-STRaND.pdf
8) V.J. Lappas, T. Harle, A. Knoll, P. Shaw, P. Bianco, M. Perren, “Micro Electric Propulsion Technology for Small Satellites: Design, Testing and In-Orbit Operations,” Proceedings of the 27th AIAA/USU Conference, Small Satellite Constellations, Logan, Utah, USA, Aug. 10-15, 2013, paper: SSC13-III-9, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=2931&context=smallsat
9) Lourens. Visagie, Willem Herman Steyn, Vaios Lappas, “Modular Simulation and Visualization Application for Satellite Attitude Control,” Proceedings of IAC 2011 (62nd International Astronautical Congress), Cape Town, South Africa, Oct. 3-7, 2011, paper: IAC-11-C1.6.1
11) “World's first "phonesat", STRaND-1, launched into orbit,” Space Daily, Feb. 26, 2013, URL: http://www.spacedaily.com/reports/Worlds_first_phonesat_STRaND_1_launched_into_orbit_999.html
13) C. P. Bridges, S. Kenyon, P. Shaw, E. Simons, L. Visagie, T. Theodorou, B. Yeomans, J. Parsons, V. Lappas, C. Underwood, S. Jason, D. Mellor, N. Navarathinam, P. Wellstead, A. Schofield, R. Linehan, J. Barrera-Ars, B. Dyer, D. Liddle, M. N. Sweeting, “A Baptism of Fire: The STRaND-1 Nanosatellite,” Proceedings of the 27th AIAA/USU Conference, Small Satellite Constellations, Logan, Utah, USA, Aug. 10-15, 2013, paper: SSC13-X-3, URL: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=2980&context=smallsat
15) “Smartphone satellite "STRaND-1" operational in orbit,” Space Daily, March 11, 2013, URL: http://www.spacedaily.com/reports/Smartphone_satellite_STRaND_1_operational_in_orbit_999.html
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.