Software Archives - Near Future Laboratory

The Global Village and its Discomforts

Or why designers and data scientists should learn from the anxieties, obsessions, phobias, stress and other mental burdens of the connected humans.

We live in the ‘Global Village’ and our behaviors as connected humans have been evolving since Marshall McLuhan popularized the term in the 60s. Today, we form a society that captures the ‘moment’, refashions it to ‘share’ across a network of endpoints containing algorithms and humans, perpetually. Simultaneously, we live in a society that prizes speed. Amazing technologies are delivering real-time notification of those moments to our wrists, pockets and handbags. Through the virtue of feedback loops, real-time predictive algorithms and collaborative filtering, things are recommended to us for instant actions. That optimized movement of information promise to help us gain now the time that we can then put back in our life.

That evolution came with a price. In the Global Village, it is common to hear a co-worker complain over lunch about ‘social media overload’, to have a friend share their ‘chronic infobesity’ issue with a simple look on their Tweetdeck, to overhear in the metro a person who cannot keep up with their multiple profiles on Tinder or to observe a ‘validation junky’ defying Dunbar’s number and obsessively seeking new forms to obtain ‘likes’ from ‘friends’.

In this essay, I argue that most connected people are subject to anxieties, obsessions, phobias, stress and other mental burdens resulting from living in the Global Village. In an era where some behaviors and habits are measurable, there is an opportunity to learn from the negative effects of technologies that extend our social practices. Particularly, designers and data scientists — besides from being held accountable for many of these discomforts — could get inspirations from the descriptions of these social media related pathologies to improve their design of user experiences and algorithms.

Pathologies of the Global Village

As of 2014, according to the Nielsen US Digital Consumer Report almost half (47%) of smartphone owners visited social networks every day. On top of that, it is not uncommon for a Facebook user to have 1,500 posts waiting in the queue when logging in.

Since the presence of social network is relatively new, the real gains and losses of their use can be found in the mood, behavior, rituals, manners and feelings of connected people. Only recently, the popular media started to consider the psychological effects of ‘social overload’, its impact on mental, social and even physical well-being. We are starting to hear about compulsive behaviors or any other kind of pathologies with acronyms such as FoMO (Fear of Missing Out) or FoBO (Fear of Better Options) provoked by the exposure to social media. That evolution can also easily be traced in recent academic literature. For instance, social psychologist Andrew Przybylski and his colleagues defined FoMO as:

“A pervasive apprehension that others might be having rewarding experiences from which one is absent, FoMO is characterized by the desire to stay continually connected with what others are doing.”

Building on that definition, Michael Hogan proposed a number of categories of FoMO consequences including: Pressure, Paranoia, Separation, Self-identity problems, Dissatisfaction, Loneliness, Negative Self-Image, Personal Inadequacy, Disconnection, Jealousy, and Judgement.

The consequences of FoMO. Source: Facebook and the ‘Fear of Missing Out’ (FoMO)

As a consequence, some people who first embraced constant connectivity are now looking for ways to resist the constant call to be permanently connected. These reactions manifests a need to establish boundaries, resist information overload, and strike a greater emotional balance. Some opt to follow media ‘diets’ or ‘detox’ programs as attempts to move away from being constantly ‘on top of things’ and to give up on fears of missing out or being out of the loop.

Every Technological Extension is Also an Amputation

Social network platforms act as an extension of our social practices. Like with any technological extension we are right to be fascinated by its power and scale. However, we too frequently choose to ignore or minimize the ‘amputations’ and implications they produce. Or as French cultural theorist Paul Virilio would argue:

“The invention of the ship was also the invention of the shipwreck”

For instance, our capacity to record every moment of our lives comes with the high vulnerability of digital data. In fact, no machine can today read a 15 years old hard drive. It is ironic that we have the technological means to record and share our social lives, yet we all might suffer one day from ‘digital amnesia’. Similarly, the capacity to record our lives might reduce our ability to forget inconsequential factoids which is the way for our brains to optimize the recollection of important things. Indeed, our memory uses abstraction and generalization to forget and better remember.

The understanding of these ‘amputations’ represent a source of inspiration and discussion to improve the design and algorithms of social media or any technology that touches humans and extend their social practices.

Gathering Material from Fictional Near Future

With the objective of producing an inventory of ‘amputations’, designer Etienne Ndiaye and myself projected into the near future the current discomforts in using social media. With an approach called Design Fiction, we employed that inventory as a totem for discussion and evaluation of alternative ways to experience social media.

In this exercise we postulated the future increase of cases of ‘validation junkies’ (i.e. individuals who obsessively like, favorite, share and retweet) and ‘input junkie’ (i.e. individuals obsessed with social network feeds). After a vast study on social habits and individual addictions to social media, the US Food and Drug Administration (FDA) and the European Medicines Agency (EMA) decided to set up a large technology initiative that placed limits on design, algorithms and access to social media. For instance, they imposed limits to Facebook photo clicking. In consequence NGOs and the media started to portray pathologies like FoMO as the nicotine of social network platforms forcing the Facebooks, Googles and Amazons to react.

Based on that premise, our Design Fiction took the form of a fictional start-up called 6andMe active in the sector of wellness for connected humans.

That Design Fiction helped us think on how popular media might describe conditions like FoMO in the future. We debated on the tools and behaviors that could prevent or mitigate the discomforts augmented by social media; the mechanisms that 6andMe could use to detect feelings like ‘lone envy’, ‘social exclusion’, ‘missing out’ and ‘being left out’. For instance we listed the indicators that could give signs of unfilled need of ‘belongingness’ and ‘connectedness’ of a person.

Relative Production, Relative Participation, Reciprocal Endorsement, Relative Social Dispersal, etc. The 6andMe diagnosis rely on a battery of basic tests gathered from an individual behavior on social media services to rate concerns for social media related pathologies.

Further into the exploration, we looked at the evolution of language and how some mental conditions might be linked to popular figures. For instance, 6andMe can detect levels of Systrom’s Anxiety. This fictional pathology originates from Instagram’s CEO Kevin Systrom who once said:

“We humans are forever on a quest to take a moment and record it forever in time. Because however long life is, or however short life is, we know we may never get that moment back.”

that we translated into the following symptoms:

Systrom’s Anxiety (SA)

Systrom’s Anxiety is a feel of having to capture and share a moment from the fear of not being able to get to live it again. It happens in situations when one has to decide whether a moment is best enjoyed in the present tense or preserved for posterity online.

We also investigated the emergence of technologies and research that measure social media behaviors. For instance, Michal Kosinsk at Stanford and companies like Apply Magic Sauce API are currently optimizing ways to transform digital footprints into psychological profiles. Our fiction stands 2 or 3 iterations away from that reality. As a result, data scientists at 6andMe use similar algorithms to produce a diagnosis for social media related pathologies. For instance:

The results: 2 weeks after sharing the access to your social media activity, 6andMe sends you by mail a complete diagnosis with levels of concerns on social media related pathologies (e.g. Cloud Syllogomania, Online Tachylalia, Fear of Missing Out, …)

Cloud Syllogomania (CS)

Like many people, you have a tendency to compulsively hoard documents in the cloud such as photos, music, videos, discussions, emails, or any other data formats. However, when reaching storage limit you fail to organize and discard large numbers data even to the point of causing significant clutter and impairment to basic operation of a software, computer or mobile device. This hoarding behavior is often unwanted, automated by online services and can become distressing.

Online Tachylalia (OT)

You have a tendency to share social content fast, frenetically and very frequently, so frequently that it becomes impossible for your relatives, friends, colleagues and contacts to follow you online. It may be exhibited as frequent streams of rapid posting without prosody leading to online social rejection and disdain.

Profile Schizophrenia (PS)

You suffer from a personality disorder that emerges when losing control of multiple accounts and profiles on social networks. Profile Schizophrenia (PS) becomes latent when you start to notice gaps and inconsistencies between the information that you share online. For instance you might develop different personalities from your life biography on LinkedIn and what you share on Facebook, your World of Warcraft characters and your Twitch videos.

Online Monophobia (OM)

You feel alone in online social networks. You might have relatively too few online contacts and receive low amounts of contact requests, likes, comments, reblogs or retweets. Many people with this fear feel awkward and uncomfortable on social networks. It is related to Online Athazagoraphobia that is fear of forgetting or being forgotten on social networks.

Overshadower Syndrome (OS)

In this form of a judgment disorder your mind blurs the social etiquette of knowing too much about somebody else from the information available on the Web. That behavior often leads to uncomfortable social and cultural situations when too much knowledge on a person is gathered from the extensive use of search engines and social networks.

Storage Claustrophobia (SC)

In moments of bandwidth restrictions, abusive data plans, or limited cloud space you notice an extreme fear and feeling of being confined to the limits of a specific data plan or storage system.

Six Degrees Jealousy (SDJ)

You feel or show envy of an online contact for receiving more attention in the form of “likes”, “comments”, number of contacts or the klout score. Inspired by network theories on six degrees of separation, Six Degrees Jealousy is often a reaction of teenagers to a strong social pressure and fear of not belonging to a community or tribe leading to Online Monophobia (OM).

