SkyCube Project Final Report
13 November 2014
Tim DeBenedictis, Southern Stars Group, LLC
Summary
SkyCube was a privately funded CubeSat mission produced by Southern Stars Group, LLC. SkyCube was financed through a successful Kickstarter campaign in September 2012, raising over $116,000 from 2711 sponsors. SkyCube’s purpose was education and public outreach, and had three mission goals: broadcast "tweets from space" heard by amateur radio operators worldwide; to take numerous low-resolution Earth images from orbit, and to inflate an onboard balloon to make itself visible and deorbit at end of mission. Mission sponsors were able to follow the mission’s progress, submit tweets, and request images, through a mobile app for iOS and Android developed by Southern Stars.
SkyCube launched on the ORB-1 commercial ISS resupply mission on 9 January 2014 from Wallops Island, VA, and arrived at ISS on January 12th. SkyCube was deployed into its own orbit from ISS on 28 February. Transmissions believed to be the satellite’s were detected that day, but definitive contact was not established until 27 March. Despite numerous attempts to communicate with the satellite, no further contact was made. This paper examines the probable causes of this outcome, shares some of the lessons learned, and looks forward to ongoing and future developments in the CubeSat ecosystem.
SkyCube Project Final Report p. 2
Satellite Hardware Overview
SkyCube is a 1U CubeSat, 100 x 100 x 113.5 mm in size, with a total mass of 1.3 kilograms. SkyCube was designed to fit the ISIS ISIPOD CubeSat deployer spec. It also fits the Nanoracks CubeSat deployer. SkyCube has four solar panel "wings", each 86 mm wide, which deploy in space to a length of 21.5 cm. When folded for launch alongside the satellite, the solar panels wings extend outward 7.5mm from the satellite's main structure.1
Figure 1. SkyCube in its packed configuration. All dimensions in mm.
SkyCube was certified to meet the vibration/shock survivability standards of NASA-STD-7000, General Environmental Verification Standard (GEVS). It was certified by Nanoracks to meet NASA offgas requirements. Both certifications are available on request.
Inhibits
To meet NASA/Nanoracks safety requirements, SkyCube contains four "inhibit" switches. These prevent the satellite from powering on prematurely or operating unintentionally. One "inhibit" is an RBF (Remove Before Flight) screw, which must be removed before inserting SkyCube into the Nanoracks CubeSat deployer.
1 The folded solar panels make SkyCube slightly too big to fit into the original Cal Poly PPOD deployer. SkyCube Project Final Report p. 3
Figure 2. SkyCube in launch configuration, with annotation.
The other three "inhibits" are deployment switches located at the ends of the CubeSat rails. While any of these three deployment switches are depressed, the satellite cannot physically power on. When the satellite is released into space from the CubeSat dispenser, these switches will release automatically, allowing power to flow from the batteries.
Power
SkyCube is powered by a lithium ion battery pack containing two MoliCel ICR18650J batteries. These 2300 mAh batteries were obtained from ABSL Space Products, a NASA supplier, and certified by ABSL to meet NASA human spaceflight safety standards. Documentation is available on request. Further battery overcharge and over-discharge protection is provided by an industrial battery protection PCB.
The lithium ion batteries are recharged directly by solar panels. These solar panels use space-grade, Spectrolab Triangular Advanced Solar Cells. These triple-junction gallium-arsenide solar cells have been widely used on other CubeSats. They are 29% efficient, maximizing the energy output available from the limited solar panel area. They provide 4 watts of power when fully illuminated.
When packed for launch, SkyCube's solar panels are folded up along the sides of the satellite. They are restrained by two loops of nylon thread, wrapping entirely around the satellite, from top to bottom, at 90° angles. These loops of restraining thread are visible in Figure 2. Forty-five minutes after the satellite powers on, it will cut these loops with a NiChrome burn-wire circuit. Cutting the threads releases the SkyCube Project Final Report p. 4 solar panels. The solar panels are spring-loaded, and spring out underneath the satellite in their deployed configuration.
The satellite's radio antennas are stowed for launch behind the solar panels, so deploying the solar panels also releases the radio antennas.
Avionics
SkyCube's single avionics board, called "Unity", combines the functions of a main computer & data handling (C&DH) board and an electrical power system (EPS) board. Unity was designed for very low power consumption: 20 mA minimum when idle, < 50 mA maximum. Unity is based on the space-proven TI MSP430, a microcontroller with a long flight heritage on other CubeSat missions. Unity's MSP430 microcontroller runs at 20 MHz, with 16 KB of RAM, and 192 KB of code flash storage.
Figure 3. SkyCube overall electrical schematic. Unity combines functions of C&DH and EPS.
Unity contains another 16 MB off-chip flash memory for file storage. A simple, open-source implementation of the FAT (8.3) filesystem is currently used. Unity has a hardware real-time clock (RTC) with a built-in temperature compensation function for accurate timekeeping independent of the microcontroller. All Unity components are certified to operate over a temperature range of -40 to +85 C, and certified to operate in vacuum.
Peripherals devices all connect to Unity by an RS-232 serial bus operating at TTL voltage (3.3V). Unity's serial ports all support data rates up to 1 Mbps, and use a small-format Samtec data connector with retention latch, designed to hold data cables securely in high vibration/shock environments. Unity has three serial connectors. One is multiplexed, and can be shared with up to four serial peripherals through SkyCube Project Final Report p. 5 a special ribbon cable. All in all, Unity can communicate with six separate serial devices simultaneously (although 4 of those 6 must "take turns" talking with Unity.)
The multiplexed serial connector was designed for SkyCube's three serial JPEG cameras.
Cameras
SkyCube contains three VGA-resolution (640x480) cameras, which generate JPEG still images and transmit them over an RS-232 serial bus. These cameras utilize Micron Technology's MT9V011 image sensor and VIMicro's VC0706 digital video processor. Both are commonly used in camera modules for industrial and outdoor security applications, and were selected for their proven ability to operate over a wide temperature range and rugged environmental conditions. They have been flown on high-altitude balloons.
Figure 4. Firmware engineer Chris Phoenix holds one of SkyCube's cameras.
We added improved, infrared-blocking lenses from Edmund Optics for improved image quality and color fidelity. These lenses have focal lengths of 25 mm, 6 mm, and 1.7 mm, providing panoramic, human- vision, and high-resolution fields of view of 120°, 35°, and 6°, respectively. The high-resolution camera has a minimum ground sample distance of 135 meters - roughly the size of a city block.
The National Oceanic and Atmospheric Administration (NOAA) issued a commercial earth-sensing license for SkyCube on 31 January 2013. SkyCube Project Final Report p. 6
Radio and Antenna
SkyCube contains a Colony II (C2) radio developed by Astronautical Development, LLC (AstroDev) for the Boeing Colony II CubeSat bus. Its maximum broadcast power is 2 watts (33 DBm). It receives on 450 MHz at 9600 baud with GFSK modulation, and transmits on 915 Mhz at 57.6 Kbps with BPSK modulation. This is six times the downlink data rate provided by typical CubeSat radios. The C2 radio communicates with Unity over its RS-232 serial bus at 115.2 Kbps.
The antenna and phasing board were also developed by AstroDev. The original radiating elements were gold-plated guitar springs deployed by spring-loaded ABS plastic arms. Numerous difficulties with the design were noted; in initial tests, the arms never successfully deployed the guitar strings, which became stuck inside the CubeSat structure. Also, the steel wire had a tendacy to kink and break.
We redesigned the antenna elements using gold-plated NiTi “memory metal” wire. Folded inside the solar panels but outside the CubeSat structure, these highly elastic wires eliminated the need for springs or plastic arms, and demonstrated a 100% successful deployment once solar panels were released. In RF testing of the flight unit in October 2013, the NiTi intennas showed approx. 2 dB gain over the previous design, probably due to the fact that the radiating elements were straight, not kinked or looped.
SkyCube's C2 radio uses the AX.25 amateur radio data protocol. SkyCube's AX.25 data packets are 256 bytes in length or smaller, and contain a header (specifying the packet length, checksum, etc.) followed by a payload. Payloads within the packets are AES-encrypted. Encryption was required by NOAA to issue SkyCube's commercial Earth-sensing license.
The only non-encrypted SkyCube transmissions are its "tweets from space". Since these are meant to be heard by radio amateurs around the world, SkyCube broadcasts them as AX.25 packets on 915 MHz at 9600 baud, without encryption. No preamble or postamble is applied to the tweets.
Passive Magnetic Orientation
SkyCube contains no onboard guidance or active attitude control system. Instead, the satellite has a passive magnetic stabilization system, consisting of permanent AlNiCo rod magnets attached to the 1U frame. These align the satellite into a stable orientation with respect to the Earth's magnetic field - a technique that has been used with other CubeSats. 3M 1380 magnetic shielding tape was used as hysteresis material.
SkyCube's orbit plane is significantly inclined to the Earth's magnetic axis, so this will result in a torque on the magnets as it moves across the Earth's magnetic field lines. This is expected to turn the satellite slowly around its magnetic axis, completing one rotation every 15 minutes.
The cameras will be rigidly mounted to three faces of the satellite body, looking 90 degrees apart from each other. At any one time, some part of the Earth should be visible in at least one or two cameras. Because SkyCube has no active orientation system, its transmit and receive antennas are omnidirectional.
SkyCube Project Final Report p. 7
Figure 5. SkyCube in its deployed, on-orbit configuration. One camera and balloon compartment lid omitted for clarity. SkyCube Project Final Report p. 8
Balloon and Inflation Mechanism
SkyCube's balloon and its inflation mechanism were designed by Mark Caviezel. Mr. Caviezel has built multiple balloons over a million cubic feet of displacement for NASA, JPL, and other clients from Spain, France, Germany, UK, South Africa, and the USA. He is currently employed by Arrowhead Products in Los Alamitos, CA, specifically as a contractor to the NASA's SLS program. He can be reached by email to [email protected] or [email protected].
The SkyCube balloon is made of 35-mil LDPE, coated with TiO2 powder to enhance its reflectivity. When packed, it fits into the upper 40% of the satellite. Its inflated diameter is approximately 7 ft. The balloon is inflated in space with a 4-gram CO2 cartridge, to a pressure of approximately 0.001 atmosphere.
Inside SkyCube, the CO2 cartridge is placed inside a cylindrical canister, referred to as "gas cracker". The gas cracker has a piercing cap that screws into its base, which holds the CO2 cartridge. As the cap screws in, a piercing pin inside the cap punctures the CO2 cartridge, releasing the gas inside.
Figure 6. Left: CO2 cartridge "gas crackers" shown with 4-gram CO2 cartridges inside. Right: gas cracker cap with piercing pin inside, and rotary spring attached outside. Images provided by M. Caviezel/Global Western.
The motion of the gas cracker is controlled by a rotary spring. The spring is attached to the cap, and wound to a torque of 20 ft-lbs. The cocked spring is restrained by a loop of 65-lb tensile-strength spectra line. NiChrome burn-wire is wrapped around the spectra. On command from SkyCube's microcontroller, the NiCr wire is energized with 1.8 amps of electrical current from the satellite's battery pack. This melts the spectra line, releasing the spring. This screws the cap into the cylinder, piercing the CO2 cartridge inside.
SkyCube Project Final Report p. 9
Ground Communication
SkyCube was designed for compatibility with the Mobile CubeSat Command and Control (MC3) network. MC3 is a new high-bandwidth CubeSat ground station network headquartered at the Naval Postgraduate School (NPS) in Monterey, CA. MC3 ground stations are located at:
• Naval Postgraduate School, Monterey, California, 36° 35' 56" N, 121° 52' 23" W, 23 m • University of Hawaii, Honolulu, Hawaii, 21° 17' 54" N, 157° 48' 59" W, 8 m • Utah State University, Logan, Utah, 41° 44' 27", 111° 48' 52", 1397 m • Air Force Institute of Technology, Dayton, Ohio, 39° 46' 58" N, 84° 4' 56" W, 239 m
MC3 was primarily developed for use with US Navy CubeSats. However, it is also intended for use by other government and university CubeSats.
Southern Stars is the first private US company to secure an operating relationship with MC3. Additionally, we have partnered with Saber Astronautics to use an additional ground station in Sydney, Australia.
Figure 7. Ground track of typical SkyCube orbit, with locations of MC3 and Saber ground stations.
The MC3 network was designed to communicate with the Boeing Colony-II bus, and the same C2 radio that AstroDev has supplied to us for SkyCube, and to Boeing for other NPS CubeSats. For bidirectional communication with SkyCube, ground stations must transmit on 450 MHz and receive on 915 MHz – the complement of the Tx/Rx frequencies used by SkyCube's C2 radio.
However, "receive-only" ground stations capable of hearing SkyCube's "tweets from space" need only receive on 915 MHz, and be capable of decoding BPSK-modulated, unencrypted AX.25 data packets sent at 9600 baud. This should be well within the ability of amateur radio operators worldwide to detect.
SkyCube Project Final Report p. 10
Internet Server
Southern Stars developed a server, skycubedata.net, to communicate with both the Saber and MC3 radio infrastructure. In this architecture, the ground stations are the clients which "dial into" skycubedata.net when SkyCube is passing over their locations. Given SkyCube's orbit and the ground station geometry, a collision between the MC3 and Saber ground stations is impossible.
Clients will connect via SSL on two TCP ports. Client certificate authentication is required on both ports:
• Port 10000: outgoing data, from Southern Stars to SkyCube satellite • Port 10001: incoming data, from SkyCube satellite to Southern Stars
Data exchanged between SkyCube and Southern Stars are divided into packets. This happens twice: first over the radio link between SkyCube and the ground stations; and second over the internet link between the ground stations and Southern Stars' server.
The AX.25 amateur radio data protocol defines the packets exchanged between ground stations and the satellite. Each AX.25 packet contains a header (describing packet length, checksum, etc.) followed by a data "payload" at most 256 bytes in length. AX.25 does not specify any payload format - it can be any blob of ASCII text or binary data up to 256 bytes in length.
When the Southern Stars server sends data to the ground stations, it sends only the payloads. The ground stations are responsible for wrapping our data payloads in AX.25 and radioing them to the satellite. Going the other way, ground stations also "unwrap" AX.25 packets coming in from the satellite to extract the payloads inside. What we get from the TCP/IP link to our ground stations is the "payload" of the AX.25 packets coming in from space - in other words, our own protocol!
SkyCube Project Final Report p. 11
Development and Testing
Two satellites were built. The flight unit (“Alpha”) underwent complete qualifications required by the launch service provider, including shock/vibration testing to NASA GEVS-7000 levels. The backup/spare unit (“Omega”) was not flight-qualified, but used for communication tests and redundancy purposes.
SkyCube’s original design included separate CDH (Computer and Data Handling) & EPS (Electrical Power System) boards, as well as an auxiliary board containing solid-state relays for the nichrome burn wires. These avionics were developed by AstroDev in 2012. Numerous quality problems and integration difficulties were noted; however we proceeded with the hardware as purchased. The flight unit passed all GEVS vibe/shock testing in April 2013 at Quanta Labs in Sunnyvale, CA; vibration tests were re-qualified by Nanoracks in June, 2013.
The solar panel deployment mechanism was tested ~5 times in development, and succeeded 4 of 5 attempts. The single failure was due to low battery levels causing microcontroller brownout when high current was applied to the NiCr burnwires. Firmware was reprogrammed not to attempt the burnwire sequence until battery charge reached 7.5V. All solar panel deployment tests were conducted in air (not vacuum) prior to launch. However, the same mechanism was tested in a near-vacuum (< 3 kPa) in March 2014, and observed to cut 150 lb spectra in < 3 seconds in both vacuum and air. The CO2 balloon deployment (which also used 30 AWG NiCr burnwire to cut spectra restraining spring-loaded pin) was vacuum-qualified, and succeeded on 8 out of 8 tests.
In May 2013, Alpha’s solar panels deployed prematurely while shipping the satellite to Nanoracks for initial safety review. The cause was later determined to be an electrical short which allowed current from the batteries to bypass the inhibit switches. The satellite powered itself on and executed its solar panel deployment sequence while inside FedEx box. After this incident, Nanoracks conducted a thorough review of the EPS design in June 2013.
Following review, we redesigned the multiple CDH & EPS boards into a single “Unity” board in July- September 2013. This reduced board count to one, and reduced inter-board wiring requirements threefold. Thermal vacuum testing performed in October 2013 revealed one firmware issue, fixed; otherwise Unity exhibited no thermal issues over -30C to +90C.
NASA/Nanoracks also requested reinforcement of the spectra lines restraining the solar panels. The concern expressed was that premature balloon inflation inside the CubeSat deployer could harm other satellites or the deployer itself. As a result, tensile strength of the spectra ties was increased from 30 to 150 lbs, and ties were doubled. Together these measures provided a ~4:1 safety margin over the maximum internal pressure generated by premature release of CO2 gas from the balloon inflator.
Extensive communication tests were performed with flight unit at the NPS MC3 ground station in October 2013, and with the spare/backup unit (“Omega”) at Saber Astro in December 2013. Successful transmission of commands, data, telemetry, and image files were all demonstrated at 3 km range. While some “flakiness” was observed, overall data throughput was within the expected range. Signal strengths recorded during those tests indicated that the system should perform reliably on orbit.
Saber noted significant directionality of space antenna based on differing orientation. We also noted this, but did not attempt to quantify the antenna’s radiation pattern. Comms were re-tested in January – February 2014 at NPS using the production Southern Stars server and Omega (the flight unit had been SkyCube Project Final Report p. 12 launched and was on ISS by that point!) Some bugs were removed, but overall communication worked well. We noted that MC3’s radios take a long time to locate peak signal, we increased AX.25 preambles on sat’s 915 MHz responses to 7.5 seconds to compensate. Flight Experience
SkyCube launched on the ORB-1 commercial ISS resupply mission on 9 January 2014 on an Antares booster from Wallops Island, VA. The Cygnus cargo craft carrying SkyCube arrived at ISS on January 12th. SkyCube was deployed into its own orbit from ISS on 28 February along with LithuanicaSAT-1, LITSat-1, UAPSat-1, ArduSat-2 at 07:30 GMT. These objects were given NORAD tracking numbers 39567 thru 39571, though we did not know which number corresponded to which satellite at the time.
Figure 8. Antares/Cygnus ORB-1 launch from Wallops Flight Facility, 9 January 2014.
Shortly after deployment, the satellites entered eclipse over the Earth’s night side. The first pass ~45 minutes later was over the Syney, AU ground station. Nothing was heard by Saber; however no commands were sent to the satellite due to network connectivity issues on the ground; therefore no responses were expected.
SkyCube Project Final Report p. 13
Figure 9. SkyCube deployment from ISS, 28 February 2014, along with LITSat-1, LithuanicaSAT-1, ArduSat- 2, and UAPSat-1. SkyCube is the middle satellite in the “train”. SkyCube Project Final Report p. 14
The first pass over an MC3 ground station took place at the University of New Mexico on Friday 28 Feb ~0800 PST. The ground radio detected carrier, bit lock, bit sync, but did not decode any data. The same behavior from was reported by the SDL ground station (Logan, UT) later that afternoon. We believe these transmissions were SkyCube’s, since they coincided with the beginning and end of ISS passes over those respective ground stations, and no other satellite in the deployment responds on 915 MHz.
Over the next few days, the satellites spread out far enough along their orbits that we could ping each one individually to attempt getting a response. On Wednesday, March 3rd, space-track.org assigned identifications to the 5 NORAD numbers corresponding to satellites in our deployment. This surprised us: if we could not identify our own satellite, how as JSpOC able to? The name assignments later turn out to be arbitrary, and a point of confusion noted both at home and internationally.
Over the next three weeks, amateur radio detections of LituanicaSAT-1, LitSAT-1, and UAPSat-1 let us eliminate 3 of the 5 possible candidate objects, and confirmed that JSpOC’s name assignments were indeed arbitrary. We concentrated on the remaining 2 objects, but did not obtain any responses.
On Wednesday 12 March 2014, Russian radio amateur Dmitry Pashkov UB4UAD reported a possible 915 MHz SkyCube contact. He submitted a SDR waterfall diagram trace that looked like a SkyCube tweet. However, the timestamp of the signal detection, and antenna direction, were consistent with LithuanicaSAT (39569), not with either of our 2 remaining candidates. The object later determined to be SkyCube (39567) was below his horizon at the time.
On Friday 14 March 2014, NPS conducted a radio test using the 60-ft dish at Stanford University to listen for a C2 radio identical to SkyCube’s carried aboard a high-altitude balloon. During the test, both candidate SkyCube objects passed overhead, and both were observed using the Stanford dish. Nothing was heard from either candidate object; however, the C2 radio on the balloon was heard clearly by both Stanford and by the more-distant MC3 ground station in Monterey, CA at ~200 km range.
SkyCube Project Final Report p. 15
Figure 10. Antennas used to detect SkyCube. Left: 20-meter dish at Stanford. Right: UHF Yagi antennas at NPS. A successful bi-directional link was established at NPS, but no signal was detected from Stanford.
Successful Contact
Finally, on Friday 28 March 2014, while conducting a routine review of our server logs, we discovered an unambiguous contact with SkyCube late the previous evening. These were not tweets, but rather two complete command-response sequences. NPS personnel reviewed their own logs the next day, and confirmed the contacts. At the time of the first contact (27 March 2014 at 07:52:47 UTC), the NPS station antenna was pointed at NORAD object 39567, at an elevation angle of about 33 degrees and a range of 700 km. No other candidate object was in view of the NPS station at the time, definitively identifying SkyCube as object 39567.
2014-03-27 07:52:58 ------response received ------2014-03-27 07:52:58 ------response received ------{ { "battery_mV": 8250, "battery_mV": 7712, "command": "SC_GET_TELEMETRY", "command": "SC_GET_TELEMETRY", "header": { "header": { "command": 3, "command": 3, "crc": "ce185b53", "crc": "3cee3c28", "crc_check": true, "crc_check": true, "rssi": 84, "rssi": 81, "sequence": 171 "sequence": 172 }, }, "rtc_time": { "rtc_time": { SkyCube Project Final Report p. 16
"day": 27, "day": 27, "hour": 14, "hour": 14, "min": 55, "min": 55, "month": 1, "month": 1, "sec": 8, "sec": 15, "year": 14 "year": 14 }, }, "solar_mA": [ "solar_mA": [ 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1 1 ], ], "system_time": { "system_time": { "msec": 490, "msec": 12, "sec": 2301535 "sec": 2301542 }, }, "temp": 16.209911346435547 "temp": 16.690961837768555 } }
Figure 11. Decrypted AX.25 command and telemetry response packets received from SkyCube on 27 March 2014, excerpted from Southern Stars server log file.
03/27/14 07:52:52.934 RCVR:MC:STATUS? : Lock 03/27/14 07:52:52.934 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:52.934 RCVR:MC:DEV? : 1472 03/27/14 07:52:52.934 RCVR:MC:LEVEL? : -87 03/27/14 07:52:52.935 RCVR:BS:DEV? : 9 03/27/14 07:52:52.935 RCVR:EBNO:1? : +5.7
03/27/14 07:52:54.000 RCVR:MC:STATUS? : Lock 03/27/14 07:52:54.000 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:54.000 RCVR:MC:DEV? : -58 03/27/14 07:52:54.000 RCVR:MC:LEVEL? : -89 03/27/14 07:52:54.000 RCVR:BS:DEV? : 5 03/27/14 07:52:54.000 RCVR:EBNO:1? : +8.2
03/27/14 07:52:55.064 RCVR:MC:STATUS? : Lock 03/27/14 07:52:55.064 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:55.064 RCVR:MC:DEV? : -1116 03/27/14 07:52:55.064 RCVR:MC:LEVEL? : -86 03/27/14 07:52:55.064 RCVR:BS:DEV? : 4 03/27/14 07:52:55.064 RCVR:EBNO:1? : +9.4
03/27/14 07:52:56.127 RCVR:MC:STATUS? : Lock 03/27/14 07:52:56.127 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:56.128 RCVR:MC:DEV? : -1796 03/27/14 07:52:56.128 RCVR:MC:LEVEL? : -88 03/27/14 07:52:56.128 RCVR:BS:DEV? : 3 03/27/14 07:52:56.128 RCVR:EBNO:1? : +9.8
03/27/14 07:52:57.058 RCVR:MC:STATUS? : Lock 03/27/14 07:52:57.058 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:57.058 RCVR:MC:DEV? : -2283 03/27/14 07:52:57.058 RCVR:MC:LEVEL? : -87 03/27/14 07:52:57.058 RCVR:BS:DEV? : 2 03/27/14 07:52:57.058 RCVR:EBNO:1? : +10.1
03/27/14 07:52:58.122 RCVR:MC:STATUS? : Lock 03/27/14 07:52:58.122 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:58.122 RCVR:MC:DEV? : -2783 03/27/14 07:52:58.123 RCVR:MC:LEVEL? : -87 03/27/14 07:52:58.123 RCVR:BS:DEV? : 3 03/27/14 07:52:58.123 RCVR:EBNO:1? : +9.5
03/27/14 07:52:59.054 RCVR:MC:STATUS? : Lock 03/27/14 07:52:59.054 RCVR:BS:1:STATUS? : Lock 03/27/14 07:52:59.054 RCVR:MC:DEV? : -3157 SkyCube Project Final Report p. 17
03/27/14 07:52:59.054 RCVR:MC:LEVEL? : -89 03/27/14 07:52:59.054 RCVR:BS:DEV? : 1 03/27/14 07:52:59.054 RCVR:EBNO:1? : +9.5
03/27/14 07:53:00.119 RCVR:MC:STATUS? : Lock 03/27/14 07:53:00.119 RCVR:BS:1:STATUS? : Lock 03/27/14 07:53:00.119 RCVR:MC:DEV? : -3585 03/27/14 07:53:00.119 RCVR:MC:LEVEL? : -88 03/27/14 07:53:00.119 RCVR:BS:DEV? : 2 03/27/14 07:53:00.120 RCVR:EBNO:1? : +9.0
03/27/14 07:53:01.050 RCVR:MC:STATUS? : Lock 03/27/14 07:53:01.050 RCVR:BS:1:STATUS? : Lock 03/27/14 07:53:01.050 RCVR:MC:DEV? : -3912 03/27/14 07:53:01.050 RCVR:MC:LEVEL? : -89 03/27/14 07:53:01.050 RCVR:BS:DEV? : 3 03/27/14 07:53:01.051 RCVR:EBNO:1? : +9.5
03/27/14 07:53:02.115 RCVR:MC:STATUS? : Lock 03/27/14 07:53:02.115 RCVR:BS:1:STATUS? : Lock 03/27/14 07:53:02.116 RCVR:MC:DEV? : -4272 03/27/14 07:53:02.116 RCVR:MC:LEVEL? : -88 03/27/14 07:53:02.116 RCVR:BS:DEV? : 2 03/27/14 07:53:02.116 RCVR:EBNO:1? : +9.8
03/27/14 07:53:03.047 RCVR:MC:STATUS? : Lock 03/27/14 07:53:03.047 RCVR:BS:1:STATUS? : Lock 03/27/14 07:53:03.047 RCVR:MC:DEV? : -4627 03/27/14 07:53:03.047 RCVR:MC:LEVEL? : -88 03/27/14 07:53:03.047 RCVR:BS:DEV? : 2 03/27/14 07:53:03.047 RCVR:EBNO:1? : +10.1
03/27/14 07:53:04.112 RCVR:MC:STATUS? : Lock 03/27/14 07:53:04.112 RCVR:BS:1:STATUS? : Lock 03/27/14 07:53:04.112 RCVR:MC:DEV? : -4967 03/27/14 07:53:04.112 RCVR:MC:LEVEL? : -90 03/27/14 07:53:04.112 RCVR:BS:DEV? : 1 03/27/14 07:53:04.112 RCVR:EBNO:1? : +10.9
Figure 12. Excerpts from MC3 radio logs during the period when the receive radios at NPS achieved lock on satellite 39567.
The decrypted telemetry packets indicated a battery level near full charge (8250 mV); solar panel current readings all near zero mA (as expected on a night pass); processor temperature 16.7 C (notably cooler than the 25 – 40 C observed testing SkyCube at room temperature). The satellite’s real time clock reported the date as 2014/01/27 14:55:15 (the RTC initializes to 2014 Jan 1.0 at power-on), and the processor’s reported uptime was 2301542.12 seconds (26.7 days, nearly the time elapsed since deployment). In short, telemetry indicated that the satellite’s electronics and power system were healthy, and that the microcontroller had been operating without interruption or reset for the previous 27 days.
Received signal strength indicators both on the satellite and the ground were notably weaker than expected. (RSSI in command packets received by satellite were -80 & - 84 dBm; RSSI in response packets received by ground were -90 & -96 dBm). NPS personnel commented that these RSSIs were about 10 dB lower than expected. Saber’s ambient noise level (in Sydney) is about -80 dB. Despite the later addition of noise-reduction circuitry, Saber feels that a detection at these very low signal levels would not be possible.
On March 30th, we tested communication with Omega and a ground station near Pumpkin, Inc. in San Francisco. These tests were performed at ranges of 1 and 2 miles, with Omega’s solar panels and SkyCube Project Final Report p. 18 antennas both packed and deployed. We had not previously tested communication in the packed configuration, due to AstroDev warnings against testing the radio with antennas shorted to frame.
These test results showed that the radio was able to communicate bi-directionally with the ground station even with solar panels packed. However, RSSIs were noted to be 9 – 12 dB below values observed with antennas and solar panels in the deployed configuration. One unresolved mystery was noted: when doubling distance from Pumpkin to Omega, RSSIs dropped by 20 dB, both with panels deployed and not deployed. A simple free space path loss calculation would have predicted a drop of 6 dB.
Following the March 27th contact, we tried many different command sequences to cut the solar panel restraints, reboot the satellite, and inflate its balloon. These did not generate any apparent response. On July 8th, further communication attempts were abandoned. No balloon inflation, de-orbiting the satellite, was observed or inferred.
SkyCube Project Final Report p. 19
Questions, Conclusions, Lessons
Several scenarios were proposed to explain the very sporadic weakened signal from SkyCube:
• Intermittent radio hardware failure; • Rapid tumbling/spinning of satellite; • Incomplete solar panel/radio antenna deployment.
SkyCube used a new radio, designed for use with a new, US government-operated network of ground stations. We noted some quality problems with the C2 radio hardware during SkyCube development, including cold solder joints, incorrect power amplification, and removal of checkum validation code in the firmware, leading to corruption in data sent to/from radio via serial link. The manufacturer addressed most of these issues. By October 2013, tests with the Monterey MC3 ground stations showed that our C2 radios could transmit data and images reliably over a range of 2-3 miles.
Two CubeSats with the same C2 radio were launched before SkyCube (Re on NROL-36 in October 2012, and Horus on ORS-3 in November 2013). Neither satellite was heard from on orbit, but the cause of these failures was ascertained to be other than the radio. Obviously these results caused concern, but by this point in our program, it was too late to change radios. SkyCube had already been delivered to Nanoracks by the ORS-3 launch, and changing radios also would have required switching to a different ground network: not possible given the remaining time before deployment.
AstroDev’s CubeSat radios have a largely successful track record on orbit, and we did actually hear from our radio 27 days after deployment. While we cannot rule it out completely, we do not feel that an intermittent radio hardware failure was the likely cause of our communication difficulties.
If the satellite were spinning/tumbling rapidly, one would expect rapid variations in signal strength due to the antenna’s non-isotropic radiation pattern. Such rapid variations could make it difficult for ground radios to lock onto signal. However, no rapid tumbling was observed in the deployment images or videos recorded by ISS. This is one of the main benefits of an ISS deployment – you get to see exactly what your satellite is doing when it’s released from the deployer.
A partial, asymmetric solar panel deployment may have imparted significant angular momentum to the satellite. However, the permanent magnets affixed inside its rails should have dampened any such rotation. For all these reasons, we don’t believe rapid tumble/spin explains our communication problems.
Of the five CubeSats deployed from ISS on February 28th, SkyCube was the last remaining in orbit. We feel this is conclusive proof that SkyCube's solar panels did not open on day 1. If they had, the SkyCube would have had more surface area than any other satellite in the deployment, hence the most drag, and fastest orbit decay.
NORAD No. Int’l Desig. JSpoC ID Correct ID Re-Entry Date 39567 98067EL ARDUSAT 2 SKYCUBE 11/8/2014 39568 98067EM UAPSAT 1 LITSAT-1 5/22/2014 39569 98067EN SKYCUBE LITUANICASAT-1 7/28/2014 39570 98067EP LITSAT 1 ARDUSAT-2 5/23/2014 39571 98067EQ LITUANICASAT 1 UAPSAT-1 7/1/2014
Figure 13. NORAD tracking numbers, International designations, JSpoC’s initial and corrected identifications, SkyCube Project Final Report p. 20 and re-entry dates of the 5 CubeSats deployed with SkyCube on 28 February 2014.
A solar panel non-deployment would explain our other communication problems. As demonstrated by the March 30th tests, antennas folded inside solar panels produced a much weaker signal than in the deployed configuration. This would also explain why the balloon did not inflate: the 150 lb spectra lines restraining the solar panels were deliberately reinforced, to prevent the lid from opening in case of premature balloon inflation. If the tie lines were not cut loose, the balloon could not have punched through the lid.
Our final remaining unanswered question is this: the solar panel deployment mechanism was tested repeatedly on the ground, and worked reliably there. So why did solar panels fail to deploy in space? Possible theories include:
1. Insufficient Burn Time. Pumpkin, Inc. provided results showing that NiChrome burnwire times required to cut spectra increased by 2x-8x in cold & vacuum, to about 15-20 seconds; SkyCube was programmed to fire its burnwires for 10 seconds. However, Mark Caviezel’s balloon inflator tests don’t show any difference between vaccuum or air, cutting 150 lb spectra in < 3 seconds with 30 AWG NiCr in both cases. Our own tests, performed in a homebuilt “near-space” vacuum chamber (pressure < 4 kPa) showed burnwires cutting 150 lb spectra in under 5 seconds.
2. Insufficient battery charge. In testing, we learned that a battery charge below 7.25 volts was not sufficient to power the burn wires. But we programmed the satellite to wait until battery charge was above this level before attempting the deployment. When signal was actually receieved from the satellite, the battery voltage was over 8V.
3. Burnwire breakage. If the burnwires broke, due to mechanical stress or vibration on launch, no amount of current would cause them to heat up! However, the burnwires survived vibration and shock tests more rigorous than the satellite likely received in flight, and we find it unlikely that all four independent burnwires would have broken this way.
4. Stuck Hinges. Perhaps the burnwires worked perfectly, but the hinges stuck. Again, all four solar panel sets would have to have experienced an identical hinge failure. Yet in ground testing we never saw hinges stick, causing solar panel deployment failure even once.
None of the proposed theories are very satisfying, and we may never know the answer. Rather, we view this as a lesson learned: if this is your first satellite, design it without moving parts that are required to deploy for mission success.
One final perplexing question is: why were no tweets heard at Stanford? The 3/27 contact at NPS indicated that the satellite’s processor had been running for 26 days without resets or brownouts; the battery was fully charged. The satellite should have been tweeting every 30 seconds, albeit through folded antennas. If so, how did the 60-ft Stanfard dish miss it, and yet 15-ft Yagis at NPS with much smaller gain, were able to establish a bidirectional closed link?
We can only assume that the geometry of the 3/27 pass over NPS was exceedingly good, considering the non- isotropic radiation pattern of the satellite’s undeployed antenna, while the geometry of the 3/14 Stanford test was very bad. But this is not a very satisfying answer, either.
SkyCube Project Final Report p. 21
Budgetary Overview
The following chart illustrates our program expenditures:
Admin. $9K Ground Ops. $13.5K
Launch Services $96K Software Dev. $62K
Advertising $40K Hardware Dev. $53K
Figure 14. SkyCube Project Budgetary Overview.
Developing software for the satellite, and to talk with ground stations, was a much bigger expense than the hardware itself. Hardware is only a small part of the total. Software, operations, and communications - i.e. the human expenses - far outweighed them, and are just as critical to the mission as the launch itself. In our case, advertising was a significant expense because SkyCube was a crowd-funded project. Advertising costs include Kickstarter & Amazon fees, sponsor rewards (T-shirts, etc.), and media & PR management fees.
Nevertheless, some “spinoffs” emerged from the program, both revenue-generating and otherwise. These include Satellite Safari, the iOS and Android app developed to let end users request images and send messages to the satellite; and SeeDeR, a free Windows-based software-defined-radio application developed to let amateur radio operators directly receive AX.25 “tweets” from the spacecraft in orbit. Both have been positively received, with over 70,000 Satellite Safari downloads to date.
Lessons Learned
Based on our experience, here is some of the advice we would provide for other first-time CubeSat operators.
• Don’t attempt anything deployable on your first CubeSat project! If you must do deployables, include a contact switch so the sat can determine unambiguously if they’ve deployed or not. Include sealed 3-axis MEMS gyro/accelerometer) on satellite mainboard (to determine spin).
SkyCube Project Final Report p. 22
• Find a secondary/backup communication system. Dependence on a single radio, either on ground or in space, invites single-point failure modes. We could have done better in this regard. In particular, we should have engaged with the amateur radio community well before launch. Our satellite also should have beaconed more often than than every 3 minutes! If it had done every 10 – 30 seconds, multiple tweets would have been detectable in a single pass.
• Personnel changes should be avoided. The various issues and systems involved in running an entire CubeSat mission are extremely complex. It takes time and hands-on experience to learn all of their ideosyncracies. Contextual knowledge, and hence ability to make good engineering judgements, will be lost if key personnel leave the program. It is extremely important for program managers to maintain a positive team atmosphere to ensure staff retention, and to record and retain “tribal knowledge” in case a team member departs.
• It’s going to be harder and take longer than you think it is! The appeal of CubeSats is that hardware can seemingly be operated in orbit at a very low cost. However, don’t forget: this is still rocket science. CubeSat hardware is often described as being made of “inexpensive, off the shelf” components. Most of it is not. CubeSats hardware is usually developed to meet aerospace-specific standards in quantities of dozens or hundreds, not consumer standards in quantities of millions. Don’t expect a CubeSat to be as easy to program and operate as a smartphone.
• It’s hard to get a launch. Despite claims of “cheap, easy, frequent” access to space, putting a CubeSat in orbit is not like FedExing one across the country. Unforeseen delays and other program expenses will inevitably creep in. Make sure your program is adequately funded and staffed to handle these situations. A six-month launch delay – not at all uncommon – could result in (for example) a radio communications expert leaving the program, since there is nothing to communicate with in space. When your satellite launches, his or her newly-hired replacement may be missing key pieces of information needed to communicate with the spacecraft. Ensuring funding to retain needed staff for the duration is by far the best way to avoid this problem.
Despite challenges, the field is growing. Our results may have been different if we'd started now instead of 2 years ago. When SkyCube's kickstarter campaign launched in July 2012, CubeSats were an academic curiosity. Up to that point, the greatest number of CubeSats launched in any year was fifteen (in 2010). But more than 23 were launched in 2012, and 82 in 2013. As of this writing, over 80 CubeSats have been launched in 2014, and more will be flown before the year is over.
On our own launch, 28 of the 33 CubeSat payloads were commercial earth-imaging satellites, operated by Planet Labs in San Francisco. In July, NanoSatisfi - whose ArduSat kickstarter preceded ours - announced its transformation into Spire, a global asset-tracking service using CubeSats. The same month, Spaceflight Services announced a new commercial small satellite communication service. Significant venture capital is flowing into the field, and communication challenges are being addressed. Access to space really is getting easier.
Would we do it again? Yes – applying the lessons we’ve learned the first time around. Although our program was under-staffed and under-funded, we did achieve contact with our hardware in orbit. That is a more successful result than many first-time CubeSat programs. Although most of SkyCube’s mission goals have not yet been achieved with this first satellite, we do not regard it as a failure. Rather, it was a tremendous learning experience whose results we are pleased to share with the CubeSat community around the world.