Weekending 12022012

This week in Barcelona started with the pleasure of having Quadrigram making the cut of the finalist of the Strata 2012 Startup Showcase. The tool is a couple of weeks away from seeing the light and the teaser video is now online. At Strata, I will present the tool with my friends at Bestiario right after my session on Sketching with Data.

On the invitation of Claro Partners to present the lab, I took the opportunity to present my experience working with network data, particularly focusing on the methods we employ to help innovate in the domain of ‘big’ data. Have a look at the slide deck: it starts with a reference to Napoléon Bonaparte ‘Un bon croquis vaut mieux qu’un long discours’, goes through the uses of sketches as part of any creative work exemplified by Le Corbusier, and concludes with Picasso and the art of sketching.

Okay. What else? In Los Angeles, we used a solder paste stencil for the first time. Impressed. Good stuff. Definitely worth $25-$50. You can tell in this video I haven’t used solder paste in awhile..I forgot to put the proper hot, hot air on so I’m basically just blowing balmy air on the board. More practice, again. I have to say, the stencil is definitely a time saver. Although, I’m still going to get a big-ass pick ‘n place machine cause that’d make it even faster to get boards done. ((That’s EarFreshener up in that video, by the way.))


Nicolas came to town on Saturday and Sunday we went to the crazy flea market at the Pasadena Coliseum, home of the Rose Bowl. We found weird things and Nicolas found a fantastic mint-condition Polaroid in its crushed red velvet case. Lucky old salt. Prior to that, his week was focused on both phone call with Lift12 speakers and the final presentation for the head-mounted display project, which went fairly well. Results from this field study are kind of secrets so far but there will eventually be a publication about that.

Weekending 05022012

In Geneva, where the cold winter is striking back, the week had been, for once!, very quiet with data analysis (head-mounted display project) and book writing (game controllers!). We’re also preparing two workshops for the upcoming Lift12 conference. The first one is about location-based games organized with Mathieu Castelli, who used to be the founder of New Game, a pionneer in this domain (they released Mogi, one of the first commercial LBG). The session will consist in a series of group activity based on Meatspace Invasion, a location-based game recently developed by C4M and Mekensleep. After a quick introduction about these, we will form groups who will test different combinations of game parameters. We will then go on the field in Geneva to test these scenarios and regroup after the game session to debrief the outcomes. The second workshop is organized with the friends from Superflux (Anab Jain and Justin Pickard). It’s called “Foresight suprise” and as the name indicates, I won’t tell much about it except that it’s going to be about futures and futurescaping.

Hi. It’s Julian. In Los Angeles last week we got back the PCBs for Ear Freshener. One thing that was wrong is I mucked up the holes for the little audio card that plops onto the controller card. It won’t go all the way through, but it’s fine for testing. I’ll also be trying out these PCB stencils for the solder paste process The entire week was devoted to audio design and prototyping and team wrangling, I’d say. Nick Foster was in the studio for the last few days of the week so we had time for planning the project, eating tacos, working on the future of the whoopie cushion and the like.

It was actually a bit of an existential week for the audio project insofar as I had to figure out what the fuck was up with a bit of anxiety I felt during the previous weekend’s bike ride. I don’t like anxiety on bike rides. It was best summed up as a consideration as to new team configurations and advanced design team best practices. The conclusion? In this particular Advanced Design team a few things happen. First, we are asked to put eyes on an existing project and help make it better than it would’ve been were it not possible to have an experienced team of thoughtful designers who are comfortable working in an unstructured. We are asked to work on new, emerging things that are being done in a traditional structured way. And we are expected to come up with new things. I’ve come to the conclusion that we treat the “asks” — the things that come from outside — with more urgency than the latter projects — the things where we’re expected to come up with new things. It seems that we respond to the “battle stations” klaxon as if it matters more than the things we believe in first. Those things disappear into the closet and desk drawers. Which felt a bit like self-loathing in a really horrid way. Like — when someone *else says jump, we jump. When we believe in something enough to jump, we sorta *shrug. Or put it to the side when a “client” asks for something from us, *even *when *we *don’t *believe in it.

(Although, have to say — not believing in something someone else is doing is often a great opportunity to collaborate to make it better and believable. Not to be too normative about it, but there are plenty of things that seem like lovely fancy door knobs with awesome new mechanics and latching technologies that someone will bring to us and basically ask — what sorta house do you think this should go on? And the problem is that the door knob was thought of without really thinking about either the house..or the people who might have to use the door knob and, pray — live in the house. That’s the curse of the technologists and accountants/business people and the opportunity for more collaboration with design from the get-go.)

I hope to correct this through the audio project because otherwise — what’s the point?

So, I’m treating this quite as if someone from somewhere else came down and “made” the team get to work. Which effectively they did. The team will consist of folks who can commit the majority of their time to the project — it’ll run short and sharp and be quite deliberate. Sorta no nonsense; no whining. Polite..but ruthless.

