weblog-live

My LAN has a Clock Tower

2013-02-24

This post is part of a continuing series of posts for my masters thesis project, Brooklyn Net, a wireless rooftop network that aims to connect artists and neighbors without using the Internet. The last post discussed possible rooftops for the network. This post discusses the technical network details.

Last week, my friend Glen helped me directly connect my home in Brooklyn with a clock tower in Queens using WiFi. The link was the result of about a month of work and a few failed attempts. Not only was this good practice for me, but we also now have remote connectivity to the IP camera we placed in the clock tower to observe CJ’s installation in the clock tower to see if it needs repairs.

Clock tower network technical setup

We used two NanoStation M2s running the default AirOS firmware with connected to each other in bridge mode. Working with the bridged NanoStations was analogous to my experience working with ZigBees, which added transparent wireless links to digital circuits, passing electrical signals through as though both ends were physically connected.

Behind the scenes, a virtual network interface is created on the NanoStation that links the LAN and WLAN (wireless LAN) physical interfaces. The protocols that run on the network, such as the Address Resolution Protocol, have their discovery packets forwarded and emulated by the NanoStations on either end, acting as transparent middlemen if the destination happens to be on the other side of the network.

We reduced the frequency of the 802.11 signal from 20 MHz to 5 MHz, lowering maximum link throughput (less oscillations mean fewer encoded bits) but boosting the signal to ensure that data travels reliably (same amount of energy powering the radio, so higher amplitude for the signal).

Bridging the clock tower LAN with my home LAN meant that two DHCP (Dynamic Host Configuration Protocol) servers were running on the shared LAN. DHCP servers provide IP addresses to devices connecting to the LAN, and typically each LAN has only one. Our fix for the colliding DHCP service was to block DHCP messages from crossing the wireless link using a firewall and to give each DHCP server different address ranges to ensure they do not assign the same IP to two devices.

One snag we had with the setup was the PoE injector for the NanoStation M2. It turns out that Ubiquiti has a variety of PoE injectors that all look the same, but with different output voltages for different pieces of hardware.

Brooklyn Net topology

Completing the clock tower link got me thinking about the implementation details of Brooklyn Net. Bridging LANs is a simple application of wireless technology, now I need to think deeper, about precisely how the locations of Brooklyn Net will talk with each other; what equipment they need and what protocols they will run.

A visual interpretation of the Internet (source)

The topology of the Internet topology is something like a hierarchical tree structure of nodes (e.g., computers and network equipment). This structure scales well because the average number of hops packets needed to travel in order to reach their destination is reduced by having a edge nodes (e.g., your home Internet connection) reasonably close to the highly connected nodes of the backbone at the top of the tree.

In contrast, networks with a mesh topology are non-hierarchical and connected without an explicit child-parent relationship. Packets on the network are passed from node to node to reach their destination, and mesh protocols are constantly trying to determine the best path between nodes behind the scenes. A positive side-effect of this is mesh networks are “self-healing”, meaning that if a node disappears from the network, packets relayed on that node will be dynamically given a new route around the missing node. Or, if a new node is added, it will automatically be discovered.

In theory, no node in a random mesh deployment is any more important than any other node, but in reality that is not the case. There will be a number of very important nodes in Brooklyn Net: those that are geographically central and those that are highly connected to other nodes. In the beginning, each node in the network will be important, but, in the future, creating redundant links in the network will be important for network resiliency.

Present day mesh network technology is fairly advanced. Physically deploying a mesh network is easy for a technical end user: buy a few consumer routers, load them with mesh firmware, and place them in places close enough for their wireless signals to overlap. The routers are then mesh peers and computers on each of the routers can connect to each other over the mesh.

It’s important to think about what Brooklyn Net could become. If it were to grow outside of Brooklyn, then it would be a “last mile” subnetwork of a larger network, like the Internet. A couple of network nodes on Brooklyn Net will be gateways to the larger infrastructure, funneling network traffic from and to terminating nodes in Brooklyn. The larger network must be hierarchical to scale effectively, ensuring less hops across longer distances. A disproportionate number of hops may happen within Brooklyn Net, but network speed shouldn’t be too hampered.

Brooklyn Net will use a mesh network. I am going down the avenue of mesh networks despite the announcement of DarkNetPlan on Reddit last year and the valuable criticism it received. Mesh networks don’t scale very well and tend to cause management headaches for network operators. The lesson from this article is that it’s important to not commit to a particular network topology, but instead use the best choice for the occasion. The goal for the remainder of my thesis is to deploy Brooklyn Net rapidly and that is why choosing a mesh topology is appropriate for now.

