SkyCube, a 1U CubeSat that failed to communicate with ground stations after its deployment from the ISS.

CubeSats are challenging

by Charles PhillipsMonday, November 6, 2017

Articles about small satellites (such as CubeSats) that got into orbit but apparently did not function correctly are few and far between. It is often very difficult to tell why a satellite is doing what it is doing: their telemetry can be ambiguous. People speculate about what might have happened but it is hard to get satellite developers to talk about satellites unless they exceed their planned mission.

One thing we might get from projects that don’t work as expected is we establish some good practices that will help us out on the inevitable anomalies.

First, we have to start with some stereotypical things that project managers say. Since the very early days of exploration. people have had to reconcile themselves to the fact that we get a tremendous amount of value from assembling an expedition, and sometimes only from that. Of course we hope that the expedition brings back new discoveries, but putting an expedition together and getting them sent on their way has great value. This is similar to what we have learned while operating systems in space: getting a system deployed is not easy and is an accomplishment in and of itself.

That said, we do learn a lot from systems that just make it into space and do not operate there. One thing we might get from projects that don’t work as expected is we establish some good practices that will help us out on the inevitable anomalies.

CubeSats have been like most new systems, with significant “infant mortality”. According to a paper presented at the 30th Annual AIAA/USU Conference on Small Satellites, about 33 percent of the “DOA” (dead on arrival) satellites have unknown failure causes.1

One example is SkyCube, built by Southern Stars Group, LLC, and designed to echo Twitter messages around the world.

SkyCube was a 1U (unit) CubeSat that was a part of the cargo of the first operational Cygnus flight (called Orb-1; the Cygnus vehicle was named C. Gordon Fullerton in honor of the astronaut) to ISS. It was deployed from the Japanese Experiment Module (Kibo) along with four other CubeSats at the same time. It was deployed after four months of storage. That did cause some concern, but the team had taken precautions to make sure that this storage could be compensated for. Other CubeSats have deployed with this same setup and it worked well. The team had arranged to use four dispersed ground sites to talk to the satellite, all in the United States.

SkyCube was deployed on February 28, 2014, from the ISS and the ground did receive some telemetry that proved it was alive on orbit.2 However, there was some trouble at first trying to establish which satellite was SkyCube, as there were five objects that could have been it. In this situation it is often hard to distinguish among satellites: the satellite catalog has orbital parameters for all of the satellites but they may be misidentified. On March 3 and 4 a signal was detected, so they know that the satellite was operational, the battery was charged, and so on.

Telemetry was received on March 27, which would turn out to be the only actual telemetry received. On March 30, the team was certain that they had identified the right satellite and that it was broadcasting. So they started to send the commands to deploy the solar panels: that would increase the amount of time that the satellite could charge and would also release the radio antennae. So about a month after deploy, they knew that they had built, tested, delivered, and deployed an operational satellite. Now they just needed to get it to do more than tell them that it was alive.

One good resource could be the busy amateur community that likes to listen for the downlink of satellites: a developer probably should have some amateurs lined up to listen just in case they are needed.

However, apparently the solar panels did not deploy and that kept the radio antennae trapped inside them. The satellite had to be in the exact right orientation for telemetry to be received and, with a limited number of ground sites, the satellite was not in that orientation often enough. Perhaps the satellite was in the exact right configuration on March 27 and over a ground site, but not after that.

One potential lesson is that the more potential ground sites you have, and the more dispersed they are, especially for the critical activation phase, the better. One good resource could be the busy amateur community that likes to listen for the downlink of satellites: a developer probably should have some amateurs lined up to listen just in case they are needed.

The SkyCube antenna design is another lesson learned. It was under the solar panels so if they did not deploy the antenna would have been covered, and so the radio signal would not be heard well. A potential lesson learned is to have any antennae built so that they are able to extend as soon as the satellite is deployed.

Tim DeBenedictis, in a letter to me, said, “Analysis indicated that the most likely cause of failure was non-deployment of the satellite’s solar panels. However, not all evidence was consistent with this finding. A radio hardware failure, though less likely, could also have been the cause. Repeated testing of the solar panel deployment mechanism on the ground could not reproduce the failure, either.”3

