DEV Community


Discussion on: Space, The Final Deployment!

phlash909 profile image
Phil Ashby Author

So: reflashing was the one thing we couldn't do from the ground, the uplink bandwidth (5 baud) makes it impossible to push significant amounts of code (ROM image was ~35k for the first deployment) during a pass where the satellite is communicable, and flash memory has an unfortunate sensitivity to radiation when the programming voltage is applied. We calculated that we would end up with a bit corruption approx every 1000 bits. For this reason we also used ferromagnetic storage for data.

Risk management: launching a brick was the biggest risk (total mission failure) - deployment is the most complex part of the process (actual moving parts, battery condition after months of storage, interaction with launching pod, etc.) and there is significant empirical evidence that this is where many other cubesats have failed. After that, ongoing ability to provide the primary mission function: telemetry for schools, then secondary function: the ham radio transponder. We also knew that this was not our only chance, additional launches were coming along, which provided mitigation through learning cycles too.

Technically, we didn't have a formal risk management process (the joy of amateur work), and cubesats are specifically aimed at higher risk experimental stuff through reduced costs. We did have a lot of testing from experienced colleagues at our launch partner company which provided a good deal of confidence (well placed I think - we have never had a catastrophic problem so far).

Hours - wow, in the low thousands I think over the 4 years of sporadic working and several people, I suspect the project managers know better than I :)

What would I change and use of modern tech? It's ongoing right now with the creation of our next gen design this year: primarily moving more stuff into software (especially radio technology), so we launch a platform with safe dynamic storage, much faster configurable radio systems, sensors and core functions, that supports ourselves & 3rd party developers running ongoing experiments on the platform after launch. A big challenge with FC-1 was having to specify and build everything up front, people really don't like committing to features as 'final', so this new approach removes some of that difficulty and makes the platform useful over longer time periods. We also really, really want to take 4k video of the actual deployment process from the satellite itself :)

From a software architecture / choice of hardware viewpoint, we would look at more distributed / autonomous processing capability to protect against cascade failures, to offer a range of processors (RISC, FPGA, DSP/hybrid) for experiments and take advantage of modern sensors (cameras, IR, magnetics, accelerometers, particles) as they are much smaller thanks to phones!

bosepchuk profile image
Blaine Osepchuk

5 baud uplink. That's crazy. I took another look at your cpu specs and realized you guys are running a spacecraft with less processing power than a microbit. That's quite the engineering achievement. Well done.

Thanks for taking the time to reply. It's all fascinating to me.