First test of passing data from XBee to Arduino to Node.js to client

Today I successfully mapped data from three different XBee modules onto a web page hosted on a local server. This is a very big accomplishment for me since it is truly a proof of concept for the entire Sonome project.

Just a few days ago I finally hooked up the receiver XBee to the Arduino so that I could see the packets coming in through the serial monitor. Today I took that one step further, by incorporating that Arduino code into the du.ino code used to connect the Arduino to the Node.js server.

I don't have an XBee shield so I had to wire the pins myself. It's very easy though; as indicated in the code, Arduino digital pins 8 and 9 connect to the XBee DOUT and DIN pins, respectively.

AltSoftSerial allows you an additional serial port simulated through software, and is necessary since both the XBee and Arduino use serial communication. In my testing I found that the hardware serial baud rate must be significantly higher than the XBee rate in order to minimize mixed-up packets. I found this using only 3 XBees, but it will become even more critical when all 16 are blasting away simultaneously.

I then had to incorporate the code above into the du.ino stock code. There was some sort of conflict with the Servo library used by du.ino, so I removed all servo-related code; I don't need to control servos for this project.

As you can probably see from the code, I am printing an array of 16 bytes to the serial port - one byte for each sensor. This is what gets passed through to Node.js, and is how a client knows which value is which. The indices correspond to the transmitter XBee addresses so I can correctly map their locations.

I'm in very good shape now to finish the project on time. I need to connect the microphones to the XBees, and start testing ranges and levels in the real space.

Heatmap color schemes and XBee update

I have been spending a lot of time trying out different color schemes for the Sonome heatmap. Even if all of the sensors are working and successfully transmitting to the server, the visualization could easily be ruined by using the wrong palette.

I decided to focus on a single color because I think it will stand out beautifully on a minimal, sparse background. The final floor plan image will use even thinner lines than the one shown here so there will be plenty of negative space for everything to breathe.

Below are some possible options, the last being the stock heatmap colors for comparison (gradient from blue to green to red). I am favoring #1 but am curious about the grayscale versions because I think they are visually compelling as well.

In addition to the graphic design, I have pressed onward with creating an XBee network. Right now I'm borrowing 4 XBee modules and can successfully send packets from each transmitter to the master receiver. However, I am still hard at work figuring out the best way to send the data from the receiver XBee to the Arduino, and through to the web server.

The program XCTU makes programming the modules so much easier. As shown above, it even can visually display the network topography. This has proven helpful in testing multiple modules at once. I have researched further techniques for managing the barrage of data received by the single receiver. One technique is to stagger the transmit rate of each module by a few milliseconds in order to reduce overlap.

I configured the XBees using custom parameters, including the use of API mode, which allows them to send packets instead of simply serial data. This makes it possible to identify the source transmitter from the data alone. Also I am much more confident that I won't run into RF interference problems from other XBees because of the steps I've taken to isolate them in one part of the XBee wireless spectrum.

Trying out my own pyramid scheme

To explore an "equilibrium of an ecosystem in which players’ selfish behavior collapses the system," I decided on the classic pyramid scheme, in which a person's success depends on their recruiting of additional people, ad infinitum. The inherent problem is easily illustrated in the image below, which proves that a system of this nature is quite literally unsustainable.

I designed an ambiguous pen-and-paper "game" to see if I could embroil my colleagues in a similar scheme. I told two random people that the goal was to create a team-network and they needed to each recruit two people, and tell them the exact same thing I told them. They would fill out the small papers I provided and continue until the paper ran out. Each recruit was to return their papers to the person who recruited them, in effect creating a depth-first search, since I would not get any papers back until all of the people below me had submitted them to their higher-ups.

I also mentioned that their score would be determined by the number of people they managed to recruit underneath them, so that they should only choose people who they thought were likely to carry out the instructions. The lack of real incentive didn't seem to hinder people's eagerness to participate, but then again, this is ITP.

After my own recruiting, I receded into the shadows to watch the chaos unfold. It was hilarious to watch as people starting asking questions about who the higher-ups were.

"Who do I give this back to?"
"Me."
"Who do you give it back to?"
"The person who gave it to me."
"You mean that guy that was standing over here?"

It only had taken me five minutes to become an anonymous figure of lore, just like the criminals who I read about while researching the basis of this experiment. I'm sure these same questions were asked during the downfall of Bernie Madoff's investment scandal.

The game also evolved on the fly, which is not something I had anticipated. Due to the half-baked nature of the rules I explained, it wasn't clear to the participants what to do if they only had one sheet of paper. I heard at least one person suggest that they should make their own paper in order to keep it going, which was not my original intention, as I wanted to minimize the amount of effort required by each individual participant. However, I did not intervene, as the mark of a good pyramid manager is to stay laissez-faire all the way to the end.

Unfortunately, I did not get back any of the papers yet so I cannot say with any certainty what happened. It appears though that there was not enough of an incentive to encourage their timely return. I will update this when all of the papers are returned to me.

Update on Sonome

A couple weeks ago I decided that the original scope of my project was too ambitious. Creating a wireless sensor module that could exist outdoors is a fairly daunting task (and solar-powered? what was I thinking...), and when combined with the front-end map interface it is entirely too much for one semester.

However, an indoor version removes a lot of constraints. The modules don't necessarily have to be wireless, power is readily available, there are plenty of mounting options, and the physical area covered by the sensor array is much smaller.

