Founder/CEO of Albedo here. We published a detailed write-up of our first VLEO satellite mission (Clarity-1) — including imagery, what worked, what broke, and learnings we're taking forward. Happy to answer questions.
Clarity is designed for a GSD (ground sample distance) of 10 cm. Generally the industry uses resolution<>GSD interchangeably. Agree it's not the true definition of resolution. But I'd argue the diffraction limit is an incomplete metric as well, like how spatial sampling is balanced with other MTF contributors (e.g. jitter/smear). For complete metrics, we like 1) NIIRS or 2) % contrast for a given object size on the ground (i.e. system MTF translated to ground units, not image-space units).
The main performance goal for us was NIIRS 7, and we decomposed GSD/MTF/SNR contributors optimized for affordability when we architected the system
Moving fast to make launch, we had missed a harness checkout step that would’ve caught a missing comms connection into an FPGA, and it was masked because our redundant comms channel made everything look nominal.
On orbit, we fixed it by pushing an FPGA update and adding software-level switching between the channels to prove the update applied and isolate the hardware path — which worked. Broader lesson, it is possible to design a sw stack capable of making updates to traditionally burned-in components.
> it was masked because our redundant comms channel made everything look nominal.
Hah, this has bitten me often enough I check for it in test suites now - ok, you’ve proven the system works and the backup works, have you proven the primary works? Another in the long list of ways you don’t expect a system to bite you until it does…
With image resolution this high, ground accuracy becomes an important factor as many people that prefer higher resolutions also want geospatially accurate images. Did you have any findings or results on this?
Congrats on having a successful mission, it seems quite successful for a first try, and you clearly have some talented people on your team. But I’m going to give you my unsolicited opinion on the writing style.
The writing style sounds more like a tech bro describing some weekend conquest, and is wholly unappealing to most of the space industry (or at least the ones with decision making authority). Your CMGs were “locked in,” several times you “nailed it,” and so on.
You might have a business strategy that I’m not aware of but I’d expect that most of your market is controlled by aging men in suits, and they don’t talk like this. Most startups and tech bros aren’t spending money on space. It’s big established corporations that can fund this kind of stuff. Write like them. You can talk like a tech bro and get seed funding, but if you want to get to a sustainable business you have to talk corporate.
I would hate for your company to get passed over for lucrative opportunities because your public image seems immature. I looked at your website and you have a bunch of ex-government people on your senior advisory board. Get their opinion on your writing. It sounds silly, but you significantly lower your probability of winning contracts if people see you as a team of “bros.” People don’t want to spend millions on guys who are “locked in.” People want to spend millions on people who do professional engineering and risk reduction and clearly communicate how professional and competent they are.
I ranted way too long about your writing style. It’s pretty cool that you were able to design your own bus and most of it worked.
> Next up was maneuvering from our LEO drop-off altitude down to VLEO, where it would be safe to eject the telescope contamination cover
Why would it be unsafe to do this earlier?
> We had been tracking intermittent memory issues in our TT&C radio throughout the mission, working around them as they appeared. Our best theory is that one of these issues escalated in a way that corrupted onboard memory and is preventing reboots. We've tried several recovery approaches. So far, none have worked, and the likelihood of recovery looks low at this point.
Seems to be a pretty big problem as well, I wonder what their ideas are to diagnose the root cause here.
It all sounds a bit overoptimistic, but that may just be my interpretation.
Terrific writeup. Massive congrats to the whole team for all that creative thinking in flight and all that was achieved. (Add a note about updating FPGA's in space!) Looking forward to team Bedo unlocking VLEO for everyone.
Founder/CEO of Albedo here. We published a detailed write-up of our first VLEO satellite mission (Clarity-1) — including imagery, what worked, what broke, and learnings we're taking forward. Happy to answer questions.
https://albedo.com/post/clarity-1-what-worked-and-where-we-g...
s/learnings/lessons/g
The diffraction limit (under 1.22 h* lambda/d) of a 1m optic at 250km in visible light is about 17cm. How can you achieve 10cm resolution?
Clarity is designed for a GSD (ground sample distance) of 10 cm. Generally the industry uses resolution<>GSD interchangeably. Agree it's not the true definition of resolution. But I'd argue the diffraction limit is an incomplete metric as well, like how spatial sampling is balanced with other MTF contributors (e.g. jitter/smear). For complete metrics, we like 1) NIIRS or 2) % contrast for a given object size on the ground (i.e. system MTF translated to ground units, not image-space units).
The main performance goal for us was NIIRS 7, and we decomposed GSD/MTF/SNR contributors optimized for affordability when we architected the system
Can you tell us some war stories about the software your group wrote for the satellite?
Stacks? Testing? Firmware Updates? Programming languages?
Thank you!
Moving fast to make launch, we had missed a harness checkout step that would’ve caught a missing comms connection into an FPGA, and it was masked because our redundant comms channel made everything look nominal.
On orbit, we fixed it by pushing an FPGA update and adding software-level switching between the channels to prove the update applied and isolate the hardware path — which worked. Broader lesson, it is possible to design a sw stack capable of making updates to traditionally burned-in components.
> it was masked because our redundant comms channel made everything look nominal.
Hah, this has bitten me often enough I check for it in test suites now - ok, you’ve proven the system works and the backup works, have you proven the primary works? Another in the long list of ways you don’t expect a system to bite you until it does…
With image resolution this high, ground accuracy becomes an important factor as many people that prefer higher resolutions also want geospatially accurate images. Did you have any findings or results on this?
Congrats on having a successful mission, it seems quite successful for a first try, and you clearly have some talented people on your team. But I’m going to give you my unsolicited opinion on the writing style.
The writing style sounds more like a tech bro describing some weekend conquest, and is wholly unappealing to most of the space industry (or at least the ones with decision making authority). Your CMGs were “locked in,” several times you “nailed it,” and so on.
You might have a business strategy that I’m not aware of but I’d expect that most of your market is controlled by aging men in suits, and they don’t talk like this. Most startups and tech bros aren’t spending money on space. It’s big established corporations that can fund this kind of stuff. Write like them. You can talk like a tech bro and get seed funding, but if you want to get to a sustainable business you have to talk corporate.
I would hate for your company to get passed over for lucrative opportunities because your public image seems immature. I looked at your website and you have a bunch of ex-government people on your senior advisory board. Get their opinion on your writing. It sounds silly, but you significantly lower your probability of winning contracts if people see you as a team of “bros.” People don’t want to spend millions on guys who are “locked in.” People want to spend millions on people who do professional engineering and risk reduction and clearly communicate how professional and competent they are.
I ranted way too long about your writing style. It’s pretty cool that you were able to design your own bus and most of it worked.
What an impressive project.
> Next up was maneuvering from our LEO drop-off altitude down to VLEO, where it would be safe to eject the telescope contamination cover
Why would it be unsafe to do this earlier?
> We had been tracking intermittent memory issues in our TT&C radio throughout the mission, working around them as they appeared. Our best theory is that one of these issues escalated in a way that corrupted onboard memory and is preventing reboots. We've tried several recovery approaches. So far, none have worked, and the likelihood of recovery looks low at this point.
Seems to be a pretty big problem as well, I wonder what their ideas are to diagnose the root cause here.
It all sounds a bit overoptimistic, but that may just be my interpretation.
I think they want to get low enough that the jettisoned cover will not stay in orbit long or run into anything.
Ah, safe for others, not for the telescope. Thanks, I did not consider that option.
Terrific writeup. Massive congrats to the whole team for all that creative thinking in flight and all that was achieved. (Add a note about updating FPGA's in space!) Looking forward to team Bedo unlocking VLEO for everyone.
So the root cause was the lubricant in the gyros couldn’t stand up to operating temperatures.
I’d be interested to read a postmortem of the systems engineering approach there.
The lesson there - dig multiple levels deep in supply chain
Alas.. the speed & resources of a startup. But we're learning.