Blog

Few missions more acutely embody the maxim “space is hard” than Atomos Space’s first demonstration mission, which the company has managed to pull back from the brink of disaster — more than once.

That demonstration mission, dubbed Mission-1, launched to orbit on a SpaceX Falcon 9 rocket on March 4. The objectives of the mission are ambitious to the extreme: The two spacecraft — an orbital transfer vehicle called Quark-LTE and a target vehicle called Gluon — will eventually demonstrate extremely complex maneuvers including rendezvous, docking, orbital transfer and on-orbit refueling.

The company has faced two main issues related to communications and the spacecraft rotation rate — and it’s (largely) solved both problems, despite enormous constraints, infrequent data packets and extremely limited bandwidth. (So limited, in fact, that the team has had to cap its flight software updates to a string of text that is just 145-characters long.)

“It’s been relentless,” Atomos CEO and co-founder Vanessa Clark told TechCrunch.

The company’s COO and co-founder, William Kowalski, agreed. “What makes it so hard, even in our situation, we’re trying to extrapolate the status of a very complicated system from maybe 100 bytes of data,” he said. “It’s a lot of, you’re making guesses as to what is driving this, knowing that some of those guesses could take you down a path where you never recover.”

The issues started just hours after the two spacecraft, which are mated together, deployed from the Falcon 9 upper stage. Deployment was nominal, and Atomos received its first ping from the spacecraft seven minutes after deployment. The mood was celebratory.

But then 40 minutes went by until the company got its next ping. Then two more hours after that. Then eight hours.

Atomos was expecting data packets every couple of minutes.

“The worst [day] was the Monday when we launched, that evening,” Kowalski said. “It was 11 o’clock at night, it was me and the chief engineer … and we haven’t heard anything, and we’re just thinking, did we fail? Did they die? We gave it a shot, and it just didn’t work. That was really a gut punch.”

Mission controllers only identified the root cause 24 to 48 hours after deployment, and they did so with the help of another company with assets on orbit. After pulling some strings, they were able to get on the phone with the chief systems engineer of satellite communications company Iridium. The spacecraft were using Iridum-supplied modems, in addition to using Iridium’s constellation as their relay satellites. Atomos’ spacecraft were moving too fast, and in direct opposition, such that they couldn’t perform the data “handshake” with those Iridium satellites to actually transmit information back down to Earth.

Atomos engineers ended up pushing a series of software updates that removed the duty cycling of the radios, and modifying the recovery modes in the spacecraft so that the radio would always be on, even if the spacecraft was in a low-power state.

As engineers were trying to fix the communications problem, however, they faced a different issue: The spacecraft were tumbling at an extremely rapid rate of 55 degrees per second (they were designed to deal with a roll rate up to 5 degrees per second). In addition, the spacecraft were slowly rotating so that the solar arrays were no longer facing the sun. That meant it was a race against time — and against the spacecraft batteries dying completely.

“We had two graphs,” Kowalski said. “We graphed out our power trend on when we think we’d then be pointed to the sun and be [at] normal power, and our detumble rate. It was get the detumble rate to zero before the power goes to zero.”

The issue was exacerbated by the limited comms; the teams didn’t realize something was wrong until the fourth day after deployment, and the spacecraft could only digest new commands in-between long periods of what were essentially communications blackouts.

Slowly, over a period of days, they were able to slow the spacecraft. The team got another major win when it managed to establish high-bandwidth comms, a space-to-space link on the Quark-LITE that talks over the Inmarsat network. The company made the first attempt to get on the high-bandwidth comms Thursday, and they successfully maintained comms with the spacecraft for six minutes.

During that period, mission controllers received 17 times more data than they had since launch. This has provided mission controllers with immense amounts of data on the spacecraft health. Not all the news was positive — one of the battery packs on the OTV was hit hard by the aggressive cycling, and it seems like the GPS needs to be reset onboard one of the spacecraft — but these are easy fixes, Clark said.

By Tuesday or Wednesday, the company is aiming to start commissioning the propulsion system. If all goes to plan, and engineers can establish that the prop system is providing pointing accuracy and control, they will turn off the torque rods and reaction wheels. The company aims to separate the spacecraft in around a month’s time, with the aim of completing all the mission objectives by the end of June.

Kowalski and Clark credit some of the startup’s success to the fact that it’s highly vertically integrated. The team — which pulled a 100-hour week in that first week after deployment — was able to bring its intimate knowledge of the spacecraft design to problem-solve the issues that came up.

“It’s obviously been very painful, but it’s like the CEO of Nvidia says: ‘I wish upon you great suffering.’ We have gone through that and it wasn’t great in the moment, but now that we’re through the thick of it, we’re definitely more accomplished,” Clark said.