Therefore, Sonome ITP is the new name of the project. I still want Sonome to exist as it's own concept so that's why ITP is secondary in the name (small distinction but I think it's worth mentioning as I think about the future of what an urban Sonome would look like).

Sonome ITP will be a visualization of noise on the 4th Floor of 721 Broadway, premiering at the 2014 ITP Winter Show (pending acceptance of course). Visitors will see a display in the ITP lobby that will look something like this rough version below (using random data):

I may experiment with a Google Maps overlay but this depends on if and when they install the indoor map which I submitted to them two weeks ago. The idea would be to place the Sonome visualization on top of an integrated Google Maps floor plan so that mobile users could see their current location within the space. Unfortunately as I said before this feature may not come to fruition, and so my focus for now is on this simplified image version of the ITP floor.

The sensor is coming along, too. I think now that "module" is a bit too strong of a word, since what may happen is that several microphones will be connected to one transmitter instead of one microphone per transmitter. Wireless is now optional since I have the space and infrastructure to run wires, but Despina brought up a valid point that a wireless solution may still be the smartest choice, based on the description of the microphone wiring so far.

I bought a MEMS microphone breakout and it works really well. It is incredibly sensitive so I have been trying to come up with various ways of normalizing the values coming off of it. I have also successfully connected an Arduino to a Node.js server (via USB) using duino and am able to see the microphone live on the noise map, as well as access the map on other devices on the same network.

Some major things that need to be done:

• Decide on the exact physical system layout and connectivity
• Normalize the noise data
• Set up a public server (instead of a local server)

More to come soon.

Two color map + current event map

Two color map

Being able to use only two colors on a map might at first seems like a limitation. But it makes things much less cluttered and easier to understand, if you choose the right data to visualize.



This is a map of every building in Manhattan. Each blue bubble is a building, and the size of the bubble is determined by how many floors that building has. The background of the map is white, and the building bubbles are blue. The attribute that gives a meaning to the map layout is the bubble size.

Notice how easy it is to pick out the areas where skyscrapers exist. Better yet, zoom in a bit and the city begins to deconstruct. The space between buildings increases and you can see the relative footprints of a high-rise or a walk-up.

Current event map

I had been interested in the number of Americans who joined/tried to join ISIS after reading a couple articles about them. When we read about historical rebel groups, we tend to ignore the fact that that kind of thing can happen in our present day. At least I do. This was an attempt to humanize some of these people.




Using Odyssey.js I constructed a simple list of people and the places of their origin, along with short blurbs taken from the original article (dutifully cited in the first slide). It shows that potential jihadists can be found all over the country, and some are even that guy who "was a goofball in high school."

Foosball front-end

Link: Foosion

Partially for class, partially for fun, I created the front-end framework for some of my Cloudcommuting colleagues' foosball-centric RFID projects. The systems are not connected as of yet but by the end of the semester we should have a fully-functional identification system that updates the front-end in real-time.

There are several data points that we are recording:

• Date of match
• Winning player names
• Winning team score
• Losing player names
• Losing team score

In future iterations we will be recording the goals scored by each player, as well as the time of the goals with respect to the start time of the game.

For this project I used AngularJS as the framework. Eventually it will be integrated with Node.js and MongoDB so that the front-end and the Yún(s) can communicate with the server and with each other. With this setup it will be feasible to display a foosball game live on the internet (similar to ESPN's Gamecast).

Since seeing the web site is helpful to understanding how the system works, please check it out at the link at the top of this post.

Noise mapping proof of concept

Link: http://hidden-fortress-3752.herokuapp.com/map.html

This week I made a proof of concept that would allow me to demonstrate what a live noise map might look like. Originally I was going to use real audio from multiple locations but I ended up using one audio file and just simulated the drop-off of noise levels at each successive node.

The map uses a hard-coded array of 44,100 decibel level samples (from a 44.1k audio file). The visualization steps through the values at a rate of 5 per second to simulate the rate that I had wanted to achieve with the actual system.

The color scheme is based on sound level intensity (green is low, red is high) and has a radius large enough to just overlap, creating a heatmap-style visualization. You can see the high-intensity noise travel through the nodes, and the heatmap smoothes the movement so the nodes don't display as discrete points.

County names = state names and a map of the news

I wanted to make an interesting map of all U.S. counties that are named after U.S. states. I was able to display the shapes of such counties but was unable to do anything further - following the slides verbatim I couldn't get ST_MakeLine to work (after substituting my own table names). Here's the initial map I created using the following SQL.

SELECT * FROM uscounties_merge WHERE name IN (SELECT state_name FROM uscounties_merge)



From here I was hoping to draw lines connecting the center of each shown county to the center of each state, respectively. There are a ton of counties named Washington and I wanted to show the intensities of the various namesakes. Again, I couldn't make the map, but here's a mockup of what could've been.

Midterm: Toward a Self-Sizing Mobility-on-Demand System Simulator

For our midterm project involving Citi Bike, my group (Aaron Arntz, T.K. Broderick) was interested in exploring how to simulate a self-sizing network. However, before we could do that, we needed to create a simulation that somewhat accurately depicted the behavior of the real system.

T.K. sculpted our overall message, tone and delivery – what was important about the system we were we aiming to simulate, and how would we connect our simulator to real world data to make it relevant? Aaron mined the Citi Bike System Data for clues about real-world behavior and refined them into data points describing stations and bikes. And I incorporated T.K.'s and Aaron's findings into a system simulator which I wrote from scratch in NetLogo.

In order to have as accurate a simulator as possible, we decided to populate NetLogo with the actual number of stations in their actual geography. The latitude and longitude of stations in the simulator are mapped to Cartesian coordinates so that the shapes of Manhattan and Brooklyn are easily distinguished.

To populate the stations' data, we used two types of information: (1) a snapshot of station capacities at a particular moment in time and (2) aggregate data from all trips in August 2014. Each station has the following fields:

• Station ID (1)
• # of available bikes (1)
• # of available docks (1)
• Master launch rate (2)
• Launch table (2)

The last two fields are the most important for achieving realistic behavior. The master launch rate is the percentage of trips from a given station out of all trips. The launch table is a collection of destination station IDs whose frequencies match the percentage of trips from a given station to a given station. Note that the master launch rates and the launch table rates always add up to 1, respectively, as they account for all trips taken in August 2014.

Below is the launch table for station 339 (Avenue D & E 14 St), constructed from the percentage of trips from station 339 to any of the other station IDs in the list. Note that selecting a random item from the list will result in the selection of a given station ID with the same probability as actually occurred from this particular station in August 2014.

[339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 339 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 295 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 361 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 259 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 279 307 307 307 307 307 307 307 307 307 307 307 307 307 307 307 307 332 332 332 332 332 332 332 332 332 332 332 332 332 475 475 475 475 475 475 475 475 475 475 475 475 475 501 501 501 501 501 501 501 501 501 501 501 501 507 507 507 507 507 507 507 507 507 507 306 306 306 306 306 306 306 306 306 306 351 351 351 351 351 351 351 351 351 351 385 385 385 385 385 385 385 385 385 385 412 412 412 412 412 412 412 412 412 412 337 337 337 337 337 337 337 337 337 504 504 504 504 504 504 504 504 504 375 375 375 375 375 375 375 375 375 519 519 519 519 519 519 519 519 519 497 497 497 497 497 497 497 497 326 326 326 326 326 326 326 326 502 502 502 502 502 502 502 502 3002 3002 3002 3002 3002 3002 3002 3002 445 445 445 445 445 445 445 284 284 284 284 284 284 284 415 415 415 415 415 415 415 280 280 280 280 280 280 280 315 315 315 315 315 315 315 285 285 285 285 285 285 401 401 401 401 401 401 293 293 293 293 293 293 511 511 511 511 511 511 2009 2009 2009 2009 2009 455 455 455 455 455 518 518 518 518 518 393 393 393 393 393 341 341 341 341 341 350 350 350 350 350 263 263 263 263 454 454 454 454 428 428 428 428 335 335 335 335 312 312 312 312 363 363 363 363 296 296 296 296 264 264 264 264 347 347 347 347 224 224 224 224 297 297 297 297 433 433 433 161 161 161 266 266 266 250 250 250 342 342 342 2003 2003 2003 265 265 265 394 394 394 150 150 150 531 531 531 505 505 505 331 331 331 438 438 438 311 311 311 490 490 490 382 382 382 260 260 260 2012 2012 2012 410 410 410 317 317 376 376 379 379 302 302 380 380 168 168 528 528 127 127 316 316 2023 2023 304 304 540 540 236 236 174 174 400 400 486 486 404 404 360 360 473 473 432 432 305 305 496 496 2006 2006 237 237 532 532 512 512 153 153 301 301 483 435 2022 494 358 345 521 310 308 491 320 392 487 349 232 294 411 482 444 212 291 459 173 128 303 252 340 79 457 300 461 318 405 116 2017 229 427]

To better represent the stations' states, they are color-coded to match their current usage. Green stations are balanced (i.e. less than 95% full and greater than 95% empty), red stations are too full (i.e. greater than 95% full), and blue stations are too empty (i.e. less than 5% full). Here is the state of the system before any simulation has occurred:

Our focusing on stock rebalancing issues meant defining the concept of station balance, or the potential use of the station compared to its actual use. The goal of a self-sizing system would be the spread the usage evenly (or better yet, optimally) over all stations so as to minimize congestion due to either a shortage of bikes or a shortage of docks.

The final piece of the simulator was to model the basic behavior of a user (bike) arriving at a station that is completely full. We guessed that a realistic radius for seeking out an alternate station is 0.4 miles, or about 8 minutes walking. The bikes in the simulator wait a short amount of time, then proceed to another station within this radius if no docks are available.

After running the simulator many times it was clear that our model highlights one of the basic truths of the system: on average more bikes are launched from Manhattan stations than Brooklyn stations, and this causes an imbalance if no restocking is performed. This can be seen in the progression below (the first image is the same initial system state shown above).

We were pleased to identify some of the same stations that our previous visualization picked out. This gives further proof that their are certain stations that may be candidates for self-sizing and/or elimination.

Having this simulator as a base for our future exploration of the Citi Bike system is an important step, and we are pleased that we were able to make such progress for our midterm project.

Three maps, three lies

A lie told about space
Link: Population Density - Derek Watkins

This map shows the world's population density using a slider to move through the various density levels. Viewed at the slider's lowest density threshold, the world's continents are clearly visible. However, when the slider is set at the maximum density, the map is pretty meaningless. Plus, the extreme minimalism and low resolution of this map is very misleading. At 500 people per square kilometer, we should be able to see hundreds of metropolitan areas in the United States (Reno, Nevada is at about 800 people per square kilometer), not to mention plenty of other places in the world.

An unintentional lie
Link: US Stream Names - Derek Watkins

This map is one of a trend of maps showing local terminology across the country, in this case the names of natural watercourses. Because of the high-contrast visual design, it's easy to assume that the blackout areas either have no corresponding data, or that they don't have one predominant nomenclature. This isn't true, though - buried as a footnote to the map description, the gray and black areas are where the terms "river" and "stream" are most common. This map has essentially removed from view the largest data points in favor of the more uncommon names. I think this was an unintentional result of the visual design, as this map would've been just as interesting.

A clear distortion of the truth
Link: A Texan's Map of the United States

Novelty maps often distort reality for comedic effect. This map does exactly that by enlarging the geography of Texas in relation to the rest of the U.S., mimicking the stereotype of the proud Texan's perception of non-Texan areas as inferior and/or physically smaller. The labels also reinforce stereotypical prejudices of Texans.

Abstract noise map

Link: Can you hear me now?

In order to make a map that changed depending on the user, I used browser geolocation to center a map over the user's current location. Then I zoomed in as far as I could into the visualization I created, which paired U.S. county shapes with population density for each U.S. county.

I made a choropleth to try to estimate the average noise level for a user's current location based on the population density of the corresponding U.S. county. While the link is tenuous at best, it abstracts the idea of distinct zones of noise that I think make sense to most people.

After the browser detects your current location, you will see a huge area of bright color (because of the high zoom level). You can compare this color to the scale in the legend at the bottom-right of the map to see how your location's noise "profile" stacks up against the rest of the country. I wanted to make the visual aspect as simple as possible and I think I at least succeeded on that level.

Here's an embedded version (for geolocation please visit the link at the top of this post):

A more personal mapping experience

There is a base level of service that all Google Maps experiences provide, but being signed into a Google account really changes the amount of information available to, and usable by, the user.

One of the obvious areas where personalization can be seen is during a search. Google indexes not only your contacts but your map history to provide the most relevant location results possible (this is why I always try to save my contacts' addresses).

Another way Maps can be tailored to your needs is the inclusion of calendar event information displayed on the map. If I have an appointment on the same day, and the location of the appointment (again, needs to be stored in the calendar event) lies within current map view, Maps will display a marker showing the appointment time and estimate of travel time. I couldn't get a screenshot because it seems to take a bit of time to index this information.

You can also explicitly tell Maps about your favorite locations, like Home and Work. Keeping this up to date ensures that Maps will always try to anticipate your commute across other services like Google Now.

The bottom line is: always save address so that Google Maps can make your life easier!

Instructional "thing" on the web

Link: Print-your-own piano helper template

Part 2 of the instructional “thing” assignment was to make it accessible on the web. I wanted to make the piano template I created into a web page so that anyone with a printer could print out the design at actual size and cut it out themselves without having to measure anything.

I used some HTML5 canvas elements, JavaScript, and CSS. This was my first time using HTML5 canvas and I found it to be unintuitive. My experience with the Java-based Android canvas helped a fair amount but there were more than a few things that baffled me.

By far the biggest problem I had was that I couldn't figure out how to make an element print at an exact physical size. It turns out that the CSS in (inch) units are just multiples of fixed pixel amounts. I have a pending question on Stack Overflow and will update this post if I get an answer.

After getting things close to correct, I added instructions for the templates' use. I realized that not everyone would know a piano keyboard well enough to identify one octave starting at C, so I found an SVG image of such an octave so that people could identify this better.

One improvement I want to make is to include the physical measurements on the template so that people can measure and draw their own templates without needing a printer. Assuming that everyone has access to a printer was a major oversight.

Visualization of Citi Bike station node influence

My group's midterm is based on pruning "weak" stations and/or adding supplementary stations to the Citi Bike network in the hope of improving the system overall. The first step in this process is to identify weak stations that might be candidates for pruning, so I decided to make a visualization to get this information.

I used Gephi to create my visualization. Gephi worked best when I gave it separate data tables for nodes and edges. I loaded the Citi Bike station data (nodes) and trip data for February 2014 (edges) to form a graph.

One of the first things I realized was that the nodes could be easily divided into Manhattan stations and Brooklyn stations just by looking at the network's modularity (the strength of division of a network into modules). There are of course thousands of trips that start in Manhattan and end in Brooklyn, and vice versa, but the vast majority of trips start and end in the same borough. In the graphic below, Gephi grouped the nodes in this shape after I ran a modularity analysis (with a resolution of 2.0).

This means that pruning the weakest node overall might not affect the network as much as we had hoped it would. However, focusing on each module specifically is bound to have better results.

To determine the weakest nodes I looked at eigenvector centrality (Google's PageRank is a variant of this metric), which is "a measure of the influence a node." Connections to higher-scoring nodes are valued higher than those to lower-scoring nodes. The results (after 1,000 iterations) can be seen below. Gephi has several layout options to optimally display the network graph based on the chosen measurement (in this case eigenvector centrality). The Brooklyn visualization used a different layout for improved legibility.

Red nodes have higher scores and blue nodes have lower scores. The visualization makes it obvious which nodes are candidates for pruning; Railroad Ave & Kay Ave in Brooklyn and Leonard St & Church St in Manhattan are the lowest-scoring nodes in their respective boroughs.

This is accurate for trips made in February 2014. However to really get a sense of the all-time weakest nodes we would need to use all available data in these algorithms. There are likely seasonal changes in ridership that make certain stations less utilized in the winter.

A map of noise for the rest of my day

Making a map for the "rest of my day" was complicated by the fact that I am stuck at home sick, so I focused my efforts on understanding the noise in my own living space.

First I identified the major noise generators: coffee grinder, air conditioning, television, alarm clock. Then I eyeballed a radius for each, based my own perceptions while living here. Finally, I color-coded their respective regions.

The result is a cool-looking map that can support quite a few lies. I wanted this map to be as simple as possible so I sacrificed things like exact noise level, exact boundaries, exact measurements, and pretty much anything else that required me to leave bed.

One thing that I learned is that overlapping colors become very confusing. Originally I wanted the coffee grinder red to cover the entire apartment because the coffee grinder can be heard in all rooms. The problem was that you couldn't then tell where it started and ended, even with the red dot denoted the source of the noise. It just tinted all of the other colors red without any indication it was doing so.

Another thing became obvious in that you really need to decide ahead of time what you want to focus on. Do you treat each noise as a distinct sound? Or do you treat all noise equal and just focus on area? Or do you do both, but incorporate measurements of the noise levels to differentiate them? Or do you...

This was never meant to be a highly accurate map, but even making this inexact map made me think about exacting requirements for other mapping endeavors.

Project overview: Sonome module

Concise description
To design, construct, and implement a module for transmitting noise levels wirelessly in an urban environment.

Target user
The module is for my personal use.

User feeling
I want to feel empowered to increase the scale of my project, and confident that I can achieve my goals using the module.

User action
Once programmed, I desire to "set and forget" the module; that is, the module should require minimal tinkering after correct programming, even in failure cases.

User knowledge
I want to know that the module is operating correctly. I also want to know the noise levels where the module is located, and this information should be easily accessible to me (as the developer) even without a visualization.

Problem to solve
In order to create a realtime noise map, realtime noise data is necessary. The primary function of the module is to measure the ambient noise level in a given location and transmit this information wirelessly to a server. However, the module also needs to be robust to exist outdoors,

Recommended solution

1. Start with a homemade piezo microphone and an Arduino to measure the efficacy of such a microphone in measuring this kind of data.
2. Make the Arduino wireless, likely using a WiFi shield.
3. Measure power consumption during normal usage (reading & transmission every 200ms) and experiment with optimal settings.
4. Determine definitive power needs (batteries or solar?).
5. Finalize all components and eliminate excess
6. Iterate designs and materials for an enclosure
7. Test in real world...

Opportunities in problem space
Realtime noise maps basically do not exist for the general public. There are proprietary systems that provide such information but these are limited to professional applications. Providing this information on a democratized platform (i.e. any web browser) would promote a discussion of the role of noise in urban spaces in an accessible way. The only way to achieve this is to create a module capable of supplying this information.

General challenges in problem area
Gathering live data over a relatively large physical space is not an easy task, which I'm guessing is why realtime noise mapping is not more common. And even if you are able to deploy an array of sensors, keeping track of and presenting the data is always a concern.

Specific challenges
The main problem is requirement that the module must run and transmit data wirelessly in a variety of physical environments. Power is a significant concern because either the device needs to be self-sufficient (i.e. solar-powered) or it should run at least several months on batteries.

Another concern is mounting the module in the physical environment. The module should allow for a variety of mounting situations and weather conditions; this may suggest that the mounting system should be decoupled from the primary module design.

Research
stillspotting nyc – Non-realtime noise map focused on finding quiet areas
SoundPLAN – Proprietary software packages for grid and meshed noise map simulation
Navcon – Engineering consultants utilizing SoundPLAN software
DataKustik – CadnaA (Computer Aided Noise Abatement) proprietary software offers up-to-the-hour dynamic noise mapping
2012 Manhattan Noise Complaints – Self-explanatory static map by Karl Sluis
Citygram – "Visualizing Urban Non-Ocular Ecology" (possibly defunct)
CONTACT – Hannah Mishin's PDS project from last year that visualized sound inside ITP
WideNoise – App for reporting and displaying chronologically-disparate sound data

Technical, spatial, and interactional requirements
Technical:

• Handle a wide range of noise levels
• Run in a wide range of temperatures
• Handle failure cases without crashing
• Employ modular codebase to speed development and testing
• Queryable status

Spatial:

• The shape of the enclosure minimizes or negates effect of precipitation
• The effect of echo off or vibration of the surface on which to be mounted
• Inconspicuous design shouldn't attract unwanted attention

Interactional:

• Minimize the sensitivity of module to hyperlocal noise (e.g. "noise vandals")
• Needs to have a "set it and forget it" interaction style (for me)

Criteria/evaluation of success

1. Accurately measure the ambient noise level in the sensor’s vicinity
2. Transmit data wirelessly over Wi-Fi or GPRS several times per second
3. Easily and safely mount in a variety of built environments
4. Be quickly and economically manufactured

Besides #2, all of these criteria are subjective. For #1, a tolerance will be determined in conjunction with the proposed visualization of this data. I will define #3 through the process of creating and mounting the module. I will define #4 by researching potential materials and technologies and putting a cap on the total cost per module.

Draft timeline

Week 1 – Write project description

Week 2 – Research microphone

Week 3 – Build microphone prototype

Week 4 – Test microphone

Week 5 – Finalize microphone

Week 6 – TAKE A BREAK

Week 7 – Research wireless Arduino

Week 8 – Configure wireless Arduino

Week 9 – Finalize all electronic components

Week 10 – Research enclosure

Week 11 – Build prototype enclosure

Week 12 – Finalize enclosure

Week 13 – Final testing

Instructional "thing"

For my instructional "thing" project I attempted to create a simple device, made from a sheet of copy paper, intended to help the user learn to play the piano. "Learn" is a strong word in this case; future versions of this prototype could possibly teach piano fundamentals but my focus here was just on enabling the user to play pleasant sounds rather than nothing at all.

The basic device is a paper cutout that fits over the span of one octave starting at any C key. This is important because the C major scale is generally the first scale encountered when learning the piano as it does not include any black keys. It provides key labels for the user, but it allows acts as a base for a number of possible "shields." The basic device and a shield are shown above.

The chord shield helps the user find simple triad chords within the major C scale. Though the visual language needs improvement, the basic idea is to show finger positions of the I, IV, and V chords so that the user can quickly play a more substantial-sounding piece of music. I developed an additional shield for learning "Mary Had a Little Lamb" but, again, the visual language is at this point non-standard and could be more confusing than helpful.

Overall, I think there is potential in such a template that anyone could print or measure and draw themselves. It would be a good exercise for kids to use math in the creation of the paper cutout, and then give them a reward by enabling them to play notes and chords on a piano without needing any formal instruction.

Financial management and the poor

Chapters 6 and 7 of Poor Economics deal with the many financial risks faced by the poor. The poor are likened to hedge-fund managers in that their "portfolios" possess great risks. But unlike most hedge-fund managers, who are liable for a fraction of the assets they manage, the poor are liable for 100% of their own assets.

The poor tend to diversify their activities in the same way an investment portfolio might be diversified. This is a necessary precaution to spread risk over several domains. However, this creates a roadblock to acquiring greater skills and experience because it's "hard to become a specialist in anything without specializing in it." It seems that doing many things at a low skill level is less profitable than doing one thing at a high skill level.

The concept of informal insurance predominates as insurance plans as we know them are simply unavailable. Informal insurance refers to a system of communal sharing and lending that acts as a safety net for those in the community who have fallen on hard times, as well as those who may fall in the future. A constant circulation of informal aid can be vital to sustaining all members of such a community. Furthermore, informal insurance is usually performed on individual bases; that is, direct assistance rather than a "common pot."

Similar to micro-credit, micro-insurance schemes have been tested in poor communities with mixed results. There are major risks involved for the lenders:

"Offering reimbursement-based health insurance for outpatient care in a country where health care is at best weakly regulated, and where anybody can set up shop as a 'doctor,' seems like the first step toward bankruptcy."

Additionally, rampant corruption, commonplace in many countries, undermines any trust the poor might have in financial institutions. Government subsidies may prove to help acceptance of traditional insurance take hold by making it more affordable.

In general, "banks are unwilling to touch the poor" for a variety of reasons, but the main constraint is the cost of gathering information about the creditor. Large institutions are not equipped for the groundwork necessary in verifying a poor creditor's standing in a small rural community. This increases the interest rate and eventually boxes out the poor from even trying for a loan.

Micro-credit has been proven to be a viable option, and can more than sustain itself as a business for the lender. Unfortunately it is quite susceptible to rumor and groupthink – it can be dismantled overnight by false information spread by bureaucratic and/or political opponents of such schemes. It also puts medium-sized businesses in a tough spot; too big for micro-credit financing but still too small for large bank finance.

Class 1 response (Mobility on Demand Systems)

Intelligent urban system

Smart trash receptacles

The BigBelly Solar trash compactor is a "smart" receptacle that makes garbage collection more efficient by 1) increasing the density of the garbage to be picked up and 2) providing the status of its current capacity electronically.

Basic feedback loop

1. Receptacle accrues garbage
2. Receptacle capacity monitored by city
3. If receptacle near maximum capacity, city collects garbage

Form of governance

The receptacles are created by BigBelly Solar and controlled by the city government. The city government expects that the use of these receptacles will reduce inefficiencies and cost of garbage collection. Stakeholders include:

• BigBelly Solar (desire publicity for its product)
• City government (desire to recoup their investment and improve eco-friendly image)
• Citizens (desire improved system of garbage collection)

In practice

These particular receptacles have drawn criticism for the fact that they require the user to touch a handle on the receptacle, as opposed to ordinary garbage receptacles with an open top. This has caused a backlash against the use of the receptacle, even though the handle issue seems at a glance to be extremely superficial. Citizens have voiced concerns that it improves the aggregate garbage collection at the expense of the citizens' health (i.e. touching the surface of the receptacle could lead to illness).

Driverless cars as a mobility on demand solution

While I think driverless cars are important in the development of autonomous/intelligent vehicles in general, I don't think they are a great solution for improving urban mobility. They may seem like a natural choice given the configuration of most cities, but I believe that there are even better options if we were to consider alternative urban architectures.

The fact that urban space is made of roads greatly limits the imagination when dealing with mobility, especially the last-mile problem; that is, how to travel the last mile of your journey to a destination. If we created more urban space in which roads didn't exist, we could develop new locomotive mobility systems (e.g. moving walkways) that allowed us to move our own bodies freely through urban space without needing an external vehicle.

If all taxis in NYC were replaced with driverless analogues, we would still have many of the same problems, like traffic, refueling, pollution, and safety. However, if the number of roads was reduced, and focus was instead turned toward creating space for humans instead of automobiles, we could reduce the need for the latter and provide a more fulfilling environment for the former.

The lie and story of a Symap

A Symap is a map which uses the densities and shapes of typographical characters to convey scale data. They were commonly used in the heyday of typewriters and character-based printers which could print "graphics" by using contrasting ASCII characters.

My attempt at a Symap deals with NYC noise complaints per capita per borough, as seen below (full-screen version here):



There are a number of problems with this map. Though the characters are not nearly different enough to make a convincing story, the bigger issue is the per capita scale. The five boroughs vary greatly – 26 complaints per thousand residents in Manhattan versus less than 5 complaints per thousand residents on Staten Island, with Brooklyn, Queens, and the Bronx all somewhere in the middle.

Unless I am explicit in my terminology, I could unintentionally mislead you by showing a graphic derived from one calculation while you assume it comes from another. In this graph I used the borough populations so as to only compare the boroughs to themselves (e.g. 42,048 complaints divided among 1,626,159 residents in Manhattan gives the Manhattan per capita value). However, per capita often suggests a comparison to a whole (perhaps the entire city), espcially when the entire city is shown on the map.  In this case, we would take 42,048 complaints and divide among 8,405,837 city residents, and get a different value.

NOISE COMPLAINTS PER THOUSAND RESIDENTS
Borough	Borough- centric	City- centric
Manhattan	26	5
Brooklyn	10.5	3.3
Queens	6.3	1.7
Bronx	7.5	1.3
Staten Island	4.9	0.3

As seen in the table above, the choice of calculation can alter the "facts". Borough-centrically, the Bronx has more complaints per capita than Queens. But city-centrically, it is reversed. This data, once mapped, becomes the story.

Furthermore, we can simplify the story for the sake of a concise headline and say (in one case) that "the Bronx is noisier than Queens" without ever giving thought to what a noise complaint means. Does it mean that the Bronx is actually louder than Queens, or might it mean that Bronx residents are more inclined to complain, regardless of noise level?

This Symap is incredibly simple, but through analyzing the Lie and the Story we can see that there is an unbelievable amount of room for opinion, persuasion, and plain old error. Taking on larger and more complex mapping projects will require me to always question my methodology, even before the data makes it onto my map.

Fall 2014 courses

Building for Learning (Aidan Feldman)

The web has already revolutionized the way that people consume information, but only recently has it been taken seriously as an avenue for teaching. MOOCs, online tutorials, and interactive applications all offer different means of learning, from the highly structured to the exploratory. They raise new questions around evaluation and assessment, while providing new avenues for collaboration and opportunities for students outside of traditional learning environments. In this class, we will examine various educational platforms and tools, and get the opportunity to speak with their creators. What can we offer to teachers to make their lives easier? What features increase and sustain student engagement? The course will be largely project-based, where students will learn frontend web development skills to build new web-based learning experiences and tools.


Cloudcommuting: Rethinking Point-to-point Urban Mobility Systems (Dimitris Papanikolaou)

This course introduces the theory, underlying technologies, and operational challenges of intelligent mobility on demand (MoD) systems, using NYC City Bike sharing program as a living laboratory.

MoD systems utilize networks of parking stations and shared fleets of vehicles (bikes, scooters, automobiles) allowing users to make point-to-point trips on demand. Today, more than 650 bike sharing systems around the world mobilize 3 million trips every day while at least 200 additional systems are planned. Despite their seeming convenience and advanced technology, asymmetric trip patterns cause many stations to temporarily deplete from bikes while others from parking spaces decreasing reliability and level of service in the system. Operators spend their entire usage revenues paying gas, trucks, and workers to manually move bikes from full to empty stations. Yet, level of service is often low. In Paris 48% of users find no bikes and 58% of users find no parking spaces available. In Barcelona, 50% of the stations are either empty or full during 30% of the time.

In this course we will explore how information technology, social mechanism design, and game theory can be used to design the next generation of intelligent self-organizing MoD systems that motivate their own users to rebalance the fleet using price incentives. The course will combine lectures, readings, technical skill workshops, and a hands-on experimental project in a collaborative studio environment.


Frugal Innovation (Catherine Muther)

This course gives students conceptual and practical experience in developing ideas, tools, products and processes to augment and improve the lives of the global poor. We will use a variety of resources and methods to explore the emerging field of Frugal Innovation, beginning with an understanding of the context and constraints of living on less than $2.00 a day. Students will learn to identify key principles and challenges of designing for the Bottom of the Pyramid; for example, relentless pursuit of affordability. What are innovative models of using communications technologies to serve an illiterate market?

We will use Case Studies that address real life problems in emerging markets, particularly in healthcare and financial inclusion, where the use and potential of communications technologies is proliferating. Classes will feature cases of actual products or processes developed to solve a problem or meet a perceived need– some successful and others not. Why? How do we know what success looks like? We will look at metrics, methods and markets to explore the question of measuring impact. Entrepreneurs and field leaders will come to ITP as guests to share their knowledge and experience, and engage with students. Student teams will work on a project to create a frugal innovation for a critical challenge in the lives of the global poor.


Maps, Lies and Storytelling (Andrew Hill)

Maps have an incredible potential to do good and evil. Throughout history access to a map has been synonymous with power. In this course we will look at why that has been true, how it has changed through the digital revolution, and how we can harness mapping to gain power. The course will take a critical approach to maps and mapmaking, trying to pick apart all the ways they can be evil and be used to do evil. Through that critical approach, we will learn how to use maps effectively to communicate data, create knowledge, and tell stories. Students will also learn how maps are changing. We will try to find innovative new maps to create, both unassuming and controversial, and share those with a broader mapping community to create a public dialog. Students will learn the fundamentals of mapmaking, using tools from a pencil to Javascript, to create original maps from original data. We will create interactive maps with tools such as Leaflet and CartoDB to make maps from our imagination. We will also look at collecting or creating new geospatial data to make original maps never seen before.


Project Development Studio (Despina Papadopoulos)

This is an environment for students to work on their existing project ideas that may fall outside the topic areas of existing classes. It is basically like an independent study with more structure and the opportunity for peer learning. This particular studio is appropriate for projects in the area of interactive art, programing, physical computing and digital fabrication. There are required weekly meetings to share project development and obtain critique. Students must devise and then complete their own weekly assignments updating the class wiki regularly. They also must present to the class every few weeks. When topics of general interest emerge, a member of the class or the instructor takes class time to cover them in depth. The rest of the meeting time is spent in breakout sessions with students working individually or in groups of students working on related projects.

Timeout update

Last time I wrote about Timeout, it was called Time Out! and it was only a wireframe. Since then, I showcased a half-working prototype at the 2014 ITP Spring Show, and had largely given up development due to my inability to overcome the challenge of reliably locking down an Android device, regardless of make, model, or version.

Then, two weeks ago, I stumbled on the Android Device Administration API. I have no clue how I missed this during my months of research but clearly I was making things way too hard for myself. In an attempt to mimic apps like Toddler Lock that prevent you from leaving the app, I had overlooked the fact that you could simply force the device to lock, and force it to lock immediately on unlock, ad infinitum, using a built-in Android feature that didn't require anything from the user besides activating device administration through one additional dialogue.

I got busy and, sure enough, it worked. In fact it works all the way back to Android 2.2, which is even more ideal, since that was the oldest version I had planned on supporting.

Today I finished development, and Timeout is now available on Google Play. Thank you to all of my classmates in Always On, Always Connected for sitting through various iterations of the early app, as well as Shawn Van Every his knowledge and support.

Solar challenge

For the Solar Challenge I created a prototype of a prototype - a data logger that records the ambient noise level (in volts) wherever it's located.

The project consists of the following elements:

• Solar panel
• LiIon battery (3.7V 2500mAh)
• LiIon/LiPoly USB charger
• Arduino Uno
• Sparkfun microSD shield
• 8GB microSD card
• Various USB adapters

I am getting upwards of 8V from the solar panel in moderate sun. The entire system seems to only be drawing around 40mA. I suspect this is because the Arduino Uno draws about 40mA and the microSD shield draws a negligible amount in comparison.

Testing the panel + battery + charger 

Close-up of microSD shield 

Panel in a bag for weather protection

Action shot - on window ledge gathering sun + data

Consolidated package using found surveillance mount

Data is written to the microSD card every 200ms - a timestamp of milliseconds since startup and a reading from the electret microphone in volts. My latest test was foiled because the microSD card got wet and stopped logging shortly after startup, but I was able to get a solid chunk of real data last week and this is presented below.

Final project: Empathemes

Download here: Empathemes (unpacked)

My final project is Empathemes, a Chrome extension which changes the color scheme of the current web page based on the most prominent emotion detected in the textual content. My goal was to subliminally induce a higher level of empathy with any content a user views, without any extra action needed to be taken by the user.

I took interpretations of colors and their meanings and combined them with word counting and scoring techniques to produce a short script that calculates the most significant emotion.  The emotions currently available are Love, Fear, Grief, Anger, Anxiety, Surprise, and Trust.

I created lexicons for each of this emotions.  Each lexicon has three levels of significance, and a word in each level will score either 3, 2, or 1 point(s) on a "hit", depending on the priority given to that level. This way, the algorithm more accurately assesses vaguely emotional content. This is the current lexicon for Anger. The words in the first array are weighted more heavily than those in the third array because they are stronger.

anger[0] = ["anger","angry","fury","acrimon","affront","belligerent","bitter","enrag","fuming","furious","heated","incensed","infuriat","intens","outrage","provok","provoc","seeth","storming","truculen","venge","vindictive"];

anger[1] = ["violen","outrage","hatred","enmity","aggravat","annoy","antagoni","crabby","cranky","exasperat","fuming","grouch","hostil","ill-tempered","indigna","irate","irritat","offend","resent","sore","spite","testy","ticked off"];

anger[2] = ["displeas","bugged","chagrin","dismay","galled","grim","impatien"," irk","petulan","sullen","uptight"];

After scoring, the page is styled only if the highest emotion score is 15% greater than any of the other emotion scores. This is to prevent styling for all-zero score cases, or cases in which there isn't a clear winner.

Here are some examples of pages styled according to the emotion of the content:

Final project proposal: Sonome

Sonome (Solar-powered Noise Measurement) is the tentative name of my final project for Energy. It will be another iteration on my project for the solar challenge, but in an extremely compact, low profile, wireless form.

Tagline: Wireless, self-powered noise level analysis tool!

I want to use this module in a larger project. Having accurate (even real time) measurements of noise levels in New York or any other city is something that most people would find useful when searching for housing or even just a quiet place to relax. Unfortunately, there is no way to get this data besides putting a bunch of loggers out into the world.

Sonome would help get this going by creating an all-in-one module that could be easily deployed anywhere in the city. The main problem is getting live data. Even with a WiFi shield (which seems prohibitively expensive for mass production), the placement of the module then depends on the availability of WiFi networks in that area.

There is no GPRS shield for the TinyDuino; however, GPRS may be the only way to truly untether these modules from any sort of location restrictions.

Bill of Materials (tentative)
Component	Price
Polymer Lithium Ion Battery - 400 mAh	$7.95
Mini Solar Panel Module - 0.5W, 5V	$2.13
TinyDuino Processor Board	$20.95
TinyShield microSD	$14.95
TinyShield WiFi	$59.95
Total:	$45.98

• Week 7
• Decide on components
• Week 8
• Order components
• Diagram components and data flow
• Week 9
• Build prototype
• Week 10
• Test prototype
• Week 11
• Test prototype
• Week 12
• Rebuild prototype if necessary