Find more informal descriptions on 6andMe of: Timeline Myopia (TM), Impulsive Posting Disorder (IPD), Social Media Dependence (SMD), Social Media Overwhelm (SoMO), Sense and Attention Overload (S&AO), Abrupt Online Dropout (AOD), Pocket Check Obsession (PCO), Screen Addiction (SA), Compulsive Screen Absorption (CSA), Stressful Attention Battles (SAB), Online Attention Disorder (OAD), Tagophobia, Compulsive Data Cleaning Disorder (CDCD), Data Loss Meltdown (DLM), Digital Amnesia (DA), Online Athazagoraphobia (OA), Visiobibliophobia, Social Escapism (SE), Online Perseveration (OP), Avataragnosia, etc.

Our Design Fiction and the description of these fictional pathologies do not claim to be medical but are provocations on how connected humans might express their anxieties, obsessions, phobias, stress and other mental burdens in the future.

Takeaways for the present

While working on wonderful technological extensions of human body and mind, designers and data scientists need also to consider the amputations provoked by the experiences and algorithms they introduce into the Global Village. In the the book The Shallows, Nicholas Carr worries that the flood of digital information is changing not only our habits, but even our mental capacities:

Forced to scan and skim to keep up, we are losing our abilities to pay sustained attention, reflect deeply, or remember what we’ve learned.

The inventory of social media related pathologies listed in 6andMe highlights these types of technological implications. The descriptions of FoMO, Systrom’s Anxiety, Six Degrees Jealousy, etc. provide a new source of inspiration and discussion to improve the design and algorithms of any technology that touches humans and extends their social relations.

To build better data products and services, I would argue that most designers and data scientists should be aware of notions such as graphopticon introduced by the like economy and question if the technology they build establish an insatiable ‘desire for more’ or any other type of discomfort. Moreover, they should get inspirations from the techniques social media user develop to strike a greater emotional balance.

Many companies have the data and skills to consider the wanted, unwanted and toxic changes in behaviors their services or products create and amplify. For instance, Facebook introduced the roles of social engineers and a group of trust engineers to make the online world a ‘kinder, gentler place’. In their first approximations they introduced mechanisms for their users to tune the feeling of status update overload.

Currently, only a few apps and platforms promote social media experiences that mitigate the types of discomforts listed in 6andMe. Meshfire is a recent attempt to ‘make social media human again’ or as its CEO puts it in abstract terms:

“If we were to start again with social media — a completely clean slate — we’d like to see real human interaction rather than all the automatic output we witness today.”

Screenshots of Little Voices by Charles Gower

Another example is the app Little Voices that removes the Tweets that contain images, links and replies from Twitter feeds. As its developer Charles Gower describes it:

“Little Voices is complementary to Twitter, not a replacement. It’s ideal for those who like their feeds slightly quieter.”

Finally, at Near Future Laboratory we have been building Humans as a platform to ‘experience social media at human pace’. Humans offers a way to rationally manage too many contacts and slows down the consumption of status updates, tweets, selfies, photos of all kinds. Its aim is to:

Reduce the compulsion to perpetually check for status updates.
Keep away from the distractions in social media feeds.
Mitigate feelings and symptoms of remorse whilst taking short or long offline breaks.

The Atlas of Desire

Or: privatesquare, ten months later

It would be generous to say that privatesquare was ever released. Instead, the source code was made public with a long and twisty blog post and a flurry of screenshots. I’ve told a few people about my installation of privatesquare but since I haven’t had the stamina to run a service for strangers (and a free one, at that) it’s remained small and reserved for friends and family. A few people along the way have set up their own instances and that’s been both gratifying and enormously useful in working out some of the kinks.

Maybe there are lots of copies of privatesquare running in the wild. I have no idea and no way of knowing. This is not a bad thing. In the meantime, I’ve continued to chip away at the project adding small features and fixing bugs as they come up.

Recently, we moved from San Francisco to New York City. Maybe foursquare, itself, woulda-coulda-shoulda started in another city but once you start to live the day-to-day ritual in New York it becomes pretty clear why it started here. The Atlas of Desire feature, described below, probably would have languished in a pit of good intentions if we hadn’t moved here but I’ll come back to that in a bit.

When it was first announced, last November, privatesquare came with a long list of tricks it hadn’t learned so it’s probably long overdue for a status update.

New old things

Here’s an unordered list of the things privatesquare said it didn’t do went I pushed it out of the nest:

History pages

There are now history pages for venues and dates (and date ranges) as well as for cities. Details on that below.
Sync with the foursquare API…

This is now possible, although it’s not enabled by default.

Specifically, there is a little script that can be run by hand to import any foursquare check-ins that may have happened outside of privatesquare. This includes the history of check-ins that predate someone starting to use privatesquare. Or not. That’s why the feature needs to be explicitly enabled by each user choosing from one of three options:
- Do not sync foursquare check-ins – Which is what it says on the tin. What you do elsewhere is entirely your business and privatesquare doesn’t need to know about it.
- Only sync recent foursquare check-ins – Tell privatesquare to archive missing check-ins but only those that have happened since you signed up (with privatesquare).
- Sync all foursquare check-ins past and future – This tells privatesquare to archive your entire foursquare history. This is what I’d expect most users to choose but it just always ends better when you let people make that decision for themselves.
The nearest linear cell-tower problem…

Sort of. Not really, though.

The nearest linear cell-tower problem is caused by the fact that when a person is using privatesquare from their phone they are connected to the Internet through a cellular rather than a wireless network. Since the nearest cell-tower is used as a proxy for your location and since cell-towers have a range that is sometimes greater than the radius used to query nearby venues the list of places that gets returned is sometimes weird and full of bunk.

One issue is that the W3C geolocation API, used by web browsers to determine your location, doesn’t tell you how your location was acquired. Was it from a wireless network? A cell-tower? A passing drone, overhead? There’s no way to know and by extension no way to adjust expectations.

The nearest linear cell-tower problem is ultimately a user-interface problem and not one that’s ever been tackled particularly well. In more recent versions of privatesquare there is sometimes a little grey dot (rather than blue) that’s meant to indicate where the code thinks you are and help provide some context for the other dots.

Another option is to allow you to grow the search radius for each query but I haven’t done that yet. File under: Something, however inadequate, instead of nothing.
There is no ability to delete (or undo) check-ins…

Done.

Except for the part where there’s no way to delete check-ins using foursquare API which is … puzzling, to say the least. So in those instances where you’ve checked in to both privatesquare and foursquare and then delete check-in using privatesquare you’ll be presented with a short (exasperated) note explaining the situation and a link to the foursquare site where you can finish things up.

I know, right?
There is no ability to add new venues….

Nope. Still not possible. Chances of it happening remain close to zero.
Nor is there any way to record events offline…

Sort of. Kind of. But only one particular facet of the problem is handled well.

I first started thinking about this at SXSW this year because the combination of both the cellular network and foursquare being simultaneously overloaded with eager users meant that privatesquare was often unusable in downtown Austin.

There are two problems that need to be sorted here:
- The first is some way to store a check-in for future use when foursquare API is sad.
- The second is some way to store a check-in for future use when the network itself is sad.
The first problem is now accounted for with pending check-ins, something I’ll discuss more in a bit. The second problem isn’t really accounted for at all and at some point I just need to sit down and look carefully at what the Lanyrd kids did for their mobile site and probably just copy that.
There is no way to distinguish duplicate venues (same name, different ID)…

Nope. Still punting on that.
Pages for venues…

Totally!

Every venue you’ve checked in to now has its own page on privatesquare. Each venue page has a list of the dates you’ve checked in there (including links to the actual check-in page), a link to other places you’ve checked in to nearby and a handy I am here now button for … well, check-ing in again.

Designing for thumbs, and all that.
Pages for cities…

Yes!

All check-ins in privatesquare are reverse-geocoded using the Flickr API which returns a list of Where on Earth (WOE) ID associated with a venue. At the moment only cities are recorded so you can’t filter check-ins by neighbourhood or country. Technically, there’s nothing to prevent it from being possible but cities seemed like a good and easy place to start.

The places pages are kind of great and they are especially striking when you see them on a screen that is bigger than your phone. And because it uses the Flickr API it means that airports are bucketed as cities which makes even more sense in a foursquare context.

Neighbourhoods are also a near-certainty given that no one’s geo infrastructure can figure out how to make peace with the meta-neighbourcities, called boroughs, that form the NYC metropolitan area and I actually have to suffer the consequences now that I live here. See also: the Atlas of Desire, below.
Export…

Yes!

There are handy links at the bottom of most pages to export your check-ins as either a CSV or a GeoJSON file.

Exports are available for the following buckets: check-ins by date or date range; check-ins for a venue; check-ins for a place. Exports should be available but aren’t yet for for: check-ins by nearby-iness; check-ins by desire (more below).

It has also been the case that if you’re running privatesquare in a controlled environment (like a shared web-hosting service) that enforces its own usage limits exporting check-ins for a user with billions und billions und billions of check-ins can be problematic. I don’t have a ready-made solution for this problem, yet.

New new things

At the same time all of that was being done, there were a bunch of smaller things happening. In no particular order they are:

Documentation!

Gary Gale has done an amazing job of peeling away, with fresh eyes, the stack behind privatesquare and Flamework and keeping detailed notes about what everything means and how to get privatesquare up and running with a minimum of fuss in a variety of environments.

Gary is also one of those people who checks in every time he exhales so he’s been excellent at finding the crumbly edge of things in privatesquare.
Weather tracking

