What Images Will We Get Back from the LightSail Test Mission?
In the March issue of The Atlantic magazine, there’s a brief meta-analysis on scientists’ relationships with superstition. The article cites a variety of studies showing that when it comes to something as intangible as luck, scientists are often no different than the rest of us. The article, by Matthew Hutson, opens with this anecdote:
A visitor once asked the Nobel Prize–winning physicist Niels Bohr whether he really believed that the horseshoe he’d hung at his country home was lucky. “Of course not,” Bohr said. “But I understand it’s lucky whether you believe in it or not.”
With less than two weeks remaining before the May 20 launch of The Planetary Society’s LightSail test flight, the team behind the solar sail spacecraft continues to prepare for orbital operations. Late last month, I brought you the story of LightSail’s Operational Readiness Tests, where flight controllers in California and Georgia carried out simulated, mission control-like ground station passes. Those tests revealed a software bug that will prevent the test spacecraft’s attitude control system, or ACS, from functioning properly. Some of LightSail’s sensor data may also be blocked from inclusion in the spacecraft’s automated telemetry chirps.
Finding and fixing bugs like this are part of the reason for having a test flight in the first place. But even though the mission’s goal of demonstrating a sail deployment is unaffected, a disabled ACS complicates the situation. Communications will be challenging, ultimately jeopardizing the downlink of onboard camera imagery. And while there are other options for verifying sail deployment, such as ground-based telescopic observations, it would be nice to finish the mission with a pretty picture of the sails from Earth orbit.
I’ve spent the past several days trying to understand the implications of the ACS bug in order to report on whether or not we should expect any images. The numbers tell us it should be possible. But experiences reported by a similar CubeSat team shows us the math doesn't always reflect reality—orbital communications can be more persnickety than predicted. Ultimately, we won’t know for sure until we try—no later than 28 days after launch, when the sails are scheduled to deploy.
Which brings us back to Niels Bohr's horeshoe. Do you believe in luck?
What's the big deal about a tumbling spacecraft?
Georgia Tech aerospace engineering professor Dave Spencer, along with student Sean Chait, ran orbital simulations on how LightSail will behave after it is ejected from its P-POD on the Atlas V rocket. Without an ACS to stabilize the spacecraft against Earth’s magnetic field, LightSail will tumble.
But how much? Spencer and Chait came up with two scenarios, based on estimated P-POD “tip-off” rates (the net forces applied to the spacecraft by the coiled spring inside the P-POD). The most likely case was a rotation rate of one, one, and one-half degrees per second about the X, Y and Z axes. This means LightSail is expected to complete a full revolution on its X and Y axes every 72 seconds, with a Z-axis rotation every 180 seconds. Georgia Tech also came up with a worst-case scenario of five, five, and two degrees per second about X, Y and Z. The math for that scenario is six minutes for X and Y, and 12 minutes for Z.
Using those rotational rates, Spencer and Chait modeled the spacecraft’s orbit for two weeks in both its CubeSat and sails-out configuration. Despite an early proposition that LightSail’s 32-square-meter sail might stabilize edge-on against atmospheric drag, the simulations suggested otherwise. Even when accounting for solar radiation pressure (the same force responsible for solar sailing), the models showed LightSail continuing to rotate at roughly the same rates throughout its orbit.
Jason Davis / The Planetary Society
LightSail flight unit with labeled axes
This photo of the LightSail flight unit shows the labeled +X and +Y axes. The +Z axis points downward through the center of the spacecraft.
To establish a communications link with either Cal Poly or Georgia Tech, LightSail’s antenna must be pointed within five to 92.5 degrees of the ground station. (Why five degrees? Counterintuitively, at a direct, zero-offset angle, communications don't work—because physics.) The purpose of the ACS was to keep the spacecraft stabilized within this range. Now, without a functional ACS, LightSail will tumble in and out of communications during a typical ground station pass.
Here are a few sample passes showing the typical offset angle between LightSail and its ground station target. Communications are only possible when the blue line is between the red and green lines.
Dave Spencer / Sean Chait
LightSail antenna offset during sample Cal Poly ground station passes
Dave Spencer / Sean Chait
LightSail antenna offset during sample Georgia Tech ground station passes
A glance at those diagrams reveals slices of communications time will be lopped out of each pass. How much time? Spencer and Chait’s two-week simulations showed a 50 percent reduction for LightSail in both the CubeSat and sails-out configurations.
During the sail deployment sequence, LightSail’s two cameras automatically snap up to 32 images each. (I explained the “up to” qualifier in a previous article—basically, the camera must take the time to compress each image to fit a 256-kilobyte slot. If the compression algorithm is still processing when the next image capture command is issued, that command will be ignored.)
Back in September during LightSail’s day-in-the-life test, camera 0 captured 18 images, and camera 1 captured 19. Each image comes paired with a low-resolution thumbnail. The full-resolution images increase in size as the scene grows more complex, which corresponds to a growing amount of sail material visible in the frame. The largest DITL image was 251 kilobytes and was taken at the end of the deployment sequence.
The thumbnails, in turn, are compressed into two database files. The thumbnails from camera 0 added up to 40 kilobytes, with camera 1 ringing in at 52 kilobytes.
All told, if our mission results mirror the day-in-the-life test, we'll need to download 343 kilobytes of data to get all the thumbnails and a high-resolution image.
The Planetary Society
Final LightSail onboard camera image
This was the final automated image captured by camera 1 during LightSail's September 2014 day-in-the-life. The file size is 251 kilobytes. The sail is not fully deployed because engineers had yet to determine the final motor revolution count required for tensioning.
A mere 343 kilobytes—from space
The next step is figuring out whether it’s doable to download that much data from a tumbling LightSail before it reenters the atmosphere.
Last year, the folks at Georgia Tech ran a two-month simulation of LightSail’s test mission orbit to see how often it would fly within range of Cal Poly and Georgia Tech. They calculated an average of 7.6 total ground station passes per day, with an average duration of 349 seconds each.
Remember, the LightSail test mission’s orbit is low enough that atmospheric drag will quickly doom the spacecraft to reentry once the sails are deployed. In spaceflight parlance, the nominal lifetime is two days. LightSail could hold on longer if we’re lucky (Bohr again!), but for now, we’re keeping the projection conservative.
With the ACS bug cutting our communications budget in half, we end up with about 15 ground passes over two days, with 44 minutes of communications time. LightSail transmits at 9600 bits per second, so that comes out to a total data budget of 3,183 kilobytes, or 3.18 megabytes. More than enough to grab 343 kilobytes, right?
Data in, data out
Unfortunately, there’s another problem introduced by the spacecraft’s rotation that we haven’t accounted for. When our ground stations send LightSail a command to begin transmitting a file, the entire file queues up in the spacecraft’s data buffer. The radio fires away, but there isn’t any fancy two-way data checking that helps LightSail make sure the ground station is actually receiving the data.
Instead, the radio transmits until the data buffer is empty. Refer back to those sample Cal Poly and Georgia Tech ground station passes, and you’ll see the problem: If the time to clear the buffer is too large to fit into one of those slices where the blue line is between the red and green lines, some of the data will be lost—fired uselessly into space. For any given file transfer, depending on the position and orientation of the spacecraft, we might get a chunk of data, miss a chunk of data, and repeat—until LightSail travels out of range.
What happens to the data we miss? We have to ask for it again during the next pass, or, if we’re fast, we could try asking for it again on the same pass when the spacecraft rotates back into communications.
This will inflate the number of ground station passes required to grab a single file. By how much is difficult to say—as you can see from the samples, there are a wide variety of pass types.
That didn’t satisfy me, so I set out to find the answer using an admittedly convoluted (but still valid, I believe) estimation system. First, I opened those sample passes in Photoshop and measured the number of pixels between each pass’s 50-second increment. Using that, I was able to measure the time periods spent in and out of communications range for each pass.
Over all ten Cal Poly and Georgia Tech sample passes, I arrived at an average of 140 seconds in range, followed by 83 seconds out of range. This yields a 41 percent communications degradation—a bit less than Georgia Tech’s 50 percent rate. It’s likely a result of my limited sample size—just ten sample passes versus their two-week orbital simulation. I also calculated the average number of in-range communications cycles per pass to be 1.8.
With LightSail transmitting at 9600 bits per second, an average ground station pass, according to my estimates, will look something like this:
1,343,929 bits of data received
796,830 bits of data missed
1,075,143 bits of data received (80 percent of the first ground station pass)
Recall that the thumbnail databases from the DITL tests were 40 and 52 kilobytes, or 320,000 and 416,000 bits each. Both easily fit within one of those inbound data increments.
What about our 251-kilobyte high resolution image? By my estimates, it will only take two passes to download a single, high-resolution image. In total, that’s just four out of 15 passes to get our data—plenty of room to spare, even with a tumbling spacecraft.
The IPEX CubeSat captured this picture of Earth on Dec. 6, 2013, as it was passing over the Australia coast.
Bellardo said it took eight passes over the Cal Poly ground station to download this image. Those passes occurred over a 54-hour timespan—close, but a little longer than LightSail’s nominal 48-hour sails-out lifetime. Furthermore, IPEX was stable. LightSail will be tumbling.
On the other hand, the IPEX image is 576 kilobytes. LightSail takes lower-resolution images and only needs 251 kilobytes. Additionally, IPEX only had one ground station—Cal Poly. We also have Georgia Tech.
So, back to the original question: What images will we get back from the LightSail test mission?
We don’t know.
The math says one thing, but comparable situations say otherwise. In my opinion, it ends up being a wash—right up against a razor-thin margin. In the days leading up to sail deployment, the LightSail team should be able to learn how to best communicate with our tumbling spacecraft, preparing them for the brief two days in which they can try to download images for the entire world to see. With LightSail bolted to its rocket at Cape Canaveral, and the countdown to May 20 underway, all we can do now is sit back and enjoy the flight.
And maybe hang horseshoes over our desks for good measure.