At the Interface of Open/Closed Technologies

One of the unique features of my work as a fellow (the “trailblazing” part) was building open hardware on top of closed-IP hardware (closed intellectual property, i.e. proprietary hardware and patents). The Loom Pedals system is an alternative software/hardware interface for the TC2 Digital Jacquard loom, a product of the Norwegian company Tronrud Engineering. I want to discuss “interface” from a couple of different angles. First, we’ll take the literal definition of “interface” in digital technology and go into some technical details in the software and hardware development process. Then, I want to explore alternative interpretations of “interface” for the Loom Pedals: a social interface between academic researchers and industry engineers, a craft interface between weavers and their looms, and a translation interface between two communities of hackers.

The Loom Pedals system directly replaces the existing software interface for the TC2. The TC2 communicates via Wi-Fi with this driver software, which is running on the weaver’s personal computer. Over Wi-Fi, the TC2 and driver exchange instructions—such as “start weaving”, “send the next row”, and “roll the fabric forward”—in byte packets according to Tronrud’s unique protocol. While we had to reverse engineer this communication protocol, we really didn’t have to take apart any of the underlying TC2 hardware like the motor drivers or vacuum control, or even reverse-engineer the driver software. The protocol seemed to have some quirks that hinted at the TC2’s system design, such as the loom expecting a particular sequence of start-up commands. But again, it was enough to just figure out what bytes got the right response through trial-and-error. Knowing the underlying system implementation would likely help us figure out the commands more quickly, but it was just icing on the cake.

In the middle of our reverse-engineering and development, we were very fortunate to get in touch with Tronrud about our lab’s research, including the hardware work with the TC2. Rather than discouraging any further hacking on their product, they were instead intrigued to talk to members of a newer, growing group in their customer base. Many TC2’s belong to art schools, university textiles departments, artists, and designers. Because the TC2’s development was led by weavers and intended for weavers, Tronrud has put in remarkable effort in creating a community of TC2 weavers and showcasing what users do with the loom. Yet in recent years, more STEM research groups and makerspaces have become interested in the TC2 and other textiles equipment in general. 

We were up front with Tronrud’s engineers that we intended for our work to be open-source, but part of our existing codebase depended on their proprietary protocol.  As someone who does not have industry experience in a large, well-established company like Tronrud, talking to their engineers has exposed me to new perspectives. Like many companies in industry probably worry about, Tronrud’s main concern is protecting their unique invention and preventing another business from copying their product to undersell the TC2. A key focus in our conversations has been identifying a clean separation between what could be shared and what could be kept closed, and we have been proposing an open API specification that any software could use to communicate with a TC2. This would open the proprietary communication protocol, but as I mentioned previously, Tronrud would not have to reveal any other components.

Personally, I believe that Tronrud would be capitalizing on a huge opportunity if they ended up releasing their communication protocol. My lab will certainly not be the last of their customers who want to hack the loom, and supporting users who want to customize their TC2 interfaces would only encourage this particular user group to grow. Rather than making their design more easily copied and possibly less unique, I think this would make the TC2 an even more unique product. After all, can you think of another hackable, maker-friendly, prototyping-scale Jacquard loom where the manufacturer is so involved with their user community? And what’s more, could Tronrud’s communication protocol become the standard for open hardware Jacquard weaving?

Can you think of another hackable, maker-friendly, prototyping-scale Jacquard loom where the manufacturer is so involved with their user community? Could Tronrud set the standard for open hardware Jacquard weaving?

Grappling with the interface between open/closed systems has been a challenging, yet rewarding experience, made even richer when we consider the wider context of weaving and the history of technology. Weaving is a craft that often relies on complex machines, yet it is also steeped in thousands of years of history and culture. Our human eyes and hands are how we interface with a weaving loom and its various accessories. The loom is our interface to the yarns and emerging cloth design. The (first) Industrial Revolution actively opposed many of these interfaces with its emphasis on automation and large-scale production. Ironically, the Jacquard loom was an invention of this era and drove much of the industrialization of textiles. By establishing many features of our current technological paradigm, I would also theorize that the Industrial Revolution set the stage for the closed-IP, black-boxed hardware, and planned obsolescence of modern electronics. 

The OH community, maker movements, and contemporary craft revivals represent what some call a “new” Industrial Revolution, one that values small-scale, on-demand production and celebrates the hand’s ingenuity. By looking at traditional craft tools, we can find technological interfaces that are already “open” in their design and highly hackable, despite the earlier Industrial Revolution’s efforts to make them obsolete. Traditional looms come in so many different forms because they have been hacked on and modified throughout millenia by countless communities. There is an elegance in being able to see all the mechanisms of a hand-powered loom or spinning wheel, an almost self-documenting system. I see potential for new machines, like the TC2 and the Kniterate, to find a compromise between closed-IP equipment and their open hardware ancestors through open interfaces.

If you have more business experience than Shanel Wu (i.e. any business know-how at all), please send them your version of how you’d make the business case to Tronrud. You can find them at: (website) / (Github) @sminliwu / (Instagram and Discord) @pipernell / (email)

On Open Hardware and Being a PhD Student

As one of the Open Hardware Trailblazer Fellows, I hope that my experiences can be informative, or at least bring some sense of solidarity, to other PhD students working on open hardware (OH). PhD programs seem to be isolating experiences by design. After all, you’re supposed to do original research — by definition, doing something that nobody else has ever done. How do you find community when you’re the only one doing what you’re doing?

