This is an article in a story format, about the design of the space segment software for the FUNcube missions, from FUNcube-1 (AO-73) in 2013 to th...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Cool! We are on the same rocket!
I am from the MOVE-II team. My job was ADCS software
Space is just amazing
Excellent! Is this your first launch?
Mine yes, our university already did one (that died after 3 month)
3 months is better than zero :)
I hope you find launch #1 as exciting as I did, I was on a high for several days, here's a photo about 5 seconds after first signal:
..aaand repeat :) data.amsat-uk.org/ui/jy1sat-fm
I posted a link to this article on r/programming and someone mentioned using Ada/Spark. Did you guys consider something like that instead of C?
Interesting question! We chose to work with the supported tooling for the MCU (MetroWorks Code Warrior for MCUs, which supports C/C++ and ASM), and didn't really consider anything else. CW4MCUs also comes with the Processor Expert device driver templates, giving us tested hardware access code (yes, we are lazy and risk averse :))
I briefly looked at SDCC as an open source toolchain alternative, because CW4MCUs is bloated Windows-only goop. I got a demo program to boot then the team reminded me they all used Windows, it was just me on Linux being weird.
I should note that we found two compiler bugs during development, one issue with the optimiser (register aliasing two variables together), another with 'smart' parameter passing conflicting with C permitting calls to functions without prototypes, oh the joy of stepping through assembly :)
A brief search for 8-bit Ada tooling only find Ada for AVR targets, although GNAT might be able to generate HCS08 output, looks like they aren't popular devices for missile guidance or medical gear.
Ah, that makes sense. At reddit a user linked to the following video based on a cubesat deployed by a college in vermont:
blog.adacore.com/carl-brandon-vid
On closer inspection, the hardware they are using is on a totally different scale though. Toward the end of the video, they mention a proton 400k. I looked this up ( cubesatlab.org/IceCube-Hardware.jsp ) and it appears to have a dual core powerpc CPU running at 1GHz.
You guys were operating with something not so far from Apple II hardware, though about 10 times the clock speed thankfully, so probably C/ASM would be the only realistic option! I should have noticed that in your post myself - sorry about that!
Yup - I went and found the Reddit post (thank you for the publicity), would have replied but I'm not a Reddit user (and not sure I wish to be!) Their target system for the first satellite (cubesatlab.org/BasicLEO.jsp) was a TI MSP430, which is a 16-bit CPU, with 16k+ RAM. Later work used larger devices.
Also their toolchain was interesting: since there is no native Ada/Spark compiler for MSP430 they transpiled to C... underpinned by ~2k lines of driver code in C.
We have ~10k lines of C (including comments) in the latest build for JY1SAT.
I'm curious, was solar power used to charge the battery or was it truly 100% battery powered?
They are (all still working 5 years in) solar powered, with a battery for eclipse-side operation, lots of hardware detail from here for FUNcube-1:
funcube.org.uk/space-segment/