This week in Barcelona has been almost exclusively dedicated to Quadrigram performing some interface polishing and documentation tweaking with the help of Tim Stutts and Brava Büro. In the backstage, the pipes and wires are gently coming into place with some mind blowing resulting reaching the frontiers ‘Quine computing‘. All this will make sense in the near future.

I also took some time to step back and order my thoughts for an upcoming talk at Strata that will focus on our approaches and tools to work with network data. This week, I will test and rehearse a first iteration responding to the invitation to our friends at Claro Partners.

I will use our study hyper-congestion at the Louvre as one case study. A work that was actually featured yesterday in the newspaper El Periodico as a consequence of Yuji presenting some results in Sweden last week.

Finally, our measures of mobile phone network activity in Geneva have led to some beautiful visualizations and animations produced by Interactive Things. Keep your eyes wide open if you happen to stroll around the Geneva main train station during Lift12.

This Is What I Sent — The Ear Freshener PCB Design

Here’s the current PCB CAD for the Ear Freshener. It’s sorta got two sides, but on the top I basically have a carrier for another board that contains the audio codec device. The components around it are all the brains that control track selection from the potentiometer/knob — that people will think, hopefully, is the volume knob, but actually it isn’t.

The gag/provocation is that knob. It’s an audio thing with a knob..but the knob isn’t an on-off thing. Rather, it’s some kind of semantic intensity knob. You turn it “up” and you get more-of. You turn it “down” and you get less-of.

There’s also a spot to hook up a little button. The button switches the Ear Freshener sound idiom. So you can go through the seasons; or cities; or airports.

((We should figure out a good name for the gag/provocations that we always build into our little devices.))

To do this, I’m probably a little over-engineered, maybe. Maybe not. I use two Atmel Attiny25‘s that basically do the track selection through a data port control on the audio codec. Basically counting in binary, with the track selection one doing the low-order bits and the high-order bits selecting the sound idiom you’ll be freshening your earballs to.

There’s also a bit of circuitry for a step-up regulator. I want to run this off of a single, readily available battery cell — AAA or AA. I’m over USB charging for the time being. At least now. The extra crap you need is a headache. Sorta. I guess I just wanted to get back to that thing where your audio devices take a battery. Not that I want more batteries in the world, but the rechargeable ones? They’re fantastic nowadays. Lots of capacity.

You’ll notice there’s a bunch of nothing on the right. I put that there for mechanical mounting of a battery holder for now. I just didn’t want the battery dangling off in nowheresville. This way I can double-sided sticky tape it to for testing and carrying around.

That’s the deal. I sent off the data to AP Circuits for the first time. It was about $40 with shipping for two boards. The boards are about 2.1in by 2.3in, so sorta small. There was a bit of back and forth to get the data they needed, especially for the board outline. This always ends up being something I leave out — my CAM Processor script doesn’t have that layer built in as output. Need to look into that.

Why do I blog this? I need to keep going on making logs of activity for the various projects that go on here, even if it’s a quick note.

Weekending 28012012

Here in Barcelona, we continue fine tuning Quadrigram, with now a meticulous work on the coherence of pre-programmed modules the tool will provide to access, manipulate and visualize data flows. It also means some backstage cleaning and improvements of the engine that supports the visual programming language.

We have also been busy joining forces with our new friends at the user experience & data visualization studio Interactive Things. They have been mandated to produce visualization mobile phone network traffic and we do our best to provide the cleanest and more meaningful pieces of data. Their magic will be presented at Lift 12.

In the meantime, Yuji Yoshimura traveled to Helsingborg, Sweden to present at ENTER2012 a study of the visiting experiences at the Louvre Museum. His paper New tools for studying visitor behaviors in museums: a case study at the Louvre is the result of a collaboration between Universitat Pompeu Fabra, MIT SENSEable City Lab and us. It builds on the data we collected in 2010 to measure hyper-congestion phenomena in the busiest areas of the Louvre.

In Geneva, the week was focused on various projects. It was the last week of teaching at HEAD-Geneva this semester. Last Monday, I gave a course about innovation and usages and another one about design ethnography (which was actually made of students presentation). Tuesday was devoted to meetings in Saint Etienne (France) at Cité du Design, a quite big Design Center located in an old and beautiful manufacture. Then I (Nicolas) gave a presentation there about human-robots interaction (slides are on Slideshare). The rest of the week was spent in meetings with Lift speakers, students (time to discuss their masters thesis!) and watching video material for the current field study about head-mounted displays. The end of this project is pretty soon and we are currently working on the final presentation for the client.

In Los Angeles, Julian was a busy-bee trying to get PCB’s fabricated for the Ear Freshener’s

Design Fiction + Advanced Designing + Trust in Volume Quarterly

The most recent — now a month or two old — issue of Volume Quarterly was on the topic of The Internet of Things. And within that was a small sub-volume of essays and articles on Trust compiled by Scott Burnham who has been running a project called Trust Design for Premsela which I understand to be The Netherlands Institute for Design and Fashion.

