The Spacecraft That Wouldn't Die | Hacker News Reader

The Spacecraft That Wouldn't Die

corememory.com

50 pointstrothamel11 comments

Ah, one of those articles that starts with a few paragraphs related to the title, and then pivots to talk about the childhood of one of the people involved...

I feel your pain. Skip a few paragraphs and it gets back to the subject at hand

So the way I see it is fundamentally there was an issue with receiving signals on the spacecraft and that caused issues. I'd really like to know more about that. They mention doppler shift but that's bidirectional so even without the spacecraft knowing how fast it's going, they should be able to account for it based on the received signal. Common issues could be reduced receive sensitivity, interference, oscillator drift or instability, or plenty of other things but there's no mention of even one that I've been able to find.

Didn’t they say the initial issue was some compatibility issue with the base station they were working with? Although throughout the article it sounds like they had a ton of software problems and maybe the spacecraft wasn’t quite as baked as they thought at the time of launch.

Yeah but that's kind of a meaningless description. Unless they literally had 0 planning on how they'd talk to the base station, presumably they tested this to some capacity or had some assumption it would work that was misguided for a specific reason. As is this could vary from "we pointed an AM radio station transmitter at it but it turns out it only listens to 20 GHz unconverted WiFi" to "we needed to adjust the transmit frequency by 1ppm due to vibration during launch shifting our oscillator." One is moronic, the other is a plausible oversight.

Why did they not validate their connection with the base station? Couldn’t you send your radio front end to your base stations and have them communicate in a shielded environment? I know that’s how consumer wireless is tested. Had they done that they could’ve addressed the incompatibility on the ground.

I thought orbital launches were very carefully planned:

> Epic had been designing its mission for one drop-off point only to find out relatively late that it would be dropped off somewhere else altogether. This change brought with it major ramifications for the flight path of the Chimera GEO-1. Montero and his team realized they might now need to do an extra burn and execute it in a tight time window to prevent the Chimera GEO-1 from being hurtled out into space.

> SpaceX’s rocket took off on February 27th, and reached space a few minutes later where its fairing opened and began plopping out the payloads. Shortly thereafter, Epic received a message from SpaceX telling it where and at what velocity Chimera GEO-1 had been dropped off. From there, Epic began trying to communicate with its spacecraft and to figure out what sort of maneuvers it would need to complete.

> It did not take long for things to start going really wrong.

Not shocking, based on that story. With so much at stake - money, years of work, careers, and dreams - I'm surprised it is so ad hoc. Are all launches like that? Maybe commercial launches, focused on profit, cut a lot of corners and deal with more failures. It sounds like a Musk, Inc. mode of operation but I don't really know.

Edit: Also, Epic dug their own hole by agreeing to such an arrangement.

I would suppose the lower pricetag reflected that arrangement: they weren't the primary customer, but just riding along to get into orbit at all.

They mention spacex rideshare by name in the article but neglected to link to it: https://www.spacex.com/rideshare advertises really cheap delivery... the lowest price they brag about is "$350k for 50kg to SSO with additional mass at $7k/kg"

The things that "start going really wrong" are listed immediately after that quote, and have nothing to do with the drop-off trajectory. Epic had problems with the ground stations they were using to communicate with their spacecraft. One of the two stations was offline because of a power failure. Then they "discover[ed] an unlikely incompatibility between their transmissions and the ground station hardware."

On a ride share mission, the primary payload determines the target orbit. If Intuitive Machines decides they want to go to a different orbit, then Epic has to deal with it. But they will be told this well before launch, with enough time to plan how many trajectory change maneuvers they need.

But even though they know beforehand how many burns they'll need, their exact parameters have to be calculated after launch once SpaceX uses the rocket's on-board guidance instruments to determine the actual insertion orbit. Usually this is within a few meters per second of the planned orbital velocity, but you need to know that last bit of error to figure out exactly how long the correction burns need to be. This doesn't change the overall maneuver plan, just the fine details.

The problem was that after launch, when SpaceX gave them the information they needed to calculate the burn parameters, they didn't have a working uplink to command their spacecraft to do the burn. So it just stayed on its original trajectory for longer than intended, getting more off-course the whole time.

Cool story. But the sad truth is, even after reading the article, I can't tell why any space agency should be interested in helping to bring the spacecraft back. Besides a certain curiosity about whether it's achievable at all, there's just nothing to gain for them; no knowledge, no utility, very little fame.

A space startup took a shot and fucked up, due to circumstances. That's tragic, I empathise with them, but I don't suppose that's reason enough for NASA or ESA to provide any of their scarce resources.

I'm seeing how the story could make for a nice semi-fictional dramatization, though. It's certainly poetic.

Reply on news.ycombinator.com