Testing out a batman-adv mesh

I’ve worked with the Commotion firmware which employs the OLSR mesh routing protocol. I was suggested to play with the batman-adv protocol, which operates on layer 2 of OSI model and makes the whole network seem like a big network switch (with some magic under the hood). I’ve played with batman-adv before and it was fun to revisit.

I set up a test network on my studio tables in a configuration similar to what I could imagine the first links in Brooklyn Net to be. I wanted to make sure that nodes on either end of the network could talk to each other through the middleman node.

The black Netgear WNDR3700v2 routers acted as the WLAN providers that end users on Brooklyn Net will connect to, and the white NanoStation M2s acted as wireless network links that connect remote Brooklyn Net locations.

Indeed, by setting up the OpenWrt firmware and following batman-adv the instructions on all the devices, the network was fully connected, as shown in the visual diagnostic tool.

Refocusing on the main goal

This week I dove deep into the network hardware and topology. Not only did I get hands-on experience with networks, I learned about cool features that could push the limits of the network infrastructure.

However, my thesis goal is to create applications for local networks. It’s important for me to focus on creating a network infrastructure that is reliable and manageable without getting caught up in features that don’t benefit applications.

My main focus is to get the network in the hands of the people. Once it’s there, an honest conversation can begin about applications and end user experience.

Rooftop Tour of Brooklyn

2013-02-18

This past weekend I embarked on a rooftop tour of North Brooklyn and Long Island City. (It was one of the coldest and windiest weekends of the winter. Brr!) It was good to scout how precisely the network could be laid out and to engage potential network hosts about the idea to generate some interest and feedback.

Many thanks to Mark Krawczuk for facilitating some of the meetings and encouraging the tour.

Proposed network map

I’ve been thinking that creating network links between art institutions such as Silent Barn, Flux Factory, and 319 Scholes is a good way to start. These spaces are well-established and could be home to the first real users of the network. I could imagine a simple video booth between spaces being a first application of the network.

Other network design considerations include ease of access, network redunancy, application ideas that require certain spaces to be connected, and how they connect to me — because it’s important for me to experience the network as the initial designer.

The map is rather optimistic and likely a subset of the locations will be connected by my project presentation at ITP and Bushwick Open Studios.

Rooftop views

Creating a roofnet has many challenges, one of which is getting up onto roofs! Lucky for me, I have friends with roofs that graciously have given me access, and friends who want to help the project who have friends with roofs.

Trying to understand the neighborhood layout by rooftop was as unexpected challenge. I have experienced North Brooklyn in many modes. First by the subway, then by bicycle, then by walking. Each mode provides a new experience of the neighborhood, the amount of detail perceived inversely correlated to the speed of the mode. A place that is so familiar on the street can be so foreign viewing it from far away.

Here are selected photos from my rooftop tour of Brooklyn. (Roll over images for annotations.)

The key rooftop I visited was at 56 Jefferson St (location 1 on the network map) in Bushwick. This building is one of the tallest buildings in the neighborhood and overlooks most of the East Williamsburg Industrial Zone, as shown in the picture above.

As a fortunate coincidence, many of the buildings that I’d like to connect to the network lie in a straight line from this building, including 250 Moore St, Kitchen Table Coders, and the Queens Plaza Clock Tower, requiring only one antenna to reach all of them.

319 Scholes, rooftop view pictured above, will be a spiritual hub for the network, with possible special events for the network being facilitated by the space. It has a clear view of the Kitchen Table Coders loft space.

This rooftop view is from 566 Johnson Ave, home to the Active Space, a artist building and gallery that I rent a studio in. Connecting this building to 319 Scholes will connect a number of artists in the area away from the main thoroughfare of the network.

This rooftop view from the ITP House is courtesy of my classmate Nick Johnson. His thesis proposal is for an emergency SMS distribution system using a GSM network he is creating. His system could be aided by a backbone network that I could provide for him. Working with Nick on a similar timeframe would be nice to provide an application on the network. However, the location is rather far away from the core of the network and it doesn’t look like there will be a way to connect ITP House to the network

Moving forward

With an understanding of how the network can be created, I can now focus on the user, host, developer, and network operator experiences of how the network will be interacted with, maintained, developed, and setup. My next step is to create prototypes of the physical and coded product to be deployed in the mapped out locations.

