Dwell Belt

Dwell Belt

Chris Luginbuhl


This project was motivated by the creative anarchy of the 6th floor digital futures lounge. In this chaotic and collaborative space, students work, talk, mix, rest, study and hide out.

The videos posted by DF students on this blog give a pretty good sense of the variety of creative activities taking place there. The air is filled with experimental music, flux fumes, hilarious conversation and the sights and sounds of creative collaboration. You often have the opportunity to test someone’s brand new prototype or learn how to do something new with or without a computer.

In addition, students working on individual assignments like this one, and those in second year sometimes require uninterrupted time to focus, to code and to think. But how can I know if the student sitting across from me is available to help with a technical question, or would rather be left alone to work?

We’ve seen a students C-clamp a shelving unit to a table to hide behind, or wear earphones to signal their intentions. We’ve rolled whiteboards over to a table to create some visual, if not auditory seclusion. Despite this, it’s usually not clear when someone in the space is available to talk, or when they’re working against a tight deadline and would rather be approached later.

The Dwell Belt is intended to provide a friendly non-verbal cue about the wearer’s availability.

Highly focused time, such as when writing or coding can be interrupted by smartphones and notifications (Ward, 2017). Likewise, when brainstorming with a colleague, it’s detrimental to have a phone anywhere near, even if you don’t look at it (Przybylski 2013). How can wearable electronics provide us with the ability to connect professionally and socially with others without causing all of the distractions associated with smartphone use and desktop notifications?

The Dwell Belt provides the option of posting pre-programmed messages directly to a Facebook group, summoning coding help, or suggesting face-to-face social time.

Posted to DF 2019 Facebook group wireless from the Dwell Belt

Hardware and software details
(Code, sketches, design files, photographs)

Final piece

The finished product consists of a belt and electronic buckle that allows the user to select an LED animation, and a button for wirelessly posting to Facebook

Finished belt buckle
Finished belt buckle
In class demonstration. Audience like a deer frozen in headlights.
In class demonstration. Audience speechless.


System Architecture:
Hardware and software architecture
Hardware and software architecture

As produced, the Belt consists of a battery pack, on off switch, arduino with wifi, three LED rings, a six position mode switch, a button, software and a housing.

The switch permits various display animations, and the button posts to Facebook, via IFTTT. Since I wanted to post to a Facebook group rather than a page, I needed to use Gmail to post, since IFTTT supports posting to pages but not groups. (Zapier supports posting to groups, but the feature is in beta, and didn’t work for me).

Wiring diagram. Rotary switch is 2P6T, neopixel array is round and has only 36 elements. Protoboard is only used for power and ground.
Wiring diagram. Rotary switch is 2P6T, neopixel array is round and has only 36 elements. Protoboard is only used for power and ground.
In use:

The Belt has several modes to signal the wearer’s state.
Off: power switch is off to save battery
On/standby: code is running for quick start, but no display.
Converse/collaborate: In the first switch position, the lights animate outward in a gentle magnetizing display
Party Time: This colourful flashing display of many colours is inspired by a disco ball. The wearer is looking to chat, have fun, go for coffee or drinks and debrief about how Creation and Computation critique went
Need Help: The flashing red pattern indicates distress and sends the message that all is not well. Perhaps there is a persistent error in the code? People who are not otherwise occupied are invited to come over and ask “How can I help?”
Summon Help: The animation changes to concentric red rings highlighting the “Post” button. When pressed, the Belt connects to wifi to post to Facebook. The animation switches first to amber, and green rings appear as the wifi connection process completes. When the message has been sent successfully, a soothing pulsating green light displays. The wearer may keep debugging, or may adopt the recovery or fetal positions until help arrives.

Video https://youtu.be/0Qi7TIDl5rQ

Mechanical design:

I originally intended to design a smaller housing with an ornamental design covering the Facebook button (“Svelte Dwell Belt”, see design v.1 below), but I ended up with a more boxy approach.

Miniaturization was a challenge. I used hook up wire and a small PCB bus for power. I made the buckle hardware from bicycle spokes and spoke nipples, since these were the smallest threaded parts I could find without machining anything or going to specialty stores.

Mechanical housing v1 and ornamental design (hair becomes circuit board trace)
Mechanical housing v1 and ornamental design (hair becomes circuit board trace)
Belt buckle with removable flask - can be replaced with arduino housing v.2
Belt buckle with removable 3oz flask – I thought flask would be swapped for mechanical housing v.2
Buckle design v.2 based on cowboy belt buckle which holds a 3oz flask.
Buckle design v.2 based on cowboy belt buckle which holds a flask.
Mechanical design v3. "Boxy but good"
Mechanical design v3. “Boxy but good”


buckle with hardware made from bicycle spokes
buckle with hardware made from bicycle spokes
Feather mounted to standoffs
Feather mounted to standoffs

Software Design

I started with example code from Adafruit – WifiClient from their Wifi101 demo, and striptest from the Neopixel demo. First I got the Feather working as a server, then as a client, then reading switches & buttons, then making calls to adafruit.io when a button is pressed. I then added the animations, and finally “interwove” these so that animations could be interrupted with a switch or button. I wrote rough pseudocode along the way to help me structure the code and prioritize the tasks.

I alternated between writing code and assembling the product. This seems like an unusual approach, but I didn’t want to get too far with any one part before realizing there was an in surmountable problem in another area that would require a redesign.

Pseudo-pseudo code v.1
Pseudo-pseudo code v.1
Pseudo-pseudo code v.2
Pseudo-pseudo code v.2


As expected, the original concept evolved during the creation of this project due to technical constraints, part availability and schedule limitations.

In addition, while working on the project’s details – making parts, soldering wires, writing code – I noticed I spent a lot of time dwelling on the problem and the creative space; part of the reason for the Dwell Belt’s name. This was different from the more ordered and deliberate design phases of concept generation, selection, design, etc. It made me think there is some value in the idea of “Critical Making” I was studying to Research Methods class (e.g. Ratto, 2011). While building, I spent contemplative time with the question of how we can interact and give each other signals, rather than just analytical time.

Issues with this version

The belt did work as intended. There are a few questionable bits of code. Firstly, it was necessary to comment out the serial port communication when working wirelessly. Secondly, in order to run the animation which reading the switches, I couldn’t separate our the functions for animation and switch-checking. A better solution would use “listeners” or other asynchronous computing techniques.

In addition, the wifi call (to Adafruit, and from there to Facebook via IFTTT and Gmail) is pretty basic, and not very secure, since it includes my Adafruit credentials in the http GET request, which could be overheard or cached along the way. It does not use https.

I had hoped to have time to do more with the belt and not just the buckle. I would have liked to have a smaller buckle and more light signals from the belt itself. Some of the components (e.g. battery) could have been distributed around the belt rather than being solely contained in the buckle.

The critique feedback was pretty clear – the belt buckle is not a place people want to look for social cues. It would certainly be possible to move the LEDs to other areas. I would like to try sewing 6 or so LEDs around the belt for a more understated effect, and removing the animations from the belt buckle.


Andrew K. Przybylski, Netta Weinstein Can you connect with me now? How the presence of mobile communication technology influences face-to-face conversation quality. Journal of Social and Personal Relationships Vol 30, Issue 3, 2013

Adrian F. Ward, Kristen Duke, Ayelet Gneezy, and Maarten W. Bos Brain Drain: The Mere Presence of One’s Own Smartphone Reduces Available Cognitive Capacity. Journal of the Association for Consumer Research 2017 2:2, 140-154

Ratto, Mark Critical Making: Conceptual and Material Studies in Technology and Social Life. The Information Society: An International Journal, Volume 27, 2011 – Issue 4 pp252-260

Material MadLibs 1 – Max, Shawn & Chris: Kitty Catwash


Sean Harkin, Chris Luginbuhl, Max Lander


Blue foam, button, servomotor, furry


Kitty Catwash


Everyone loves a clean cat. Everyone loves a carwash. Our project combines these two great things for something even greater.

Remember the first time you were in a carwash? Those soapy rollers like an undersea spectacle, magic fingers washing away the traces of your dusty travels? Now cats can experience the magic of a carwash with Kitty Catwash!


We did some brainstorming and came up with a few ideas:

-Using the servomotor and an attached arm to press the button (referencing Useless Box)

-Hacking the button to use it as a spring-powered fur launcher, which would glue blue foam “fur” to a blue foam model of Chris’s bald head.

Button modified to be a launcher
Button modified to be a launcher

-Taking the spring out of the button, compressing it with the servo and making a furry creature hop or fly (pics below)

Launcher button being operated with servo
Launcher button being operated with servo

-Modifying two buttons to have a longer spring-loaded travel, and put them in the legs of a blue foam sasquatch. Use the servo to compress and release the buttons in alternate legs to create a walking motion.

Servo & spring powered legs make this furry guy lurch around, scaring the children.
Servo & spring powered legs make this furry guy lurch around, scaring the children.

-Making a machine to draw fur patterns with a stylus.

3 servos on an arm draw semi-random dashes that look like fur
3 servos on an arm draw semi-random dashes that look like fur

-Using two servomotors to power large brushes/rollers like a miniature carwash….for cats. This is the concept we developed further


We tried making blue foam furry in a variety of ways

-Drawing fur on it in pen

-Cutting triangles onto it

-Using different sizes of cheese graters

-Using a woodworking rasp

-Using a lathe with a dull toolbit

Large cheese grater vs blue foam
Large cheese grater vs blue foam
Rasp vs. blue foam
Rasp vs. blue foam
Small cheese grater vs blue foam
Small cheese grater vs blue foam

Building the circuit with servomotors and making them run helped give us the idea of a carwash because of the washing machine-like back and forth motion.


Step 1: Initial Sketches

Once the final design had been chosen, the first step were some rudimentary sketches to get an idea of how the product would go together. The sketches, although basic, were the preliminary basis for the rest of build. This process allowed us to establish rough sizes for our components; however we failed to account for the fully assembled height of the button. Thankfully, we were able to correct for this in the digital modeling stage.

Rough sketch
Rough sketch

Step 2: Digital Modeling

The components were then digitally modeled using Autodesk Inventor. The aim was to create and assemble the components digitally to try and predict any issues which may arise in the build. Initially they build went well, until the button component was added. As can be seen below, the casing did not accommodate the full length of the button. The solution was to increase the size of the handle’s lid. By increasing the depth of the lid instead of the base, the button itself would be better supported in the prototype.

3D model in Inventor
3D model in Inventor

Step 3: Build

Building the components was fairly straight-forward since we had both sketches and a digital model to work from. As the brief for the project outlined our material as blue foam, we tried to minimise any additional materials. For the handle and the lid, the blue foam was cut to size using a bandsaw, and any supplementary subtraction was made using a free-hand cutting blade. The only additional material used – outside of our Creatron Kits –  was the hot-glue which was used as an adhesive. For the handle, the material was cut to the correct size and then cut in half. This allowed the excess material to be cut out with ease. The pieces were then glued back together to form the handle. The lid was also cut to size, only requiring a bored hole from a pillar drill for the button.

Soldering and glueing
See the poem “Axe Handles” by Gary Snyder for details on how cool it is to make handles by hand.
Making the kitty brushes on the lathe
Making the kitty brushes on the lathe

Step 4: Assemble

Again, due to our thorough design process and simple design, we were able to assemble the product without much hassle. First we moved our electronics from the breadboard to the protoboard; this was always the plan as the breadboard was thought to be too cumbersome to be included in the final product. We assembled the components on the protoboard and were able to cut it down to size for the handle (Note: Max’s button died at this point making us think the soldering/code was not correct, after a short while we realized it was the button and replaced it).The protoboard was inserted into the handle using a tight-fit. Similarly, the servos used a tight-fit joint into the handle, with the rollers were attached to the base of the servos by a hot-glued washer. The button supplied came with a washer to secure in place inside the lid. The group discussed using more permanent joints, however settles on the idea that this was a prototype of the final product. Although functional, if we were proceed with the product more permanent adhesives and joints would be used.

Circuit transferred to a protoboard
Circuit transferred to a protoboard
Pending UL certification
Pending UL certification
Kitty Carwash assembled
Kitty Carwash assembled


Circuit Layout v.1
Circuit diagram for v.2
Circuit Layout for v.2




The most recent code can be found on our GitHub.


The v1 code can also be found there if you dig. An easier way is to find it in our other repository:



Version 1

Getting the button connected to the servo was easy.  That being said, the button itself is quite finicky/sensitive. It’s very tricky to get a single press out of it and more often than not it reads multiple click (AKA many 1’s). Looking into it further provided us with a number of avenues to compensate for this, but after talking it out we decided to with holding down the button, and avoid the press down noise altogether.

Using the “buttonservo” code (which is a mashup of the default Button and default Servo codes in Arduino), we tried to play with the angles and time between updates to see if we could get a constant increase, but again was confronted with the finicky button. Most of the time, regardless of the settings, the button would interrupt itself and the servo would stop and start again from it’s updated spot, which would have been great if it could process it fast enough to give a constant loop, but we weren’’t able to get that happening.

So, we moved on to the internet to try and find a solution, which led us to this ask for help – https://arduino.stackexchange.com/questions/17536/controlling-servo-motors-with-push-button-problem-though, which moves the servo from one end of it’s range to the other on a button click. The problem with this for our purposes was, again, the single click. We tried multiple ways to adapt this to to be constant press friendly – namely trying to make one click result in one degree of movement, mostly to no avail. What this process did make us realize was that the range of movement needed to be much shorter than both of these options were currently operating on, somewhere in the range of 60 degrees. And also back and forth, the back and forth is important (this was forgotten many times and resulted in half successes of it going in one direction and then breaking when trying to add reversal). All this lead to “ButIncr” (see GitHub repository revision with this name).

Unsurprisingly, the code did not work. As we was trying to troubleshoot this and not having much success, we returned to an earlier version that had been close and adjusted the degrees to 60, thinking that worst case scenario it could be multiple fast clicks if not a constant press. Plugged it in and held it down, and it did exactly what we wanted – it moved quickly between two points. Which is great, except that’s not what it’s supposed to do. It works because it is constantly cutting itself off after only a small amount of movement. But also, it functions exactly how we wanted to, so we decided to keep it and move on to putting it altogether.

Version 2

With this first version working, we created a branch of this code on github a fresh developer was brought in to pick up the torch.

One issue with servomotors that we wanted to address is their tendency to “lurch” at full power to a new position when first connected. In our development branch, we made a change to the algorithm: in the arduino’s loop() method, had the arduino read the button state, and if pressed, move from 1 degree to 60 degrees and back to 1, then check the button again and repeat.

Returning to 1 degree ensures the servo is always “parked” in the same position and avoids lurching. We used 1 degree as the start/end point rather than 0 because one of our test servos was straining against the hard stop when set to zero.


As a general rule, animal owners will buy anything for their pets. In the context of the internet and a constant need for entertainment, this is twofold applied when talking about things that make their pets entertaining . Further to that, cleaning cats is often the worst part of having cats, besides finding their fur in everything (An example DIY solution to all of these consideration can be found here, in this video of people vacuuming their cats – https://www.youtube.com/watch?v=v_qYwJ94Ja8).

As physical computing technologies because more and more accessible to more and more people (and kids!) we get to see the creation of more and robots, many of which exist primarily as entertainment devices (most notable of these is Simone Giertz’s Shitty Robots). One of the question sometimes being asked by these experimental and DIY robot makers is “Will a robot solve this single unique problem better than a human?”

Kitty Catwash sits firmly in between all these ideas & processes. With the Kitty Catwash, we tried to combine a solution for a real life problem, via the functional reference of the traditional carwash, with a strong sense of whimsy and entertainment value, with the ultimate goal of answering a single and super niche question – Can a robot brush my cat better than a brush?

Simone Giertz’s Shitty Robots – https://www.youtube.com/channel/UC3KEoMzNz8eYnwBC34RaKCQ

Weird pet products – http://twentytwowords.com/ridiculous-pet-products/

The many reasons why we love useless robots – https://www.newscientist.com/article/2082014-the-many-reasons-why-we-love-useless-robots/