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.