I think my answer is to find connections with other people who are making things with similar features, and asking similar questions. I try to ignore traditional labels and disciplinary silos like “researcher”, “artist”, “engineer”, etc. so to some, the connections I make might seem like big reaches. My research in textiles and maker tools falls under the human-computer interaction (HCI) umbrella, and building hardware is my way of ensuring that my output research can not only support textile makers in their designing processes, but also play a part in the physical fabrication of those designs. Through the Trailblazers fellowship, I met academics who were working on very different projects, but we found unexpected connections anyway. I was the only person working with textiles, but everyone struggled in their own way with staying on top of documentation and hustling for recognition. Meeting with the other fellows during our cohort meetings gave me comfort that I wasn’t alone, even if I felt like my project was weird and niche. Moreover, most of the other fellows were faculty rather than students and many of the mentors worked outside of academia, so I had constant reminders that the stress of my PhD studies was only temporary, and open hardware would lead to much more exciting places in the future.

However, sometimes doing open hardware and PhD research added more stress to my plate, despite the community I found. Because my research focuses more on the design theories around and qualitative evaluation of the hardware in question, my writing needed to mostly discuss these aspects and heavily streamline the implementation details. Thus, I couldn’t use much of the technical documentation I wrote for the OH project for my academic writing. I essentially had twice the writing to do. And I already had a lot of writing to do.

I noticed other conflicts between academic output and OH output when judging how “ready” the work was. For the Loom Pedals, my advisor suggested that it was “publishable” once I had a proof-of-concept prototype. The Loom Pedals were nowhere near their current level of functionality and polish: I hadn’t designed the PCB yet, the enclosures were an earlier boxy version, and I was still ironing out the software interface. The crux of the manuscript was to be the “novel” concept of creating a customizable interface for a Jacquard loom. If I were to post about the project online, as I have with some personal hardware projects, I would’ve waited until I had documented things better and organized my files — a “pushable” state. Maybe this is just my perfectionism speaking, and/or specific to publishing in HCI, which is so focused on “novelty”. 

Lastly, I can’t forget my dissertation. This fellowship lined up with my final year as a PhD student, so for my final few months, my primary focus was just putting together my dissertation. I hope I’m not sounding repetitive because all of my issues have been with writing. But writing has been the single most prominent aspect of academia that I wouldn’t think about so much if, say, I was working as an engineer in a start-up.

Starting with this one parallel, I’ve been thinking about other ways that academic tasks mirror open-source practices; and going even further, ways that academic spaces could learn from open-source communities to become more nurturing and collaborative. 

As a minor example, I ended up putting my dissertation (LaTeX files, images, and other assets) into a Git repository because I was overwhelmed by organizing my files and tracking changes in response to my committee’s feedback. On a whim, I made it public on GitHub, like so many other projects that I’ve just thrown online. I’ve already sent the link to a few other students who wanted ideas for their own dissertation processes. I’ve realized that I want my academic work to include my process to transparently show the mess that preceded a polished manuscript. I want to be honest about my struggles, so I can share and create resources with others (like a living dissertation template that will be updated every year, not every decade). I want my work to exist outside of paywalls and institutions. And most of all, I want to dispel the myth that academics are solitary geniuses who periodically emerge from their wizard towers, publications in hand — a myth which only perpetuates elitist, exclusive institutions that isolate and burn out prospective academics who lack certain privileges.

I recognize that some (maybe most) of my feelings of isolation stem from doing my PhD during the height of the COVID-19 pandemic. Conferences were moved online or outright canceled, and in a field that heavily emphasizes publishing in conference proceedings, I missed out on a lot of networking, commiserating, and collaborating with other students that would normally take place at in-person conferences. Nevertheless, I would love to talk with others who might feel similarly and brainstorm ideas to support each other. Discord server? (entirely serious)

If you would like to commiserate about PhD angst and lament about not having actual wizard towers, you can find Shanel Wu at: (website) / (Github) @sminliwu / (Instagram and Discord) @pipernell / (email)

Trailblazer Recap: Shanel Wu

Hi! It has certainly been a year since I began as an OSHWA Trailblazer Fellow. For one, I defended my dissertation and finished my PhD.

I feel very fancy when I sign my new title.

— Dr. Wu

Over the next few days, I will be posting some reflections on my experiences during the fellowship. The Trailblazers program, true to its intention of supporting open hardware in academia, directly supported development on the Loom Pedals, an open-source customizable interface for a Jacquard loom, intended to promote improvisation and experimentation for makers. The system is based on a modular set of foot pedals with customizable functions, integrating with the TC2 Jacquard loom. You can find the latest prototype and documentation on the project website. (always in progress!)

But I think we all know that open hardware is more than just development. And academia is more than just building things. The Loom Pedals system was the final capstone project for my PhD research, forming a chapter in my dissertation. Beyond supporting this cohort of academics on their projects, the Trailblazers program seeks to support those in academia more broadly by generating resources, building networks, and increasing awareness in these spaces. These upcoming reflection posts will explore some of the particular dimensions of my work, namely doing this as a PhD student and hacking a closed-source machine. I hope I can contribute to OSHWA’s efforts by putting out these posts to generate discussions and build new, supportive connections between people.

Links will be updated as posts go live. Stay tuned for:

If anything I share resonates with you, please get in touch with me!

Contact Info

You can find Shanel Wu at: