LightSail update: Three steps forward, one step back

A few years ago, when my day job was still IT systems administration, I was troubleshooting a particularly annoying problem in which a heavily-trafficked website was inexplicably shutting down every few days. I couldn’t figure out what was causing the shutdown, but as a test, I configured the server to preemptively restart the website every night at 4:00 a.m. when fewer people were likely to be using it. 

It worked—the random outages stopped. However, I still had no idea what caused the initial problem. Should I declare the website fixed, and move on to the next item on my ever-increasing to-do list?

In a sense, this is the choice the LightSail team currently faces with regard to the spacecraft’s boom deployment difficulties. Using their BenchSat engineering test model, the team has worked around three problems that cropped up during a June 2 boom-only deployment test. Should they call it a day and move on? After all, LightSail 1 is slated to begin a battery of environmental tests in August, and before then, the team still needs to perform a full “day in the life” test to shake out any remaining bugs. 

Alex Diaz, who has been working intently on the deployment hiccups, didn’t hesitate when I asked him this question. “As much I’d just like to move forward, I’d like to understand what the root of the issue was,” he said. The rest of the LightSail team concurs, and the investigation continues.

For clarity, I’ll break down each of the three deployment problems, describe the current fix, and discuss the team's plan for further analysis. 

Processor overload

In my last update, I posted a video of the June 2 boom-only deployment test, in which there are discernible stalls every few seconds as the spacecraft attempts to simultaneously monitor the deployment and send telemetry back to Earth.  

Current fix: The team reconfigured the spacecraft to stop gathering telemetry during boom deployment. As a result, the stalls went away.

Next step: Because sail deployment is one of the spacecraft’s most critical functions, it would be preferable to gather and send telemetry. The team is investigating either storing the data for future transmission or implementing a way to collect and send the information without overwhelming the processor.

Deployment motor power anomaly

As I also mentioned last week, the deployment motor’s power supply is drawing more current than it should, which could potentially overheat and damage the spacecraft’s circuitry. To compensate, the motor executes a tiny time-out every 160 milliseconds. These hesitations are too slight to notice in the video, but they still need to be remedied.

Current fix: As a test, the team instructed the motor’s power supply to limit its power draw by about 10 percent. While they believed this might solve the anomaly, they feared the motor would produce less torque and encounter new problems deploying the booms. 

Surprisingly, the motor produced more torque on this new power setting. Diaz said that because the motor no longer resets every 160 milliseconds, it runs more smoothly than it did at 100 percent power, resulting in a net torque increase.

Next step:  It is important for the LightSail team to understand why the motor was drawing excess current in the first place. Some of the spacecraft’s circuitry has been redesigned to increase power efficiency, which could have allowed the motor to draw the additional current. More testing is needed to see if this is the case.

Boom deployment stops short

This is a problem I haven’t yet mentioned, mainly because I was still getting up to speed on LightSail when it happened, and the team has been focusing their efforts on the previously mentioned issues. So here’s the scoop: during the last boom-only deployment test, the motor stopped short by 17 seconds, leaving the booms a half-meter shy of their final length. 

During boom deployment, LightSail’s sensors watch for a change in voltage each time the motor makes a revolution. These voltage changes increment an internal counter that knows exactly how many revolutions the motor must make to fully extend the booms.

In the process of solving the other boom deployment problems, the team added code to LightSail’s software to make it more robust. In IT terms, robust code helps validate a system is working properly and provides more thorough details when things go awry.

Using their new code, the team was able to compare the readings from LightSail’s sensors with the actual revolutions the motor was making. The results were inconsistent. The sensors were reporting more motor revolutions than had actually occurred. This meant the spacecraft believed its booms were fully extended before they actually were, triggering a premature stop.

Current fix: Diaz said noise in the circuit may have fooled the voltage sensors into recording false motor revolutions. The team has added additional code requiring the sensors to compare their readings with each other. The readings are also cross-checked with a table of expected voltages before the motor revolution count is incremented. Finally, noise filters were installed in an attempt to eliminate the problem altogether.

Next step: More testing is required to verify the problem diagnosis was correct, and that the new code has solved the problem.

That wraps up my update for this week. Next week, I’m hoping to give readers a breather from the motor deployment issues and take a look at Earth’s magnetic field. It’s a fascinating topic that directly affects how LightSail operates in orbit.