LightSail Workshop Recaps Lessons Learned from Test Mission

Last week, the entire LightSail team descended on a hotel conference room in Pasadena, California, just a short walk from The Planetary Society’s new headquarters on South Los Robles Avenue. The office space was still a hub of construction activity as workers assembled furniture and installed network cables. LightSail planning, therefore, had to move elsewhere.

It was the first time the core team had been together since a similar meeting last December, and the first reunion since the test mission wrapped up in June. When Ecliptic Enterprises Corporation's Alex Diaz, Riki Munakata and Stephanie Wong arrived, I remembered a skit from Saturday Night Live where a star-struck Chris Farley awkwardly interviews Paul McCartney. 

"Hey," I said, walking up to the engineers. "You remember that time you deployed a solar sail in Earth orbit?"

"That was awesome."

LightSail's 25-day test mission was a success, but not for a lack of drama; we’d prefer the next mission to be less anxiety-inducing. To that end, the LightSail team, now under the direction of project manager David Spencer, met for two days to discuss lessons learned and solidify plans for moving forward. LightSail's current delivery date is December 1, 2015. The launch of the CubeSat and its partner spacecraft, Prox-1, is scheduled for September 2016 aboard a SpaceX Falcon Heavy. With the loss of a Falcon 9 rocket last month, there’s a chance that could be delayed—but we’ve received no official word thus far. As of now, Spencer and Ecliptic, LightSail’s primary contractor, have five months to finish hardware and software modifications, complete testing and hand over the spacecraft.

Here are some of the major lessons learned from the test mission, as well as proposed corrective actions. This is not all-inclusive; the team has dozens of spreadsheets, action items and problem reports beyond the scope of this article. Some big-ticket items not listed include Barbara Plante’s work on preparing the attitude control system for solar sailing, an overhaul of the spacecraft’s software system by Cal Poly’s John Bellardo, ground station upgrades at Georgia Tech, and a plan to support and leverage the worldwide radio tracking community. 

Invalid imagery

While the team was able to download a complete, sails-out image from camera 0—as well as a second, partial image showing slices of Earth—no sails-out images were successfully compiled from camera 1, located on LightSail's opposite side. Our complete inward-facing test image also came from camera 0 (we did receive a partial image from camera 1 in the stowed configuration, but moved on to the next operational phase before the image was complete).

Perhaps most importantly, we didn't get any usable images captured during the sail deployment sequence from either camera. The lone sails-out picture was obtained only after clearing both cameras and snapping new image sets.

The invalid images we received on the ground contained repeating hexadecimal patterns, and cannot be compiled into viewable JPG files. The Aerospace Corporation, which built LightSail’s cameras, says they have seen this problem during lab testing, but no definitive cause has been found.

In an attempt to recreate the problem, Alex Diaz and Riki Munakata are performing end-to-end tests with BenchSat, the acrylic-mounted LightSail clone. Ecliptic will eventually test the cameras in a thermal vacuum chamber to simulate a space-like environment. Newer versions of the cameras are available from Aerospace, so the team is assessing how many software and hardware modifications would need to be made in order to upgrade.

Radio failure

Four days after LightSail finished sending home the image of its sails in space, the spacecraft’s radio began transmitting a wail of continuous gibberish. Doppler plots of the signal show two, unbroken lines—normal plots should include breaks as LightSail talks, listens, and talks again.

Neither Cal Poly nor the radio provider, Tyvak Nano-Satellite Systems, has ever seen this behavior. Like the camera problem, the team hasn’t been able to reproduce the situation in the lab. Was it a hardware or software failure? LightSail was rebooting regularly at this point in the mission—did the problem persist across reboots? We can’t say for sure, since we never received any more telemetry.

In any case, the radio system is being upgraded to a newer version, and a new watchdog system is being implemented to kick the spacecraft into various safe modes when things go wrong (more on that in a bit).

Power system fault protection

We lost contact with LightSail (for the second time) shortly after solar panel deployment. The working theory is that the power system tripped into a fault protection mode where the batteries were overcharged in sunlight and undercharged in darkness. Prior to this incident, LightSail’s fault modes were not well-characterized. That’s the NASA-speak way of saying there wasn’t a thick binder full of flowcharts and schematics that could easily show the team what was happening and how to fix it. Ecliptic’s Alex Diaz will take charge of this with the help of the LightSail's newest subcontractor, Aquila Space.

All eight battery cells have been replaced, and once the the power system has been characterized, the battery board may be re-spun—physically altered, that is. The goal is to obtain more discreet control over individual circuits and bring the spacecraft partially back to life in the event of a problem. Additionally, more software logging will be enabled to show the team exactly what is happening.

Safe mode

The first LightSail contact loss was caused by a runaway, spreadsheet-like file that froze the flight software, leaving us waiting for the spacecraft to reboot on its own. That software glitch has already been fixed, but the incident highlighted the need for a more robust safe mode.