((The Laboratory seems to be a recurring guest in Volume Quarterly. We were in one a couple of issues back — their issue on The Moon.))

Scott started his project on Trust just as we in the Advanced Projects (then Design Strategic Projects) Studio at Nokia were beginning a project with the same name and some of the same questions. One of our questions was to understand what Trust is and how Design can somehow illuminate where Trust exists and its paths and relationships. When I say “illuminate” the image that comes to mind is one of a special detective’s forensic UV light illuminating something under specific conditions that would otherwise not be seen. Or, in those weird 1950s era medical treatments in which a subject drinks some wretched fluid or is injected with something that shows the paths of digestion or the networks of arteries when shown under X-Rays or something. (Maybe it isn’t wretched, but the thought gives me the willies for some reason.)

In any case there were many facets of the Design work we did in the studio, one of which was this Alarm Clock which was meant to operate precisely in this fashion — to focus our attention on a simple interaction ritual in which we were forced to consider characteristics of Trust.

The essay far below below was my contribution to the Volume Quarterly issue.

But first..

There’s a thing or two to add as well, that have more to do with this particular way of doing Design — or Design Fiction. The process of *making these clocks — which were made out of plastic and aluminum and electronics and solder and all that — was only partially about the specifications that determined how those things would be configured. Beyond those pragmatic, specified things were the ideas we sought to force to the surface — the concepts that we wanted to make ourselves address and consider directly. The preposterousness of the interaction ritual that the alarm mechanism forces was a deliberate way of compelling us to think and talk and design for this ephemeral social bargain called Trust. There was no way around it. We couldn’t lose ourselves in the geekery of circuit design; or choosing a color for the LED numerical displays; of obsessing over compound curves in the industrial design of the thing; or fetishizing any aspect of the “Design” as it is traditionally understood — a material instantiation of an already-accepted and well-understood object. There’s not much movement these days in Alarm Clocks. They are what they are and the variations come in things like…size. Like…color. Like…brand. Like…AM/FM or longwave. Like…number of alarms. Like…style. Like…box-y or round-y. Etc. You get it.

You’ll get stuck with those sorts of boring variations if you think about Alarm Clocks traditionally. Rather, thinking *not about Alarm Clocks but about waking up, and the rituals around it changes one’s approach. All of a sudden, you’re mucking with tradition. You’re getting people upset. You’re not responding to the client’s brief the way they expected. You’re not just doing color and materials variations.

Pfft. So what? Well — looking at things a little sideways is, for lack of a better moniker, advancing design. Advancing it beyond the expected. Doing the Fosbury Flop for Alarm Clocks.

The other thing to say about the project is that the making of the thing — all that plastic prototyping; all that circuit design; all that figuring-out-of-colors-and-materials; all that CNC machining; all that figuring out of tool paths; all that figuring out of firmware and interaction algorithms..why was all that done? Yes, of course — to make the thing *work, in the plainest sense. But, more than that — it was all done to do the Design. The making of the thing is *also a way of doing the Design of the thing. We didn’t figure everything out and then said, “right. now we can make it!” The making was the designing. Assumptions and questions are raised. We interrogate our own ideas and create new ones, whilst making and building and handling material and trying out little scenarios. The peculiar nature of the clock was such that we had debates, one in particular was about what the display should do when the little keyfob alarm-buzzer part was removed to be given to a friend. I felt quite strongly that the display on the main clock should go off, so that you’d have to Trust completely the person who was meant to be your human alarm. Otherwise, you can wake up and check the time, which is an implicit way of not really trusting that human alarm person.

This was the bit of fiction insofar as a clock like this would be quite otherworldly. There would be a very different set of assumptions about how relationships work; about what waking up entails and what it is for (getting to a meeting on time; making sure the kids are ready for school; not missing a flight and all the weight and significance of what happens if you *don’t do these things when and what time they need to be done.)

It would be a very different world if we just *woke up when we woke up, rather than waking up to the same time nearly every day. It’s a slightly skewed universe that this clock came from, but it’s crucial to do this kind of design. Why? Well — it advances the realm of possibilities and begins one considering quite directly about creating new, more curious and sensible interaction rituals. It is also a way of advancing design — doing design differently; questioning and challenging assumptions not only of materials and colors and forms and such, which is good. But questioning the actions and rituals and behaviors of the humans, even to the point of something so seemingly absurd as waking up in different ways. This isn’t to say that people will want to wake up to other people knocking on their doors or shaking their pillows, but it forces a number of unexpected considerations and questions and new ideas that plainly wouldn’t come about if one just focused on different colors for clock displays or snooze button styles. Its a kind of advanced design that is able to engage in its topic by throwing out all base assumptions and free-fall a bit into a weird world and then *not allow the usual questions to arise. Sink into the discomfort zone and do some advanced designing.

How does the underpinnings of social relationships become a design principle? How does one design for trust? Can an intangible like trust become embedded in an object?