So why didn’t the solar panels deploy? SkyCube had nylon thread on it that kept the solar panels against the body of the spacecraft and a NiChrome wire loop that would cut the thread once the satellite is commanded to do that. Either the thread did not release or perhaps the solar panels had some sort of “stiction” that held them against the satellite.

One thing to note is the satellite was built and tested and this was briefed to NASA, who then requested changes to retention, deployment mechanisms, and the electrical power system. The satellite was tested after this, but sometimes late changes in configuration can cause unexpected performance later. After modification it was delivered to NASA in early May 2013.

Tim and his team presented results at a conference in late April 2014 and at that time they knew that, of the 28 CubeSats deployed from the ORS-3 flight (a different flight that had good statistics for satellite activation), half had not been heard from. One satellite was silent for two and a half months but then did respond to commands from the ground.

The second example is BisonSat, a 1U CubeSat built by Tim Olsen, Thomas Trickel, and their team at Salish Kootenai College in Pablo, Montana, beginning with a NASA award in 2010. This satellite had a camera on it, and the camera was pointed by passive magnetic stabilization. Over the northern hemisphere the satellite would point down, while over the equatorial regions it would point perpendicular to the Earth’s surface. Apparently in the southern hemisphere it would point out to space. The BisonSat team hoped to do Earth resource missions: take photographs of the Earth below them and document the conditions seen.

It was integrated into its deployment system with two other CubeSats on March 25, 2015, and launched on an Atlas V rocket from California on October 8.4

A good practice would be to design the receive antenna so that it extended as soon as the satellite was deployed.

The BisonSat team built their own ground station at the college5 and planned to have fairly limited contact with the spacecraft: possibly only one good pass per month, according to a presentation they produced. Some communication was received on launch day (apparently by people at California Polytechnic) and the next day by amateur radio operators in Europe. It was again heard from, by amateur radio operators, in late October of 2015 and late January of 2016. But the ground station was never able to command the satellite.

Tracking this satellite (given catalog number 40968) might have been more difficult since it was launched with a National Reconnaissance Office payload and so the orbital elements were not publically released. As I said earlier, on flights where several small satellites have been released it has often been difficult to tell which is which. Hopefully the BisonSat team attempted to communicate with every small satellite deployed on that launch, just in case they had been given orbital parameters that applied to a different satellite. But if the orbital parameters had been public, a larger group of amateur observers might have had a chance to listen for it.

With a perigee of 523 kilometers in late 2015 it certainly is still in space. The satellite catalog does not show BisonSat as being decayed, but that information is only sporadically released for some of these national security launches; none of the objects put into orbit with that flight are shown as decayed. One significant resource for which CubeSats operated, a table maintained by Bryan Klofas,6 does list a status for CubeSats but has a few errors: BisonSat is shown there as operational.

This case may also be one where the team could have communicated with the amateur community before launch and gotten them to listen for the satellite. But since the amateur community would have had a difficult time getting orbital parameters for any of the satellites deployed, they would have had more of a challenge to know when to listen for it.

In his letter to me, Trickel said “Analysis indicated that the most likely cause of failure was the non-deployment of the satellite’s receive antenna.”7 So again possibly a good practice would be to design the receive antenna so that it extended as soon as the satellite was deployed. Presentations on BisonSat say that the antenna was deployed on orbit by switching on resistors that burn through monofilament lines; this sounds like the way that the SkyCube solar panels should have been deployed. Since the BisonSat team never was able to command the satellite, likely it never got the command to energize those resistors.

Not all anomalous behavior is from the same cause, as is shown by a satellite that was also deployed on the same flight, the Alaska Research CubeSat 1 (ARC1), which also did not apparently turn on. This was built by a team including Dr. Denise Thorsen at the University of Alaska Fairbanks and was designed to validate a low-power attitude control system and a high-bandwidth data transfer system.

ARC1 was delivered for flight on March 25, 2015, and launched on October 8. Apparently it did not activate and no signal was received on the ground. Thorsen said that her team was given orbital parameters on all of the satellites deployed on that mission, so they could listen to each in case they were mistagged, but none of them had a beacon on the right frequency.8 Post-flight assessment indicated that an activation switch might have not operated correctly.