Do-It-Yourself Wireless

2013-02-12

This entry is cross-posted between my personal blog and the ITP thesis blog. It was written as a research findings piece to accompany my graduate thesis project, a mesh network in Brooklyn.

There are a few networks in the DIY network community that are very well-regarded. There’s Freifunk in Germany, Funkfeuer in Austria, Athens Metropolitan Wireless Network in Greece, and, the most well-regarded of them all, guifi.net in Catalonia.

Success in Spain

Guifi.net was covered extensively in this month’s newsletter entitled “Why Have a Network in the First Place?” produced by The COOK Report on Internet Protocol. The newsletter is a monthly industry publication put out by Gordon Cook, a global telecommunications reporter and critic who covers global Internet affairs that typically involve government and business. The piece chronicles the method, philosophy, growth, impetus, and economics of guifi.net.

The network was started outside of Barcelona in the Catalonian countryside. Ramon Roca, whose interview is largely the content of the piece, recounts the early 2000s and his need of a broadband Internet connection in order to feasibly do his work as an employee of Oracle from home, as well as to partake in his computer hobbies. His only option at the time was to travel to Barcelona, which was over an hour away.

In the early days of guifi.net, the Roca and his guifi.net friends focused on interconnecting the local neighborhood with wireless connections. He relied on making connections with other like-minded geeks, offering his assistance as much as possible to foster a community-led effort of interconnectivity. Later, he found it important to make friends with local passionate municipal officials and Roman Catholic bishops who, despite the network being non-secular, found the project good for the community. Guifi.net was given free access to high vantage points on church steeples to mount networking equipment and further their wireless reach.

In the present day, guifi.net has scaled to a point where they are able to pool community resources to lay fiberoptic network cable throughout the countryside to connect households to the Internet with a gigabit connection. This demand-driven model ensures that connectivity happens where it is desired. Most of what the enduser pays is a one-time equipment and setup fee, and a competitive monthly fee to an ISP that connects them to the Internet via the guifi.net network.

Instead of phrasing guifi.net as “fiber to the home”, implying that the home is the last and least important connection, they brand the network as “fiber from the farm” or “bottom-up broadband”, implying those connections are the most important components of the network.

In his interview, Roca outlines an argument as to why the major Spanish telecommunications provider, Telefonica, has no economic interest in expanding broadband access to the Catalonian countryside and the gross inefficiencies of municipal incentive-based models to spur private development. Telefonica, once the Spanish public telecommunications monopoly, was sold off over a decade ago, “given” to one of the then prime ministers' friends and has remained closely tied to the ruling elite. The goal of the company no longer is to provide telecommunications to the people, but to accomplish fiduciary duty and maximize shareholder value. Because of this, the success and rise of competition by guifi.net has not been publicly celebrated in Spain, however it has been embraced as a success by the European Union in programs that actively encourage community-based innovation.

The economic model that Telefonica employs as a private company (image from The COOK Report)

Roca is very passionate and deliberate about how the network is managed and used. The guifi.net network was created as a commons, meaning “a resource that is owned in common or shared between or among communities”; forests, atmosphere, rivers, fisheries are all examples of commons. The users of the network must agree to the service-level agreement to allow “open peering”, which guarantees free transit through the network and, in short, upholds the spirit of the commons. The organization, guifi.net, is a non-profit and the founding members of guifi.net are the board members, which forbids them to be paid by the organization according to Spanish law. It also appears that they have a legal structure that is more protected against aggressive takeover tactics from private for-profit companies, like Telefonica.

The economic model of guifi.net (image from The COOK Report)

The lack of innovation and expansion, the need for connectivity at a municipal level, and the present-day reduced cost of networking equipment have led to the success of guifi.net.

Back to America

There are parallels between American network duopoly of Comcast and Time Warner and Spain and Telefonica. It’s unclear from the piece at what point guifi.net transitioned from solely connecting people locally and turned into a project that connected people to the Internet. Certainly guifi.net is a noble project and competition in New York City for Internet connectivity does not properly exist, but creating an alternative ISP is well beyond the scope of my thesis. Creating a network that is sufficiently reliable for residents to eventually receive Internet access from an ISP, however, is something that can certainly be strived for. Indeed, perhaps this is how this project can be part of the disruption in the American telecommunications industry that Susan Crawford in her book Captive Audience is calling for.

In the meantime, and in my original interest-space, my thesis will focus on the end user experience on local networks, specifically with the network I will create in Bushwick. The leaders in the community wireless movement in America, such as the Free Network Foundation, the Open Technology Initiative, Allied Media Projects, and the Project Byzantium, all focus on hardware, firmware, digital divide, and disaster scenarios. The missing component, however, is the day-to-day application. What can local networks do for us that the Internet can’t?

Answering this question and the journey to it, I believe, is a key piece to popularizing community networks so they gain a critical mass of users for alternative ISPs to make economic sense. Broadband access in cities is not an immediate issue unlike rural areas. Cities, however, are full of early adopters of new technology who could be the incentivized through a novel user experience and applications to try the network and help build out the inexpensive wireless network. Then, creating a replicable stack of software for local networks could help other independent networks across North America gain traction in a way that European networks have.

What Brooklyn Has

In the same way that Roca was a member of local “geeks” who wanted to start guifi.net, there is a talented set of geeks who are willing and able to start a new alternative network in Brooklyn.

For builders of the network, there is Glen Duncan, HAM operator and founder of NYC Meshnet, a movement of hobbyists and professionals who aim to create a decentralized network across New York City. There is Sean Auriti from Alpha One Labs who hosts the NYC Meshnet meetup in the A1 hackerspace.

From the art and technology creative applications perspective, there’s Dan Phiffer who created Occupy.here, a decentralized message board hosted on network router access points across New York City. There’s Sarah Grant who is creating local applications for businesses. There’s Mark Krawczuk who created the L Train Notwork to connect commuters on the L train with Brooklyn artists, like writer Robin Grearson who saw the L Train Notwork as an interesting new medium to present her work.

From the social justice perspective, there is the Red Hook Initiative whose efforts, led by Tony Schloss and Jonathan Baldwin, created a wireless network in Red Hook to provide local services to document stop and frisk procedures in the neighborhood. With Hurricane Sandy, the network was repurposed to provide free Internet access to the residents of Red Hook as all of the utilities were not restored in the neighborhood until nearly a month later. Work done by Occupy Sandy in the Rockaways could also include network projects in the future.

Brooklyn has a unique mix of communities focused on creativity and expression through arts, technology, and social justice. Indeed, perhaps this is the proper place to create the local applications that I posited are very important for alternative networks to grow. Working with these people will be key to creating a successful movement.

Progress

As for my progress, I’ve determined that making connections with people who are interested in hosting network nodes will be the best thing I can do right now. Building out the network as quickly as I can is the next best move. I am well-positioned on both of those fronts. With the network built, I can start testing applications and attract people to it so they can try their applications on it using a call for proposals method via 319 Scholes. The big unveil of the network, besides the presentation of my thesis, will be at Bushwick Open Studios.

The network I create with my thesis will be licensed with the same network commons stipulations that guifi.net came with. This idea is rather utopian, but my feeling is that it will be a welcome change to the target audience of the Bushwick network. The Free Network Foundation is developing a “network compact” that mirrors the guifi.net service license agreement that I will adopt and enforce.

The conversation of the network commons made me wonder what the application equivalent of the commons is. The answer for the global scale so far appears to be Wikipedia and Reddit, websites that are made up of entirely community submitted content. OurGoods, meanwhile, is a service for connecting people who can help each other with their wants and needs, typically a local connection. EveryBlock was a local news website that aggregated local news stories and public announcements for their readers. EveryBlock was shuttered this past week by its parent company, NBC, but I will miss the service and so will others.

Roca mentioned in his interview that a key to their success with clients was to provide “a quick win [for local residents] in a short time.” The repercussions of a long wait for connection was discouragement amongst the community members. The quick timeframe of the thesis forces this project to be created rapidly.

Building a Modular Light Installation

2012-11-19

Reid and I built our largest light installation yet last month called Public Constructions. I want to explain a few early design decisions that made the project a huge success for us.

Reid is always talking about how he can modularize his life — he is especially proud of his stackable milk crate shelves at our work studio and his bedframe at home made from pipes (via Lady Ada). His influence made us collectively think about all the ways the project could be modularized, and, in the end, designing for modularity is what made the project work.

Modular decision #1: Breaking it down

