AstroForge's mission is to create an unlimited supply of resources to remove Earth’s resource constraints. We're moving at a speed, at a price point, and with a level of risk that is unheard of in the aerospace industry. And it's always been our mission to transparently share our progress with the public.
Many watched along with our multi-day live-stream of our Odin mission and have been following along on X/Twitter. Today, we want to share a condensed and detailed post to walk you through the first 48 hours of the Odin mission, including our communications and attempt to get our Odin spacecraft in a healthy state. Our goal here is to give you a raw and detailed look at the "what", "when", and "why" in more detail than has ever been done closely following a space mission.
Before we come online with any ground station, we have what is called a pre-pass briefing. The first ground station that would be over was Capricorn, a 5M dish located in Australia.
During this briefing we found a few issues. Our scheduled time was shifted by 4 hours, and the IP address used to gather the configuration of the receivers was incorrect. These were easy, albeit stressful, fixes.
We got them fixed, and then sat back and watched the launch on the Falcon 9.
We separated from the Falcon 9 right on time. We used an exoLaunch separation ring to deploy us from Falcon, and it went off without any issues. We were now on our own, floating through space at an extremely high rate of speed.
130 seconds after launch, Odin turned on. We have an automatic sequence that performs a series of tasks on the spacecraft like powering on our flight computers, turning on our attitude control, and deployment of the solar panels.
Capricorn was our first pass post separation from the Falcon. If you remember from our previous blog post, we knew pre-launch that this sequence would not enable our power amplifier. This means that unless we sent a command through to turn on the power amplifier, we would not get any telemetry from the spacecraft.
As soon as the pass started, we ran into some massive issues.
Our own carrier signal might have been leaking across frequencies.This could have interfered with our commands, but we lacked the data to confirm it at the time.
The wrong polarization was on the antenna, and we still have no idea why. We had already done a live on-site test, and the configuration file was correct. Yet, the polarization is wrong. This was wrong for about the first 4 hours of the mission.
This error ment that both uplink and downlink for the first 4 hours of the mission did not work. No commands were getting through, and also, no data was getting down.
It took us a few hours, but once we found the issues we were able to fix them. It was unclear at the time if the wrong polarization had blocked the uplink (this was calculated after) so we had to make some decision on what to send.
The primary question to us at this point was whether the power amplifier had turned on. We had no data confirming it was on, but we also would have not heard the signal. So we made a decision to start sending commands that would enable the power amplifier in a way that would not put the spacecraft in danger.
We began sending commands every 30 to 60 seconds, hoping something would stick. By the end of the pass, we had sent 132 commands, including:
Why the different commands? Well if the spacecraft is in a state where something went wrong with the flight computer, the radio has the ability to turn the power amplifier on. If this were to happen we would get a very specific type of packet from that spacecraft and know that it had failed to boot. But if the flight computer was on, it would notice the power amplifier was on when it should be off, and command it to shut off.
The second command would leave the power amplifier on, but would only be effective if the spacecraft was fully operational. Any issue onboard and it would be a worthless command.
And just to make it a little more complicated, these commands require different ground configurations to send, so we can't just flip back and forth at a high rate of speed.
But despite all our efforts, we received nothing in return.
At 07:48 UTC, an unexpected save came from AmSat, an amateur satellite network that wasn’t even looking for us. They found a signal, and a strong signal that was aligned with our frequency.
Here is the challenge with space. While we got a signal and it was on our frequency, it takes hours to confirm it was from us. It was a single 13 second long communication. We had to contact Peter at AmSat and have him give us the actual receiver signal. Once we got the raw data, we spent hours attempting to replay and extract data out of the signal.
We were eventually able to get information from the header, and were able to confirm that this was a packet from Odin. We also were able to tell that this was a data packet from the flight computer. This was important because it meant that the vehicle was fully booted up, and the flight computer had commanded the power amplifier on. But keep in mind this was hours after getting the packet, and we did not have this information going into the next pass.
But we did know Odin was alive. This was also a huge clue; the batteries onboard the spacecraft can only support the spacecraft for about 2.5 hours. So if we got a signal about 7 hours into the mission, it means that the spacecraft must have received power from the sun and started to charge.
At 16:42 UTC, our ground station in India came online. India has 3 dishes we can use, a 32 meter and two 18 meter dishes. The 32M dish is definitely the most powerful, but it was also the most contested dish as Intuitive Machines, ourselves, and some other vehicles all wanted access to the dish.
We had another issue we talked about pre-flight, which was the dishes at India had an unexpected interference introduced mid-last week. This turned out to be a cell tower. We don't have all the details, but this interference was large enough to make the dishes unusable by us. However during our passes on the ground station, the cell tower was put into a lower power state so the interference would be less and we could communicate.
But at this point, 16 hours in the flight, we are starting to really pick up some distance from the Earth. We are somewhere around 100,000km away from the planet. This matters a lot as to make sure we can close the link we use very narrow beam widths, around 0.3deg. This means that if we are even off just a little bit in our position, we won't be able to communicate with the spacecraft.
So one of the things we did during this time was to do a search pattern. Every deep-space ground station has this capability, and essentially we spiral out increasing the offset in where we expect the spacecraft to be. We went up to 1 degree away from our nominal trajectory.
Despite these efforts, Bangalore was unable to confirm reception.
We got a call during this phase of the mission. AmSat and another large dish ground station detected a signal from Odin.
Again, Peter at AmSat was key in detecting this. He tried to save the data for us, but there was an issue on the record, and the data was corrupted. But this was still an amazing piece of information, the vehicle is alive. We also know that the vehicle was able to charge the batteries, at least to some extent, to survive for 17 hours into the mission.
During this time we were asking the radio to turn the power amplifier off. So we didn't answer any real question on the state of the vehicle. If the vehicle was nominal, it would have commanded the power amplifier to shut back down, explaining why we saw the amplifier turn off. If it was in some weird power state, then we see the vehicle go back into its sleep mode.
The other got the data and has it, but we have not been able to take a look at it yet. As soon as we get this packet it is going to be the most critical piece of information we have.
This is where we first developed our theory: we had a very slow tumble. So, we started thinking about how we could verify this. What we did realize was that our friends at Intuitive Machines had taken some amazing pictures of their separation. While it was very small, it was clear that you could see Odin.
Intuitive Machines offered to download high-resolution images from Athena—the ones we requested—so we could see more details of the spacecraft.
From these images, we were able to calculate that Odin’s roll rate was 0.3deg/sec or 1.6°/sec in the frame of the image taken. This is a completely normal rate after separation from the rocket, and the spacecraft should have been able to detumble. However, if for some reason the spacecraft was unable to detumble, we should still have been able to receive telemetry at this rate.
The Morehead ground station in Kentucky powered up its spectrum analyzer and began scanning. No reception was confirmed. At 17:06:45 UTC A possible signal blip was recorded while sending a radio direct turn-on command. This was not repeatable, so it remained inconclusive.
Originally we didn't expect to use Morehead. But with the other previous failures, we decided to grab some time and spin it up.
This meant that not all tests got done with all ground stations. We found out after launch that these stations needed an additional amplifier for downlink to bring weaker signals above the receiver threshold. So even if Odin was talking, we would not have heard it.
We got a call from our friends at Intuitive Machines, and they offered to give us some of their allocated time to help us, starting, well now.
This last-minute tracking opportunity arose just 55 minutes before our scheduled pass. With little time to prepare, we scrambled to verify whether our receiver was configured correctly. However, due to the rushed setup, we only gained control of the station 20 minutes before the pass ended—leaving us with almost no time for adjustments.
During the attempt, we detected signal bleed-through, meaning our uplink signal was unintentionally appearing on the receiving dish—a serious issue that can interfere with proper communication. Unfortunately, there wasn’t enough time to shift the frequency and correct the problem. Before we could try again, we were kicked off the station.
With no other immediate options, we rushed back to the office to salvage what we could. We managed to get the dish online, but the bleed-through issue persisted. While the technical details get complex, the short version is: this was bad news for our ability to establish a clean signal.
We also noticed that the noise pattern looked very similar to the original interference we saw on the 18M dish from the cell tower. We later concluded by looking at some of our past test data, that we got put on the wrong dish.
The nice thing was we had scheduled time on the D32 dish. So in preparation for this pass, we had our receiver manufacturer on a call with the Indian team, as we wanted to make sure we could get the signal across. Keep in mind that Odin is getting further and further away, so the smaller dishes we had used previously were becoming unusable.
So about 30 minutes before the pass we made sure our configuration was correct. The last step is a verification test, called a loopback test, where we take the output of our receiver, and make sure we see it on the input of the receiver.
The test goes off without a hitch, and at 12:20am UTC we are ready to attempt to reach Odin.
We then discovered a major issue. When you send a radio signal to a spacecraft, you first send what is called a carrier, and then you modulate data on top of it. The carrier is a set frequency and is generated at the dish. When we attempted to look at our first pass we had an issue, a large carrier signal was sitting right in the middle of our receive dish. What this was was our uplink showing up on the downlink. Not the spacecraft. Even worse, because this is so powerful, we are trying to reach a spacecraft which at this point is 300,000 km away, it would block us from getting any actual signal from the spacecraft. Think of it like trying to hear a whisper in a room where someone is blasting music at full volume—it drowns everything else out.
What we concluded, in short order, was that our loopback test was still running, meant to verify whether our transmissions were correctly reaching the dish. However, for the next 8 hours, the team in India struggled to remove the carrier signal. No matter what adjustments were made, the interference persisted.
In short, this meant that the dish was completely unusable for the entire pass. Any weak signals from Odin would have been buried beneath the overpowering carrier, making it impossible to establish a link. This was an incredibly frustrating setback because, without a clean frequency, we had no way to tell if the spacecraft was even attempting to respond.
When we noticed the interference on the dish in India, our aggregator, KSAT, quickly spun up Wilheim for us, a large dish in Germany. The team was ready and listening intently for any sign of Odin’s signal. But despite their efforts, nothing was received.
We have received a bunch of alternative measurements and data on Odin, the space and science community has been an unstoppable force for us. While this can help confirm and deny some of our theory, we are still in the process of looking at all this data and trying to determine how to best apply it.
Observable Space got us some great Magnitude plots using our trajectory data.
Photometry Data:
Through some connections at Keck Observatory in Hawaii, we got connected to the Pine Park Observatory which supplied us with some interesting photometry data that helped get a sense of apparent magnitude, or how bright an astronomical object appears from Earth.
At this point, Odin is still out there, and we are still trying to talk. Our current theory is that Odin is in a very slow rotation, and that we will become power positive again at a regular rate.
We are going to keep trying to command the spacecraft when we have the large transmitters available. The dish in India can talk to Odin until it goes down for Maintenance at the end of March.
While we can’t guarantee success, one thing is certain: we will keep learning, iterating, and taking shots on goal—because space is unforgiving, and you only get better by doing.