The principle that “theory” can be expressed in an object plays a part in this question. Substitute “Trust”, a kind of philosophical principle that is perhaps, in my mind, best expressed through exemplars that represent it, rather than the abstractions of philosophical discourse.

The topic of “Trust” presented itself in October 2008 with a tremendous force. The world rattled as global networks of “Trust” institutions collapsed on a scale that sent apcoloyptics scurrying for Old Testament passages consistent with the sequence of events witnessed across the globe. “Trust” became a keyword for these events as macro social institutions that were once “too big to fail” failed despite their size. These institutions that were once the bedrock of society cracked and dissipated and in their failure, revealed what Trust is, at its core. It is, of course – people and the networks of relationships that define what it is to be a social being.

In the Advanced Design studio at Nokia, we were curious about Trust and what it means. Trust is recognized as a core values of the Nokia brand. The worldwide events brought the topic to the fore and provided an impetus for a design-based experiment. Our question was — what is Trust and how could one design with Trust as a guiding principle? How do you embed Trust in the material of a designed object?

The project walked around the topic, building up the studio’s expertise on the topic through the Design equivalent of a “literature review”, both in the sense of readings as well as a more tangible equivalent. We collected essays and books and made things — objects. We brought in both internal to Nokia and external experts on the topic. A social psychologist talked to us about how ordinary people become extraordinary liars. We followed closely the daily events of the macro level systemic failures of insurance companies, banks, economies and entire governments.

Our goals were deceptively simple — to develop a set of principles that could become “actionable” and be “designed-to” in order that Trust could be embedded in the material of an object.

Amongst a dozen principles, one is worth highlighting and is best paraphrased and represented in one of our tangible exemplars. The principle goes something like this: facilitate the trust network — allow people to trust the people they already trust.

Our tangible prototype was, of all things — an alarm clock. We called it the Trust Alarm Clock. The design brief was simply to make an alarm clock that embodied the principle — an alarm clock that highlighted the idea that trust is a relationship between people. At the same time, it was a platform that allowed us to experiment with this simple principle. As you will see, it is an almost absurd object. But it was the response to the brief that we made, without questioning our motivations, but rather following our curiosity on the topic of Trust.

The clock is best described directly. It consists of two components. The main component is not unlike a conventional bedside alarm clock. The second sits nearly where one would expect the canonical “snooze” button of a conventional alarm clock. This second piece is a small, removable “fob”. When one sets the desired time to wake up, the fob is programmed with a digital count down timer. The alarm setting ritual starts when one sets the wake-up time using a dial on the back of the clock. While doing this, the fob timer is configured so that its count down would expire and the fob would “alarm” when the alarm clock setter would like to wake up. The ritual is completed when the fob is removed from the main component and given to a most trusted friend. In that ritual of handing over the fob, the network of trust is established and embodied. The “handshake” of the passing represents the creation, or the invigoration of trust in its most elemental form. Handing over the fob signals that there is Trust amongst this small, two-person social network. If one wants to wake up — or be woken up — one must first consider a number of things. Primarily — who do I trust to wake me up? Who would I want to be woken up by? To whom do I want to convey that I do indeed trust them?

Short animation of an interaction ritual.

We did not suppose that a bedside alarm clock like this has mass-market appeal. It’s a theory object — a way of questioning and probing and exploring the idea of Trust as made into this provocative material exemplar. In a way it is a bit of fiction, only not written, rather made as a physical object that compels one to think of the stories and “user experiences” that may surround it. The fiction is established through a provocation created through design practices.

Theory objects are like material instantiations of ideas — perhaps even our hopes and our imagination. Theory objects refract some social practice in a peculiar and hopefully thought-provoking way. They are “theory objects” in this sense, ways of shaping refining, refracting and altering social practice hopefully in a way that creates more habitable worlds.

The theory object is a way to think about “technology” as something that does more than utilitarian or instrumental. It is an embodiment of some sort of practice that is not outside of the realm of social action. In other words, the theory object is a social object — one that can shape and mutate social practice. Technologies are mutable. They can be what we need them to be, and shape how we experience the world and in that way, are social. What we are doing here is over-emphasizing this point by skirting around the usual assumptions about technology in order to make this point about their social nature more evident and obvious and provocative.

Why should we care enough to make this point that technologies are embodiments of social practice? Because we need to reveal the human hand in their creation and their possibility. Once we can see that people put these things together (and show this process plainly, through images and descriptions without secrets) it becomes possible to talk about how they could be different, or obey different laws and assumptions — possibly become more environmentally conscientious, or help us find playful ways to be more compassionate to mean people, or find ways to be kind to strangers (whatever..need some concrete examples, perhaps anticipating the projects.)

In the case of the Trust Alarm Clock, we were confronted with a rather exciting and unconventional direction for ways of waking up, which everyone does, with the regrettable exceptions, of course. The question evolves beyond *who do I want to wake me up, and who do I trust the most to, say — make sure I get up to make an unusually early meeting or airplane departure. Rather, through this theory object we were drawn into thinking about other *things one may wake up to besides the time of day. What sort of alarm clock might the near future bring that represents a trusted evolution of the waking-up ritual. Perhaps an alarm clock that allows someone in my networked social graph to wake me up. Or — are there things that I trust more than people in these circumstances? Somethings that are beyond the rather mechanistic and mundane ritual of waking to the time, which, after all — is not particularly exciting. Might the things that are more relevant or consistent with our connected age be what wakes us in the near future? In the near future, might we trust more an alarm clock that wakes us up when other people start waking up in order to facilitate that sense of being amongst a larger group of people who are also starting their day. Who are we to say that the now common ritual of waking to a specific time become as antique as luggage without wheels.

Varieties of Controls

Never would’ve thought how particular a fella could get about the action of audio controls. I’ve collected an assortment of potentiometers for the audio mixer project. From well-dampened to action that goes tick-tick-tick with detents. The red one in the foreground? That’s an optical encoder that continuously spins — no stops. It might be a bit of a control fetish, but the action of these things matters. Even in an era of touch, click and very screen-y interactions tactility and motion matter. Which raises a little concern — not doubt, just concern — about going hog-wild with gestures.

Why do I blog this? Things are moving forward with the audio mixer. Slower than expected; unexpected things in and around the studio plus upcoming travel preparations and a shift-in-time to make the U.S. Labor Day holiday happen for me this Friday. Downtime and uptime. Sending the PCB off any minute now..
Continue reading Varieties of Controls

The Week Ending 150110

Saturday January 16 15:51

From here, the next week begins. Sayulita, Mexico to repast, float, read, drink and celebrate with friends, a friend’s birthday.

The week began with the Microsoft Social Computing Symposium, 2010 edition. I’ve put my notes from the event here in the immediately preceding blog post.

Back in the studio on Thursday and Friday to tidy up a few loosened ends with the Trust project and coordinating some final assembly particulars with Tom, Simon and the fine folks at the prototyping family house Aeolab for the second clock. The industrial design is fantastic and lovely which only complements the provocation of new interaction rituals embodied in the object itself. Next Tuesday should be close to the last hand-off of hardware and I suspect we’ll begin machining next week, and finalize some decisions about stock and some workarounds to avoid a rather expensive block of acrylic.

I did a share on the project in-house on Friday, sort of slipping and sliding over the story and the communication — it’s been probably a month since I’ve been up in it, what with the holiday break and all. Soon, it’ll be back on the tip of my tongue.
Continue reading The Week Ending 150110

Preposterous Scales of Time and Size

20091110_07

A ridiculously quaint DB9 connector attached on the far end to some peculiar, but not-mini-USB connector. (Best as I can tell, the thing on the other end is a proprietary connector, but I’m prepared to be proved wrong. Every of the variety of old and new *scaled* USB connectors I have lying around would not fit into the connector port on the device that is meant to be connected). The grotesque scale difference reminds me of the queasy feeling I get when I stand close to and look up at tall things like grain silos, especially.

The preposterous DB9 is the thing that make me shake my head ruefully and do that sucking of air between my teeth because it came packaged with a 2010 device, which is to say something quite new, freshly produced. It’s a decidedly geeky, quite expensive software programmable wide-band radio. The fact that it is geeky is almost certainly why it comes with a DB9 connector on the *computer* side, rather than a USB connector. Geeks tend to (a) have a *PC* containing at least one old-fashioned RS232 sputting serial port on it, and (b) know how to program things that talk RS232 over the *serial port*. But, then to put some fancy subminiature connector on the *other* end as if to say —

*we’re connecting your creaky, ancient computational device that needs a fan to keep it from blowing up to your fancy, new fuck-off-and-die software programmable radio, and we’re going to link the ancient past with the new, gleaming future — you just need this this special flux-capacitor cable. And, bonus — you can *buy* another cable with a so-called *Universal Serial Bus* connector instead of the *DB9* plastic cudgel if you’re already living in the 21st century.*

G’aaaaahhhh!

Well, although I am intellectually peeved that I am still finding things in the 21st century that contain DB9 connectors on them, what I am intellectually curious about is how, when, why and what becomes *legacy*? How do things such as this enter into the idiom of *quaint*, or *old fashioned*? How long before such things become *obsolete*? What standards, norms, expectations, specifications, technical requirements compel a *holding onto of the past?* What are the scales of historical pasts — retro, old-fashioned, quaint, legacy, plain-old, ancient — and how do they shape design and engineering possibilities for the near future?

Why do I blog this? Attempting to understand how to make the future into today, possibly by making extraordinary things that might come to be into either ordinary or even normal and everyday and then into quaint and old-fashioned. I am curious as to how to play with scales of time to help place things/experiences/moments that might be quite near futuristic into the quotidian, everyday. That is, making the new crazy stuff ordinary so we can begin to explore the kinds of rituals and practices that these things exercise. At the same time, reflecting on how Everything That’s Happened, Has Happened Already — so how do you create those moments that elevate the experiences that are now happening again rather than over-fetishizing the technical and instrumental aspects of the kit?
Continue reading Preposterous Scales of Time and Size

