It’s fair to say that the majority of Hackaday readers have not built any hardware that’s slipped the surly bonds of Earth and ventured out into space proper. Sure we might see the occasional high altitude balloon go up under the control of some particularly enterprising hackers, but that’s still a far cry from a window seat on the International Space Station. Granted the rapid commercialization of space has certainly added to that exclusive group of space engineers over the last decade or so, but something tells us it’s still going to be quite some time before we’re running space-themed hacks with the regularity of Arduino projects.

That being the case, you might assume the protocols and methods used to develop a scientific payload for the ISS must seem like Latin to us lowly hackers. Surely any hardware that could potentially endanger an orbiting outpost worth 100+ billion dollars, to say nothing of the human lives aboard it, would utilize technologies we can hardly dream of. It’s probably an alphabet soup of unfamiliar acronyms up there. After all, this is rocket science, right?

There’s certainly an element of truth in there someplace, as hardware that gets installed on the Space Station is obviously held to exceptionally high standards. But Brad Luyster is here to tell you that not everything up there is so far removed from our Earthly engineering. In fact, while watching his 2018 Hackaday Superconference talk “Communication, Architecture, and Building Complex Systems for SPAAACE”, you might be surprised just how familiar it all sounds. Detailing some of the engineering that went into developing the Multi-use Variable-G Platform (MVP), the only centrifuge that’s able to expose samples to gravitational forces between 0 and 1 g, his talk goes over the design considerations that go into a piece of hardware for which failure isn’t an option; and how these lessons can help us with our somewhat less critically important projects down here.

Check out Brad’s newly published talk video below, and then join me after the break for a look at the challenges of designing hardware that will live in space.

Step By Step

Brad didn’t always develop hardware for Space Stations. When he was still a Research Assistant at the University of Louisville, he was part of the “White Star Balloon Project”, an ambitious attempt to send a robotic balloon across the Atlantic Ocean undertaken by the LVL1 hackerspace. As he explains early on during his presentation, working on this project within tight personnel and budget limitations taught him valuable lessons about breaking down complex projects into more manageable pieces, which still hold true whether your project is riding off on a helium balloon or a Falcon 9.

According to Brad, tackling each part of the larger system as an independent unit is not only more efficient from a division of labor standpoint, but it also makes adding new features or capabilities down the line much easier. Rather than getting stuck with a monolithic design that you later realize doesn’t offer any wiggle room, using the more modular approach leaves open the possibility of wedging in new hardware or software if the need arises. As an example, he recalls that during early testing of the MVP they discovered their original design didn’t have sufficient thermal control capability; an issue which could have been a major stumbling block had the design not offered the leeway to easily add in additional thermoelectric modules.

Brad also says this modular nature of system development can make debugging easier, but to get the most out of it you need to follow a few guiding principles. Namely taking the extra step to break out module-specific debug ports on the front of the device, and making sure that a bootloader is installed on every component capable of getting one. In a situation where taking the device apart is difficult to impossible, say when it’s installed in the payload rack of an orbiting space laboratory, these are critical elements to successfully debugging and maintaining the hardware. Even if your build doesn’t have to go into a payload rack, there’s no point in making it harder on yourself than necessary.

Gluing it All Together (Carefully)

Of course, a whole heap of individual modules doesn’t make a project, so at some point you need to tie it all together. But you might be surprised to hear that, even in space, there’s nothing so alien about the technology used to turn a bunch of individual modules into a complex system. In fact, the two protocols used in the MVP device will surely be familiar to any Hackaday reader: a Controller Area Network (CAN) bus and Universal Serial Bus (USB).

Unfortunately, Brad explains that USB ended up being a complete nightmare. It certainly seemed like an easy way to get high speed communications between devices, after all, everything supports USB these days. But signal integrity issues plagued the system. It worked, just not very well. In the end, it took adding additional hardware such as filters and USB hubs that weren’t part of the original design to clean up the signal to get it working reliably.

CAN bus on the other hand was a completely different experience. Brad says it’s about as perfect of an interconnecting technology as you could hope for. Designed primarily for the automotive market, it’s very robust and resistant to interference while remaining electrically and logically simple. Its popularity in industry also means that there’s a good chance the hardware you’re experienced with has support for it already, so there’s no need to reinvent the wheel.

Brad points out that CAN bus isn’t limited to complex systems like modern automobiles and spacecraft, either. He explains that his experience with CAN bus inspired him to try to implement it in the electronic door controls at his hackerspace, and the robust nature of the technology means that it was easy to get the system up and running even with the questionable infrastructure available.

Keeping One Step Ahead

If there’s one lesson Brad would have you take away from his talk, it’s that to succeed when designing complex systems such as the Multi-use Variable-G Platform or trans-Atlantic balloons, you need to do your engineering defensively. He’s not talking about egos, there’s already enough of that going on in complex projects and your personal feelings will often need to take a backseat to the needs of the project. Rather, he’s referring to the idea of approaching the project with an open mind towards possible future expansions or upgrades.

According to Brad, one of the biggest mistakes you can make is designing a system that only operates within a rigid set of parameters or requirements. The rules of the game occasionally change, and if your design can’t quickly be adapted or expanded as needed, you run the risk of having to go back to zero and starting all over again. When it’s an Arduino on a breadboard you can get away with yanking out the wires and starting from scratch, but when there are boards to be fabricated and deadlines to meet, there simply may not be enough time to recover from a shortsighted design.

While there’s perhaps some disappointment in learning that hardware aboard the International Space Station is occasionally more buck converter than Buck Rodgers, there’s something comforting about knowing our projects down here aren’t so far removed from what’s happening above our heads. With dedication and an eye for detail, Brad Luyster took the principles learned from launching balloons with his hackerspace and turned that into the experience of watching his design roar off into the black. With his tips and a little luck, perhaps any one of us could be the next to take their own personal “giant leap”.