privatesquare tries to record the weather (based a venue’s latitude and longitude) whenever you check in. Not much is done with that data except to show in the list of check-ins for a venue. The data is stored alongside the check-in so there’s always to opportunity to do something clever and interesting with in the future and in the meantime it makes for a nice soundtrack when scrolling backwards through the history of a place.
Time of day tracking

Sort of.

Vladimir Agafonkin wrote a lovely little Javascript library to calculate the time pie for a given timestamp and Tom Carden was good enough to create a handy HTTP pony wrapper for it on Heroku that can be poked when a user checks in.

All your check-ins that happened during the golden hour and that sort of thing.

Unfortunately, with all the other network requests going out to third parties (foursquare, weather services and so on) the API call to get a time pie is often the one that fails or is killed because it happens so late in the chain of events. For the time being it is not a feature that is enabled by default. There’s a branch of privatesquare with the start of a pure PHP port of the code but it is both incomplete and full of bugs.

If you’re not familiar with the idea of time pies, you should definitely read this blog post about them from the Stamen kids.
Deferred check-ins

Occasionally the foursquare API is sad. Sometimes it happens when you’re trying to use privatesquare. In the past you were sorry-out-of-luck but now when that first API call to fetch nearby venues fails privatesquare will give you the option of writing down the name of the venue you were trying to check in to and stick it, along with a timestamp, in your browser’s local (storage) cache.

Once that happens a link titled pending will magically appears in the navigation menu and from there you can go back in time (sort of) and finish check-ing in.

Essentially all that’s happening is the usual check-in process being replayed but with a canned search term and a note to privatesquare to use a an equally canned check-in time instead of of right now.

For a bunch of perfectly good reasons you can’t do the same in foursquare so any pending, or deferred, check-ins are not forwarded along to the mothership. I may change that in the future and handle the spacetime disconnect by simply adding a note to the foursquare check-in. We’ll see.

This is basically what should happen when the network itself is down or unavailable. Cities like New York are strange beasts that way. It’s hard to keep the scale of the infrastructure, and the burden of its history, in mind some days. Aside from the fact there are whole pockets of the city with terrible network (read: cellular) connectivity there are others that completely silent, to this day.

Subways are an obvious place to want to check-in and privatesquare shouldn’t let itself be defeated by the dark spaces underground so teaching the code to play nicely as an offline application is rapidly bubbling up the totem pole.

I’m told that if you have one of the fancy auto-refilling monthly New York City subway passes it’s possible to retrieve a history of all the stations where it’s been swiped so that bodes well for some sexy Clipper Futures style integration with privatesquare in the not too distant future.
The Atlas of Desire

Let’s be honest. On its current trajectory privatesquare will, sooner or later, become Dopplr. I don’t know what that says about foursquare and since the thing I built is, by design, not social I couldn’t exactly call the Chris Heathcote buckets described in the first blog post a Social Atlas. So, I called it what it is: an Atlas of Desire. Or, in concrete terms:
- Web pages and list view for all the places you’ve checked-in to rolled up by the status you assigned: I am here; I want to go there; again again; and so on.
- The ability to change a status after you’ve checked-in. For example, you could check-in to a restaurant when you sit down to eat and then change to again maybe when you leave.
I’ve also added a new status simply called meh which, to my mind, is somewhere between again maybe and again never but ultimately the semantics are left up to individual users.

If you asked me I’d tell you it’s for those places that you would visit for purely mechanical reasons: No matter how lackluster the food is it remains less bad than the bad craziness and temper tantrums caused when you melt down out of hunger.

Shelley Bernstein, from the Brooklyn Museum, deserves a proper shout-out for the Idea of Meh which was part of her work making public the museum’s collection metadata.

In addition to filtering your check-ins by status, you can further prune those places by nearby-iness or by city. It’s become pretty obvious that you should also be able to scope your desire to a neighbourhood. (See above inre: neighbourhoods.) It’s not a hard feature to add but it is a lot of typing so it will happen sometime between this blog post and re-wiring everything to work offline.

Still broken things:

Things that should never have been broken in the first place and that maybe I should fix before I say anything else, but oh well…

OMGWTFTZ… timezones

There are no excuses for this. It’s a thing that conveniently Just Works ® on the West Coast (because that’s the default timezone in the source code) and a thing complicated enough, under the surface, that I’d like to spend a little bit of time thinking about it before I go charging in to fix things.

Probably the best thing would be to check for the timezone in the foursquare API response when you check-in and store that information locally. Failing timezone information in the API response I might build a simple httpony service on top of the whereonearth-timezeone dataset to do reverse geocoding for timezones.

Sorry.

Things still TO DO

Mike Migurski has requested that privatesquare grow an I’m on my way status flag which is tempting but we’ll have to see about that one. Meanwhile, in no particular order these are some of the outstanding known-knowns:

Make the tasteful pale grey permalink button and link for individual check-ins less invisible

Yes, there are tasteful pale grey permalink buttons and links and for every check-in.
Build scripts for “cloud app” hosting

Gary’s documentation for setting up privatesquare is great and makes the whole process less painful but enough technical hoop-jumping remains to make it all inaccessible to a lot of people. Meanwhile, there are a whole raft of hosted services, like Heroku or PHPFog, that allow you to one-button install web applications which seem like they would be a good fit for things like privatesquare.

Unfortunately the way the privatesquare is bundled (read: the ways the files and folders are organized) doesn’t lend it to one-button anything with many of these services. privatesquare (and similar tools I’ve been tinkering with at the same time) has never had versioned releases but it might be time be time to start freeze-drying the code at particular moments and creating discrete bundles targeted at specific environments.

Those releases would always lag a little behind the new and shiny but the up-side is that it would be easier to install, which is probably a trade-off some people would make.
Sharing. Maybe? Probably not…

privatesquare is so-called for a reason. Every now and then I think about changing the default check-in status from don’t tell foursquare to don’t tell anyone which would, once you pulled in a user’s contact list, allow for sharing of things on privatesquare.

I am still unconvinced about this one as it adds another layer of complexity and it’s not clear why it’s useful (foursquare is pretty good at that side of things) outside of the Atlas of Desire for which plain vanilla exports are probably more important. To whit:
Better integration and/or pillaging of the Dotspotting codebase

A couple months ago I forked the source code for Dotspotting and started to add the ability to edit individual dots. That’s really as far as I got and I’m not entirely sure where it all fits with privatesquare but the shadows of the two projects seem to overlap more often than not.

Something something something see above something about exports something something something maps something something something.
A proper API

privatesquare already uses its own API but punts entirely on delegated authentication and still uses cookies for authentication and authorization. This is not ideal or, rather, is not a reason to lack an API that third-parties could build on.

This is just another one of those tasks that requires some time where I sit down and spend the time to finish all the typing necessary to make it happen. Unfortunately, it is a thing made more complicated by the fact that having to read any of the OAuth specs makes me a little crazy in the head. It will happen.
Notes

Maybe. I’m of two minds which is to say I’m not inclined to add notes because I like the simplicity of the site, now, but could be convinced. For a while I had a version of privatesquare that would let you add notes to Findery (née Pinwheel) from venue, or check-in, pages and relied on the magic of machine tags (on their side) to stitch everything back together. I liked that and when there is a public API for the site (in the past I was… well, yeah, anyway…) I will probably slip it back in as an optional feature.
Artisanal Integers!

No, really.

Privatesquare is at least half the reason that artisanal integers exist at all so it’s only fitting that is should start using them. Dan Catt’s blog post about London Integers is good place to start if you’re sitting there oscillating between confusion and table-pounding muttering the words artisanal… integers…

Really.

One of the nicest things anyone has said to me about privatesquare since I started building it was: Oh, I’d love to use it but I can’t because I have an Android phone. The nice part is: you can! privatesquare is nothing more than a what-do-you-call-it web application.

The whole native versus web application debate on mobile is interesting, but only insofar as there are still a few tricks that web browsers can’t do or that they are prevented from doing by the operating system itself. Beyond that it all smells too much like the insane and self-serving hair-splitting that people, in the 90s and early 2000s, made about WAP and other uniquely mobile technologies. Read: Small computers, in your pocket.

privatesquare is meant to play equally well with your desktop as it is your phone. As time permits and I can work through what a print-specific CSS file looks like it should also work on that crazy retrograde technology that refuses to die: paper. The extent to which privatesquare fails, in any of those arenas, is more a reflection of (my) poor design skills than it is proof that somebody’s preferred form factor wins at celebrity death match.

And on and on, it goes!

LIS302DL. A 3 Axis Accelerometer

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..

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);
}

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.

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.

GPX to DXF – Drawing GPS Tracks

Lines and arrows and splines point the way. Taken in a parking lot near the beaches at Santa Monica.

It has not been a quiet couple of days here in the Laboratory. Lots of gear and glassware about. Goggles, bunsen burners and all that sort of thing. And the report draft was just finished with Nicolas Nova, which occupied many early mornings. We almost spilled an organic, but toxic material on the draft which cause a collective gasp, but it was pulled out of the way, just in time before irrevocable damage was done. We’re writing with ink and pen these days, which feels so much more angelic and respectful, but are, through incidents like this, reminded that such may have nostalgic integrity, but it is also quite delicate and precious.