LIS302DL. A 3 Axis Accelerometer

Tuesday July 14, 13.12.21

Ooooh. Those code jockeys in the Laboratory have been mucking about in the ol’ locker room, giving each other rat-tails, chucking firecrackers in the halls and having a good horsin’ around. Smoking cigarettes and drinking cheap booze. Everything. Stink bombs in the girl’s room. Whatever. It’s a regular Lord of the Flies fest on the electronics wing of the Near Future Laboratory. And, look what we found! Some pole dancin’ hardware porn! Step right up! Don’t crowd..

Wednesday July 15, 13.04.33

In reverent honor of my friends and chums who are holding forth with Sketching in Hardware 09 in London and for the solemn sadness I have for not being able to participate this year, I hereby drop some code and hardware science up on this piece of blog with a dozen or so lines of Arduinoness meant to articulate and instrumentalize the wonderful ST Micro LIS302DL 3 axis accelerometer, delivered here via the Sparkfun breakout board. Without further ado, but with plenty of firmware nakedness, here’s the sketch..*slug* this one’s for you, Sketchers..*sob*

#include

// TWI (I2C) sketch to communicate with the LIS302DL accelerometer
// Using the Wire library (created by Nicholas Zambetti)
// http://wiring.org.co/reference/libraries/Wire/index.html
// On the Arduino board, Analog In 4 is SDA, Analog In 5 is SCL
// These correspond to pin 27 (PC4/ADC4/SDA) and pin 28 (PC5/ADC5/SCL) on the Atmega8 and Atmega168
// The Wire class handles the TWI transactions, abstracting the nitty-gritty to make
// prototyping easy.

// We've got two accelerometers connected. You configure the address of each one
// by some wiring
int address_1 = 0x1C; // SDO on the LIS302DL connected to GND makes it at I2C address 0x1C
int address_2 = 0x1D; // SDO/MISO on the LIS302DL connected to VCC makes it at I2C address 0x1D
void setup()
{
  // we'll use the serial port to spit out our data
  Serial.begin(9600);

  byte tmp;

  Wire.begin(); // join i2c bus (address optional for master)


  // Read from the "WHO_AM_I" register of the LIS302DL and see if it is at
  // the expected address.
  // If it is not, spit out a useful message on the serial port. We'll get
  // erroneous data from querying this address, though.
  Wire.beginTransmission(address_1);
  Wire.send(0x0F);
  Wire.endTransmission();
  Wire.requestFrom(address_1,1);
  while(Wire.available()) {
   tmp = Wire.receive();
   if(tmp != 0x3B) {
     Serial.print("Problem! Can't find device at address "); Serial.println(address_1, HEX);
     delay(1000);
   } else {
  // configure the device's CTRL_REG1 register to initialize it
  Wire.beginTransmission(address_1);
  Wire.send(0x20); // CTRL_REG1 (20h)
  Wire.send(B01000111); // Nominal data rate, Device in active mode, +/- 2g scale, self-tests disabled, all axis's enabled
  Wire.endTransmission();
   }
  }


  // Read from the "WHO_AM_I" register of the second LIS302DL and see if it is at
  // the expected address.
  // If it is not, spit out a useful message on the serial port. We'll get
  // erroneous data from querying this address, though.
  Wire.beginTransmission(address_2);
  Wire.send(0x0F);
  Wire.endTransmission();
  Wire.requestFrom(address_2,1);
  while(Wire.available()) {
   tmp = Wire.receive();
   if(tmp != 0x3B) {
     Serial.print("Problem! Can't find device at address "); Serial.println(address_2, HEX);
     delay(1000);
   } else {

  // configure the device's CTRL_REG1 register to initialize it
  Wire.beginTransmission(address_2);
  Wire.send(0x20); // CTRL_REG1 (20h)
  Wire.send(B01000111); // Nominal data rate, Device in active mode, +/- 2g scale, self-tests disabled, all axis's enabled
  Wire.endTransmission();
   }
  }
}

void loop()
{
  Serial.print("1:"); read_acceleration(address_1);
  Serial.print("2:"); read_acceleration(address_2);
}