The fourth example is AESP-14, a 1U CubeSat developed by students and staff of the Technological Aeronautics Institute (ITA) in Sao Paulo, Brazil. Three people involved in that project exchanged email with me: program manager Pedro Lacava, project mechanical engineer Eduardo Burger, and project electrical engineer Cleber Toss Hoffman.

AESP-14 was also deployed from the ISS using the same mechanism as SkyCube. It was delivered to the ISS by a Dragon cargo capsule launched on January 10, 2015, and was deployed on February 5. When no telemetry was received, the team appealed to the Brazilian amateur radio community to listen for it.9

When asked about the potential reasons for the lack of communication, Burger said:

We don’t think the problem was the long storage time which discharged the batteries. We keep here in our lab the same battery in same conditions to check voltage, and it remains at good voltage levels after long storage time.

The most probable cause of this failure is the antenna deployment, which we think was not too reliable with the burning dyneema wire the way that we set it. Also, the transmitter was settled to run just after antenna deployment switches are deactivated.

For the next mission we intend to put some redundancies and improve this antenna deployment mechanism.10

Hoffman also sent an email where he said that the problem was in the antenna deployment.11

The AESP program manager, Pedro Teixeira Lacava, said in a letter to me, “Analysis indicated that the most likely cause of failure was non-deployment of the satellite antenna. However there is no evidence of such failure.”12

In his most recent email, Burger said that they had some concerns with the antenna after thermal vacuum testing but that it had passed that testing. 13

But it is interesting that of the CubeSat developers that I have been able to talk to, three indicate that a potential problem could have been a failure to deploy the antennae, and all three apparently depended on melting a loop that secured the antennae.

So here again there was something that constrained the antennae until the team on the ground commanded them to be cut loose. Also apparently the transmitter was designed to work only after the antenna deployment was confirmed by switches. This is possibly another example of where a retention device was implicated in a failure to deploy.

Researching this article was challenging since it is very difficult to get good information regarding satellites do not operate as designed. Once you have a list of them it is hard to get information about potential failure paths. Some companies have policies about not commenting about if a satellite is functioning or not.14 CubeSat developers are scattered around the world and also tend to not be inclined to answer email. But it is interesting that of the CubeSat developers that I have been able to talk to, three indicate that a potential problem could have been a failure to deploy the antennae, and all three apparently depended on melting a loop that secured the antennae. One additional CubeSat developer concluded that a separate switch was the most likely cause of the satellite being non-responsive.

It also seems that CubeSat developers plan on limited communications paths when they may need as many as they can get and there are people out there who are willing to help.

One good practice that might be adopted by future small satellite developers is to notify the amateur community of upcoming missions. The developer could make the details of telemetry available before deployment, just in case the community could help in an anomaly. Burger, for example, noted they did alert the Brazilian amateur radio community.

Of course, this is not a statistically large population of satellites, but rather anecdotes at best. But the sites that are out there do not make it easy to determine if a satellite actually worked or not. One very comprehensive site, Mike Swartout’s site has a lot of information but you have to look closely to see which ones might have worked as designed. Bryan Klofas’ site is very good but has a few mistakes.

Acknowledgements

The author would like to thank Tim DeBenedictis, Denise Thorsen, and Eduardo Burger. DeBenedictis greatly helped me understand what might have happened with the SkyCube satellite that should contribute to success of future projects. Thorsen was very patient in answering my questions. Burger reviewed this article and offered several improvements.

Charles Phillips is a long-time space industry veteran. He is a retired USAF Lieutenant Colonel who started his career in 1978 working as an Orbital Analyst in what would much later become the JSpOC. At the time this was in the Cheyenne Mountain Complex, Colorado. From there he went to be a Senior Director at Clear AF Station, Alaska, at the Ballistic Missile Early Warning System (BMEWS) radar site. As an Active Duty Air Force officer he was a Space Shuttle flight controller and was stationed at the Johnson Space Center during the STS 51-C, 51-J, and 51-L, STS 26 and 27 missions. Then he was a flight controller for Spacelab Life Sciences-1 (STS-40) and supported Spacelab Life Sciences-2 (STS-58). Since then he worked on the ISS Human Research Facility, the NASA/Mir program, and did Space Shuttle and ISS safety.