In the midst of all that was the need to translate a GPS track from GPX format to DXF. This was harder than I thought it would be, at least after poking around the Google. There are some tools that’ll do format conversions and so forth, but they were way more expensive than I thought was reasonable, seeing as we’re not making precious objects. It’s basically a translation of one connected graph format to another.

Okay, so — it was time to think about making our own tools, which took 10 times less time than the original set of Google searches, mostly because of the recently discovered ancient treasure of a Java library our buddy Tom Carden wrote back in the Precambian of the Age of the Network — somewhere’s around 1996 or some such…

This library provides enough functionality to read a GPX track and draw it on screen. The Processing.org DXF library can spit that drawing from the screen out as a saved DXF. So, that basically solves the problem. The DXF files that come out are flat lines that can then be serviced by other software to do other things. (There also exists this Kabeja library for consuming DXF and creating DOM models, which we’ll save for another day.

My lead toward the Carden code was found here on the Processing.org forums, where I found enough of a simple code snippet to get me out and through the chiseled hole in the brick wall I had hit.

Also to note is the small comment in the small simple bit of code that can cobble together many separate GPX files (tracks from a GPS) into one larger one, which can be quite convenient.

Why do I blog this? Mostly for my own recollection and notes as to how things are done. It’s been enough time in the jungle of small, utility challenges that, when on another project inevitably in the future, some small task I need to perform smells familiar — but, why? One gets the feeling — I’ve had to do this before? What project was it? How did I do it? Playing in the geo/map-making/cartography space has all these little formats and translation steps that are a bit zany to wrangle. Jotting a post with a bit of a reminder helps. Te bigger “why do I blog this?” has to do with using real-world GPS tracks as a basis for constructing other things — the input is movement in the world, an effort to figure out how a map might look that inverted the assumptions about static geographies and fluid movement, so that the ground moved and the things that moved became static. *shrug*


import processing.dxf.*;

// Based on Tom Carden's code and GPX library available at
// http://www.processing.org/hacks/hacks:gpx
// Press "R" and your track gets saved as a DXF file which
// you can use in lots of other things..

import tomc.gpx.*;

GPX gpx;

GPXTrack track;
GPXTrackSeg trackSeg;
String trackName;

double minLat, maxLat;
double minLon, maxLon;
double minEle, maxEle;
boolean record = false;

final static int SEPARATOR = 200;
String filename, filepath;

// I collapse lots of individual GPX files into one larger file
// using the free gpsbabel.
// At the command prompt (the GUI editions don't have enough features
// to do this) you'll do something like this:

/************

/Applications/GPSBabel+-1.3.5/gpsbabel -i gpx -f 20090321.gpx 
-f 20090401.gpx -f 20090402.gpx -f 20090403.gpx 
  -x transform,wpt=trk,del 
  -x radius,distance=5,lat=34.0236,lon=-118.4319,nosort 
  -x transform,trk=wpt,del  
  -o gpx -F foo.gpx

The "-x" filters do a couple of things.
The first -x filter turns the tracks into waypoints to work around
an issue that gpsbabel has with the "radius" filter
The second -x filters the output only to points that are within a
5 mile radius of the specified lat/lon, which is useful if you want
to limit the range of data you draw.
The final -x filter turns the waypoints back into tracks, which is what we want
Finally, we output as GPX formatted data and
write the whole thing to the file called foo.gpx.dxf


*************/

void setup()
{
  // Yep, hardcoded path to the GPX file we'll process
  filepath = "/Users/julian/Desktop/GPS Tracks/foo.gpx";
  // We'll use the name of the file for our DXF output, with the ".dxf" extension added
  filename = (new File(filepath)).getName();
  size(800, 800, P2D);
  gpx = new GPX(this);

  // you can load a file or a URL evidently..
  gpx.parse(filepath);

  // Find scope of track file so we can scale our drawing
  minLat = 2000; minLon = 2000; minEle = 100000;
  maxLon = -1000; maxLat = -1000;

  println("track count "+gpx.getTrackCount());
  for(int j=0; j < gpx.getTrackCount(); j++) {
  track = gpx.getTrack(j);
  println("track size "+track.size());
  for(int k=0; k<track.size(); k++) {
     trackSeg = track.getTrackSeg(k);
     println("track seg size "+trackSeg.size());
  for (int i = 0; i < trackSeg.size(); i++)
  {

    GPXPoint pt = trackSeg.getPoint(i);
    if (pt.lat < minLat)
    {
      minLat = pt.lat;
    }
    if (pt.lon < minLon)
    {
      minLon = pt.lon;
    }
    if (pt.ele  maxLat)
    {
      maxLat = pt.lat;
    }
    if (pt.lon > maxLon)
    {
      maxLon = pt.lon;
    }
    if (pt.ele > maxEle)
    {
      maxEle = pt.ele;
    }
  }
  }
  }
println("Lat: " + minLat + " to " + maxLat);
println("Lon: " + minLon + " to " + maxLon);
println("Ele: " + minEle + " to " + maxEle);
}

boolean hasDrawn = false;

void draw()
{
  if(record == true) {
    beginRaw(DXF, filename+".dxf");
    hasDrawn = false;
  }
  if(hasDrawn == false) {
  background(255);
  //stroke(#FF0000);
  //line(0, SEPARATOR, width, SEPARATOR);

  double distance = 0;

 for(int j=0; j < gpx.getTrackCount(); j++) {
  track = gpx.getTrack(j);
  //println("track size "+track.size());
  for(int k=0; k<track.size(); k++) {
     trackSeg = track.getTrackSeg(k);
     //println("track seg size "+trackSeg.size());
       GPXPoint prevPt = trackSeg.getPoint(0);
      PVector prevPos = GetPosition(prevPt);
      for (int i = 1; i < trackSeg.size(); i++)
      {
       GPXPoint pt = trackSeg.getPoint(i);

    // Show track
    PVector pos = GetPosition(pt);
    stroke(#FF8800);
    line(prevPos.x, prevPos.y, pos.x, pos.y);
    prevPos = pos;
  }
  }
 }
  }
  if(record == true) {
    endRaw();
    record = false; // stop recording to the file
    println("done writing "+filename+".dxf");
  }
  hasDrawn = true;
}

void keyPressed() {
  if (key == 'R' || key == 'r') {
    record = true;
  }
}

PVector GetElevation(int n, GPXPoint pt)
{
  return new PVector(
      map(n, 0, trackSeg.size(), 10, width - 10),
      map((float) pt.ele, (float) minEle, (float) maxEle, SEPARATOR - 10, 10)
  );
}

PVector GetPosition(GPXPoint pt)
{
  return new PVector(
      map((float) pt.lon, (float) minLon, (float) maxLon, 10, width - 10),
      map((float) pt.lat, (float) minLat, (float) maxLat, SEPARATOR + 10, height - 10)
  );
}

Dog Eared "Distraction"

Turn Over LA "River" Thursday March 12, 21:39:03

Running the blog-the-dog-eared-pages algorithm on Bruce Sterling‘s fantastic “Distraction“, I’ve selected these gems. They’re all intriguing speculations about a near future world to be, complete with some insights and implications that trace the now to the then if you think about how such moments, conversations, objects and designed artifacts could come to be in the year 2050. Particularly at this agitated moment amongst the the various and multiple worlds’ and their financial-political-socio-technocultures.

Oscar took the opportunity to learn how to use a Moderator laptop. He had been given one, and he rightly recognized this gesture as a high tribal honor. The Moderator device had a flexible green shell of plasticized straw. It weighed about as much as a bag of popcorn. And its keyboard, instead of the time-honored QWERTYUIOP, boasted a sleek, sensible, and deeply sinister DHIATENSOR.

Oscar had been assured many times that the venerable QWERTYUIOP keyboard design would never, ever be replaced. Supposedly, this was due to a phenomenon called “technological lock-in.” QWERTYUIOP was a horribly bad design for a keyboard — in fact QWERTYUIOP was deliberately designed to hamper typists — but the effort required to learn it was so crushing that people would never sacrifice it. It was like English spelling, or American standard measurements, or the ludicrous design of toilets; it was very bad, but it was a social fact of nature. QWERTYUIOP’s universality made it impossible for alternatives to arise and spread.

This is a good one. I’ve been fascinated with the ways a particular configuration or design like this — the keyboard layout — becomes a kind of expressive social object. There are all of these deep histories it seems, depending on who you believe, about all standards which are always social-political-historical compromises that lock-in specific meanings. Sometimes you hear that QWERTY was a way to slow typists down so that the mechanical aspects of pre-digital keyboards would not jam the machines in early typesetting and so forth, as Sterling describes in this passage. I’ve also heard that QWERTY was a way to help early typewriter salespeople sell the typewriter because they could easily type out the word “typewriter” only using the top row of letter keys and impress early would-be purchasers. (QWERTYUIOP gives you each letter of “typewriter”, which is something many people to recognize.) In this passage, Sterling is reminding us of this first point — that things set in place, like someone etching their name in drying concrete and, even if flawed, these become “social facts of nature” leaving the inscriptions of all the considerations that will always flow forth from those early debates and conventions and compromises, which become especially resonant when the “lock-in” is for something that spreads widely becoming a universality. p.382

We love those Regulators like brothers and sisters. We got nothing in common with you. Except that…well, we’re Moderators because we use a Moderator network. And the Regulators use a Regulator interface, with Regulator software and Regulator protocols. I don’t think that a newbie creep like you understands just how political a problem that is.

Protocols, interfaces, software, networks yielding to differentiation at the level of social and political factions is a very curious extrapolation. At the same time, it is a kind of embodiment of the politics of protocols as well-expressed in Alexander Galloway’s fascinating two network books Protocol: How Control Exists after Decentralization and
The Exploit: A Theory of Networks (also with Eugene Thacker).

Without the high-flying theory and Deleuzian barnstorming, Sterling captures the reasonable future world in which the world wide network has fractured in this way between Moderators and Regulators for some reason having to do with social and political differences between these two groups. A near future such as this seems reasonable, international standards bodies notwithstanding. Receding back into the recent past of incompatible networks would be an outcome of the collapsed world Sterling depicts in Distraction, where global networks may be seen as creating exploitable linkages between teetering giant centers. For instance, the interconnectedness of financial institutions that allowed them to become too tightly connected in strategic terms — able to trade amongst each other too easily so that the game of hot potato that led us to today’s crisis finally caught everyone with bad potatos in the end — could be something that is regulated and controlled. In other words, if an outcome is that institutions must insulate themselves in some fashion, or they become categorized as to who they can do business with, a result could be different kinds of network protocols optimized for that specific business. Regulated banks use the Regulator network; Moderate banks use the Moderator network. p.335

But this was not the strange part. The strange part was that brand-new nomad manufacturers were vigorously infiltrating this jungle of ancient junk. They were creating new, functional objects that were not commercial detritus — they were sinister mimics of commercial detritus, created through new, noncommercial methods. Where there had once been expensive, glossy petrochemicals, there was now chopped straw and paper. Where there had once been employees, there were jobless fanatics with cheap equipment, complex networks, and all the time in the world. Devices once expensive and now commercially worthless were being slowly and creepily replaced by near-identical devices that were similarly noncommercial, and yet brand-new.

When “DIY” attains to its logical zenith, fake becomes the new real. I actually can’t wait for this to happen. The pinnacle of knowledge circulation in the networked age. How-to, tutorials, maker culture, sharing of knowledge (or maybe just descriptions and step-by-step procedures) all coming together so that people make their own stuff, from new materials that do not have to be tuned for epic scale levels of manufacturing. You need something, make one or two rather than having 100,000 of them made offshore someplace and shipped at great expense and with enormous carbon footprint. Natural experimentation with alternative materials, features, etc. p.329

Kevin bought four sets of earclips from a blanket vendor. “Here, put these on.”

“Why?” Greta said.

“Trust me, I know my way around a place like this.”

Oscar pinched the clamp onto his left ear. The device emitted a little wordless burbling hum, the sound a contented three-year-old might make. As long as he moved with the crowd, the little murmur simply sat there at his ear, an oddly reassuring presence, like a child’s make-believe friend. However, if he interfered with the crowd flow — if he somehow failed to take a cue — the earcuff grew querulous. Stand in the way long enough, and it would bawl.

Somewhere a system was mapping out the flow of people, and controlling them with these gentle hints. After a few moments Oscar simply forgot about the little murmurs; he was still aware of them, but not consciously. The nonverbal nagging was so childishly insistent that accomodating it became second nature. Soon the four of them were moving to avoid the crowds, well before any approaching crowds could actually appear. Everyone was wearing the earcuffs, so computation was arranging human beings like a breeze blowing butterflies.

The fairground was densely packed with people, but the crowd was unnaturally fluid. All the snack-food stands had short, brisk lines. The toilets were never crowded. Children never got lost.

Just a fascinating extrapolation into the near future of a number of ideas, such as a kind of flash mob concept, where a crowd is optimized to itself, allowing for smooth flows and transfers — a meta surveillance and control system that does not have the nasty baggage that such things normally. Ground traffic control system that helps you get from “A” to “B” in an optimal way, whatever “A” or “B” might be. This is a concept expressed here that is quite intriguing to me, such as strategies for exploring especially urban space, like the analog Near Future Laboratory project, “Drift Deck” and other psychogeography and cartography explorations. p.326-327

There was a long uneasy silence. Then Griego burtst out in a fury. “Don’t get all high-and-mighty with me, Mr. Third-in-His-Class. You think it’s easy running corporate R&D? It was just fine, as long as the guy didn’t have anything. Jesus, nobody ever thought a goddamn sugar engine would work. The goddamn thing is a giant germ in a box! We build cars up here, we don’t build giant germs! Then they pull this crazy stunt and..well, it just makes our life impossible! We’re a classic, metal-bending industry! We have interlocking directorates all throughout the structure, raw materials, fuel, spare parts, the dealerships…We can’t get into the face of our fuel suppliers telling them that we’re replacing them with sugar water! We own our fuel suppliers! It’d be like sawing off our own foot!”

“I understand about interlocking directorates and mutual stock ownership, Ron. I was sitting right next to you in business school, remember? Cut to the chase — what about the battery?”

“Batteries have the highest profit margin of any automobile component. We were making money there. You can’t make real money anywhere else in our business. The Koreans are building auto bodies out of straw and paper! We can’t support an industry when cars are cheaper than grocery carts! What are we gonna tell our unions? This is a great American tradition at stake here! The car defines America: the assembly line, suburbs, drive-ins, hot rods, teenage sex, everything that makes America great! We can’t turn ourselves inside out because some big-brained creep has bult an engine out of bug guts! There wouldn’t be anything left of us! The guy is a menace to society! He had to be stopped.”

“Thank you for that, Ron. Now we’re getting somewhere. So tell me this — why didn’t you just pull his damn funding?”

“If only it were that simple! We’re required by federal fiat to invest in basic R&D. It was part of our federal bailout deal. We’re supposed to have trade protection, and we’re supposed to catch our breath, and jump a generation ahead of our foreign competitors. But if we jump a generation of the damn Koreans, our industry will vanish entirely. People will make cars the way they make pop-up toast. Proles will build cars out of bio-scrap, and compost them in the backyard. We’ll all be doomed.”

So you’re telling me that you’ve achieved a tremendous scientific R&D success, but as a collateral effect, it will eliminate your industry.”

“Yeah. That’s it. Exactly. And I’m sorry, but we just can’t face that. We have stockholders to worry about, we have a labor force. We don’t want to end up like the computer people did. Jesus, there’s no sense to that. It’s total madness, it’s demented. We’d be cutting our own throats.”

Well, this is very much like the collapse of the automotive industry in the US, clearly. I also like this dig at corporate R&D. This idea that things discovered that could turn into something that is to the larger good would be hidden away if it would overturn the existing order. R&D in this way is ultimately conservative. I’m not sure I believe in R&D, for these reasons and others, but that’s a longer post. p.295-297

“But the economy’s out-of-control. Money just doesn’t need human beings anymore. Most of us only get in the way.”

“Well, money isn’t everything, but just try living without it.”

Kevin shrugged. “People lived before money was invented. Money’s not a law of nature. Money’s a medium. You can live without money, if you replace it with the right kind of computation. The proles know that. They’ve tried a million weird stunts to get by, roadblocks, shakedowns, smuggling, scrap metal, road shows…Heaven knows they never had much to work with. But the proles are almost there now. You know how reputation servers work, right?”

“Of course I know about them, but I also know they dont really work.”

“I used to live off reputation servers. Let’s say you’re in the Regulators — they’re a mob that’s very big around here. You show up at a Regulator camp with a trust rep in the high nineties, people will make it their business to look after you. Because they know for a fact that you’re a good guy to have around. You’re polite, you dont rob stuff, they can trust you with their kids, their cars, whatever they got. You’re a certifiable good neighbor. You always pitch in. You always do people favors. You never sell out the gang. It’s a network gift economy.”

“It’s gangster socialism. It’s a nutty scheme, it’s unrealistic. And its fragile. You can always bribe people to boost your ratings, and then money breaks into your little pie-in-the-sky setup. Then you’re right back where you started.
“It can work all right. The problems is that the organized-crime feds are on to the proles, so they netwar their systems and deliberately break them down. They prefer the proles chaotic, because they’re a threat to the status quo. Living without money is just not the American way. But most of Africa lives outside the money economy now — they’re all eating leaf protein out of Dutch machines. Polynesia is like that now. In Europe they’ve got guaranteed annual incomes, they’ve got zero-work people in their Parliaments. Gift networks have always been big in Japan. Russians still think property is theft — those poor guys could never make a money economy work..”

I love this idea of reputation servers — a possible near future for today’s social networks, friend followers, etc. Somehow participation in today’s networks yields a new index of sorts — your trust ranking or something like this. A nice substitute for today’s “credit rating” systems, which are ridiculously opaque, operating on algorithms we who are rated can only guess about. Besides, in the near future, when the role of banks will have possibly whithered to a collapsed prune of their former selves, we may in fact circulate and leverage financial activities within networks of trust that are more peer-to-peer, like this Susu financial practices that is a cornerstone of various expat communities. p.256-257 (See also http://www.theworld.org/node/24945

Continue reading Dog Eared "Distraction"

Finding The Way – HMC6352 Digital Compass

Since I was asked, and asked again, I’ll toss this technotopia solutions nugget to demonstrate that, despite the evidence demonstrated by recent public appearances and weblog postings, we here at the Laboratory are in fact still fully engaged in connecting wires amongst components. Components take a variety of forms, as do the wires. Sometimes bits of silicon strongly encased in hermetically sealed plastic. Other times, cultural components made of different materials. Observations and their conclusions take a variety of paths and sources of inspiration. We enjoy looking at curious people-practices, inspecting them for insights and stories to be told with a variety of resources: objects, images, words.

And so on. More on this point later.

In the meantime, an eager follower has asked for some simple advice that could have been dispatched in an electronic mailing. Instead, The Near Future Laboratory resources room has decided to fold that information into a weblog “posting.”

Wayfinding, of the digital variety has become exceptionally straightforward for those who are okay with writing a dozen or so lines of code for the handy-dandy Arduino and this HMC6352 digital compass which is available as a breakout board off the rack from our friends at Sparkfun.

The compass will give you a perpetual stream of degrees-heading from magnetic north and has interesting adjustments to let you make offset corrections and that sort of thing. It works simply, as all such things should be. It’s a TWI/I2C device, so you get it on the I2C bus, and send commands to its address (42h). Easy-peasy. If you’re doing anything like setting a RAM or EEPROM register, you send the approrpriate command and address. But, for the most part, you’ll just want to tell it to send heading data, right? That’s simple — send the letter ‘A’ (41h) and back comes the heading data. That’s it. Send an ‘A’, get a heading. Send an ‘A’..get a heading. Over and over, or as often as necessary.

Done.

Here’s some Arduino code to get you going!


#include

// 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
//
// These correspond to pin 27 (PC4/SDA/PCINT12/Analog Input 4) and pin 28 (PC5/ADC5/SCL/PCINT13/Analog Input 5) on the Atemga168
// The Wire class handles the TWI transactions, abstracting the nitty-gritty to make
// prototyping easy.

int address = 0x42 >> 1;
 int reading;
void setup()
{
  // this for debugging the data
  Serial.begin(9600);
  // set up
  CLKPR = (1<<clkpce);
  CLKPR = 0;
  // initialize the HMC6352
  Wire.begin(); // join i2c bus (address optional for master)
}

void loop() {

  Wire.beginTransmission(address);
  Wire.send('A');
  Wire.endTransmission();
  //delay(10);
  Wire.requestFrom(address, 2);

   if(2 <= Wire.available())    // if two bytes were received
  {
    reading = Wire.receive();  // receive high byte (overwrites previous reading)
    reading = reading << 8;    // shift high byte to be high 8 bits
    reading += Wire.receive(); // receive low byte as lower 8 bits
    reading /= 10;
    Serial.println(reading);   // print the reading
  }

//  delay(50);
}

Continue reading Finding The Way – HMC6352 Digital Compass

Autonomous Game Controllers

Continuing on my strange pursuit of designing weird interfaces that disrupt conventional game interaction rituals, I put together a bit more of my “PSX” project. You probably don’t recall, but this is the project where I’ve created a little “dongle” that can fool a PS2 (or Playstation 3, as it turns out..) into thinking that the dongle is actually a Playstation controller. You can also hook up a real Playstation controller to it and it can “read” the controller buttons and joystick and pass that data through, or do whatever you want with it. It appears as an TWI/I2C device to anything that talks to TWI/I2C devices..like my favorite TWI/I2C talking thing — the Arduino.

You can see here that the dongle — the white box with those annoying, huge Playstation connectors on either end, one male, one female — has four wires going into it. Those are for power, ground and the TWI signals, SDA and SCL. The power and ground are necessary because the Arduino (at least this one here) and the dongle run at different voltages. The Arduino is a 5V device, while the dongle is a 3.3V device, so there’s some level shifting going on inside there.

So, that’s all fine. It works, etc. But then the question that’s actually more intriguing than building the thing..what do you do with it?

Well, I have some ideas, including hooking up a bike to it and attaching a giant human form kick-boxing dummy to play old school fighting games. For some early fun and nonsense, I connected a Wii Nunchuck up to it to control Playstation games with Wii-y gestures and stuff. Which could be cool if I find the right game, or spend a little more time thinking things through rather than just writing and revising microcontroller firmware to make a TWI controllable device, and doing Catia to CAD-up and print plastic enclosures.

But, in the meantime, I decided to do an absolutely crucial bit of game science. Something that I am entirely sure is mulled over constantly, but never properly investigated. The question is best stated thusly: how long would it take the Little Prince to roll up an entire room based on a random path algorithm?

How long indeed. Well, short answer is a long time. I let it go for about 70 minutes, after which he had just 10 things to go in a particularly tricky location that required rolling across a narrow bridge. At this point, I took over..but check out the 8x speed video anyway!

Katamari Autonomy from Julian Bleecker on Vimeo

I wrote a quick little Arduino code for my PSX dongle to have the Little Prince roll forward and then, after a few moments, make a random directional change. (Or stop, take a load off and look around the world.)

This was all done by sending TWI commands to the appropriate registers in my little DIY Playstation 2 controller emulator. All the buttons and the joysticks can be emulated as to their state through a series of write-to registers. If there’s a controller stuck in the other side of the dongle, there are a complement of read-from registers so you can see if any of the buttons are pressed and how much the joysticks are displaced. (I set up an “escape” buttons sequence — pressing both L2 and R2 — to bring control back to the normal joystick so I could navigate menus or take control over, which I had to do after I realized, with four items left, the completion of cleaning the room would probably not happen before the universe ran out of steam.)

Here’s the Arduino code. Pretty straight forward Wire / TWI library stuff.


#include
#include "nunchuck_funcs.h"

#define is_bit_clear(a, n) (0 == (a & (1<<n)))
#define is_bit_set(a, n)  (1 == (a & (1<<n))

#define is_button_pressed(a, button) is_bit_clear(a, button)
#define is_button_released(a, button) is_bit_set(a, button)

#define BTN_SELECT 0
#define BTN_L3 1
#define BTN_R3 2
#define BTN_START 3
#define BTN_UP 4
#define BTN_RIGHT 5
#define BTN_DOWN 6
#define BTN_LEFT 7
#define BTN_L2 8
#define BTN_R2 9
#define BTN_L1 10
#define BTN_R1 11
#define BTN_TRIANGLE 12
#define BTN_CIRCLE 13
#define BTN_X 14
#define BTN_SQUARE 15

// register addresses in the PSX I2C device
#define W_BUTTONS_0 0x00 // (, ^, start, R3, L3, select
#define W_BUTTONS_1 0x01 // (square, x, o, triangle, R1, L1, R2, L2)
#define W_RIGHT_X 0x02
#define W_RIGHT_Y 0x03
#define W_LEFT_X 0x04
#define W_LEFT_Y 0x05

#define R_BUTTONS_0 0x12 // (, ^, start, R3, L3, select)
#define R_BUTTONS_1 0x13 // (square, x, o, triangle, R1, L1, R2, L2)
#define R_RIGHT_X 0x14 // a value from 0x00 - 0xFF
#define R_RIGHT_Y 0x15 // a value from 0x00 - 0xFF
#define R_LEFT_X 0x16
#define R_LEFT_Y 0x17

// I2C address of the PSX dongle
int psx_dongle_addr = 0x72;
int j;
void setup()
{
  Serial.begin(9600);
  randomSeed(analogRead(0));
  Wire.begin(); // join i2c bus (address optional for master)


// this is the control register. setting it to 1 means that
// we have to tell the PSX device what data to send to the
// Playstation2. Setting it to 0 means that it simply passes
// through the data from the controller to the PS2. We can
// read the state of the contorller at any time.

writeToAddress(psx_dongle_addr, 0x24, 1);
}

// we'll use count to figure out when to change direction
int count = 0;
int buttons;

// mode is used to indicate either "pass thru" where we can use the
// actually real human controller to control the PS2, or to generate
// data via the PSX dongle.
// pressing both L2 and R2 simultaneously toggles the mode
int mode = 1;
byte randomNumber;

void loop()
{
  byte val;
  count++;
  //Serial.println(count, DEC);
 // 0x70 shows up as either ID $20 or ID $E0 on Propeller

/*******************************************/
/*
  BTN_SELECT = $0001
  BTN_L3 = $0002
  BTN_R3 = $0004
  BTN_START = $0008
  BTN_UP = $0010
  BTN_RIGHT = $0020
  BTN_DOWN = $0040
  BTN_LEFT = $0080
  BTN_L2 = $0100
  BTN_R2 = $0200
  BTN_L1 = $0400
  BTN_R1 = $0800
  BTN_TRIANGLE = $1000
  BTN_CIRCLE = $2000
  BTN_X = $4000
  BTN_SQUARE = $8000
**/


// 0x00 write to BUTTONS_0, 0x12 read from BUTTONS_0
// 0x01 write to BUTTONS_1, 0x13 read from BUTTONS_1
// 0x02 write to RIGHT_X, 0x14 read from RIGHT_X
// 0x03 write to RIGHT_Y, 0x15 read from RIGHT_Y
// 0x04 write to LEFT_X, 0x16 read from LEFT_X
// 0x05 write to LEFT_Y, 0x17 read from LEFT_Y
//Serial.println(getButtons(), HEX);
//int buttons = getButtons();
//Serial.print(buttons, BIN);
//  passThruButtons();

if(count > 512) {
  count = 0;
}
//Serial.println(mode, HEX);

// get the buttons
buttons = getButtons();

// mode is used to indicate either "pass thru" where we can use the
// actually real human controller to control the PS2, or to generate
// data via the PSX dongle.
// pressing both L2 and R2 simultaneously toggles the mode
  if(mode == 1 &&
     is_button_pressed(buttons, BTN_L2) && is_button_pressed(buttons, BTN_R2)) {
    mode = 0;
    delay(1000);
  } else
  if(mode == 0 &&
     is_button_pressed(buttons, BTN_L2) && is_button_pressed(buttons, BTN_R2)) {
     mode = 1;
     delay(1000);
     }
 if(mode == 1) {
passThruAllAndShow();
 }
 if(mode == 0)
  {

  writeToAddress(psx_dongle_addr, W_LEFT_Y, 0x00);
  writeToAddress(psx_dongle_addr, W_RIGHT_Y, 0x00);
  passThruButtons();

  if(count == 512) {
    count = 0;

    randomNumber = random(1,5);
        Serial.print("FLIP! ");
        Serial.println(randomNumber, HEX);
    switch(randomNumber) {
      case 1: case 2: case 6:
        writeToAddress(psx_dongle_addr, W_LEFT_Y, 0x00);
        writeToAddress(psx_dongle_addr, W_RIGHT_Y, 0xAF);
        delay(500);
        break;
      case 3: case 4: case 5:
        writeToAddress(psx_dongle_addr, W_LEFT_Y, 0xAF);
        writeToAddress(psx_dongle_addr, W_RIGHT_Y, 0x00);
        delay(500);
        break;
          default:
         delay(500);
         break;
    }
  }

  /*
writeToAddress(psx_dongle_addr, W_LEFT_X, (float)map(nunchuck_accelx(), (float)0x48, (float)0xB0,
                (float)0x00, (float)0xFF));
writeToAddress(pssx_dongle_addr, W_LEFT_Y, (float)map(nunchuck_accely(), (float)0x48, (float)0xB0,
                (float)0x00, (float)0xFF));

writeToAddress(psx_dongle_addr, W_RIGHT_Y, (float)map(nunchuck_joyy(), (float)0x1D, (float)0xDF,
                (float)0x00, (float)0xFF));
writeToAddress(psx_dongle_addr, W_RIGHT_X, (float)map(nunchuck_joyx(), (float)0x1D, (float)0xDF,
                (float)0x00, (float)0xFF));
*/
}

delay(10);
}


//
int getButtons()
{
int result = 0x00;

result = readFromAddress(psx_dongle_addr, 0x13, 1);
//  Serial.print(result, HEX); Serial.print(" ");
result <> 8)); // MSB
  Wire.send((int)(addr & 0xFF)); // LSB
  Wire.send(data);
  Wire.endTransmission();
}

byte readFromAddress(int twi_addr, int addr, int bytes_to_read)
{
  byte rdata;
 Wire.beginTransmission(twi_addr);
  Wire.send((int)(addr >> 8)); // MSB
  Wire.send((int)(addr & 0xFF)); // LSB
  Wire.endTransmission();
  Wire.requestFrom(twi_addr,bytes_to_read);
  while (Wire.available()) rdata = Wire.receive();
  return rdata;
}

Continue reading Autonomous Game Controllers

A New Logic Analyzer and the HMC6352 I2C Compass

Two things that’ve been sitting on my bench for a good spell — this HMC6352 magnetic compass with an I2C interface, and the Saleae “Logic” logic analyzer. I figured I could combine the two together, showing how I used the Logic to check out the operation of the HMC6352.

First, the HMC6352 is a pretty easy to use magnetic compass with 0.5 degree accuracy. It’s all wrapped up nicely with a pretty normal I2C interface to a bunch of registers on the device, and command-driven queries for reading the compass heading.

The Saleae “Logic” logic analyzer is pretty sweet for debugging I2C as I’ve mentioned in the past. This one is nice and compact, with a reasonable bunch of logic lines for doing simple analysis. I played with this one for a number of projects over the last few months — mostly I2C projects, which is where most of my interface work is these days. But, the “Logic” will also work with a bunch of stock “analyzers” for RS232 and SPI as well, making it pretty versatile for many situations.

The analyzer is a pretty compact package — 1.6″ square and only .36″ high. So, basically miniature for a logic analyzer. It comes with a 9 conductor umbilical along with E-Z-Hook XKM probes that you can use or not, depending on how you’re hooking up to things.

The Logic has a pretty easy-to-use bit of front-end software to handle all the set-up and UI work for the teeny-tiny hardware. It’s a UI that is unlike what you might expect from a bit of Windows-based software. It’s very gooey, using some subtle screen effects and UI elements that, for this OSX guy, are not what I think of when I think of XP. Which is good. It makes using the UI not feel like I’m being forced to drink a Rusty Nail or something for breakfast.

The analyzer samples much quicker than I normally have need for and does so without any problems. I’m usually down in the low range — .2 MHz and 1 M samples is usually plenty for what I’m doing. But, if you need a wider range of samples or a higher sample rate, the analyzer will go all the way up to 24 MHz. Those 9 conductors are 8 data lines plus one ground, so you can analyzer an 8-bit wide bus if you wanted at 24 MHz.

So, I put the Saleae Logic on the HMC6352 circuit to give it a shot. First, the HMC6352 set-up.

Although the HMC6352 has a wide voltage range, I was playing around with a level shifter circuit that was already hooked up to an Arduino on the bench, so I went ahead and just kept that circuit as is. So, the basic set-up is my Arduino I2C lines (SDA and SCL) going through a bi-directional level shifter shifts 3.3V 5V, and then to the HMC6352 SDA and SCL lines. I use yellow wire for SCL and blue wire for SDA.

I ended up using the Saleae Logic to dig a bit deeper into the communication between my microcontroller (an Atmega168 sitting on an Arduino) and the HMC6352 as a way to test out the logic analyzer.

First I wanted to just probe the I2C communication. The basic transaction my Arduino code was doing was to send an “A” to the HMC6352. According to the specification sheet, writing an “A” to the device causes it to return two bytes of data — the high-order and low-order bytes of a 16 bit value indicating the compass’ heading. Easy enough. Here’s the Arduino doing just that. First, it sets up the write to the I2C device at address 0x21. Then it writes an “A” which, in the ASCII table, is the value 0x41. (N.B. The spec sheet says the HMC6352 is at address 0x42 but — and don’t ask me why — sometimes the address specified has to be right-shifted one bit in order to “take”. I mean I sort of know why, but I don’t know why this is the case sometimes — a r/w bit thing or something. Too much to bother with, but a good way to make good use of a logic analyzer when you’re stuck wondering why your device doesn’t seem to be listening to you. I learned this the long way and only had a fancy DSO to try and debug it.)

There it is in the top picture. A simple write to the device at address 0x21 with all the ACKs, meaning whatever is out there, heard us and is acknowledging receipt of the write. And, it looks like we get two bytes of data back — a 0x03 and a 0x64. The first byte will be the high-order byte and the second byte is the low-order byte. 0x0364 is 868, which we normalize by dividing by 10, to get 86.8 degrees. Done. I’m pretty sure that’s that. Finally, the measurement features are pretty cool — useful for confirming clock speeds or verifying a bit train. There’s a good use of a simple, pretty inexpensive ($150) logic analyzer that’ll certainly save you $150 worth of your time many times over. Plus, the small size and convenience of USB make it easy enough to fit on your bench and store away or travel around with when it’s not in use. My only quibble is that it’s only for Windows, but that’s a minor one. I don’t really play too hard in the OS religious wars. I run whatever makes my life easier at whatever moment. So, a $200-ish Windows chassis in the laboratory that just runs a few apps like some CAD software and things like my Propeller coding environment, .NET development, software for test equipment like this and AVR Studio 4 — it just helps me get things done rather than being adamantine about which OS religion I’ll adhere to and, then, not getting anything done except spending time porting things from one OS to another or complaining about how much a Windows license costs or whatever.

Wow. Okay. Off my high horse. Check this logic analyzer out. I can recommend it after using it for a few months.

#include

// http://wiring.org.co/reference/libraries/Wire/index.html
// On the Arduino board, Analog In 4 is SDA, Analog In 5 is SCL
// The Wire class handles the TWI transactions, abstracting the nitty-gritty to make
// prototyping easy.
// This sketch has a HMC6352 attached to the I2C bus, through a bi-directional
// level-shifter circuit.
int address = 0x42 >> 1;
 int reading;
void setup()
{

  Serial.begin(9600);

  CLKPR = (1<<clkpce);
  CLKPR = 0;

  // initialize the TWI / I2C Bus
  Wire.begin(); // join i2c bus (address optional for master)

}

void loop() {

  Wire.beginTransmission(address);
  Wire.send('A');
  Wire.endTransmission();
  //delay(10);
  Wire.requestFrom(address, 2);

   if(2 <= Wire.available())    // if two bytes were received
  {
    reading = Wire.receive();  // receive high byte (overwrites previous reading)
    reading = reading << 8;    // shift high byte to be high 8 bits
    reading += Wire.receive(); // receive low byte as lower 8 bits
    reading /= 10;
    Serial.println(reading);   // print the reading
  }

//  delay(50);
}

Continue reading A New Logic Analyzer and the HMC6352 I2C Compass

Urbanism, Data-Driven

(Some cartogram structures and linkages Pascal created as sensor maps where the geography is an implied and driven — rather than the driving — parameter.)

Fabien Girardin, MIT brainiac and a fellow Near Future Laboratory ‘naut presented his expert and insightful trinity of themes that appear to be the main motivators behind "urban computing", a bit of cocktail party conversation related to this short essay that Kazys Varnelis and Leah Meisterlin wrote, and that Nicolas poked a stick at.

Fabien describes three prime motivators behind the “urban computing” discussion and construction projects. Bears repeating, with some commentary.

1. Creating an opportunistic and optimistic urban environment that is somehow “better” than one without some sort of underlying computational infrastructure. This is the realm of the ubiquitous computing folks. The visions are aspirational — near-future signposts always already just out of reach and endlessly deferred — perhaps this is the definition of industry and academic R&D. Provide curious near-future fictions about possible near-future worlds. Effectively science-fiction expressed through objects and scenarios and large research (instead of film and television production) budgets. (Cf ““Resistance is Futile”: Reading Science Fiction Alongside
Ubiquitous Computing”, Paul Dourish and Genevieve Bell, forthcoming in Personal and Ubiquitous Computing.)

2. Study of the impacts and implications of computational systems and operations in an urban context, performed by GIS folk and urban planners and computer science people. These are studies of the dynamics of data-people sensed in the city, mapped and used to develop insights on urban conditions, or perhaps used as contributing information for design or re-design of urban geography. In some cases the data is interpreted in real-time, such as you might expect to be done to manage loads on cellular data networks, etc.

3. The action, postulating and creative exercises of independent and undisciplinary explorers and adventurers who shuffle and interleave the interesting data points that are anchored to geographies that can be re-mapped. This has brought us such interesting tidbits as the various crime data maps, for example, or the flows of automobiles throughout cities. (Using the geeky, horribly, self-deprecatingly named “mash-ups”.) What is happening here that is most compelling to me at least is that “GIS” activities are becoming something that anyone, without a license or professional sanction can do, inexpensively (i.e. for free and a bit of time). So, anything new here and worth glorifying is this fact — we can be our own map-makers. This is significant in the Foucauldian power-knowledge sense of significant. Cartograms such as the fundraising maps, which started out as a very DIY project, are important because they create new meaning and possibilities for action, or shifts in perspective that can lead to change, rather than stagnation. (There’s a normative element, of course. Visualizations of data with geographies, in the power-knowledge realm of things, are as free to interpretation as anything that alleges to be fact, so they can’t be counted upon to prove much of anything. At worst, they can be enrolled in larger conversations, just like any good knowledge agent.)

(Some more of Pascal’s cartogram structures and linkages. Sensor maps recorded amongst a small group of us and visualized such that the geography is an implied and driven — rather than the driving — parameter.)

I’d add a bit here. How can the experience of space — urban space, just to stick to the most discussed idiom — become fruitfully and playfully data-driven? Mapping data onto geographies by their instrumentalized location in space is okay. It’s a bit knee-jerk, though. What I mean is that re-mapping data with an entirely different basis could possibly produce an entirely different urban experience that may, at worst, be curious and playful. Just to see what comes of this. The Laboratory has been working for way too long on such re-mappings that do not assume that latitude and longitude are the canonical reference points for whatever data gets built on top.

I know..I know. This is weird. And the first project I was involved with that did this — an edition of PDPal that created maps based exclusively on interpreting an “experience” — fought a losing battle. But there are some indicators that this approach is at least worth exploring.

Creating “maps” that have a spatial aspect to them, but that do not use space as the primary or explicit reference datum can then emphasize people-practices or experiences first, with the geographic datum implicit or made into a driven, rather than driving, parameter. Paulos and Goodman’s “Jabberwocky” project comes to mind, as do Twitchr and other mappings of “encounters” and actions that are not expecting to use GPS first-and-foremost.

Situationist Space (Thomas F. McDonough)

Here in the Laboratory we’ve been building several prototype devices that record Bluetooth encounters for later visualization. The first prototype was a small Python script running on a Nokia N70 phone. It was like a little data attractor that would sniff for Bluetooth devices, and then record them in a log file, and send them to a server to be persisted in a database.

Two recent editions used a small, custom-designed device that used the Bluetooth scanning mode of a radio to essentially do the same thing, storing the results in a Flash memory device to be later extracted with a simple USB interface. Lately a bunch of us in the studio have been working with a similar concept in the form of a background sensing application developed at Nokia R&D for S60 devices that does all of this, plus quite a bit more. (Currently in closed alpha, but soon to be available publicly.) The biggest challenge (besides running it on an S60 device..) is making meaning out of all of this. The strongest vectors for me, at least, lead to re-mapping and exploring possibilities playfully, with no specific expectations that there is intelligence in the maps by themselves.


# install first the following files to your phone
# (they will install automatically the needed libraries for the script below):
# aosocket-series60_v20.sis, pdis.sis
# found at: http://pdis.hiit.fi/pdis/download/pdis/

# this script was found from forum.nokia.com

import e32
import appuifw
##import aosocketnativenew
from pdis.lib.logging import *
##import httplib, urllib
from location import gsm_location
import time
import sysinfo
import select

cell = []
init_logging(FileLogger("e:\apache\htdocs\bt_probing.html"))

def tell(string):
    #logwrite(string)
    if e32.is_ui_thread():
        print string
        e32.ao_yield()

# ----------------------------------
from aosocket.symbian.bt_device_discoverer import *
#from socket import * # for obex file send

def discovered(error, devices, cb_param):
    if error == 0:
        global cell
        #tell("start discovery..")
        cell = gsm_location()

        #tell("devices: " + str(devices))
        tell(cell)
        #print location.gsm_location()
        for address, name in devices:
            logwrite("")

            tell(cell[0])
            tell(cell[1])
            tell(cell[2])
            tell(cell[3])
            print location.gsm_location()
            urllib.urlopen("http://smalltown.nearfuturelaboratory.com/upload_bt.jsp",
                           urllib.urlencode([('addr',address),('name',name),
                                             ('imei', sysinfo.imei()),
                                             ('batt', sysinfo.battery()),
                                             ('signal', sysinfo.signal()),
                                             ('cell_0', cell[0]), ('cell_1', cell[1]),
                                             ('cell_2', cell[2]), ('cell_3', cell[3])]))
    else:
        tell("device discovery failure: error %d" % error)
    _discoverer.close()


# -----------------------------------------------------------------------------


while(1):
    try:
        _discoverer = BtDeviceLister()
        _discoverer.discover_all(discovered, None)
        #tell("discovering")
        e32.ao_sleep(15)
        print "scanning again"
    except:
        tell("init failure")
        appuifw.note(u"Fatal error.", "error")

Continue reading Urbanism, Data-Driven

PSX (With Propeller) — Digital Edition

So, feels just a little bit like converting religions or something, but I’ve started looking into other kinds of microcontrollers for practical reasons as well as to just generally expand what sits in my prototyping sketchpad. I’ve been curious about the Parallax Propeller, which has a multi-processor (they call them “Cogs”) core and can do video and audio gymnastics. It uses its own proprietary language called “Spin” which is pretty legible if you’ve done any high level programming. Assembly is also an option. The idea of having a small “microcontroller” that has built in multi-processor capabilities feels a bit over-blown, but it’s actually fairly liberating in the design phase. Suddenly, projects start to look like parallel tasks that can be designed with object-oriented sensibilities in mind. All of the “task switching” (cog switching) is handled automatically. Timing and so forth is fairly static so it’s possible to predict precisely how often tasks will get run. The Propeller will also run wickedly fast — way faster than an Atmel 8-bit microcontroller. Normally, speed hasn’t been an issue for projects, but it’s nice to have some overhead — up to 80 MHz in this case (versus 20 MHz for the Atmel, which is more then enough for most things, but the lickity-split clock makes doing embedded video projects possible.

Anyway, this seemed like a good possible fit for the PSX project because I need to simultaneously read a joystick and service polling requests from the console. I probably _could_ do both of these tasks with an Atmel microcontroller running at 20 MHz, interrogating the controller in between the console’s polling. Experience thus far has led me to think that this may not be the easiest thing to do, even sequentially. I’ve tried just servicing the console using the built-in SPI hardware in an Atmel 8-bit microcontroller and the timing is a bit flakey. Perhaps someone with a little more expertise in these things could take this on.

[ad#ad-1]

In the meantime, I went for a few extra cylinders and some more octane, which works better than well-enough.

I found some code that Micah Dowty put together for a Playstation project called Unicone. He had some code there in the midst of that project that was easily adapted to my weird PSX controller-that-gets-tired project.. Works like a charm.

I can specify the data that’ll go across the wire very simply, as a pointer to a buffer of data and Dowty’s object takes care of all the rough-stuff communication to the console. I can even specify what kind of controller I’m emulating, if I want. What’s left is to create an object that polls the real controller, makes some decisions about how “tired” it should be and changes the analog control stick values based on that tiredness and places this data in the buffer. Because the Propeller’s “Cogs” can share data, this should be pretty easy..

This is a trace of communication when I use the code below. The buffer is sent across just as it is, and Dowty’s object is smart enough to send it as if it were a simple PSX analog joystick N.B. the first two bytes after 0xFF, 0x73, 0x5A pre-amble are the button settings, as a 16 bit word, followed by four bytes representing the analog joystick positions. In the DAT section of the code at the very bottom of the listing below, this is exactly what I want sent. Simple.