void read_acceleration(int address) {
  byte z_val_l, z_val_h, x_val_l, x_val_h, y_val_l, y_val_h;
  int z_val, x_val, y_val;
  Wire.beginTransmission(address);
 // Now do a transfer reading one byte from the LIS302DL
 // This data will be the contents of register 0x29, which is OUT_X
  Wire.send(0x29);
  Wire.endTransmission();
 Wire.requestFrom(address, 1);
  while(Wire.available())
 {
   x_val = Wire.receive();
 }
 // This data will be the contents of register 0x2B which is OUT_Y
 Wire.beginTransmission(address);
 Wire.send(0x2B);
 Wire.endTransmission();
 Wire.requestFrom(address, 1);
 while(Wire.available())
 {
    y_val = Wire.receive();
 }

 // This data will be the contents of register 0x2D, which is OUT_Z
 Wire.beginTransmission(address);
 Wire.send(0x2D);
 Wire.endTransmission();
 Wire.requestFrom(address, 1);
 while(Wire.available())
 {
    z_val = Wire.receive();
 }

 // I want values that run from {-X to 0} and {0 to +X}, so a little bit math goes on here...
 if(bit_is_set(x_val, 7)) {
   x_val &= B01111111;
   x_val = -1*x_val + 128;
   x_val *= -1;
 }

if(bit_is_set(y_val, 7)) {
   y_val &= B01111111;
   y_val = 128 - y_val;
   y_val *= -1;
 }

 if(bit_is_set(z_val, 7)) {
   z_val &= B01111111;
   z_val = 128 - z_val;
   z_val *= -1;
 }

 Serial.print(x_val); Serial.print(":");Serial.print(y_val); Serial.print(":"); Serial.println(z_val);
}

Tuesday July 14, 13.09.59

Wednesday July 15, 14.37.44

What’s going on here? Well, straightforward silliness and hardware gafflin’. Two accelerometers on the I2C bus just cause. It looks like this is as many as you can have on there, unless you do some shenanigans or create a second bus with some cleverness.

The hardware spec on the device (Which. You. Should. Read.) explains that, if we’re going to talk to these things using the I2C bus we need to wire CS to the high end of the logic rail, so VCC. This tells the device that we’ll be using I2C protocol. Then we need to address the device. If we connect the MISO (master in, slave out) pin to GND, then the address will be 0x1C. If we connect the MISO pin to VCC, then the address will be 0x1D. So, MISO, in the I2C configuration, controls the least significant bit of the address. This way, without further mucking about, we can have two accelerometers on the bus, which is probably one more than most situations demand, but just in case.

If I were to connect more than two, I would probably go ahead and use the three-wire protocol and have one microcontroller pin per accelerometer dedicated for chip-select (CS). Fortunately, this device supports three-wire protocols, or the SPI protocol.

Tuesday July 14, 13.17.11

The Arduino code example above does some simple preambling — initializing the two devices after making sure they are there. Then it just loops forever, reading accelerometer data from each of the three axes of each one, doing a little simple bitwise arithmetic to make the data from a negative value for negative g (upside down in most situations) to positive g (right side up, in most situations). The initialization stage sets the accelerometer range — that is, the max/min values it will read — to +/- 2g. (The device will support +/- 8g according to the specifications.)

There are some cool additional features that I don’t play with, including some interrupts that can be triggered if the device falls suddenly, or if it is “clicked/tapped” or “double-clicked/double-tapped”, which is kinda cool, I guess. If you can come up with a non-gratuitous scenario. Which is probably harder than it sounds. But, even in your gratuitous-I-double-click-my-glass-of-Porto-to-signal-the-waiter-I-need-more-Porto the device will save you the hassle of trying to do this sort of interaction semantics in firmware and get you back to finishing what you were doing in the first place.

Why do I blog this? Notes on the integration of hardware to firmware to ideas. This time with a “new” accelerometer that has some pretty neat features. After this, we’ll be going to paper-pulp and line drawings for a bit folks.

Laboratories, Accelerometers And Kitchen Crockery

The Memsic 6202 Accelerometer, fresh out o’the skillet.

We’ve been out of the Laboratory proper — the place where things are constructed and soldered and heated up — for a bit now, not because we don’t go in there, or we haven’t been doing things that will go in there. No, rather, or because of a variety of curiosities that have attracted our attention and, in that way, have slung us around to be more in the mode of reading and observing so as to launch into the next, “next vector of interests.” We believe strongly here allowing things to stew and simmer in the reading-writing-intellect as much as in the making-things section of the young noggin. There is much good that comes from the process of tinkering as well as, err..think-ering, both simultaneously, perhaps. Doing things to help think through what one finds curious or helpful, tinkering our way to new, more habitable world. Making things is a great way to learn. It is also a great way to think-things-through. Rather than the still idle of pondering, as an adjunct to the quiet sit in the cafe — making something that helps add some weight to the thought. Perhaps closer to The Craftsman by Richard Sennett.

The interests today swing around the ways of framing things, explaining and demonstrating and communicating, especially future fictions, perhaps designed fictions, as a way of describing the sometimes peculiar imaginings that get brought upstairs from the boys in the basement in the Bureau of Coming Attractions. We have our Bureau of Urban Scouting, evolving its own practice of observation and, perhaps of more interest, a variety of instruments and procedures for seeing the world sideways. Nicolas and I are in the final stages of this short essay for the Situated Technologies project that will include this topic. Literally in the final stages. As in, right now I should be editing a Google Doc rather than writing this, but I let the morning coffee lead me.

So, this is all to say that this blog swerves constructively, probably baffling all eighteen readers into wondering — what the heck is going on here? Where is the editorial consistency? Where’s my code/diagrams/schematics?

