I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
You mentioned the ability to debug from telemetry and send commands to do stuff like turn off misbehaving peripherals. Do you also have the ability to flash new code to the sats while they are in space (to fix a particularly nasty bug, for example)?
What did you (the builders of the cubesats) see as the biggest risks to mission success? How did you prioritize and mitigate those risks?
Any idea how many hours went into each sat from start to finish?
Is there anything you'd change with the experience you gained and with the technology available if you were building the same functionality starting today? Is anything easier about building a cubesat in 2020?
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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!
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Awesome project, Phil.
A few questions if you don't mind...
You mentioned the ability to debug from telemetry and send commands to do stuff like turn off misbehaving peripherals. Do you also have the ability to flash new code to the sats while they are in space (to fix a particularly nasty bug, for example)?
What did you (the builders of the cubesats) see as the biggest risks to mission success? How did you prioritize and mitigate those risks?
Any idea how many hours went into each sat from start to finish?
Is there anything you'd change with the experience you gained and with the technology available if you were building the same functionality starting today? Is anything easier about building a cubesat in 2020?
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!
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.