John Bellardo is leading the effort to overhaul LightSail's software. There are both hardware and software-based failsafes that can be implemented. A software watchdog can periodically check certain processes and reboot the spacecraft if certain conditions are met. The hardware failsafe monitors certain spacecraft subsystems for activity. In both cases, the idea is relatively straightforward: If the spacecraft isn’t doing what it’s expected to do, reboot it.

What happens after a reboot is still being worked out. Because the test mission spacecraft rebooted often, several minutes of many critical ground station passes were spent on housekeeping tasks like turning on the radio and returning the spacecraft to its prior state. Much of that can be automated.

But should LightSail always return to its previous state after an unplanned reboot? As an example, what if the spacecraft is solar sailing—automatically tacking back and forth each orbit to accelerate—and it blips off and on? Should it keep sailing, or stop and wait for instructions? Different scenarios might call for different safe modes. In the previous example, LightSail might be programmed to resume solar sailing unless it reboots again within a certain time frame. If multiple reboots occur, the spacecraft might switch to a minimal power mode and orient itself for optimal communications.

Boom fiducials

How far out did LightSail’s sail booms get during deployment? Several estimates came in at more than 90 percent. It's understandable if you think that’s optimistic—I struggled with this question myself (at one point, I was attempting to count individual sail segments in Photoshop).

Compare our in-space image with a photo captured during a sail deployment test:

In the in-space image, the end of the center boom is a bit higher. That's because it's flexing in weightlessness rather than lying flat on the deployment table. Additionally, LightSail was tumbling rather than being actively stabilized by an attitude control system. Without additional imagery, it's hard to say exactly how much flexure was happening, but getting thumbnails of images captured during the deployment sequence will be a big help during the primary mission.

Secondly, the edges of the sail have been hand-smoothed in the lab image—this must be done before the sail can be re-folded. Unfortunately, a pre-smoothed lab image was not taken after the sails had been fully tensioned, so this is the best analog we have. The Mylar tends to stick to itself, so there is definitely some bunching occurring in the in-space image. Since the sail is not completely taut, some of the bunched material appears to go over the visual horizon. When combined with the low sun angle (rather than the lab's overhead lighting), I realized it wasn't possible to count the number of sail segments visible in the frame.

The only other deployment percentage indicator is a motor count that shows up in spacecraft telemetry. But that value doesn't persist across spacecraft reboots. When the sail was deployed on June 7, motor counts were at a near-perfect 50 percent as the spacecraft moved out of range. After LightSail came back into contact, those counts were back to zero—a reboot had occurred.

The motor count values can be made to persist for the second mission. But even that isn't enough—after all, what if the motor behaves differently in space? To answer the question of boom length definitively, we need fiducials—visual marks on the sail. These could be something as simple as small numbers or colored markings. Ecliptic’s Stephanie Wong is currently investigating the options.

Laser ranging

LightSail’s place in space can be derived several ways. The most accurate method is bouncing ground-based lasers off the spacecraft's "corner cubes"—segmented, concave, mirrors installed in several spots throughout the chassis.

Shortly before the test mission began, an analysis by Ecliptic and Georgia Tech showed the spacecraft's design had not placed the corner cubes in locations likely to result in a successful laser ranging. That conclusion was borne out during the mission; several attempts from observers around the world came up empty. Here's an example:

Refining LightSail’s position is even more important for the second mission, since it will be flying in formation with its partner spacecraft, Prox-1 (at one point, the two spacecraft will be just 50 meters apart). There's no easy way to move the existing corner cubes to more favorable locations, so Ecliptic is investigating adding a cylindrical extension nicknamed the "tuna can." The can, which is defined under official CubeSat specifications, would extend from the rear of the spacecraft (at the expense of two solar panels), and contain new mirrors for laser ranging.

Burn wire

LightSail’s deployable solar panels are held shut against the spacecraft by a fishing line-like material called spectraline. The spectraline loops through a Nickel-Chromium wire coil. At deployment time, the coil heats up, breaking the spectraline, which allows the panels to hinge outward.

This system required a last-minute redesign after LightSail’s first round of vibration testing last November. The panels, which were already loose due to a persistent bowing problem, tugged on the spectraline until the coil snapped loose. If this had happened during the mission, it would have been catastrophic—no panel deployment means no solar sail deployment. Despite the redesign and success of the test mission, the system remains a single point of failure. Ecliptic is investigating what modifications can be made to add a second, redundant coil in case the first fails.

Solar panel deployment switches

During LightSail's May 20 launch, the spacecraft's solar panels indeed pulled on their spectraline—not hard enough to break the burn wire, but enough to prematurely throw a set of switches used to indicate a successful panel deployment. 

Because prolonged storage has caused the solar panels to bow, they no longer fit tightly against the spacecraft exterior, and thus, the deployment switches. Ecliptic is looking into switches with longer throw distances, or the possibility of adding small extensions to the existing switches.

The team might also opt to leave the switches alone. During the test mission, we saw other data to indicate a successful panel deployment, including a change in rotational rates and a large temperature drop as the panels moved farther away from the spacecraft. With so much to do in so little time, fixing this problem has a comparatively lower priority.