This is the biggest installation we’ve ever made. Spanning 30 feet across and weighing over 600 lbs, Public Constructions had to fit in the cargo van we rented and be driven from our studio in Brooklyn to DLECTRICITY in Detroit. Everything — the frame, the ballast, the flower stems, the lights, the cabling — was designed to break down and disconnect from each other. Reid even used parts of the sculpture frame (2x4s) to create a false floor in the van to ease the packing process.

Modular decision #2: Visualizing the installation

As with most art projects I’ve worked on, Public Constructions came together in the last few moments and never really had a full run-through before it was installed. That didn’t really worry us, however, because I designed a 3D sketch of the installation written in OpenFrameworks that talks with the light sequencer the same way the sequencer talks with the installation software. (UDP client-server decoupling.) This allowed us to see what the installation looked like in advance and gave us confidence in our setup.

Modular decision #3: Reliablity and control

As I was researching how to design a custom lighting system that kept us within budget, I realized I could make a BeagleBone sequence the whole installation by talking DMX with tried-and-tested, high-amperage, opto-isolated DMX LED light controllers. The DMX interface in the BeagleBone was coded in assembly language, but living in assembly is no fun at all. I found a way to sequence the light values in python and pass them to the assembly code (see here). Choosing highly reliable software and electronics systems and making them work together resulted in an effortless system that never failed.

Keep it modular

The way Reid and I work is modular. We’ve worked together long enough to know how to plug in our individual abilities to design and create the whole installation. In some ways, we are able to replace each other when the other is busy with another task. I foresee a lot of modularity in my future work with him. Modular4LYFE.

Hacking FEMA

2012-11-10

More than a week after Hurricane Sandy, the hardest-hit New York City neighbourhoods are now in full recovery mode. Houses need to be gutted, mold needs to be prevented, and businesses need to be rebuilt. People need money really bad.

There are lots of opportunities for recovery hacking in post-Sandy New York. I like to get out in the neighbourhood to help, so I found the following advertisement from Jessica Lawrence very appealing: REGISTER TO HELP WITH PUBLIC WIFI PROJECT – In the coming days, we may be called to support a significant public wifi setup project in partnership with the Information Technology Disaster Resource Center.

After filling out volunteer forms and an introductory conference call, I volunteered to spend a Friday with the Information Technology Disaster Resource Center (ITDRC), a 501(c)3 non-profit founded in 2009 and operated by volunteers. I met the core of the ITDRC team, Joe and Debbie Hillis, at the IKEA in Red Hook, Brooklyn. They secured a location at IKEA to set up public WiFi networks, computers with Internet access, and SIP phones for the purpose of recovery. My job was to help set up the computers.

Joe and Debbie drove up from Fort Worth, Texas to volunteer their recovery services to the Sandy victims. The Hillis' didn’t drive to New York in a car, they drove in a custom bus they purchased from a fire department in Florida. The bus was converted into a tactical disaster response unit fully-equipped with five built-in computer workstations, a dozen CB radios, a server rack, and enough storage space to lug around equipment so they can quickly deploy temporary IT stations.

The Hillis' are amazing and humble people, devoted to helping others through technology in very direct ways. They arrived right after the hurricane and expect to stay in New York through Thanksgiving, if not Christmas. They have been sleeping on the floor of their bus and work on this relief project full time. They are constantly talking with their colleagues on other New York sites and from across North America, coordinating remote efforts to configure their systems on the ground. They also are well-connected with other efforts on the ground in New York and try to find ways to help each other out.

(Please vote for the ITDRC to give them a chance to win $5000 worth of fuel.)

The interior of the bus was incredible. Debbie proudly explained to me that the space was designed not only for working, but to prevent thefts, to be easily cleaned after 16 hour work days, and to balance the functional and storage space.

Most of my day was about hacking FEMA (for the better). We were situated in a temporary FEMA centre where disaster victims could speak to FEMA agents to apply for financial assistance. The terminals we set up in IKEA were there to give people a chance to find support by themselves and to use the option of applying online rather than waiting in line or on the phone for the next available agent. On top of that, ITDRC provided something that FEMA did not have onsite that day: an IT support team.

The environment was a strange mixture of tension, grief, and excitement. At one point I was trying to fix a FEMA agent’s computer as I sat across from a lady with tears streaming down her face, speaking on the phone in Spanish, who had clearly lost everything. Tragic.

The day was incredibly inspiring. I plan on going back to work another full day next week, and to help with other projects the ITDRC have up their sleeve. I hope you consider volunteering as well!

Adding Light to Dark Manhattan

2012-11-01

(Edited by Michelle Frank)

A few days had passed since Hurricane Sandy came through New York City and all of Lower Manhattan was still without power. I joined my friends CJ and Enki in Chinatown to see what darkness was like, and then to add our own light… with projectors. There aren’t many opportunities to do this kind of thing in Manhattan, normally so brightly lit. On Halloween night, I left Brooklyn for the first time since the storm.

Dark started at the halfway point of Williamsburg Bridge. From Brooklyn to the apex, bright lights, and then, there was nothing but a few headlamps of pedestrians and cyclists making their way toward Manhattan. As I crossed the mid-point of the bridge and stepped into the darkness, I felt suddenly as if the extra lights I wore for safety might be ruining a special moment.

In the Manhattan streets, most illumination came from cars' directional highbeams. That and the constant parade of cops with their flashing lights, although there was no real emergency. A Chinatown firehouse poured light into the streets with an intense, portable bulb. The sound of generators was everywhere, and crude advertisements directed people toward the few bars that were still open.

(Photos taken by Enki and myself)

We hopped cabs to four separate spots, trying to find places to project for the Halloween revelers in the streets. Enki found a blank white billboard at the corner of Houston and Allen that really lit up. That caught a lot of attention. There, people out and about took photos and asked us what we were up to. They shared their own stories of traveling through the dark city and told us they appreciated what we were doing.

One skateboarder stopped and showed me a couple of photos he had taken that day. The first was an image of heavy foot traffic crossing the Queensboro Bridge. He also showed me hundreds of people waiting for the city buses to take them from across the water and into Manhattan. He was so compelled to by the darkness emanating to the south that he had to venture down.

CJ and Enki were the projectionists of the night. CJ used a simple set of high-contrast images that were both jovial and political in nature. His bat signal was the most popular, and I’m a little disappointed no costumed Batman appeared to heed his call (although one un-costumed Batman did volunteer his services!). Enki, a photographer, broadcast an interesting photo of a mushroom. As the night progressed, the mushroom got dressed up and changed into a spinning jack-o-lantern!

Four hours later, our night finished without interference from civilians or police. The only thing that could have made it better would have been a hot cup of coffee to warm up!

Lunch Beat Light Painting

2012-09-20

My good friend Sarah Reynolds put together the third ever Lunch Beat LIC party this afternoon. I’ve been to every single one so far and they’ve all been a blast: food, nice people, and fun dancing. I really like the concept, too, on how it subverts New York lunch culture of eating quickly and running back to your desk to continue working.

This time, Sarah invited Reid and I to bring the Rainbow Machine to do a little light painting. There wasn’t enough space for our typical full setup, so instead we brought a mobile version like the one I made this summer.

Like the last mechanism, this is just a thin piece of wood with LPD8806 RGB strip, an Arduino, and a 9V battery. The only difference is that we used two handles (made from bolts) instead of one. The space we were in* was too small to twirl the stick around (like this).

At first, I viewed putting two handles on the stick as a negative constraint. The one handle mechanism provided one degree of freedom to the light painter: twirl the stick, damnit!

But upon further thought, I became excited to try the second handle. Two handles would allow the painter to dance with the stick, to create abstract shapes that would bend and weave.

Here are the best photos from today!

BeagleBone outputting DMX

2012-08-22

Last weekend I started playing with the BeagleBone PRU and ended my post by saying that my goal with this powerful chip was to make the BeagleBone bitbang the DMX protocol.

Well it’s been 10 days or so and I’ve done it! Here is a quick video to show the setup in action.

I’m off to Europe for the next month to participate in Interactivos?. After I’m back I’ll package and release the code so I’m not the only one with these powers. I’ll be using this code for my light installation with Reid at Detroit’s DLECTRICITY light festival.

dantheman suggested what I’m doing is a little overkill. He thinks future implementations should use serial libraries and system interrupts instead of dedicating a co-processor to bitbang DMX, like this Arduino implementation. This could be the right approach to Raspberry Pi users who want to output DMX.

First steps with the BeagleBone PRU

2012-08-12

The goal of this post is to rehash the lessons I learned with my first steps working with the BeagleBone’s pretty awesome Programmable Real-time Unit (PRU — also refered to as the Programmable Real-time Unit Subsystem, PRUSS). Prior to this post, I looked up conversations on the BeagleBoard Google Group and AM335x discussion boards and patched together what I needed to know in order to successfully compile, assemble, and run code to blink the onboard BeagleBone LEDs via the PRU.

