Back in 2020, students from Universidad Del Valle De Guatemala (UVG) pulled off a really impressive feat, designing and building a CubeSat that lasted a whopping 211 days in orbit. In addition to telemetry and radio equipment, it carried a black-and-white camera payload.
But it turns out space is hard. The first pictures were solid black or white, with the automatic exposure process failing pretty badly. A pair of good pictures were taken by waiting until the satellite was passing over Guatemala during sunrise or sunset. A hung I2C bus led to battery drain, and the team tried a system reset to clear the hung state. Sadly the craft never came back to life after the reset, likely because of one of the Lithium-Ion battery cells failed completely in the low charge state.
That was 2020, so why are we covering it now? Because the project just released a massive trove of open source design documents, the software that ran on the satellite and ground station, and all the captured telemetry from the flight. It’s the ultimate bootstrap for anyone else designing a CubeSat, and hopefully provides enough clues to avoid some of the same issues.
Even though the mission had problems, it did achieve a lot of milestones, including the first picture of Earth taken by a Central American satellite. Even coming online and making radio contact from orbit to an earthbound station is quite a feat. The team is already looking forward to Quetzal-2, so stay tuned for more!
And if you want the details on the Quetzal-1 design, and what went wrong with the electrical system, both PDF papers have been released. Seeing more open source in space is an encouraging development, and one that should continue to grow as the cost of payloads to orbit continues to fall. We’ve covered the UPSat satellite, the PyCubed framework, and even the RTL-SDR for listening to satellite radio traffic.
I would not use anything else than CAN bus on such a thing. If it´s good for a Tesla, it should be OK for a sat (joking)
CCSDS over SpaceWire.
“A hung I2C bus led to battery drain, and the team tried a system reset to clear the hung state.”
pacefalm.jpg
We’ve designed sumo robots that have multiple redundancies even though they sometimes run for less than a second or two during a fight. How can one botch so much during a atellite design?
Harsh and disrespectful
The paper actually says that the battery drains were due to “TX hang failures” that are still “yet to be determined.”
The I2C bus failures also caused problems, which you might be able to learn about, except that it’s “further detailed in Chung et al,” which is “Design, Development, and Pre-Flight Testing of the Fault-Tolerant Command and Data Handling Subsystem of the Quetzal-1 Nanosatellite. [Unpublished manuscript.]”
From what I understand, it was both issues together that caused the final problem. Latest word is that the I2C bus was the final cause of death.
Hm. So there was no watchdog installed. Why? Was there no space left for a humble 555 timout circuit?
It could have had saved the satellite, would have had taken control if the HCU wasn’t being responding for a few minutes. Like a dead man’s switch in a subway train.
Oh, well. This isn’t my time anymore. 😔 Even me, a layman knew about this. It’sbasic knowledge. I’ve been building such things for my Packet-Radio hobby years ago, when I did CB radio. The watchdog was disconnecting the PTT line once the CB radio was transmitting for too long. The idea was that a malfunctioning PC or radio modem (a TNC) wouldn’t cause any harm (transmitting forever).
Read the paper. It explains that they did have a watchdog timer, but at the time it was set for a 24 hour timeout. The watchdog timer was configured to perform a reset, but this didn’t resolve the I2C bus hang. Only a complete reboot of the satellite via a depleted battery seemed to resolve this issue. There’s probably more information in the yet-to-be-published Chung et al. (2023) paper.
The only way to ensure that a sensor doesn’t permanently hang is to power cycle it. Your sumo robots never had to deal with radiation.
Power cycle would definitely work
If you’ve never done space, it’s really hard to anticipate what you don’t know
Even if you´re ignorant, when sending something to space, you should still do a risk analysis of any component or sub-component involved.
Learning by mistake is just too costly for that class of experiment.
Failing to understand that this is needed is just *inexcusable*.
One can see the glass 1/3 full, for sure, but such a failure is quite deceiving for the students involved…
Wild guess (from experience): the electronics teachers there are stuck at the *arduino* level, and their english level is poor. Yes, arduino is big in South America because of the language support. And it barely goes beyond that.
> Learning by mistake is just too costly for that class of experiment.
Tell that to SpaceX ;)
Theoretical knowledge alone wont help you ensure a system works well. You need testing, it’s inevitable.
What you need to do though, is create a similar environment as in the goal environment. So something that radiates (safely, or ideally something else with a similar effect) and disturbes electronics, a vacuum chamber, or very cold temperatures.
All of this will make it much more likely you understand what you are doing and get an intuition for likely problems. Theory alone without practice doesn’t work.
Learning by mistake isn’t ideal, but at cubesat costs, for an institution, it absolutely reasonable if the programme boosts publicity, engages more students, progresses learning and highlights improvements that can be made. Learning by failure is a bit chunk of every major space agency (at a bigger scale and complexity of course). Typically 1U cubesats and their launch via a cheapest-available-option cost about the same as the budget for an EEE first year team project task, so if 50% of it is covered by sponsors and other funding – it’s entirely worth it and the learning they gain on the way they’ll never forget. The benefit is mostly in the build and test, not the flying.
Hopefully by sharing information like this, there will be less “don’t know what you don’t know” issues.
My understanding of technology in space is that you should have a redundant way to fully power up/down each module independently as the the reset line is unreliable as few sensors are designed for space weather. You should also have a watchdog circuit to power up/down the entire system. Space weather is harsh and does not bode well for electronics.
I wonder how many of these cubesats get pressure tested in a vacuum chamber.
This one was tested in a proper space chamber with experienced advice/help
All of them, the launch providers require thermal vacuum testing and bake-out, along with vibration testing, sometimes EMI testing, and generally the launch providers require design reports ensuring debris-release is unlikely etc. All of these things are overseen by launch providers and require local-authority licensing for radio transmission.
I kind of miss the days when custom solutions were being developed.
Open Source and Open Hardware is nice and well, but if this results in dozen of Copy&Paste projects, then were’s the creativity, where’s the fun ?
– You can’t even use new or new old technologies because the whole design had been shoe-horned for Arduino/Lithium Ion batteries ( can’t use big powerful batteries, electron tubes or robust relay logic).
About twenty years ago, students (pupils) and radio amateurs still had to developed their own satellites based on their own ideas.
The solutions were fresh, unconventional. A contribution, in short. This is an aspect I don’t like about CubeSats. They’re too strict, too standarized, lacking any character, carbon copies. In short: lame.
Here’s an example what I’m thinking about when I think of real “hobbyists” or pupils satellites. Those were being hand-tossed by astronauts of MIR orbital complex in 1997:
Old project site:
https://www.arra.re/spoutnik/angecouteurs.html
The satellite:
https://www.arra.re/spoutnik/angnewsA.html
https://www.arra.re/spoutnik/angnewsB.html
https://www.arra.re/spoutnik/angnewsC.html
https://www.arra.re/spoutnik/angnews9.html
Humble students, like you and me.
Not elite students on a fancy university:
https://www.arra.re/spoutnik/angnews6.html
https://www.arra.re/spoutnik/angnews7.html
I kind of miss those times, in which things weren’r being so commercialized. The ISS is nice and so are Cubesats. But it’s nolonger the science and human factor that’s has priority. It’s all just commerce now and prestige. The shiny ISS is, in contrast to rusty old MIR, an instrument of publicity.
That being said, I’m just an user, a layman. So it’s just an opinion, after all. I saw this site years ago when learning about history of space exploration.
I think that no one is restricting your creativity. But Open SW and HW could enable many people to have a eference design of their own, genuie designs.
I think this is a very miserable view of the market to be honest. Humble students (and school kids) are still doing this, they leverage COTS parts now and build custom missions where they can spend their time on more of the items they choose to – don’t want to develop a shonky battery solution – no need to, they’re off the shelf, spend your time on your payload and software. Want to build your own ground station – you can, or you can pay someone else to operate. Literally the only thing that is standardised is the basic shape – you can go 1U, 3U, 12U, 16U. You can have only body panels, or make your own triple deployed panels. You can buy the entire set of subsystems, or build them all providing they meet the basic operating standards.
And they’re still lobbed out of the ISS, sometimes accidentally into the station lol.
https://www.youtube.com/watch?v=zfl42B3nWr0
FWIW I have seen or been involved in about 35 cubesat designs, not one was copy/paste or used open source anything.
https://www.arra.re/spoutnik/angpigno.html
“This page is large (100kb); save it (wait during load) then read it off line…”
While I am thinking, damn this html loaded FAST ! ;)
Perhaps someone can shed some light on (possible pun) on this: Looking at the ope source files on github, the schematics contain, general, off the shelf components. I don’t see any heating/cooling system, so how are these chips surviving / working in the extreme temperature swings of space?
There was a heater system on the battery. All the rest of the system had chips rated for the temperature swings they were expected to experience, which they validated by on-ground testing, and then measured in orbit with multiple temp sensors.
The temperature swings for a small, tumbling cubesat usually aren’t too severe. Components on the exterior will see the widest variation, typically something like -20~+50 C. Things are milder inside the satellite as long as the components’ own heat dissipation isn’t too large. That’s all in-bounds for ordinary industrial or automotive rated parts.
Larger spacecraft (with less thermal coupling between the sunlit and shaded parts) and steadier attitude (therefore longer periods baking in the sun or freezing in shadow) make things tougher.
You can look into the temperature data recorded by the satellite in https://github.com/Quetzal-1-CubeSat-Team/quetzal1-telemetry, there’s also a dashboard here: https://dashboard.satnogs.org/d/js5kQceWz/quetzal-1-telemetry?orgId=1. It never went above 40 °C or below -15 °C.
So lets hope that Quetzal 2 also dies so that they open its source as well.
JK. My best wishes with the team.