To this I only ask that you look for such things even here, as they are always in-the-making, becoming the hardware in the midst of the thinking-through, in the ideas.

As the curiosity-seeker Jack Schulze recently intoned in a wonderfully Talmudic way"No one cares about what you think, unless you do what you think. No one cares what you do, unless you think about what you do. No one ever really cares what you say."

This may explain Jack’s characteristically quiet demeanor. We’re quite verbally agitated here, so we’ll let the last one slip by us. But, the yammering is the thinking-making-doing, sometimes in words, sometimes in thoughts, sometimes in the materialization of our imagination.

With this said, in response to Reader Number Fourteen’s request this morning for “some code”, I share with you this little thing: Code to Test the Memsic 6202 Accelerometer. You may remember this little guy. We used it in our early foray into fabricating surface-mount electronics. With kitchen skillets. We learned this bit of tinker-y hacker-y from our friends over at Spark Fun. It works great. And it’s cheap as rocks.

I can’t say we were super excited about this particular accelerometer, but that’s okay. It’s just an accelerometer after all. If you follow us down toward the foxhole of these things, you’ll find a whole world of accelerometer fanatics with plenty of material to fuss with — smart accelerometers, accelerometers that let you know when they’re falling, accelerometers that tell you the time as well as whether they’re falling, etc. You’ll find some material buried here in the blog archives, to be exhumed with the right incantation of search and category selection parameters.

This code was written for the Atmel 8-bit microcontrollers that live on the Arduino board. It also makes use of the Wire library for the Arduino, and, as well, the two-wire interface (TWI) hardware support on those microcontrollers, making the whole thing pretty easy-peasy.

#include
#include


// TWI (I2C) sketch to communicate with the Memsic MXC6202J accelerometer
// Using the Wire library (created by Nicholas Zambetti)
// http://wiring.org.co/reference/libraries/Wire/index.html
//
// On the Arduino board, Analog In 4 is SDA, Analog In 5 is SCL
// These correspond to pin 27 (PC4/ADC4/SDA) and pin 28 (PC5/ADC5/SCL) on the Atmega8
// Know You're Microcontroller. Check Which One Is On Your Board/Arduino.
// Newer (as of May '09) Arduinos Use The Atmega168. Can You See It?
// The Wire class handles the TWI transactions, abstracting the nitty-gritty to make
// prototyping easy.

void setup()
{
  Serial.begin(9600);
  Serial.println("Naah??");
  Wire.begin(); // join i2c bus (address optional for master)
}

void loop()
{

  byte x_val_l, x_val_h, y_val_l, y_val_h;
  int x_val, y_val;
// transmit to device with address 0x1D
// according to the MXC6202xMP datasheet, the TWI/I2C address of is fixed
// at the factory depending on what the "x" in the part name is
// Read The Data Sheet section "I2C Bus Data Transfer" for descriptions
// of what the part expects to receive as its address. If you do not understand
// how this works, you are guaranteed to get lost/confusted/frustrated.
// 00010000b is the address of the chip I have, or 0x10

  // a little fuzzy in my recollection here. I think this initializes the chip
  // by setting some bits in the Memsic device's 8-bit internal register
  // Not 100% sure why I initialize two bytes.
  Wire.beginTransmission(0x10);
  Wire.send(0x00);
  Wire.send(0xF0);
  Wire.endTransmission();

  delay(100);

  Wire.beginTransmission(0x10);
  Wire.send(0x00);
  Wire.endTransmission();

  // request five bytes of data
  // first one is the internal register, we can ignore that, but lets look at it for giggles
  Wire.requestFrom(0x10,5);
  while(Wire.available()) {
    Serial.print(Wire.receive(), HEX); // drop the internal register on the floor..
  }
  Serial.println("****");

  // next byte is the MSB of the X axis acceleration
  if(Wire.available()) {
    x_val_h = Wire.receive();
  }
  // next byte is the LSB of the X axis acceleration
  if(Wire.available()) {
    x_val_l = Wire.receive();
  }
  // next byte is the MSB of the Y axis acceleration
  if(Wire.available()) {
    y_val_h = Wire.receive();
  }
  // next byte is the LSB of the Y axis acceleration
  if(Wire.available()) {
    y_val_l = Wire.receive();
  }
  // cobble all of this together into 16 bit acceleration values
  // doing the usual bit-shift polka
  x_val = (x_val_h << 8); x_val |= x_val_l;
  y_val = (y_val_h << 8); y_val |= y_val_l;
  // spit it all out across the serial port so we can see it
  Serial.print(x_val_h, HEX); Serial.print(" "); Serial.print(x_val_l, HEX); Serial.print("n");
  Serial.print(y_val_h, HEX); Serial.print(" "); Serial.print(y_val_l, HEX); Serial.print("n");
  Serial.println("===");

 Wire.endTransmission();

 // loop and do it again.
  delay(200);
}

Continue reading Laboratories, Accelerometers And Kitchen Crockery