Getting started

The BeagleBoard team released a nice package to develop code to run on the BeagleBone’s PRU. There isn’t much documentation on what to do with this package when you get it, but here’s what I did that worked.

First, SSH into your BeagleBone.

root@beaglebone:/tmp# git clone git://github.com/beagleboard/am335x_pru_package.git
Cloning into 'am335x_pru_package'...
...
root@beaglebone:/tmp# cd am335x_pru_package/pru_sw/app_loader/interface
root@beaglebone:/tmp/am335x_pru_package/pru_sw/app_loader/interface# make CROSS_COMPILE="" # we're compiling right on the system, so no need to cross compile
...
root@beaglebone:/tmp/am335x_pru_package/pru_sw/app_loader/interface# cd ../../utils/pasm_source
root@beaglebone:/tmp/am335x_pru_package/pru_sw/utils/pasm_source# ./linuxbuild
root@beaglebone:/tmp/am335x_pru_package/pru_sw/utils/pasm_source# cd ../../example_apps
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps# make CROSS_COMPILE=""
...
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps# cd bin
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps/bin# modprobe uio_pruss # so very important, load the kernel module or else  the code will fail
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps/bin# ./PRU_memAccessPRUDataRam # one of the examples provided by Beagle / TI
INFO: Starting PRU_memAccessPRUDataRam example.
AM33XX
        INFO: Initializing example.
        INFO: Executing example.
File ./PRU_memAccessPRUDataRam.bin open passed
        INFO: Waiting for HALT command.
        INFO: PRU completed transfer.
INFO: Example executed succesfully.
root@beaglebone:/tmp/am335x_pru_package/pru_sw/example_apps/bin#

Reminder #1: always run modprobe uio_pruss before running any code for the PRU! You only need to do it once per bootup. If you search the Google Groups BeagleBoard list you’ll notice many people forgetting this step. I asked for help on IRC (#beagle on freenode) and received the same response.

Go ahead and check out how the examples works, they’re pretty illustrative. Basically there’s a C program for each example that uses the prussdrv library to expose functions to load the PRU with code, memory map the PRU’s RAM, and elegantly complete the PRU’s execution. The *.p file is AM335x assembly and runs directly on the PRU.

AM335x PRU assembly, in my limited experience, is pretty friendly. Check out the AM335x PRU reference guide (PDF). The thing I liked the most is found on page 22, where it describes the Execution Model of the architecture: “Pipelining: None (Purposefully)”. This simplifies the process of writing assembly (for the journeyman assembly coder), meaning you don’t need to worry about operations taking more than one clock cycle for a result. There are 29 registers (r1-30) at your disposal, which is more than the 6 or so I had when I first learned assembly.

Making the PRU blink the BeagleBone

Now that we’ve got example code running on the PRU and hopefully have some idea of what it’s doing, it’s time to add a new PRU example app: blinking the BeagleBone’s LEDs. This was done by Lyren Brown in a buried post on the BeagleBoard’s mailing list. I’ve reposted the code here.

#define GPIO1 0x4804c000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194
    MOV r1, 10
BLINK:
    MOV r2, 7<<22
    MOV r3, GPIO1 | GPIO_SETDATAOUT
    SBBO r2, r3, 0, 4
    MOV r0, 0x00a00000
DELAY:
    SUB r0, r0, 1
    QBNE DELAY, r0, 0
    MOV r2, 7<<22
    MOV r3, GPIO1 | GPIO_CLEARDATAOUT
    SBBO r2, r3, 0, 4
    MOV r0, 0x00a00000
DELAY2:
    SUB r0, r0, 1
    QBNE DELAY2, r0, 0
    SUB r1, r1, 1
    QBNE BLINK, r1, 0

The code is illustrative on how to use the PRU to write to the BeagleBone’s pins. Lyren uses the address 0x4804c000 which refers to the memory space mapped to the GPIO1 registers (see Texas Instrument’s AM335x technical reference manual (PDF). Writing bits to the GPIO_CLEARDATAOUT and GPIO_SETDATAOUT registers sets the BeagleBone’s pins low and high respectively. In particular, writing 7<<22 to GPIO_SETDATAOUT sets the 22nd, 23rd, and 24th pins high (excercise to reader: why does it set all three pins high?), these pins being the LEDs on the BeagleBone. Very cool.

To write our LED blinking application, lets use Lyren’s code and make it work in the same way the examples are structured (a C harness file to load the PRU assembly above). We can take advantage of the Makefile structure the BeagleBoard people gave us in the am335x_pru_package by creating a new folder for the code in am335x_pru_package/pru_sw/example_apps and adding new lines to the am335x_pru_package/pru_sw/example_apps/DIRS files.

In the process of creating this app, I was tripped up by another common snag for a new AM335x PRU developer: clearing the STANDBY_INIT bit in the SYSCFG register.

Reminder #2: always make sure to clear the STANDBY_INIT bit in the SYSCFG register, otherwise the PRU will not be able to write outside the PRU memory space and to the BeagleBone’s pins. The following three lines at the top of a PRU assembly file will accomplish this.

LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4

Great! That’s basically it, with some handwaving on my part. Our blink application is complete. You can grab it from my github fork of am355x_pru_package.

Using the PRU as a realtime interface

My goal is to use the BeagleBone to directly output DMX, a fairly simple protocol developed in the 80s for controlling professional lighting systems and still in use today. I believe the PRU can easily send these data frames with low jitter. If implemented correctly, the BeagleBone then can become a start-to-finish controller and interface for DMX lighting systems, reducing complexity and cost.

To make this, the last thing I want to do is to write lots of assembly (especially without a debugger). My idea is to map the 8KB of PRU memory space to a user-space program to update lighting values and load the PRU with a program to constantly sending out the appropriate DMX with those lighting values.

Memory mapping the PRU memory space to the C harness program is easy thanks to the prussdrv lib and is illustrated in the PRU_memAccessPRUDataRam example (see all available functions on TI’s wiki).

My first step in exploring the PRU as a realtime interface was to use the C harness program to exchange data with the PRU to control the BeagleBone’s LEDs. The assembly I wrote has the PRU continually check the shared memory space to determine the desired state of the LEDs. Meanwhile, the C program running on the Bone’s CPU happily flips the bits of the shared memory on and off in a step sequence. I made this in an example called blinkslave, you can grab it on github and see in action below.

Toy Drum Machine

2012-07-31

Last weekend Reid and I joined forces to participate in the first Monthly Music Hackathon hosted by the dudes over at exfm.

Reid and I went with our laptops and a couple sacks full of electrical gear to add a MIDI interface and beat sequencer to one of Reid’s wonderful circuit bent creations, the child’s four-button drum toy pictured below.

I’ll spare the suspense, we were successful in adding the MIDI interface. After the hacking portion of the hackathon concluded, we had a performance and demo session to show everybody what else we made. Check out the following video.

We also have audio recorded from the drum machine’s lineout. It sounds completely different, probably because it’s just grabbing the raw signal and no reverb from the space.

Other cool stuff at the hackathon were HTML5/JavaScript apps to do realtime audio processing in your browser, an app to map one song’s timbre onto another song’s pitch (??? crazy stuff), and, my favourite, a web app that drops a beat on the Google translate robot voice rapping the words you type.

How it works

We used an Arduino microcontroller with a MIDI shield to act as a MIDI interface to the circuit bent toy. The toy has four samples, so we mapped C4 (middle C) to D#4 to trigger those samples. A non-zero velocity on the MIDI message turns the sample on, and a zero velocity turns the sample off.

Reid extended two leads from each (normally open) button of the toy drum. Once the leads touch each other (i.e., the button is depressed), the sample is triggered. So we used 2N3904 transistors to act as a digital switch controlled by the Arduino.

With the Arduino’s digital out connected to the base and each of the buttons' leads attached to the collector and emitter, we were able to trigger the toy drum samples when we sent HIGH (then LOW) to the transistor base from the Arduino.

We replicated this pattern for all four buttons, created a simple sequencer in MaxMSP, then plugged our laptop into the MIDI interface, and voila! sick beats and a child’s toy.

We had our hiccups along the way. Reid inserted a 1 Megaohm potentiometer somewhere in the circuit to speed up and slow down the internal clock on the toy drum. This feature works great in standalone mode, but the pot range was limited once we started sequencing. I can’t help but wonder if this is because of the extra volts sent from the Arduino to the toy drum via the transistor.

The nice thing about the pattern of using the Arduino and MIDI shield is that we were not reliant on the laptop to be our sequencer. In the end, that’s what we ended up using, but this device could be packaged up and controlled by using someone’s standalone sequencer.

Grab the code for the Arduino and MaxMSP sequencer used for this on Github.