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: