Wireless Cap Sensing Fabric

Remembered I had this from fall. When I made some BLE based cap sensors that applied forces to some particles in processing. That was the last time I was working with particles, and I really miss it. Maybe I will do more with it over the summer?

A Shock In The Dark – Technical Challenges

Working with RF radios is hard. Hacking them isn’t that bad, but they are quirky. They do things like fall asleep, and don’t work, or don’t have a strong enough signal. They can be pokey, like all technology.

My general exploration of shock radios started a while ago, outside of a game related framework. One summer, some of us were just hardware hacking, and a friend hacked a radio for something called Pomodoro Zap. Which shocked you if you visited a site during “work time”. She showed me how to hack the RF radio.

From there, I started hooking it up to things like the Muse. Mostly to try and do some funny stuff, but also I just really wanted to shock people with my brain.

Then, like all hardware it went in a drawer for a while until this game came into play. The radios themselves are pretty simple, but there were some challenges. For starters, newer versions of the radios didn’t have hard wired LCD screens. This meant picking modes, and channels was sort of blind. Originally I had thought that maybe we could have a 2 to 1 setup, where one radio controlled 2 devices, but that proved to be difficult because there’s no real way to track states of WHERE you are in the setup. Unlike open source devices that are set up to give you feedback, hacked devices just have some things you can’t track.

To work around that we ended up doing a 1 to 1 setup, 2 radios, 2 collars. Which works pretty well.

Guts of shock box

The board itself has been difficult to get going as well. In this case, I turned to my friend Jane, who is a great hacker, and very meticulous. They’ve been a real help to get the larger protoboard going. And tbh, I really enjoy working with people who just take things and run with it.

We all bounced some ideas back and forth about possible sensors to use. I explored some ideas of capacitive sensing, but realized that we’d have to do something with breakout boards, and that would drive the cost up quite high. We also thought about using just straight up buttons, but again, nice clear ones that would be good to use in a grid, were expensive as a per unit cost.

Eventually we ended up on reed switches. There’s been a quite a few interactive chess board projects done with reed switches, and we thought that it would be good to follow suit, because of the documentation, and ease of being able to find answers online.

The catch is that each of our nodes would also need a neopixel. Jane worked out a cool little PCB design, but the lead time on shipping wouldn’t have worked, so we assembled on protoboard.

So far our tests are going well and everything is working out. Which is nice. We’ll have to figure out how to design the enclosure to hold both the arduino and the radios.

I’ve been working on the game logic for a while, which is over on github:

There’s still some stuff to be done around win conditions, but its getting there. And hopefully it will be done in time for April 28th’s DMG showcase.

Position Generator

This assignment was to figure out our position. I interpreted that more as making a kind of a set of statements, or specific rules you have about making things in general. Because I have a design and development background, those things sometimes fall into more efficiency or naming conventions.

For example there is an ENTIRE set of style rules for coding in Python . But you could also follow your own conventions, as long as they remain consistent. Programmers usually do a lot of refractoring as well, a sort of distilling code over iterations to try and make it more efficient or readable.

But anyways. I took it as rules. Personal rules. Underlying rules. I have a few rules of thumb I follow in life like: “Work is an iterative process” and “Execution Counts”. But I wanted to see what other things I could think of. So first I started w/ words and tape, and chopping up those words to make new words.

Then I moved to lists of words or possible statements that I felt held some importance to me:

Then I reduced those statements into basic-ish structures:

Finally I decided to automate my process via a python script to mix those words around into various proto sentences. Because maybe a randomized algorithm could do things I could not.


Though it was somewhat silly, it did manage to churn out some things that I resonated with quite a bit.

  1. Ridiculous futures should be the way forward
  2. Destructive composition through amusing subversion
  3. Ridiculous automation through absurd iteration
  4. Delicate remixes through robust exposition
  5. Subvert your devices
  6. Remix the glitches
  7. Expose the agenda
  8. Compose the future into futile devices

My position is one of futile devices and ridiculous futures. We should play with the systems we exist in, break them, and expose their futility. Not only will this enable us to learn more about what supports or control us, but also how we can subvert that into new modes. There is a beauty in the world’s collection of smart, glitchy devices. Make them your own. Be your process.