OfBrooklyn.com

Recap and takeaways of the Micromobility panel at Moving the Future 2020

2020-02-06T04:20:00+00:00

I moderated a panel on micromobility at the annual Moving the Future Conference at Harvard Business School. I had the fortune of discussing this decade’s favorite topic with four heavyweights in the industry. We had the panel discussion on Groundhog Day, when Punxsutawney Phil saw no shadow and thereby predicted an early spring (ain’t that the truth),

We discussed the potential for micromobility, the cannibalization of walking and transit usage, aggregation of micromobility vehicles, and what the future of the vehicle looks like. Here’s all the good stuff and memorable lines from the 40 minute conversation.

The micromobility panel includes, in order from left to right:

Matt Warfield, a new mobility planner with the City of Boston Transportation Department
Tarani Duncan, a product strategist and advisor to pioneering autonomous micromobility company Tortoise and spatial analytics company Zoba
Assaf Biderman, CEO and founder of Superpedestrian, a robotics company building the next wave of intelligent and connected micromobility vehicles
Andrew Salzberg, former head of transportation policy and research at Uber and current Loeb fellow at the Graduate School of Design at Harvard
Samuel Clay, moderator and graduate student in design engineering

Do you see micromobility moving a meaningful chunk of drivers out of cars?

With cars, putting them on the road with phones was enough to create demand. But with bikes, putting thousands on the road doesn’t have the same effect because demand depends on the design of streets. Obvious to bike advocates but not so much to the rental fleet companies.
Operators are thought to posses all these tools to robustly calculate demand but that is not the case and this is a huge problem that needs to be solved. Spatial analytics are a huge part of making micromobility work as a tool for trip planning and that’s going to take time to build.
Multiple modalities is not a new solution to reducing vehicle miles traveled. Mass transit, from the bus, light rail, and subway, are really good at serving a certain portion of the trip demand, but what about people in the suburbs? Today you can only deploy where you can ensure demand, and that means downtowns and mainly where walking would have been the dominant mode. Mayors / city officials are saying that they’re not interested in micromobility for the less than 1 kilometer trips that saves rich people from walking. But now they’re working with operators to shape micromobility into the planning of the city and that’s a slow process.
The city of Boston currently has no e-scooter operators. And that’s because the city does not yet see the added benefit of scooters relative to their risk. Ideally, we are providing options for people to forgo car trips, however, it has been shown that e-scooters take away ridership from public transit, walking, and using bike share. There needs to be a connection at the end to public transit in order to justify itself and the city is not seeing that happen.
The city of Baltimore is starved for transportation options. Public transit is not necessarily reliable and not designed to move people through the city. Baltimore like many American cities is car centric. And even the bike share system in Baltimore wasn’t doing well. Bird then launched in the city and provided the impetus to come up with a policy to address micromobility. So the city of Baltimore shut down the shared docked bike system and ramped up the scooter pilot, which allowed the city to focus more on equity in terms of who was being served by each mode. This pilot was so successful due to the latent demand for transportation options.

Are micromobility operators doing enough to ensure a healthy future? Assuming micromobility continues growing at the rate it enjoys today, and with only so much walking it can cannibalize, what does transit ridership look like in the next few years?

Having top line growth be the only concern has been a recipe for conflict with cities. Cities are reluctant to let something like micromobility grow as fast as it wants to without knowing what the consequences are. If the focus shifts to better management of fleet effectiveness, for example with the help of autonomous scooter company Tortoise (and others like the autonomous bicycle company Weel), the dynamic would then improve between operators and cities.
And the recent change in tone of the VC market, specifically the tightening of belts, might hasten be a turning point for these micromobility businesses. Cities should take this opportunity seriously or it may go away before long.
Looking at Seleta Reynolds and LADOT’s Mobility Data Specification (MDS), there’s a big opportunity for cities. Here’s an API for the city to define geofencing rules and not have to provide enforcement themselves. Let the city decide where to park, what should be the speed limit, and have the city be responsible. And if they’re wrong, let them worry about it and make changes to fix it.
Micromobility has been a trojan horse for conversations about how we allocate public space and for what ridership privacy means for data collection.
So the future of operators in the physical realm will include partnerships with cities in the form of mobility hubs and protected bike lanes. But with data there’s contention because MDS is de-identified but never truly anonymized. That means that with research people can be individually located in a dataset based on a few observations. Should cities have access to data at this level? Probably not but neither should micromobility operators.
We’re also seeing profound implications on the routing network. The city of Los Angeles is telling mapping companies to exclude certain roads and areas from routing directions, which has network effects on the road network. We’re seeing cities reining control.
The city of D.C. will subsidize public bike share programs. In a V.C. funded world there’s an approach of one company winning above others, but that is challenging when you consider how cities should be operating their own transit system.
Operators don’t need individual routes in order to interface with their data. It’s not a take it or leave it situation. What cities really want is to know the capacity of each mode moving in the city and that can be managed without individually identifying users.
Important to watch not only how many cities take up MDS, but how many later shelve it.
Thinking about the city of Boston, there’s a lot of vehicles in the city that are sitting unused. And with e-scooters, we’re probably going to convince some people to drop their cars. But e-scooters will not necessarily replace car trips in general and the impact for a city like Boston will be fairly low. But I think it will create opportunities for cities to do better things than just store vehicles on the road.

Let’s go up the value chain and continue talking about data. We now have multiple aggregators of shared scooter/e-bike availability, fixing the problem of half a dozen apps on your phone. What is the role of the consumer interface for micromobility?

There’s this question of what is the most efficient use of vehicles. If you have multiple operators that don’t talk to each other, you end up with a surplus of vehicles, and this is due partially to the fact that we currently lack a way to connect operators together.
The conversation on data has mostly been about operator-to-regulator, in the form of MDS, but there’s also the importance of operator-to-consumer, in the form of how users access vehicles. There’s been a few dust-ups recently, one where Lyft shut down Transit’s access to unlocking its bikes and where Lime shut down Scooter Map’s access to vehicle locations.
This also becomes less of a question if competition goes away and there’s a single operator in a city, perhaps if the transit agency is running it. But if there is going to be a competitive market with multiple modes working together, then the question of how to integrate them and on what terms becomes important.
It’ll be a while before aggregators will be seen on the market, at least not until vehicles are an online asset in a massive sense, possibly with autonomy. But aggregation will really have an impact if the routing algorithms do a lot better job when travel time and vehicle miles traveled can be minimized, then we’ll have meaningful impact for operators.
Mobility-as-a-service (MaaS) has been such a buzz word but it’s not yet working. So aggregation of mobility platforms is a nice thought but if vehicles aren’t where you need them when you need them, then it doesn’t matter. The success of aggregators is less about displaying digital information and more about positioning the right vehicle at the right time. Similar to how a bus stop would be known to a potential customer, knowing that a vehicle is at or near a location when you need it is more important than seeing where they are now.
If you look at the trip origins for micromobility companies, customers aren’t looking in the app ahead of time. People see a vehicle and then they use it.

What does the future of the vehicle look like? There’s quite a few changes that have happened since the gen 1 scooters, and now gen 3 is deployed and we’re talking about gen 4 and its cognitive abilities. What does adding onboard intelligence imply and what does that opportunity look like?

If you look at the industry today, there’s no gen 1, gen 2, or gen 3s. They are all gen 1. Scooters today are basically technology from the 70s, with their extruded aluminum and L shapes. Micromobility will have many different shapes depending on the distance and the task and also on the shape of the city. Mechanical improvements take you only so far.
For personal vehicles, you’re going to take care of it to a certain extent. If the brakes are not working, you’re going to take it into service. You’re going to ensure the battery is charged. Once you deploy vehicles in the streets, that equation is broken because you’ll need as many caretakers as riders. It doesn’t scale up. At the same time, you have a much higher utilization of the asset.
So the only way to take care of the problem is to automate inspection and have the service quality be a lot higher. So the vehicle needs to be able to ask itself before every ride: am I safe to ride? are the battery cells all connected? am I in the right temperature range? are the brakes working? If the vehicle can do that, and our vehicles do that, that’s when we’ll see higher safety levels and lower costs. Otherwise we won’t be able to make money on this and companies won’t be able to survive.
There’s a classic mistake in transportation which is over-capitalization and lack of investment in maintaining what we’ve built. We can see that in the $5 billion invested into micromobility to date. Sensors, telematics, and maintenance data that you can grab from the vehicle remotely is all interesting.
The push ahead of autonomy is about generating a return for a vehicle even with all of its wear parts. Those wear parts, such as brake pads or a bell or a light, are designed for ease of maintenance. And a big problem area is simply getting the earned revenue to be more than the cost to buy it and maintain it.
My concern with telematics is that if we are going to place vehicles in the field, we’re responsible for those vehicles. And we have a lot more R&D to do in creating a safe vehicle that can last a long time and is easily maintainable by trained employees.
Telematics is too little too late. Knowing that a vehicle is broken somewhere in the field is not as good as preventative measures to protect itself in real-time. We’ve been able to deploy automation that prevents fires.
But vehicles fail more often than you realize. And if you’re next to a car and your vehicle is not stable, this is a major safety concern. And then cost follows, whereas when 20% of vehicles failing switches to 5%, it changes your model completely.

Thanks to our four panelists and to Horace Dediu and Chase Stubblefield for keynoting the conference. You can follow each of us on Twitter to stay up to date on micromobility news and opinion: @TaraniDuncan, @andrewsalzberg, @superpedstrian, @chasestubb, @asymco, and @samuelclay.

The New Garden of the World — Review of The Machine in the Garden

2019-08-07T04:20:00+00:00

The Machine in the Garden, written in 1964 by Leo Marx, explores the relationship between the pastoral ideal and the industrial progress that ostensibly is in opposition to that ideal. This book is not necessarily a literature review, although it enlists a half dozen full-length writings to understand the cultural symbols that encode the interplay between imagination and reality.

The urge to idealize a simple, rural environment is strong throughout the two centuries of progress that mark the industrialization of the United States from the American Revolution through until the end of World War II.

The literature that Marx introduces to illustrate the division between the two realms are masterworks that also serve as products of their times. Moby Dick by Herman Melville, Walden by Henry David Thoreau, The Tempest by William Shakespeare, Adventures of Huckleberry Finn by Mark Twain, and Ethan Brand by Nathaniel Hawthorne are instruments played in the concordant symphony of poetic realism that unites the two fronts.

At no point does Marx introduce the actual machines of the machine age to refine his point, instead preferring to rely on mid-Nineteenth century literature and art to capture the sensory images of the age.

Marx asserts that the authors of the 1800s addressed the alienation and environmental blight that accompanies that rapid industrialization that the building and deployment of the continental railroads brought with them.

The central question that Marx attempts to address is how come there is an attitude of hostility towards civilization? What is it about the products of industrialization, which bring us a miracle of goods and services that enrich our lives in innumerable ways, that provides us the impetus for abandoning them in order to reduce the technical complexity that has befallen us? What is attractive about the pastoralism that is represented by the untouched landscape, revered at Walden Pond, that is unspoiled and identified by nature as much as a rejection of the artificial world?

The romantic pastoral, a literary device embodied in the semi-primitivism of the cultivated landscape, is located chiefly by its opposition of the forces of civilization, the so-called fever of the world. It’s hard not to be taken by the opposing scene of the abstract when faced with the overwhelming force of a dehumanizing and polluting industry.

Ultimately, Marx believes that the problem presented belongs not to the artist but to politics. Thomas Jefferson, America’s third president and a departure of the friendly mercantilist policies of the Washington and Adams administration, developed his idea of a flourishing pastoral America in 1785 when he published Notes on Virginia.

Jefferson’s views on the frontiers of science color his admonition of European values, calling them “destitute of national morality.” He had witnessed the machines and factories of Europe when he lived abroad and understood that they were a harbinger of industrialized cities and their environmental consequences.

But Jefferson does not argue from a primitivist standpoint. When he writes of Native Americans and their lack of laws providing a happiness that stands in contrast to the over-regulated European condition, he is providing his affirmation of the pastoral in that he is stressing a range of possibilities unavailable to Europeans.

In America, Jefferson writes, the primitive life is a drudgery and force is law. This is in contrast to the pastoral ideal, where his countrymen would be served better to be dependent on European manufactures instead of importing the misery that accompanies the industrialization of civilization. Here Jefferson argues that American is the exception to the rule that a country should be economically self-sufficient due to its exceptional abundance of land and its accompanying natural resources.

Marx argues that Jefferson belies his pastoral vision in this moment as he is devoted to agriculture largely as a means of preserving rural virtue. In practice this meant shipping raw materials to European factories in exchange for finished cost, no matter the financial cost. But he admits that this can be economically disadvantageous and that the loss of material living standards should not be a test of a good society.

This loss is counterbalanced by the “happiness and permanence of government” that accompanies the rejection of productivity. In a dour picture of the future, Jefferson ultimately warns that if America develops its own system of manufactures then the fresh, sunlit atmosphere of the countryside will be replaced by dark, foul air characteristic of European cities.

Curbing the economic developments of manufacturing would require the kind of governmental power that Jefferson abhorred. This contradiction, seemingly founded in a fondness for the agrarian lifestyle, would be antithetical to how the pastoral ideal would flourish.

This ambivalence is a response to the conflicting demands of industrial society and the young country. As Alexis de Tocqueville notes, the wilderness was precious not for its current state of peace and happiness but for what could be made of it.

Tench Coxe, who was notable for serving under both Hamilton as the Assistant Secret of the Treasury and then under Jefferson as purveyor of public supplies, also wrote on the economic effects of manufacturing in his Report on Manufactures. Coxe had the foresight to see beyond Jefferson’s vision. Coxe believed that machines bring out the powers latent in the environment. For example, textile manufacturing more consistently fit in with the ideal of a natural America than of Europe.

Hamilton and Coxe foresaw this potential in establishing America’s supremacy over other nations. Hamilton endorsed a program of embracing manufacturing in order to turn the United States into a behemoth akin to a corporate entity. Coxe, who supported Hamilton, preferred a subtler means of spreading this message by using the more farsighted approach of using language coached in the pastoral ideal and not to acknowledge the wealth and power that inevitably accompanies industrialization.

Coxe writes that “unless business of this kind is carried on, certain great natural powers of the country will remain inactive and useless.” By building factories, America unlocks her potential and fulfills the narrative set forth by the founding of the country. The machine accelerates history and offers a destiny that preserves the naturalness of rural life in a way that is accessible to more people than the landscape naturally supports.

The nation rejoiced at the introduction of the locomotive, even as it provided many writers and artists an outlet for the misgivings that they had for the intrusion of the machine. There is a pervasive theme in our literature that describes the green landscape that is incurred upon by the machine.

Even the artworks that Marx selects, The Lackawanna Valley by George Inness and American Landscape by Charles Sheeler, portray an accelerated vision of the absorption of industry and progress into an American landscape.

Inness’ painting, which was commissioned by the railroad it depicts and is used as the cover of the latest printing of this book, assimilates the machinery into the landscape and seamlessly blends the artificial construct with the hills, trees, and natural terrain.

The smoke from the passing locomotive is figured with the same strokes as the puffs rising up from the church. Instead of cutting the painting into sections, the graceful curves of the train tracks delicately unify the pasture with the town. Hard edges are softened and the solitary figure is seen reclining in a relaxed position, at harmony with the scene unfolding below. Marx points out that even the animals continue to graze peacefully.

It is this narrative of the two worlds meeting harmoniously that sets the stage for the acceleration in the 20th century. The organic qualities of Inness’ painting are contrasted with the regimented lines and overwhelming abstract figures of Sheeler’s industrial landscape of Ford’s early 20th century River Rouge plant, also commissioned by the company.

There is no trace of untouched nature in this landscape. In this landscape, technological progress overwhelms the solitary figure, using the human scale to provide for an industrial scale. Marx argues that this bleak vista is softer than the reality, with the whirring clamor of the machines obscured and the surreal staging of the industrial process providing a pastoral sublimity that corroborates the scene in Inness’ work.

But do these two works show the dominant narrative that is embraced by Americans? It would serve Marx’s work well to include examples of a more Jeffersonian rejection of industrialization, if only to have it serve as a catalyst for the inevitable reaction.

Even Emerson, mentor to Thoreau and a critic of the pressures of society, welcomed the new factory system. He wrote in his journal in 1837 that the logic was clear.

Hard-pressed Yankee farmers no longer felt obliged to farm as their region provided a means of economic sustainability in manufacturing, a macroeconomic concept known as comparative advantage. The technology of the day was an auspicious sign that would advance literature as much as it would advance science.

Emerson is no industrial apologist. But he sees the paradox of industry in that cities drain the flower of youth and that to support “whatever events shall go to disgust men with cities and infuse into them the passion for country life and country pleasures” is to support machine power as the conditions of science and technology can be made to serve a rural ideal.

Emerson sees this machine power as a morally neutral force, which in and of itself can be potentially dangerous. The citizens of the town Emerson inhabits merely cope with the technology ceaselessly entering their lives.

There is a famous G. K. Chesterton quote that says “progress should mean that we are always changing the world to fit the vision, instead we are always changing the vision.” Emerson sees his fellow citizens as accommodating their lives to the standard design of houses instead of designing their houses to best fulfill the purpose of their lives.

Overall Marx’s book provides a contemplative and throughly researched thesis, even as it sinews the pastoral mythology with the intransigent progress inherent to industrial society.

However, in this book there are multiple examples of literature that do not serve to advance the theories put forth by Marx but rather feel as if they are an inconsistent chorus that mirrors the uncertainty felt by the people of the age. The yearnings for a bucolic paradise are felt in the actions of the characters in the novels that Marx presents, but, for instance, Ishmael witnessing the belly of a whale as a factory system turns an uncomfortable passage into a frustrating analogy.

In the end, this book performs a convincing job of embracing the paradox between them two competing ideals, deepening my understanding of the parallels. Could there have been better analogies to mine from 19th century literature? Even with the choices made, Marx forges a timeless trail that is evocative of the pastoral ideal he blends with the ensuing mechanization of the 19th century.

Everything you need to build your own Turn Touch smart remote

2019-01-03T04:20:00+00:00

Back in 2014 I was driving up the 101 coming back from a YC alumni Demo Day and I had a lightbulb moment about the way I wanted to control my new Hue lightbulbs. That’s when the idea of Turn Touch was born. I’d had some experience building open source hardware projects for my home, and developing open source art installations for Burning Man at a slightly larger scale, but I had never thought I’d build an open source hardware project that would be commercially available (or at least available on Kickstarter). Turn Touch is now available to buy for $49 if you don’t feel like building your own.

There are four steps to building your very own Turn Touch:

Step one: Laying out the buttons and writing the firmware

Step two: Designing the remote to have perfect button clicks

Step three: CNC machining and fixturing to accurately cut wood

Step four: Inlaying the mother of pearl

Like many of you, I was one of those kids who took apart the stereos in my parent’s house to see how they worked. Since then I’ve been a full-stack engineer on most of my projects. Although I wasn’t quite sure how to build Turn Touch, I was committed to doing it, and learning how to build it from the ground up. At the Bay Area Maker Faire that year I stopped by the TechShop booth and signed up for one of their new member deals.

I build all my projects Open Source, so when I decided to start building Turn Touch I knew I wanted to document my process. My plan from the beginning was to release 100% of the knowledge, planning, and design behind Turn Touch as an open source project. Through building Turn Touch, I’ve learned what it takes to create not just one remote, but an entire manufacturing process. So that’s what I want to share with you in this series.

This is the full guide on how to make your own Turn Touch from scratch. This is the story of the design challenges faced when trying to make a seamless remote and how to overcome them. If you follow this guide, using the accompanying open source design files, then you will be able to build your own Turn Touch that you can use to control your smart devices and apps on your phone and computer.

Through open-source hardware like Turn Touch, I’m working to lower the barrier to entry when it comes to creating and manufacturing your own complex hardware devices. Sure, it’s not what you might call a “traditional business plan”. But I strongly believe that by helping other people use the same tools I use, our community of makers gets larger and more inventive.

At the end of the day, this isn’t a project devoted to turning a profit. It’s a project devoted to makers, wherever and whoever they are.

Pictured above and elsewhere in this series are all handmade prototypes. Turn Touch uses off-the-shelf components where it can, and only tools that are available to individual makers. No special tooling was required to build this remote. If you follow this blog series and use the included open source designs, you too can build a remote just like this.

I’ve broken this manual up into four sections. If you’ve done a bunch of machining my lessons may seem elementary, but the hardware part may be useful. If you’ve designed a bunch of hardware but have never worked with wood, hopefully this will lower your barrier to entry.

Step 1: Design challenges with Bluetooth for a wooden remote

At the heart of Turn Touch lies a circuit board with four tactile switches and a bluetooth module. This board alone is the remote, since it can be used without a wooden enclosure.

The source code for the Bluetooth firmware, circuit board schematic, and board layout is available on Github.

The circuit board is composed of four parts:

Bluetooth module
Other board components
The PCB
Metal dome sticker array

The Turn Touch circuit board

Bluetooth Module

Choosing a Bluetooth radio isn’t trivial. In fact, choosing Bluetooth in the first place is a tradeoff.

The goal for the remote is to control smart devices, but those devices range in terms of which wireless protocol they speak. For the most part, you can assume WiFi is in the equation.

Philips Hue lightbulbs speak Zigbee, a low-power peer-to-peer mesh network, and connect to a hub that speaks both Zigbee and WiFi. Sonos speakers, Belkin Wemo smart power switches, Lockitron smart locks, and many others are also on WiFi.

So how about just using a WiFi module?

Part of the requirement for the remote is that a button press is near-instantaneous (with less than a 100 ms delay). But a WiFi module, such as the popular ESP8266, draws up to 250 mA at 3V (750 mW) when transmitting and as low as 0.9 mA when sleeping.

Espressif ESP8266 WiFi module, $6.95 on Adafruit

Considering a standard CR2032 coin cell battery has 225 mAh, you can run a WiFi module with normal use (sleeping 99% of the time) for only 28 hours if you want instantaneous feedback. You can use bigger batteries, but now you’re working on integrating giant AA batteries into a tiny hand-held remote, which won’t work.

Better yet would be to bring the WiFi module down to the 10 µA level. But that requires a deep sleep which severs the connection. So when you press a button that requires the module to wakeup from deep sleep, it can takes several seconds to register the click. Amazon Dash buttons work this way and are able to last for over a year, since a several second latency is not a problem for them.

Raytec MDBT40 Bluetooth LE module, $7.50 on Seeed

Your phone to the rescue

The good news is that while WiFi is too power hungry for this type of device, our phones and tablets, which are on WiFi and get charged every single day, work as a terrific relay. Our phones speak Bluetooth, so why not use the still fresh Bluetooth Low Energy (BTLE) protocol?

There are a number of usable Bluetooth 4.0 modules to choose from. There’s the BlueGiga BLE112 module, Roving Networks RN-42 module, BlueRadios BR-LE4.0-S2A module, and the famous Nordic Semiconductor nRF51822 based MBDT40 by Raytec (pictured above).

The principle concerns for a Bluetooth module are:

The microcontroller and accompanying example firmware
Ease of over-the-air device firmware updates (OTA DFU)
Module size and profile
Power requirements
Debugging abilities
Community and support
Development kit and documentation

Here’s how the most well known and easily available Bluetooth 4.0 modules compare.

While all of the modules fit the necessarily small footprint, the MDBT40 module with Nordic’s nRF51 series won out due to the robust community and plentiful open source examples. It also had twice the max output power with half the power requirements of the BLE112. Plus it came with example projects for over-the-air device firmware updates (OTA DFU), which allows the remote to be easily upgraded for firmware changes down the road.

Not enough can be said about a thriving open source community around the nRF51 chip. Running into problems with power management, over-the-air device firmware updates, and even paramters for load capacitors on external crystals can be cleared up by consulting the massive online community that formed around the Nordic chip.

Now that a Bluetooth module has been chosen, let’s move on to the passive electronic components that it needs to operate.

Other board components

The nRF51822 datasheet is solid. The standard GATT attributes of the Bluetooth stack is easy enough to implement. What we’re looking for in the datasheet are low power modes. The remote will be asleep for most of its life, but it needs the ability to wake up and transmit the button press in under 100 ms in order to be called instantaneous.

There are a couple options:

Maintain connection with the phone/computer but in a low-power sleep. A coin cell battery lasts 1 year in this mode.
Disconnect and power down to a lower-power deep sleep. A coin cell battery can last 3–5 years in this mode.

I chose the 1 year option. Interestingly, if I had chosen the 3–5 year option, the quickest way of waking up and transmitting a button press to a phone uses a special advertisement packet that can take up to 4 seconds to send and be read. These numbers are adjustable and there are certainly graphs you could draw, but I found the tradeoff to be worthwhile by staying connected and being limited to 12 months of battery life.

Considerations for low power

From the datasheet we see that the low power mode works best with a 32.768 kHz external crystal oscillator with 9 pF load capacitance and a ±20 ppm frequency tolerance. This Nordic Semiconductor support thread on minimizing current consumption has the details, and this thread can help you determine the crystal specs.

Considerations for buttons

Apart from the external crystal used for low power, the only other peripheral we have on the microcontroller are the four buttons. These are internal pull-up GPIO pins with interrupts. This means that when the button is pressed in, the module is running at full power. One optimization to make would be to go back to sleep, but that would require external pull-up resistors, 1 per button, for a total of 4 more resistors on the board.

The PCB

The Turn Touch circuit schematic

Follow the rules and you get the schematic drawing above. I used EAGLE. Next time I would use KiCAD, if only because with open source EDA software it becomes easy to share the schematic and board layout with consultants and online forums for debugging and optimization.

You can download the board layout on Github.

Top (left) and bottom (right) layout of the circuit board

Here’s where we get our first intersectional consideration. Before we were just thinking about what happens to the performance of the remote based on decisions made about the firmware and microcontroller. But the shape of the circuit board needs to know what the rest of the remote looks like.

The way I attacked this problem was to declare the minimum size for the circuit board and battery. A geometric symmetry is desired, but for the battery holder and the bluetooth module to fit, they had to be rotated 45°. From that requirement, tracks were routed around the five mounting holes. Two of the mounting holes are nudged a bit apart (the two in the top right) so that the board cannot be inserted upside down or in any other orientation on the same mounting pins.

The 8 magnets that hold the remote together look like they have bitten the PCB on all four sides. The reason for those divets is that the buttons themselves only take up so much space, considering their size is dictated not by electronics but by design. But the PCB is bigger than the button size as a matter of fitting both the battery holder and the bluetooth module. So we can cut into the board a bit with the magnets and just route the tracks around them.

Metal dome tactile button sticker array

Buttons come in many shapes and sizes to satisfy different requirements. I spent a lot of time looking at buttons that were industrial sized and could take pinball machine levels of abuse. Finding a way to press down and make contact was not trivial. Getting to “metal dome array” took a long, long time.

Metal dome sticker arrays are custom yet inexpensive

The requirement for the remote was to have a low profile (short) button, but all of the mechanics of off the shelf buttons have a vertical profile of nearly a centimeter.

E-Switch TL3315 Series (L) and Panasonic EVQ6P6 Series (R)

You can find surface mount tactile switches for $0.20 on Digikey. The E-Switch is one example. There are two reasons I did not choose to use this, one pragmatic and one aesthetic.

Practically speaking, if you have surface mount components on two sides of a board, you just doubled your PCBA (PCB assembly) costs, since the board house has to solder one side at a time, holding one of the sides down in order to solder the other side. It’s time consuming and costly, and if you can get away with a single-sided board, you should.

Aesthetically speaking, there’s this phenomenom I like to call “accidental swastika”.

Whoops

By using a sticker dome array, we save money on PCBA but instead have to adhere the dome array during the full box build assembly process later on. Aligning a sticker array takes far less time, and we have the ability to choose between different click feels, pressures, and click sounds with tactile metal domes.

Depth of field for a half-inch metal dome

Snaptron M-Series metal domes were the first dome I tried. It was magical. All I had to do was design the board layout with two concentric rings, add a via in the center as an escape for air, and tape the metal dome down.

Taping metal domes with scotch tape on the left, custom made button array on the right

Ordering a metal dome array was easy. I just had to upload my gerber CAM files from EAGLE and send it off to CMD. $100 later I had 100 metal dome arrays with 400 individual buttons. Peeling them off and sticking them in the right spot is quick and accurate.

We now have a functional circuit board with a long-lived battery running Bluetooth. It’s now time to design the remote enclosure.

Step 2: Learning to build CAD models of a wooden remote

The source code for the CAD models is available on Github.

Now let’s put it all together. The remote is broken up into 7 stacked parts, starting at the top:

top four wood buttons (beige)
top wood case (gold)
top plastic insert (light grey)
plastic button arms (teal)
circuit board (purple)
bottom plastic insert (dark grey)
bottom wood case (gold)

Starting the CAD process wasn’t easy. I didn’t even know which CAD program to use. I tried four programs, in order: Sketchup, Rhino, Solidworks, and finally Autodesk Inventor.

The models for Sketchup were limited by the simplistic capabilities of Sketchup, but Sketchup to its credit does a wonderful job of introducing you to the basics of CAD.

The models for Rhino were limited by the non-parametric capabilities of Rhino, where it was easy to model shapes but extremely difficult and time-consuming to change the parameters that determined how models affected each other.

The models for Solidworks were just the right balance of ease of creation and future modifiability. But once I tried Autodesk Inventor, its admittedly minor differences from Solidworks won me over. And while Autodesk’s Fusion 360 wasn’t production ready when I started the process, if I were to begin again today I was absolutely use it.

Figuring out how pieces fit together

The question to consider when designing each of these layers is what is their relation to the layer immediately above and below itself. The circuit board defines where its mounting pegs are for aligning with the plastic insert below it, and it defines the button dome positions on top for aligning with the plastic button arms above.

Seven layers: wood buttons, top wood case, top plastic insert, plastic button arms, circuit board, bottom plastic insert, bottom wood case

There’s quite a bit of overlap, so each of these pieces fit together nicely to form a much more compact package.

2” wide × 2” deep × 0.68” tall (52mm × 52mm × 18mm)

The circuit board defines the most fundamental constraints, so the design must form around it. That’s not always the case, but when the device is trying to be as compact as possible, it’s a good place to start.

On the other hand we have the outer design, which is shaped to fit your hand. Those contours, while independent of the circuit board, are constrained to fit the circuit board footprint. So from the top constraints, inside and outside, we can begin dissecting the component layers and figuring out how to build this remote.

First problem: How to hold the buttons in place

The button travels down the height of the metal dome when pressed, so there needs to be some way of holding the button in place while it’s pressed down so that it reliably returns to the original position.

The actuator is tall enough to allow the button arms to bend without deformation

Below you can see the concept of buttons arms. Each button has two arms that angle out diagonally from the center of the button. This holds the button in place from the sides.

The button array on the left attaches to the top enclosure on the right, held in place by its own structure

The remote has no border between buttons, so the button arms cannot cross over on top of other buttons. Two arms come from opposite corners and merge into the button half-way down its length.

Why not extend the arms all the way down to the center of the remote? Extending the arm would cut the deformation in half, since each part of the arm has half the height to travel when pressed. But it would also compromise the strength of the button, allowing it to break during assembly.

The length of the arms is a good compromise between strength and flexibility.

Possibly my favorite design inside the remote is how the buttons are held in place. Originally there were pegs in the insert and holes in the button arms. This worked but not well. It was at the mercy of various tolerances when building two separate plastic pieces: the top insert and the button arm. Any misalignment had to be corrected for on the other piece.

If the peg was too fat, the button arm’s hole had to be widened using a miniature, conic jeweler’s file. If the peg was too narrow, the button arm had to be adhered somehow to the peg to prevent it from slipping off. It was a nightmare.

By using tabs that reach over the top insert, the buttons hold themselves in place. During assembly the button array needs to be bent into place, but once attached it doesn’t go anywhere. This also solved the issue of broken pegs when buttons are forcefully pushed in during assembly.

Second problem: Pressing on any part of the button face

Users are going to press a button on any part of the button. And if the press isn’t directly in the center, then it needs to be accommodated.

Each button is held in opposite diagonal corners, so when a button is pressed the arms deflect slightly downward. But they also form an axis that the button can rotate on.

If the button is pressed anywhere not on that axis of rotation, it will either push up the inside corner or outside corner and pull down the other side. To prevent this, we add a paddle on the outer corner of the button. This paddle is aligned with the plastic inserts so that it has a tiny bit of wiggle room but ultimately is constrained from moving up or down, preventing the button from rotating.

The blue paddle rests between the bottom and top plastic inserts, preventing the button from rotating when pressed

Third problem: Holding the remote together

During a demo this is everybody’s favorite part. The top and bottom of the remote need to be held together so that the end user can open up the remote and swap out the battery.

Most remotes use a plastic latch that either needs to be pinched by the user or pulled apart. Alternatively, some remotes are round and can be rotated around internal threads to open.

To solve this problem, I turned to a set of eight strong neodymium disc magnets. They get glued and placed into holes that are sized slightly smaller than the disc magnet, forcing the opening on the side of the hole to expand slightly. This holds the magnet in place and, coupled with an adhesive, ensures a strong hold on the magnet.

It is so satisfying to pull a remote apart and let it snap back together with the power of mangetism. And these magnets are strong, so they pack a lot more punch than anything else this size.

Fourth problem: Accounting for alignment tolerance stackup

This problem has been one of the most perplexing and unforgiving issues I’ve come across on the remote. The issue is that the 7 separate pieces of the remote need to be adhered together in a way that compensates for the different relative tolerances and variable sizes of each component.

There are only a few sizes that must remain fixed. These are the circuit board, which has been fixed in size due to the requirements of the button positions. Second are the wood case’s top and bottom pieces need to be the same size and aligned perfectly with each other so that they form a seamless lip.

The trick is to have a buffer that can absorb the differences in tolerance between the two constraints. This buffer is between the inside of the wood and outside of the plastic insert. That space is apportioned to allow for inaccuracies that arise from two-sided machining.

What the above image shows is that the wood, on top, has a variable amount of space for the plastic insert to move around and align itself. The problem that arises during machining is that the top and bottom may not be evenly aligned, so the tolerance has to account for the maximum offset on one top and the maximum offset in the opposite direction on bottom.

While there is no issue with having a buffer that moves the button arms around, the buttons are no longer perfectly aligned with the opening in the top of the case. To account for this, the plastic button arms are inset from the edges, as evidenced by the purple circuit board peeking around the margins of the teal button arms below.

Smaller button arms (teal) allow the wood to be independently aligned without overlapping other buttons

The wood buttons are glued on top of the plastic button arms, so they don’t need to be perfectly aligned. But the plastic arms are reduced in size so that a wood button isn’t sitting on top of two plastic arms that happen to be slightly offset due to any alignment issues.

But this brings up another issue. We want to maximize the amount of wood at every point while minimizing the total size. We do this because otherwise the wood could break in the thin sections during machining.

Let’s turn back to the see-through side view of the remote.

Notice the space by the yellow arrow is a weak spot that runs along the circumference of the remote. By minimizing the height of the plastic insert we can maximize the wood that holds it in. This minimizes the possibility of split wood during the machining process.

And with that we come to the most exciting part of the process, how to successfully machine the wood.

Step 3: CNC machining and fixturing to accurately cut a wooden remote

Now that we have our models, we need to figure out how to machine them out of wood. Workholding is the principle concern here. In order to consistently machine the wood on two sides, the wood needs to be held down. This is much harder than it sounds.

The source code for the CAM toolpaths explored below is available on Github.

Lumber and machining fixtures line the entire wall in my office in SF

There are two central issues to consider: one is that each piece needs to be machined on both sides, and second is that the workpiece needs to be held down both facing up and facing down so that it can be machined on both sides. In our case, we want to scoop out the insides of the remote out to fit the circuit board and button arms while contour cutting the outsides of the remote to fit the desired shape.

Designing the CNC machine toolpaths to sculpt the contour of the case while pocketing out its insides, assuming the workpiece is held down, is not terribly difficult. There are only a few strategies that you need to use and they mostly involve answering the question of how fast to cut while maintaining as clean a cut as possible, which we’ll get to later.

Above, I’ve designed the fixture that gives us 15 pattern-matched remotes at a time from a single board of wood 24” long and 7” deep. That’s just about 1 board-foot (bf) of wood. A single board-foot costs anywhere from $5 to $50, with maple at $5/bf, mahogany at $10/bf, padauk at $15/bf, and rosewood at $40/bf.

Pattern matching the wood

The top half of the fixture is the inside of the remote, the bottom half is the outside of the remote. We’re machining both the top and the bottom next to each other at the same time because we want the wood to pattern match.

Examples of pattern matching with mahogany on the left and padauk on the rightPattern-matched Rosewood halves come together beautifully to form a single remote

Since we want the top of the remote to match the bottom of the remote, they must be machined next to each other. Our fixture reflects this by placing a top half next to a bottom half, and always in the direction of the wood grain. That way when the top case is flipped over like a book and closes on the bottom case, the grain lines match up.

How to align the wood for two sided machining

Let’s start with the first fixture design because it was simple and was designed to only make a single remote at a time.

The first fixture that successfully machined a remote

This animated gif beautifully illustrates the basics of machining the remote on both sides. This design uses a vise clamp that will quickly prove to be haphazard and inaccurate.

Unfortunately, the truth is that using a vise clamp leads to needless suffering.

The hardest part about using a vise clamp is ensuring that the registration and orientation match when flipped upside down. Not only do points on the x, y, and z axes have to be the same, but they need to be the same all the way down the workpiece. Any accidental tilt, turn, or shift when flipping the wood blank over results in a mis-alignment, and when that shift is greater than the width of the wood, we’re left with a work piece that abruptly breaks during milling.

And to make matters worse, errors are doubled when the piece is flipped. A 0.005” shift (less than the height of a fingernail) is a proportionate shift in the other direction on the opposite side, resulting in breakage happening more often than such a slight shift would imply.

The good news is that it’s easy to design a better fixture. The vise clamp suffered from multiple issues. Having to hold down the vise clamp itself was problematic, as it could subtly shift during machining. There are constant orientation and registration issues with a vise clamp unless you are fortunate enough to have a CNC track that can securely hold down the clamp.

We can clean these issues up with a fixture cut into a ¾” plywood board.

Nearly finished with buttons on the left and cases on the right, but still needs to be cut out and sanded down before finishing.

This is fundamentally the same fixture as the vise clamp with a few important differences. See those alignment pin holes in the top image? Those are going to be responsible for keeping our x and y axis consistent when the piece is flipped over. And the z axis is kept consistent with the use of a flat plywood board that is level to the CNC’s spoilboard.

Note that the fixture itself is not registered to the table, it’s simply attached with screws. So when we put a blank wood work piece down, we drill the alignment holes directly into the wood and into the fixture. When one side is completed, we flip the wood blank over and use dowel rods to ensure we’re still registered in the same spot.

So this fixture addresses alignment and orientation issues in all three axes, but because it is not itself registered to the table, we cannot reuse the registration holes, as the fixture is never going to be put into the exact same spot again next time it’s used.

More importantly, there are still tabs holding the wood remotes in place during machining. Tabs take time to machine around since you can’t just have your toolpath wrap continuously around the contours of the remote without stopping. The CNC machine now needs to pick itself up and climb over the tabs for each rotation around the remote.

Using tabs also means that the remotes cannot be placed right next to each other. There are these bars of unused and uncut wood between each half of the remote. These untouched bars allow the wood to be held down with clamps, since the remote isn’t sitting on anything. But they are a waste of wood!

A belt sander once nearly ate through my fingernail from the top

And to top it off, once the tabs are cut with diagonal cutters and you pull the individual remote halves out of the larger workpiece, you have to manually sand down the tabs, which is error prone and dangerous.

How to hold down the wood for two sided machining

Here’s where it gets interesting. In order to get rid of tabs, we have to figure out a way to hold down each individual remote as it is being machined.

The cutter is contouring around the outside border of the case, so there’s no way to hold the case from above without having it in the path of the cutting tool. Ideally we’d hold it from below, but that requires messy adhesives or a complicated locking system. And that brings us to vacuums.

Vacuum tables are outside our price range expensive, but we can build our own for the cost of plywood and glue. Above you can see that we’ve built a hollow box about 3” high. It’s just ¾” plywood cut into the shape of a box and glued tight. On top we’ve glued additional wood, which is then machined into the inverse of the remote.

For a fixture, alignment is everything

Zooming in we see that the top case (left) is too thin to use a large hole. So we drill a few dozen 1/8” holes around the perimeter of the top case.

On the right we have the bottom case, which is solid in the center, so we can use a large 1/2” hole to have the vacuum hold it down in one spot.

You may also notice 5 metal alignment pins on each half. The vacuum holds the case down in the z axis, but the alignment pins are needed to hold the case down in the x and y axis as the wood is being machined.

A cutaway that shows the alignment pins do their job

Above you can see how the 1/8” alignment pins handle the slight variance in the buffer between the case and the inverse fixture. They do a great job of holding the remote tight while it’s being worked over by the cutting tool. Before I used these alignment pins, oftentimes a case would become dislodged by the cutter, flinging it across the room.

The fixture itself sits on a spoilboard that is aligned to the machine, which allows for reuse of the fixture without having to recut anything. To pre-align the fixture, simply cut holes into your own spoilboard that sits on top of the machine’s spoilboard.

Use those holes as reference guides for the dowel rod that aligns the fixture to the spoilboard. You can see the dowel rods sticking out of the fixture and into the pre-drilled alignment holes at the bottom.

I’ve also cut out handles into the fixture, which makes carrying these heavy fixtures around much easier.

Behold the vacuum

Just attach your vacuum hose to a $3 flanged inlet fitting attached to the side of the fixture. You’ll need to cut a hole out of the fixture. I used a $17 hole saw on a drill press to poke a hole for the vacuum to attach to.

The vacuum fixture uses a standard Shopvac 2¾” hose

This is your standard 2½” hose, attached to an inexpensive ShopVac. You don’t need more than a couple horsepower to pull enough air to hold the wood down in place. This vacuum seal isn’t going to do anything for movement in the x and y direction, so if all it has to accomplish is offsetting the minor pull in the z direction due to vibration, then you won’t need an industrial pump or expensive vacuum to do the job.

In other words, it shouldn’t hurt when you place your hand over the hose and seal the vacuum.

A beautiful rosewood workpiece being machined into five remotes

Because the fit is so tight, we need to add tiny ejection pockets underneath the wood case so we can wedge a lever in and pop the remote out. You can see this space at the bottom in the above photo.

You can see the secondary spoilboard on the button vacuum fixture, which follows the same principles as the case vacuum fixture. There are holes beneath each button, and three alignment pins holding the buttons in place as they are machined.

Maple (center) being machined, Brazilian Satinwood (right) cut up into eight remotes worth of buttons

Using off-the-shelf tools and cutters

It’s important to keep as many tools and parts of the assembly off-the-shelf. There’s something to be said about being able to order more components and tools from a trusted vendor rather than having to source new custom tools. All of the tools used to machine Turn Touch are relatively inexpensive and will last you long enough to machine thousands of remotes.

The tools above are much of what I use in the wood shop. Starting with the milling and drilling bits, left to right:

1/8” shank bits

$3, 1/8” brad point drill bit — used on the vacuum fixture to provide a vacuum channel for the top case
$12, 1/16” flat downcut 2 flute end mill — used cut out the buttons without leaving a trace
$19, 1/16” bull nose 0.01” radius 2 flute end mill — used to sculpt the two north ridges on the buttons

1/4” shank bits

$36, 1/8” flat 2 flute end mill — this pokes small holes that alignment pegs fit into inside the top and bottom case
$33, 1/4” flat downcut 2 flute end mill — pocketing out the insides of the case without tearing out wood from the edges
$24, 1/4” ball 2 flute end mill — contouring the outsides of both the top and bottom case
$12, 1/4” flat upcut 2 flute end mill — surfacing and planing the wood for the buttons

1/2” shank bit

$17, 1/2” flat 2 flute end mill — used to dig tracks and layout for each of the fixtures

Accessories

$1 Square head power bit driver — square heads don’t strip as easily as phillips screw head does
$30 1/8” ER-25 collet — size used by Shopbot CNC
$30, 1/4” ER-25 collet
$30, 1/2” ER-25 collet
Composite plastic brad nails — used to attach the remote fixture to the CNC’s spoilboard without damaging the spoilboard
$1, 4 square head screws and washer — long enough to go through the fixture and the spoilboard
a pencil — don’t use a pen on wood, it smears and it kills the pen rather quickly

Miscellaneous lessons learned

Apart from the construction of the vacuum fixture, there’s many other lessons to learn from machining these remotes.

Figuring out the feeds and speeds for cutting into the wood

The feeds and speeds took a bit of trial-and-error but eventually I settled on values that meant an entire remote could be machined just under 10 minutes. With some changes to the cutting tools it is possible to bring that down further, but custom cutting tools cost on the order of $1,000. So the workholding fixtures we have here use off-the-shelf cutting tools, like flat end mills and ball end mills, which only cost $20 each.

My rule of thumb for mahogany is 120 inches per minute with no more than a 0.15” step down. For rosewood that number is cut in a third, so 40 ipm. Finding that number is simply a matter of running the machine and interactively increasing or decreasing the feeds until there is no chatter and the CNC machine sounds like it’s under control.

How do I know if I’m moving too quickly?

Apart from the horrible sounds of chatter, this may happen.

I keep all of my broken cutters in a museum of mistakes

Different hardwoods need different cutting speeds

Some harder woods need to be machined at a slower speed than less dense woods. Rosewood needs its speeds cut into a third of what mahogany would use. Instead of having to update the toolpaths, I wrote this python script to automatically copy the mahogany toolpaths and cut the speed in a third and then re-save them as rosewood toolpaths.

The inverse fixture needs to compensate for differences in the wood

Below is a picture of what the fixture looks like without the wood on top. Notice that the fixture is red at parts. That denotes that the wood is about 0.005” inset. This means that there is a slight gap between the inverse fixture and the wood workpiece that will fit over it.

The internals of the front three remotes without the wood

The reason for this slight gap is that if there is no gap then the workpiece will either not fit perfectly onto the fixture or it will get stuck, as it is holding the fixture on all faces. By adding a 0.005” gap between the two, they can better fit together. And the alignment pins and vacuum holes protect the wood from shifting around any axis, so the buffer could possibly even be bigger.

With that, we now have perfectly aligned wood pieces that are ready to be adhered together. All we have left is to inlay mother of pearl on the bottom of the remote to complete the process.

Step 4: Design challenges with laser cutting mother of pearl and laser engraving a wooden remote

I set out to make the most beautiful remote I could. And after observing what many of the most beautiful handheld objects I’ve seen had in common, it became clear that Turn Touch deserves an inlay.

The source code for the inlay paths and laser cutter settings is available on Github.

The choice of mother of pearl came naturally. Wood and shell are both natural materials that are sustainably grown and can be beautiful to behold. The trouble with mother of pearl is that it is an exceptionally brittle material. Great care must be taken in both cutting the shell and then adhered it to the wood.

There are two main considerations to make when thinking about cutting the mother of pearl to fit. First is that the remote needs to be engraved to perfectly fit the mother of pearl. Second is that the mother of pearl itself needs to be cut to fit the engraved wood with no margin between the two.

As thin as paper, this mother of pearl shell is only 0.007” thick.

Engraving the wood

Let’s begin with how I started the engraving process. The wood is considered the source of truth and will be engraved with no compensation for the mother of pearl. The shell must compensate for the wood.

Originally I used the ShopBot CNC machine to engrave the logo into the wood using a 1/32” flat end mill. There were a few issues with using the CNC to engrave:

Every inside corner turns into a 1/64” corner radius due to the limits of axial router cutters.
The depth of the cut (height) kept changing due to machine tolerance.
This involves a tool change, which is costly and time consuming.

Worst of all, due to differences between machines, the laser cut mother of pearl would have slightly different dimensions from the CNC engraved wood in both the x and y axes, resulting in a not-quite-perfect fit, leaving a variable sized gap between the shell and the wood.

There’s an unfortunate margin between the engraved wood and the cut shell

The fix is to use the same machine for both engraving and cutting so that the same machine tolerances are applied, resulting in a uniform offset between wood and shell.

Using the laser cutter to both raster cut and vector cut

Engraving on a laser cutter is very different than engraving on a CNC machine. Whereas a CNC will route a tool bit in a pocket, stepping over itself with a minimal amount as to be efficient as possible, a laser cutter will rasterize the pocket shape and work in a way not unlike a 3D printer: line by line.

Before we begin working with the laser cutter, we take simple safety steps to ensure our health. The first few times I worked on the laser cutter, after about an hour my throat started to hurt. Probably due to all the acrylic being massacred by other people sharing the pool of laser cutters.

Wear gloves and wear a dust mask. Your lungs, skin, hair, and fingers will thank you.

Nitrile gloves have no latex and are not coated in the messy dust that makes them easy to put on and remove

Here’s what we’re going for. We need to accurately engrave into the wood. This means that the cut needs to be centered and oriented. If we were to just place the remote bottom side up and shove it in the corner of the work bed, the engraving would come out askew.

60W CO2 Universal laser cutter, sped up 40X for dramatic effect

Here we can see the laser cutter do its magic. To achieve this registration and orientation of the remote in the laser cutter, we need to do the same thing we did for the CNC machine: we make a fixture.

A fixture to ensure accurate centering

Lucky for us, this fixture is easy to make. I just took a ¼” piece of plywood and ran the laser cutter around the outline of the remote at full power to cut through. I had to adjust my offsets a bit to fit the remote, but it only took a couple tries.

This fixture gives us perfect registration and orientation for the laser cutter to accurately hit the center of the remote

The remote is sitting inside this hole. Because the laser cutter made the hole, we can just center the logo engraving (or custom inlay engraving) in the hole to ensure that we are correctly registered. The plywood fixture itself is pushed up into the top right of the work bed so that it remains in a constant location.

Finding the right power settings for laser cutting wood

The toughest thing about using a laser cutter to engrave wood is optimizing power settings. We want to perform the work as quickly as possible which ostensibly means using the highest power and fastest speed available. But we need to watch out, as too much power makes the wood burn.

There are three variables we can change: power, speed, and throughput. Power and speed are self-explanatory. Throughput is the density of the cut. Low throughput means that the laser cut spends longer making a higher resolution rasterized cut. So low throughput takes 3 minutes while high throughput takes only 15 seconds.

We want to start with establishing a minimum throughput that gives us the minimum acceptable quality of the cut we want but at the fastest speed possible. So we start with a low throughput to establish high quality and then move up in throughput until we reach a cut that’s too sparse.

Take a look below at this mahogany wood blank to see what happens when wood burns, even subtly. Starting on the right-hand side you can see how the laser cutter’s exhaust system pulls the smoke up and over the wood, leaving a burn scar above the cut.

A mahogany wood blank worked right-to-left, the left-most engraving was chosen for its perfect height match with the shell

Starting from right to left:

High power, 45 sec: notice the burn scars above the logo. That’s caused by the exhaust fan of the laser cutter pulling the burn up. You can reverse the direction of your cut so that you cut from bottom up, “erasing” the burn scar by burning it, and then possibly using a light power setting by the time the laser reaches the top quarter and going over it multiple times. But that’s quite a commitment to shave maybe 15 seconds off, and even then you still might end up with a burn scar.
Medium power, 45 sec: Same time as before but less power means less burn scar. We need to adjust the density (throughput) of the cut now.
Low/high throughput, 180 sec/15 sec: This photo clearly shows the difference between low throughput (high density) burning on the right and a high throughput skipping every 5th line on the left.
Slow speed, high power, 45 sec: I’ve established a desired throughput and now I’m experimenting here with changing the speed but maintaining high enough power. The cut is reasonable but it still burns due to the speed. If we turn up the laser to max speed but turn down the power output, we get a nice cut at a fast speed, but it’s just not deep enough. To fix that we just need to run the cut twice.
Medium throughput, medium power, high speed, double run, 35 sec ⨉ 2: Here we get to a much more reasonable cut. I’m using 20% power with 100% speed and a 5/7 throughput, but it’s still not deep enough.
Medium throughput, medium power, slower speed, double run, 60 sec ⨉ 2: And now we’ve got it. Moving down to a slower speed but at only a medium power we get the cut we want at a reasonable time of 120 seconds.

YMMV on your particular laser system, but this is a good way of narrowing down values until hitting local maximas.

Problem at the edges

When a laser cutter cuts through material, the beam diffuses and creates a sloped edge. You can see how this edge can be a problem below.

When you try to inlay the shell later, these slopes will cause the edges of the shell to sit higher than the rest of the shell. It would be very easy to crack the shell if you press it in, since it can’t handle the stress of resting on the sloped edge.

One way to reduce the sloped edge is to adjust the focus of the laser. Even if you successfuly set the height of the focus, it still might be off by ±0.005”, which is half the height of the shell itself. So it makes sense, once you establish power, speed, and throughout settings, to also attempt a few cuts above and below your laser cutter’s established focal point, in 0.0025” increments, and see if the slope goes away with the adjustment.

Alternatively, since the slopes are only at the edges, you can perform additional cuts with the laser, feathering the inner edges, offset by enough distance so that the diffusion of the laser doesn’t show up outside the engraving.

This is what I do and it only takes a couple extra seconds to make a few cuts at the edges on one side. Sloped edges do not necessarily happen on every edge, since the grain of the wood can naturally reinforce an edge or make it harder for the laser to make a clean cut. So in my case I only had to feather one edge of the engraving to get the shell to fit perfectly. And because the cuts are inside the engraving, it doesn’t show and the shell fits in at the proper depth.

Vector cutting the mother of pearl shell

This is the good stuff. Mother of pearl is such a delicate material that it only needs a light power setting. The only variables I messed around with were power and speed, since vector cutting has no throughput component like the rasterized engraving in the wood above.

Thin mother of pearl needs to be weighted down so it doesn’t get sucked into the exhaust fan

Let’s cut the inside edges of the design first. Just as you don’t want to paint yourself into a corner, you want to laser from the inside out. Otherwise your newly free-moving material may not stay in place for those inner cuts.

Test every inset variation to minimize the space between wood engraving and cut shell. I settled on a 0.001” inset.

The Universal laser cutter I used allows you to set colors that applies an order to each cut. I also used a lower power setting for the outside edge cut. Since the entire square is easier to separate that the inner cut, a faster speed cut keeps the mother of pearl marginally connected so that the individual pieces don’t go flying as they get cut.

Hot cutting action

I could have run the laser at a higher speed (at a higher power to compensate), but I kept it at a low speed to ensure a quality cut. If the wood engraving isn’t perfect, it matters less than if the shiny shell has rough corners that become a lot more noticeable.

Adhering the wood and shell together

Once you’ve got the two cut materials, the wood and the shell, you’ll need to get them to stick together. Since there’s no forces acting upon the inlay other than to reinforce it down into the engraving, we don’t need a messy epoxy or expensive shell glue to hold it in.

I tried many glues and settled on squeezable Extra Time Control super glue gel. The gel makes application easier, instead of being thin and runny. However, using off-the-shelf super glue (cyanoacrylate) without time control gave me only 5 seconds between application and drying. So placing the shell into the engraving was a one-shot deal, with the shell becoming permanently affixed to the wrong place if you didn’t nail its position the first time.

Better to apply the glue to the shell than to the wood, less run-off on to the wood that wayPlace and wipe clean

Time control or not, it’s still super glue and it adheres within 15 seconds. But because it has time control, any excess glue easily wipes off the wood with a paper towel.

2 minutes of lasering per remote, 30 seconds of glueing, and you get a finished remote

That’s it! That’s the last step. We now have a complete Turn Touch ready to ship to backers.

If you want to be one of those backers, head to Kickstarter and get your own Turn Touch.

This is a four part series on everything you need to build your own Turn Touch smart remote.

If you want to get your own, Turn Touch is now for sale for only $49.

Building Grove — interactive trees that come alive to your breath at Burning Man 2016

2017-03-31T08:17:43+00:00

Grove is a set of 10 interactive biofeedback sculptures, a conversation between humans and trees. Each tree is made of steel tubes, thousands of LEDs, and custom breathing sensors.

Grove is a 2016 honorarium installation at Burning Man and is the second installation made by the group that made Pulse & Bloom in 2014. The core team is ten people: Saba Ghole, Shilo Shiv Suleman, Severin Smith, Steve Lyon, Hunter Scott, David Wang, Francis Coelho, Naeemeh Alavi, Luke Iseman, and myself, Samuel Clay. Grove was conceptualized by the artist Shilo Shiv Suleman as part of her larger series exploring nature, intimacy and technology called Beloved.

Here’s how Grove works: you sit down at the base of a tree and a flower opens up in front of you as it senses your presence. As you breathe into a pink flower lit from inside, the tree fills up with your breath, rising white streams overtaking multiple slowly descending green lines. As you breathe, the tree shimmers with light as it becomes a nighttime desert oasis.

This post offers details on how this installation was built, from the custom circuit boards to the blooming flower and breathing sensors. You can access the complete source for Grove on GitHub.

Grove is made up of ten trees, each of which has its own breath sensor and set of two thousand LEDs across four 5 meter 144 LEDs/meter LED strips and 16 high current LEDs in the leaves. That takes both a lot of power to run and a lot of manpower to setup. This is what that setup looks like.

This photo and a few others below are by Daily Swa Laurel

How the electronics are made

Since the trees light up with your breath, we need to consider how the breath is sensed and then how the thousands of LEDs are driven.

These are five stages to making the electronics work together:

1. Designing a breathing sensor

First things first, we need to focus on how to design a breathing sensor.

The plastic lotus flower assembly

This is the plastic lotus flower assembly built and designed by the NuVu team in Boston. It is supported by a 3 foot gooseneck that is tied to the base of the tree. This allows the person sitting down by the tree to pull the flower, that at this point is lit up and has magically opened itself, over to their mouth.

We placed a pair of passive IR motion sensors a few feet up the base of the tree looking out on both sides to detect when somebody sits down. That signal then directs the servo motor in the flower to open the flower up and make the LEDs inside the flower pulsate. This beckons the person to pull the flower over to them.

The flower has a proximity sensor embedded inside that is more commonly used by paper towel dispensers to detect hand movement. We used the Si1143, same as in the pulse sensor in Pulse & Bloom, to detect proximity. When we detect that a person is positioned directly in front of the flower, we then allow the breath measurements to light up the tree. Otherwise wind would take over and the tree would be constantly lit.

Above you can see the board that is placed inside the flower. There is a trumpet that fits directly over the board and directs airflow over the board. There are two slots in the board that allow your breath to flow over the hot-wire thermistors and out the back of the flower. Otherwise when you breathed into the flower, the flower would send your last breath back out.

The sensor board and the main board are driven and controlled by their own Teensy 3.2. I cannot say enough good things about the Teensy. We originally used an 8-bit Arduino Uno compatible ATmega328p chip but found the 8K memory limiting when we wanted to address thousands of LEDs at once.

The Teensy gives us plenty of head room and it was easy to get a GCC-based Makefile deployment setup so all we had to do was run one make command and the board was flashed and rebooted.

Detecting your breath

Now we get to the heart of the matter. To detect your breathing, we turn to the Modern Device wind sensor. They use what’s called the “hot-wire” technique. This involves heating a couple of thermistors to a constant temperature and then measuring the electrical power required to maintain the heated thermistor at temperature as wind cools it down. The electrical power is directly proportional to the square of the wind speed.

You can buy anemometers for hundreds of dollars but we made our own following the Modern Device wind sensor. Hot-wire anemometers excel at low wind speed, which is pretty much the same speed as breathing.

While out on the playa we discovered that the plastic trumpet, which is used to channel your breath toward the sensor while keeping out wind, would cover a bit too much of the proximity sensor. We solved this problem by adding ultrasonic sensors (thanks to Frys for letting us buy out their collection of ultrasonic sensors on the way to the burn), pictured below on top of the orange trumpet.

We spent a couple days adding these ultrasonic sensors into the boards, soldering in the desert and making do with what we had. Thankfully we left a few pins open that we could then use for the new and improved proximity sensors.

You can explore the code we used to sense your breath on Github. There’s a few parts that I’ll highlight below in the writing the firmware section.

2. Making the main control board

This is the board that talks to the sensor board and the dispatcher board and gets all of the LED strips plugged into it. This is where the main battery connects to the tree and where power is distributed to each of the sensors and LEDs. This board also communicates with the dispatcher board up top in the leaves to make the high current LEDs fade between colors.

You’ll notice on the left is an 8A DC-to-DC step-down voltage regulator that brought the 12V down to 5V needed for the LED strips and sensor board. The dispatcher board and its 16 high current LEDs needs the full 12V. We originally used a cheaper 3A voltage regulator, but it turns out that the number of LEDs we had on at any given time would regularly hit 5A, so we had to boost the voltage regulator.

You should also note that we used a Teensy here as well. There are some protections built into the circuit to prevent burning out the Teensy if we happen to short somewhere. Thankfully this didn’t happen, but we made the Teensy removable and replaceable in case it did.

All of the wire-to-board connectors are MTA100 Series female and male pin headers. They are an inexpensive connector that you can crimp onto AWG 22 gauge wires and then easily insert into 0.1” male header pins. They even include an optional polarity wedge on the side so that you can ensure the wires are always plugged in the right direction, which is especially helpful when you have people helping you out and you want to ensure that no mistakes are even possible.

Crimping the MTA100 headers to the wires is pretty fast. You can use either a $30 insertion tool or a $100 crimping tool with a $163 MTA100-specific crimping head.

The best part about the MTA100 is that the wires are removable, so if you make a mistake you can just pull the wire out of the crimped head and try again.

Sometimes the connections wouldn’t take and they would have to be re-crimped. This happened on a few of the trees. In the future what we would have done is add circuit testing to the mainboard. This would be an in circuit current measurement sensor. On boot we would turn each of the LEDs on individually, sensing whether or not the LEDs are actually drawing current. This way we can identify improperly crimped LEDs (or just plain old broken LEDs) and turn on a status LED on the board to quickly check.

3. Driving high current LEDs with a custom lighting board

That brings us to the dispatcher board on top. The goal is to have 16 individual 3W ultra-bright LEDs on top of the tree light up as each breath climbs to the top of the tree. These high current LEDs look like they are effectively breathing, turning your breath into the breath of an entire tree. It’s a magical effect and to pull it off we’re going to need a custom board just to handle these tricky LEDs.

Last time with Pulse & Bloom we didn’t have a dispatcher board, instead relying on driving the LEDs with loose wires connected directly to PicoBucks. It was a mess. Here’s the wiring diagram just for the 9 high current LEDs.

This means that there are over a hundred wires (6 per LED) per tree.

We decided instead to make a board that not only could handle all of this wiring mess but also allow us to easily change out the PicoBucks if they shorted, which is something that happened surprisingly often until we realized that the factory solder jobs on the LEDs themselves could sometimes short.

You can see from the schematic below that we simplified the setup by hooking up a set of four high current LEDs per PicoBuck. This let us individually address four sets of lights, giving the tree a mesmerizing pattern of lights that would slowly breathe on their own in green, turning blue when filled with “oxygen” from somebody sitting down and breathing into the breathing sensor at the base of the tree.

We also added protection fuses to the dispatcher board in case the LEDs did short. Since each LED draws a quarter amp at 12 V, we needed to make sure that they would be protected.

There is also a 12 channel SPI DAC. Since the PicoBucks need an analog signal as input to specify the PWM-enabled brightness on the LEDs, we couldn’t easily send an analog signal up from the main board since it would have to traverse over 5 meters and be subject to massive voltage drop. Instead we sent a digital signal and converted it to analog on top. This was easy and inexpensive to do with the $4 BH2221FV chip from Rohm.

4. Writing the firmware

There are two boards that need their own firmware loaded on to their own Teensy. The sensor board and the main board can both be found on Github.

The sensor board

Let’s go over a few of the more interesting functions that are used to light up your breath.

void loop() {
    readRemoteState();
    updateLEDs();
    updateFlowerServo();
    updatePIR();

    runWindAvgs();
    updateProx();

    evaluateState();
    runBreathDetection();
}

To begin, the sensor board runs through a tight loop looking for the proximity and PIR motion sensors to trigger so that it can begin to read breath measurements. If the proximity sensor is not firing then that means nobody is in front of the front and we should not be showing any of the breath measurements we might be reading due to wind.

If we didn’t have a working proximity sensor (which happened to a few trees) then we would actually just be showing the Earth breathing, otherwise known as the wind. The Earth breathes differently than you or me. Instead of long pulses of hot air, the wind shows up as a sustained line of many tiny pulses, since it’s both cooler and smoother than your breath.

Next we have a finite state machine determine which state we’re in. The choices are neutral, motion detected, and proximity detected.

void evaluateState() {
    switch (overallState) {
        case STATE_NEUTRAL: {
            if (pirState == PIR_ON) {
                overallState = STATE_OPEN;
                openFlower();
            }
            break;
        }
        case STATE_OPEN: {
            long now = millis();
            if (now - openTimeoutLastEvent > openTimeout) {
                overallState = STATE_NEUTRAL;
                closeFlower();
            } else if (isProx()) {
                overallState = STATE_PROX;
            }
            break;
        }
        case STATE_PROX : {
            if (remoteState == STATE_NEUTRAL) {
                overallState = STATE_NEUTRAL;
                closeFlower();
            } else if (!isProx()) {
                overallState = STATE_OPEN;
                breathOff();
            } else {
                runBreathDetection();
            }
            break;
        }
    }
}

Using a FSM makes it easy to ensure that we always know where we are, even with three separate sensors that all trigger independently of each other, while ensuring that one does not cause a change in the tree without its predecessors.

void runWindAvgs() {
    long now = millis();
    if (now - lastWindSampleTime > windSampleInterval) {
        // Currently tuned to sample every 20ms roughly
        int raw = getRawWind();

        lowWindAvg = lowWindAvg * lowWindAvgFactor + raw * (1 - lowWindAvgFactor);
        highWindAvg = highWindAvg * highWindAvgFactor + raw * (1 - highWindAvgFactor);

        lastBpassWind = bpassWind;
        bpassWind = (int)(highWindAvg-lowWindAvg);
        windHistory[windHistoryIndex++] = bpassWind - lastBpassWind;

        if (windHistoryIndex >= WIND_HIST_LEN) windHistoryIndex = 0;

        lastWindSampleTime = now;
    }
}

We use the above runWindAvgs to average the raw readings and establish a moving average with hysteresis. This means that we want to intentionally avoid rapid switching of states, so we have upper and lower thresholds that move with the average.

The main control board

Next we come to the main board. Let’s walk through the steps. Instead of showing the code from the main board, I’m going to talk about the various functions. You can view all of the main board’s code on Github.

void loop() {
    addRandomDrip();
    advanceRestDrips();

    updatePIR(0);
    updatePIR(1);
    transmitSensor();
    receiveSensor();

    #ifdef RANDOMBREATHS
    if (millis() % (60 * 1000) < 5000) {
        addBreath();
    }
    #else
    if (proximityState == STATE_PIR_ACTIVE && detectedBreath) {
        addBreath();
    }
    #endif
    advanceBreaths();

    runLeaves();
    runBase();

    leds.show();    
}

What’s going to happen is that the tree will randomly add “drips” to the top of the tree.

addRandomDrip();
advanceRestDrips();

These drips are a random length with a random green-tinted color. They will use easing equations to slowly but rhythmically drip down the tree. The effect is that the trees are swimming in their own green waves.

updatePIR(0);
updatePIR(1);
transmitSensor();

When a person sits down at the base of the tree, the PIR motion sensor fires. We then send this signal over to the sensor board, which then opens up the flower using a servo motor and changes the color of the flower.

receiveSensor();

The sensor then sends back data about the proximity sensor and the detected breaths.

#ifdef RANDOMBREATHS
if (millis() % (60 * 1000) < 5000) {
    addBreath();
}
#else
if (proximityState == STATE_PIR_ACTIVE && detectedBreath) {
    addBreath();
}
#endif

Once a breath is detected, we add the head of the breath to the bottom of the tree and guide it upwards.

advanceBreaths();

The high current LEDs in the leaves are glowing in randomly paced greens.

runLeaves();
runBase();

When the head of the breath reaches the top of the tree, the high current LEDs then begin to glow in a whiteish blue. This signals that the tree is breathing at the same pace as the person sitting underneath it.

leds.show();

Since we’ve queued up all of the LEDs, it’s now time to send the data over the line and update the tree for this loop. There will be dozens of loops per second, enough to make the tree’s many LEDs look fluid in their motion.

The dispatcher board

Finally, because we’re using a 12 channel SPI DAC on the dispatcher so that we can send digital signals up the long trunk of the tree to later be converted to analog signals used to set brightness of the high current LEDs, we need to make the simple transactions over SPI.

/**
 * Set the analog output on the dispatcher board.
 * Channels are numbered 1 to 12 inclusive (THEY DON'T START AT ZERO !!) 
 * value is 0-255 range analog output of the dac/LED brightness
 */
void dispatcher(uint8_t chan, uint8_t value) {
    // We could normalize here to a "real" range
    // There's nothing below 45 because below 0.5 the pico buck is off
    // value = value * 210 / 255;
    // if (value > 0) value += 45;

    // take the SS pin low to select the chip:
    SPI.beginTransaction(dispatcherSPISettings);

    digitalWrite(slaveSelectPin, LOW);
    //  send in the address and value via SPI:
    SPI.transfer(flipByte((chan & 0x0F) << 4));
    SPI.transfer(value);
    // take the SS pin high to de-select the chip:
    digitalWrite(slaveSelectPin,HIGH);

    SPI.endTransaction();
}

5. Powering ten trees in Grove

Running an electronics installation out in the desert presents a few power problems. First is that there is nowhere to plug in, so all of the energy you’re going to need, whether it is stored or rechargeable, is going to have to be brought out there on the playa with you.

We quickly decided on running the installation on solar-powered deep cycle batteries. The cost for the batteries was mitigated slightly by the fact that we already had a 1.2 kW solar array handy. In past years you could affordably rent solar arrays from non-profits (like Black Rock Solar, who have written about how to solarize your playa art installation), but changes in Nevada’s energy policy have meant that’s no longer an option. It’s kind of tragic and the New York Times recently covered how Solar City had to move out of the state.

The other option is to use a generator, but while relatively cheap, they are loud and would detract from the serenity of the installation. We could instead choose to run a generator in a baffle box and run AC power over a length 50 meter distance, but that was deemed un-Grove-like and we stuck with batteries.

Let’s take a look at what’s on the market.

Most batteries cost around 20 cents per Watt-hour. Let’s perform some calculations to figure out how much we need. Let’s look at a single tree. Most of the time a tree is going to be in a “rest” state, where nobody is actively using it. This means the tree is draped in green and the high current LEDs are in a lower power state.

About 5% of the time we’re going to be in active mode, with brighter LED colors on the 4 × 5 meter strips and 16 × high current LED colors.

 95% × ((4 LED strips × 1.50A @ 5V per strip) + (0.25A @ 5V base lighting) + (16 × 0.08A @ 12V))
+ 5% × ((4 LED strips × 1.75A @ 5V per strip) + (0.25A @ 5V base lighting) + (16 × 0.10A @ 12V))

= 0.95 * (4*1.5*5 + .25*5 + 16*.08*12) + 0.05 * (4*1.75*5 + .25*5 + 16*.1*12)

≈ 47W per tree

At 10 trees, that’s 470 watts of power. We expect the installation to run 10 hours (8pm - 6am). That’s 4,700 Watt-hours. We’re looking at a set of batteries that should cost (4700 Wh × $0.20/Wh) = $940.

What we did was put 3 6V 250 Ah batteries in series to boost it up to 18V instead of just using 2 6V batteries at 12V. We did this to limit the DC voltage drop between the battery array and the trees, each of which was between 10 and 20 meters away from the battery array. Since voltage drop is linear with respect to distance, the reduction from 18V to ~15V is a 16% drop but 12V to ~9V is a 25% drop. This prevents the high current LEDs from flickering, since they need a minimum of 10V to work.

We charged the batteries using Luke’s solar array that he just happened to have handy. Here’s Luke on the challenges we faced:

Sam and I had a few 5-minute discussions about how much power we needed, and this was inadequate: our installation often ran out of power around sunrise. I should have brought twice as many batteries and 1.5x the solar panels. By dumb luck, this ‘low power mode’ produced an interesting ‘dead red’ effect: the batteries at lowest levels provided only enough power for the red leds to pulse, leaving out all other colors. Unfortunately, the batteries needed desulfated for a month straight after playa and a few were still killed.

In the future, we’ll test the actual power consumption of our installation in the real world: with a kill-a-watt or other power meter, how much is your installation actually drawing over the course of 24 hours? Your battery capacity should be at least 4x this: 2x to keep from discharging more than 50%, and another 2x for when somebody (in our case, me) imbibes too much and forgets to move batteries to solar array until noon.</blockquote>

Installing the Installation

Before the trees go up we need to assemble them and give them a coat of spray paint. These trees are shaped steel tubes that need some gold applied.

All of the work is done at American Steel Studios in Oakland, California. We want to do as much work as possible before we get to the playa. Once we’re in the desert, anything we may need is going to be 6 hours round trip to Reno, whereas the Home Depot in Oakland is a 5 minute drive away.

Alas, as much as we try to avoid it, there’s plenty of firmware debugging to be done on the playa.

Naturally, firmware debugging often lasted well into the night.

Putting the trees up is also a ton of work. We prototyped the leaves at a small scale.

But once on the playa we realize it’s a lot more work to attach 16 individual leaves to each of the 10 trees simply as a matter of scale.

The trees go up a lot faster than individual subassemblies on the tree. This is a good photo of the Pareto principle for art installations. Putting up the first 80% of the installation by volume only took 20% of the time.

Enjoying the fruits of our labor

It’s dusty out there!

And as we did with Pulse & Bloom, these cushions are some of the only seating on the playa, offering a beautiful respite and place to recharge and re-energize from the heat of the playa.

The entire process lasted 3 months and involved 5 people on the electronics team, a half dozen people on fabrication, and another dozen people on assembly and installation. My hope is that others learn from our work and use some of the open-source firmware and designs for their own art installations.

If you’d like to bring Grove to your art or music festival, please contact Shilo Shiv Suleman.

I’d love to hear from you if you’re inspired or build your own art installation. Reach me @samuelclay on Twitter.

breath (n), breathe (v)

Open letter to my family in Ohio: I am still coming home for Thanksgiving this year

2016-11-21T13:38:10+00:00

Dear Mom and Pop,

This was going to be an awkward year for us from the start. Thanksgiving is normally a time when we, two dozen immigrant Jews and first-generation Americans, come together to eat a turkey stuffed with oranges, served with a side of smoked fish and a dozen competing salads.

Before the election, I thought the greatest thing that would divide our dinner table would be my recently adopted vegetarianism. But us Jews are all about dietary restrictions. Eight breadless days of weight loss every year during Passover. Fasting from food and water every year for the day of atonement. Two sets of plates for Shabbat and for everyday. I was certain that refusing meat wouldn’t stop me from feeling embraced and loved at the table.

A russian salad feast courtesy of my friend Andrey Petrov

But then last week you voted for Trump. Jewish refugees from the Ukraine now living in Ohio voted for Trump. You have told me several times that Obama is the worst president in our lifetime. And so you voted for Trump.

This letter would not have been written if this were just about politics. Both of you have always voted conservatively. And I wouldn’t be this livid if it were just about privatization of health care, or import tariffs, or the unchecked negative externalities of infrastructure spending on energy extraction. The political tide goes in and out. How we run the country makes for a spirited debate over the Thanksgiving dinner table and I welcome our family’s contrary viewpoints. But this is not about politics.

Voting for Trump is clearly a vote for hate. I know you voted against Hillary, and not “in favor” of Trump, but the action is the same. Your vote signals to me that you see our fellow citizens as less than human. History shows where this leads and history is not just words in a textbook for us. You are choosing to ignore our past.

Donald Trump Says He’d ‘Absolutely’ Require Muslims to Register

We would have seven times as many cousins if it weren’t for the Nazis. You helped elect a fascist and are now complicit in what’s going to happen to families both in and outside of our country.

It is not unreasonable for people to think that fascists, if given power and an attempt to govern, will moderate their views. But history repeats itself.

“Several reliable, well-informed sources confirmed the idea that Hitler’s anti-Semitism was not so genuine or violent as it sounded, and that he was merely using anti-Semitic propaganda as a bait to catch masses of followers and keep them aroused, enthusiastic, and in line for the time when his organization is perfected and sufficiently powerful to be employed effectively for political purposes.”

“You can’t expect the masses to understand or appreciate your finer real aims. You must feed the masses with cruder morsels and ideas like anti-Semitism. It would be politically all wrong to tell them the truth about where you really are leading them.”

I take Trump at his hate-filled words. Last time we spoke, you did not. You said he probably wouldn’t be fulfilling any of his promises, like the ones to register Muslims or deport Latinos. However, even if you do believe that his campaign was only hype, you still ignored despicable behavior and rhetoric. Normalizing racism is itself an act of racism.

Some positions are binary. You either care about the protection of minorities or you do not. I have friends now who will stand in the same shoes that my grandparents stood in before. And you knew, regardless of your enthusiasm for Trump’s economic policies, that these people would suffer. The increasing number of graffitied swastikas, along with other vile behaviors now edging into the mainstream, are the kind of atrocities your vote was supposed to suppress.

You taught me that my highest responsibility as a Jew is to never forget, to fight against discrimination. This was a common refrain told to me during seven years of Hebrew school. I take that responsibility seriously and that is what I am trying to do now. Elie Wiesel said “We must take sides. Neutrality helps the oppressor, never the victim. Silence encourages the tormentor, never the tormented.”

I understand why you voted to put Trump in office. It’s just hard for me to forgive you for it. And now is not the time to give bigotry a pass. I’m trying to live by the values you taught me, which is why I am only asking you to take our President at his word. And when he tells you of his bigoted promises to force members of a religion to register, you should be outraged.

I am coming home this Thanksgiving and it’s going to be painful, most of all for me. I try to be empathetic with how you feel about the state of our country, but what I do not understand is how you think that voting for a racist and hate-filled demogogue with no political experience is going to promote growth and peace. At best, it will alienate over half of this country, and at worst, history will repeat itself.

I am coming home because I want to believe the love that brings us together at Thanksgiving is strong enough to not only include a vegetarian, but also strong enough to allow you to understand my perspective and possibly even change your minds. I need my family with me in this fight.

Your son,
Samuel

Building Pulse & Bloom - an interactive biofeedback installation at Burning Man 2014

2014-09-06T06:00:00+00:00

This was my second year attending Burning Man. Many use Burning Man as a week to detach from their workweek and experience a new life of intense leisure. Not me, I come to Burning Man to build.

Pulse & Bloom is a 2014 honorarium installation. The core team of 6 people — Saba Ghole, Shilo Shiv Suleman, Rohan Dixit, Heather Stewart, Luke Iseman, and myself — built 20 interactive lotus flowers made out of steel and rowlux. Each lotus flower ranges from 8 to 18 feet tall, each of which lights up with your pulse. You and another person can put your hands on a couple of Hamsa hands at the base of the lotus flower and your respective heartbeats will light up the flower.

We’ve gotten some great press coverage at the BBC, The Guardian, The Atlantic’s Big Picture twice, CBS News, NBC News, and MSNBC.

As usual, the complete source code for Pulse & Bloom is on GitHub.

Your heartbeat in light

Here are a couple videos of all twenty lotus flowers in full working order.

Each lotus flower is blue until a person or two sits down at its base and places their hand on the pulse sensor. You can see the Hamsa hand and its embedded pulse sensor in this shot of my girlfriend Brittany and me working on keeping the electronics going.

Photo credit Jim Urquhart / Reuters

When a pulse is read, the lotus flower shoots the heartbeat up the stem and into the petals, where it blooms in a brilliant display of amber. When two people’s hands are being measured, both of their heartbeats are shown as two distinct colors.

How the electronics are made

There are five stages to making the electronics:

Making the custom circuit boards
Making the custom pulse sensors
Driving the high current LEDs
Writing the firmware
Powering the lotuses

1. Making the custom circuit boards

The circuit board controls all of the lighting, sensors, timing, and debugging sequences. A reliable circuit board couldn’t just be an Arduino and a breadboard. I decided to use OSH Park and OSH Stencils to fabricate inexpensive circuit boards. I ultimately went through seven revisions while we worked out the final design of the lotuses. This included adding additional lights, additional sensors, controls for EL wire, and better power management using an external buck converter.

This board has support for multiple high current petal LEDs driven by digital RGB pins (used for fading colors in and out using PWM) and in multiple voltages. The high current petal LEDs runs on 12V, which comes directly off the battery, the ATmega328p chip and stem LEDs run at 5V, and the pulse sensor runs at 3.3V.

To convert 12V to 5V I use a $3 switching voltage regulator from Electrodragon. This requires a +/- connection for both 12V in and 5V out. To convert 5V to 3.3V I used a linear voltage regulator soldered directly on the board, since the current requirements of the pulse sensor were around 20mA. The heat dissipated was negligible compared to the rest of the circuit.

I also added terminal connections for two 5 meter LEDs that wrapped around the tall lotus stem. We attached two 5 meter LED strips around the stems because when two people put their hands on the two pulse sensors, we need an easy way to show both heartbeats without one winning out over the other. When only one person’s hand in being measured, both 5 meter light strips show the same color, which makes it that much brighter for a single person.

Lastly, the two pulse sensors terminate their I2C wires directly on the board. I used two separate I2C channels instead of one to cut down on time. I could easily have put both pulse sensors on the same I2C connections, but that would’ve required both pull-up resistors on the SDA and SCL data lines as well as a rewrite of the timing functions for the sensor.

All of these terminations are made using 2.5mm and 3.5mm pitch screw terminals. In hindsight I would have used female JST-SM mounted connectors and ordered custom wires with JST-SM male connectors. I assumed the lowest common denomenator would be bare tinned wire, but all of the bare wires could easily have been switched over to polarized, latching connectors. This would have reduced over 90% of the field work I had to perform on boards, as their wire would fall out of the screw terminals due to not being screwed in with enough force.

The board was laid out to be as big as a pack of gum. All of the 12V traces are thickened and isolated on the right side of the board. They are rated for 3 amps although they would end up only driving 1 amp on the playa.

These boards are then stenciled with solder paste and populated with their chips and passive components.

An inexpensive hot plate is used to reflow the solder. The chip is in a TQFP package, which has a 0.5mm pitch between pins. This makes it nearly impossible to hand solder. This stencil and reflow technique works well and my yield stayed high at around 95%.

Finally, the board is ready to be populated with screw terminals.

The final board in a dust-proof enclosure.

2. Making the custom pulse sensors

This was both the riskiest piece of the puzzle and also the most fun to build. In order to show your heartbeat on the lotus, I need to have a clear reading of your pulse. There are a fair number of issues with most off-the-shelf heartbeat sensors, including:

Cost: While a $50 pulse sensor is nice, it’s way out of our budget. We spent $6 in components to make each of our pulse sensors for a total of 40 sensors (two per lotus).
Design affordance: There were a fair number of pulse sensors that required an infrared light on one side of your finger and an infrared detector/receiver on the other. This clamping of your finger wasn’t something we could get away with in the desert. We needed a sensor you could just touch and hold on one side. It needed to be a simple interface so we wouldn’t have to show any instructions.
Reliability: When a sensor gets covered in dust, will it still work? Infrared light, thankfully, passes through a layer of dust and can read the changes in blood flow in your finger. Some options were entirely visual and they would have performed quite poorly out on the playa.

The first prototype I built suffered from the design affordance and reliability issues, although it worked pretty well in ideal conditions.

We ended up finding an IC by Silicon Labs called the Si114x, which uses three LEDs — two infrared and one visible — and a small QFN-10 sized light sensor. The original sensor we used was the Modern Device pulse sensor, which also provided firmware and ideas for a board layout. The folks at Modern Device were kind enough to offer advice on how they built their sensor and about how to fix the infrared LED issues we hit. I owe them beers for saving me from many more excruciating hours of trying to build sensors that don’t sense.

I built out a small PCB the size of a fingertip.

This tiny IC is a bit tricky to solder as it has no leads and the pins are extremely close together. My yield dropped to about 80%, but 4 out of every 5 pulse sensors I built worked perfectly the first time. If they failed, I would remount them on the hot plate and try wicking away any solder bridges I could find. This worked only about half the time. After that I gave up and now have a plastic cup full of broken pulse sensors.

Finally the sensor is hooked up and a tiny red light is emitted, letting people know where to put their fingers.

3. Driving the high current LEDs

What turned these lotuses from flowers into gems are the high current LEDs mounted in the petals at the top. There are 9 of these high current LEDs per lotus, split into groups of three, each driven by a constant current driver.

If you were to look at one of these LEDs from a few feet away, you would immediately see spots in your eyes. They are extremely bright pinpoints of light. The fact that they are also full color and need a heatsink due to their brightness means that you won’t just find these in an easy package ready for plugging in.

Photo credit Jim Urquhart / Reuters

Normally a single LED is powered by a single constant current driver. This driver can drive up to 1A of current at 12V. Because we were only using a single channel of color (blue) in the rest state, which is where the lotus spent most of its time, we could triple the number of LEDs driven by a single constant current driver.

When in use the petals glow amber, which uses two channels (100% red, 50% green) but only for a moment while at peak current. So while the peak current is above what this constant current driver is rated for, it’s only at peak and therefore within our tolerance.

Using a Chinese distributor, we bought these Sparkfun high current LEDs for $0.86 each instead of the full $15. However, we also bought 80 of Sparkfun’s PicoBucks to use as our constant current driver. While we could have built this ourselves to save money, buying 80 of something at $15 each is still only $1.2k, while building them ourselves would only have saved a few hundred dollars.

We bought 200 high current LEDs, all of which had to have their 6 anode and cathode connections soldered.

In order to connect 9 high current LEDs to the board, we need to drive them in groups of three. Each group has 6 connections: red, green, blue anodes, and red, green, blue cathodes. The wiring diagram for this setup can get a bit rats nesty, but the end result was fairly easy to work with, as the picobuck groups didn’t cross.

Finally, a shot of a complete picobuck with the wire connectors in the background.

4. Writing the firmware

The complete source code for Pulse & Bloom is on GitHub. There you can find the firmware used to program the main circuit board’s ATmega328p chip, as well as designs for the laser cut cowl that sits over the pulse sensor’s Si1143x IC.

The easiest way to read the firmware is to dive into src/pulse.cpp. It has all of the pulse and rest states and handles the high level logic.

The state machine that runs the entire routine is determined by a couple of critical measurements. The program takes a measurement of both pulse sensors and determines whether a finger is covering either of them and whether or not that finger has an active pulse going.

// Modes
void determinePlayerMode();
void determineFingerMode(int sensor1On, int sensor2On);
void resetStem(PulsePlug *pulse);
uint8_t adjustBpm(PulsePlug *pulse);

When there are no fingers on either of the pulse sensors, the program runs the rest state, which is a blue-topped lotus with a small blue snake running up and down the stem. The program is merely waiting for somebody to put their finger on a sensor.

// State: resting
void runResting();
void runRestStem();
void runRestStem(PulsePlug *pulse, int16_t currentLed);
void clearStemLeds(PulsePlug *pulse);
void beginPetalResting();
bool runPetalResting();

The firmware for the pulse sensor originally came from Modern Device’s pulse sensor. Before a heartbeat is shown an accurate measurement of a heartbeat needs to be read. In order to determine whether a heartbeat is found and at what speed, a number of light detection measurements are taken and analyzed.

Modern Device’s firmware simply finds the high frequency curve (the heartbeat) and the low frequency curve (the light sensors leveling out) and then use a simple peak and valley hueristic to determine the moment a heartbeat begins. This can take up to two or three seconds at first, so a bit of unwinding animation prepares you when you first put your finger on the sensor. I modified the firmware to account for multiple pulses on the same lotus and to have thresholds that worked better for the desert.

When a finger is detected, the stem snake lights shoot backwards up and down the lotus in prep for a heartbeat. This looks seamless as it clears the stem. This way a heartbeat doesn’t interrupt the rest state.

// State: end resting
void beginSplittingStem();
void runSplittingStem();
void runSplittingStem(PulsePlug *pulse, int16_t currentLed);

When a heartbeat is detected, it is first shot up the stem. The color is determined by how many pulse sensors are being used. 1 heartbeat shows amber. 2 heartbeats show in white and light red.

// State: stem rising
bool runStemRising(PulsePlug *pulse, PulsePlug *shadowPulse);

Once the heartbeat reaches the top of the stem, the petals then fill with light.

// State: petal rising
void beginPetalRising();
bool runPetalRising();

After a set delay, the petal slowly lose light while waiting for the next heartbeat.

// State: petal falling
void beginPetalFalling();
bool runPetalFalling();

Lots of debugging messages have been left in the code and are accessible using the Serial pin on the board. Just turn on USE_SERIAL, which is commented out at top. Note that this increases binary code size by about 2.5K. I wrote a lot of logging.

// Debugging
void printHeader();
void blink(int loops, int loopTime, bool half);
int freeRam ();

5. Powering the lotuses

While much of what I built above came out of knowledge I already had, learning how to power this large of an installation off just a battery was all new to me. I’m used to microelectronics that run off a coin cell or AA batteries.

Measuring current and power usage

First, in order to figure out how big of a battery we needed, we had to measure how much power we were taking. I hooked up an ammeter in series with a single lotus to measure the current draw. In rest state, a single lotus drew 0.75A at 12V. In the active pulsing heartbeat state, a single lotus drew 1.5A at 12V. Since a lotus spends 95% of its time at rest, we rounded the average current consumption to 1A.

Twenty lotuses at 1A at 12V meant we needed 240Ah to sustain a 12 hour night. A car battery was recommended, but car batteries can only discharge down to 80% without irreparable harm. However, a marine deep-cycle battery can go down to 20% without harm.

This 150 lb. battery has enough capacity, although we ended up adding a couple 6V batteries in series (to boost them to 12V) and then running them in parallel to offset some of the load.

Dealing with the voltage drop

A big issue we ran into was the voltage drop across the power lines. We placed the batteries on the edge of the installation, which meant some of the lotuses had 20 meters of wire between them and the battery. The voltage drop per 10 meter section is nearly 2V, which means that the voltage reaching the further lotuses was down to 7.5V.

The high current LEDs were not able to be smoothly driven at this low of a voltage, causing them to flicker. We determined that a voltage drop was responsible for the flickering, which got worse the further the lotus sat from the batteries. But when we discovered this the wires had already been trenched 6 inches beneath the playa. A day of work lost, but we sucked it up and ripped out all of the ground wiring to accommodate the battery which had to be moved into the center of the installation.

At the end of each night we had to bike out with a trike and carry all 300 lbs. of batteries back to camp, where they were hooked up to a 1 kW solar array, where they were charged at 48A over 6 hours.

Prototyping the lotuses

Back at American Steel in Oakland, the lotus stems, bases, and petals were ready to be hooked up. These twenty lotus stems were bent by Heather. They range from 6ft to 16ft in length and each weighs 50 lbs.

Such a heavy stem needs a larger base and heavy anchors to stay upright in the wind.

We placed the lily pad over the base to cover it up and then added all of the electronics. Lights, sensors, and circuit boards all had to be mounted.

This is a photo of our first complete lotus flower. Just compare its sheer size to Shilo.

Once we were confident that one lotus would successfully light we left the other 19 lotuses packed away for assembly on the playa.

A dusty scene

We drove out in the biggest rental car I could get my hands on. Our minivan is full of electronics, bicycles, tents, costumes, coolers full of fruit and veggies, dry snacks, and water.

Since we were early arrival, they give you these red bracelets. They say Work hard, don’t do stupid shit.

The boards would accumulate dust on them everyday. Our plastic enclosures turned out to be too big for the holes we made in the platform. So we ended up using ziploc bags. These baggies stayed attached, but the only reason they didn’t cause any issues is that the boards worked just fine in the dust, as you can see here.

If dust was a real problem for the boards, then I would have spent a whole lot more time making a tight fitting enclosure and a hole for it that protects it both from the elements and from people.

The playa gets covered in dust storms regularly throughout the week. A particularly nasty dust storm is pictured here, eating our poor lotus flowers alive.

Although during the day when its not dust storming the lotuses offer a cozy respite from the heat of the playa.

Photo credit Jim Urquhart / Reuters

The entire process lasted 4 months with 2.5 months of nearly full-time work on my part. I’m thrilled that I get to open-source both the process and the firmware. I hope others who build art installations can use some of my lessons learned here. I’m happy to answer any questions on Twitter.

See you next year on the playa!

Adventures in Wearable Electronics - Making a Light-up Dress

2014-01-15T11:07:50+00:00

For New Year’s Eve 2014, my girlfriend and I went to a dance party where wearable electronics were not only encouraged but also on display from a variety of hobbyists. I decided to use this as an opportunity to combine two of my favorite hobbies: sewing and electronics.

It is my goal to encourage more people to weave wearable electronics into their own clothing. It’s the future and we might as well look the part. Plus it’s easy to get started and to modify existing code.

The full source code for this dress is available on GitHub.

Hardware

I attached six addressable LED strands from Sparkfun ($20 each) to the lining of Brittany’s dress, and then used a Flora module from Adafruit ($25) to control them. I then used a 3 x AAA battery holder from Adafruit ($2).

Setup

I used Adafruit’s NeoPixel library to control the LEDs. There were 60 LEDs per 1 meter-long strand. We only needed 40 of the LEDs, but instead of cutting them off, we simply sewed the unused third underneath the strand and cut the software off at 40 LEDs. This way we can repurpose the LED strands when we decide to move them to a new dress.

In order to make the connections between the LED strands and the Flora module, I used 30 AWG wire, which is an extremely thin and light wire. The gauge is 0.01” and is as fine as thread. This allowed me to sew the wire into the fabric. I could have used conductive thread, but this wire wrap has a sheath that prevents it from shorting other wires when they touch. It’s also extremely light-weight, so having 18 wires (3 wires per LED strand: power, ground, data) looping around the dress wasn’t an issue.

I also want to mention that the code below is hard-coded for six stands. There is a fine line between a hack and a project, and for this, due to my limited time budget, was closer to hack than reusable project. You can easily abstract the code below to account for more or fewer strands, but I was able to ship before midnight on NYE, so I’m considering it a success.

void setup() {
  // To ensure that the first random color in `loop` is never the same
  randomSeed(analogRead(0));

  led_a.begin();
  led_b.begin();
  led_c.begin();
  led_d.begin();
  led_e.begin();
  led_f.begin();

  clearLEDs(true);
}

void loop() {
  for (int i=0; i<2; i++) {
    hulahoop(randomColor(), random(20,60));
  }

  sparkle(randomColor(), random(30,70));

  raindrops(randomColor(), random(20,60));

  spiral(randomColor(), random(15,30));
}

Above we have the code for setup and loop, the two main Arduino routines. Notice that I am repeating the hula hoop routine, since it’s pretty quick and looks good on repeat.

I also want to note that every single routine gets its own random color and random delay. This bit of randomness is something I weave into all of my wearable electronics, since it goes just a bit further than off-the-shelf components and shows that there was some intelligence behind the routine.

By giving a random delay to each routine I am actually changing the speed of the routine. Sometimes the raindrops would fall quickly, sometimes the hula hoop would have a slow fall and rise. It’s all part of making mesmerizing patterns.

Hula hoop

For the hula hoop routine, I chose to use cylons at equal positions that move up and down the strand. To make the transition from one LED to the next, I use a cylon, which is a fancy way of saying that the LEDs immediately above and below the active LED are also on, but at a reduced brightness.

In this case the cylon is 5 LEDs wide. 100% brightness for the middle/active LED, 1/18th brightness for the two adjacent LEDs, and 1/36th brightness for the two LEDs further out from there.

So what you see to the left are actually 5 LEDs turned on per-strand, although they get quite dim as you get further from the active LED. You can adjust the dimness of the adjacent LEDs by adjusting the weight parameter.

void hulahoop(unsigned long color, byte wait) {
  // weight determines how much lighter the outer "eye" colors are
  const byte weight = 18;  
  // It'll be easier to decrement each of these colors individually
  // so we'll split them out of the 24-bit color value
  byte red   = (color & 0xFF0000) >> 16;
  byte green = (color & 0x00FF00) >> 8;
  byte blue  = (color & 0x0000FF);

  // Start at closest LED, and move to the outside
  for (int i=0; i<=LED_COUNT-1; i++) {
    clearLEDs(false);
    led_a.setPixelColor(i, red, green, blue);
    led_b.setPixelColor(i, red, green, blue);
    led_c.setPixelColor(i, red, green, blue);
    led_d.setPixelColor(i, red, green, blue);
    led_e.setPixelColor(i, red, green, blue);
    led_f.setPixelColor(i, red, green, blue);
    // Now set two eyes to each side to get progressively dimmer
    for (int j=1; j<3; j++) {
      byte redWJ = red/(weight*j);
      byte greenWJ = green/(weight*j);
      byte blueWJ = blue/(weight*j);
      if (i-j >= 0) {
        led_a.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_b.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_c.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_d.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_e.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_f.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
      }
      if (i-j <= LED_COUNT) {
        led_a.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_b.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_c.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_d.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_e.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_f.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
      }
    }
    led_a.show();
    led_b.show();
    led_c.show();
    led_d.show();
    led_e.show();
    led_f.show();
    delay(wait);
  }

  // Now we go back to where we came. Do the same thing.
  for (int i=LED_COUNT-2; i>=1; i--) {
    clearLEDs(false);
    led_a.setPixelColor(i, red, green, blue);
    led_b.setPixelColor(i, red, green, blue);
    led_c.setPixelColor(i, red, green, blue);
    led_d.setPixelColor(i, red, green, blue);
    led_e.setPixelColor(i, red, green, blue);
    led_f.setPixelColor(i, red, green, blue);
    // Now set two eyes to each side to get progressively dimmer
    for (int j=1; j<3; j++)
    {
      byte redWJ = red/(weight*j);
      byte greenWJ = green/(weight*j);
      byte blueWJ = blue/(weight*j);

      if (i-j >= 0) {
        led_a.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_b.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_c.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_d.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_e.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
        led_f.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
      }
      if (i-j <= LED_COUNT) {
        led_a.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_b.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_c.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_d.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_e.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
        led_f.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
      }
    }
    led_a.show();
    led_b.show();
    led_c.show();
    led_d.show();
    led_e.show();
    led_f.show();
    delay(wait);
  }
}

Sparkles

This is by far the easiest routine to program yet the one that brought the most attention. It simply flashes a random LED across all of the LED strips.

void sparkle(unsigned long color, uint8_t wait) {
  for (int i=0; i < LED_COUNT * STRIP_COUNT; i++) {
    clearLEDs(true);
    int strip = floor(random(STRIP_COUNT));
    int led = floor(random(LED_COUNT));
    switch (strip) {
      case 0:
        led_a.setPixelColor(led, color);
        led_a.show();
        break;
      case 1:
        led_b.setPixelColor(led, color);
        led_b.show();
        break;
      case 2:
        led_c.setPixelColor(led, color);
        led_c.show();
        break;
      case 3:
        led_d.setPixelColor(led, color);
        led_d.show();
        break;
      case 4:
        led_e.setPixelColor(led, color);
        led_e.show();
        break;
      case 5:
        led_f.setPixelColor(led, color);
        led_f.show();
        break;
    }
    delay(wait);
  }
}

Raindrops

This is by far the most difficult of the routines. This one sends down cylons (5 LEDs, with the center LED being the brightest and the adjacent LEDs becoming decreasingly bright, so as to give the impression of smoother animation).

But you should notice that the next raindrop starts when the previous raindrop is half-way down the dress. In order to make it seamless, at the beginning of the routine I actually start another LED at the half-way mark, referred to in the below code as e_alt. This means that there is no point at which the dress looks spent and is waiting for the routine to start over.

void raindrops(unsigned long color, byte wait) {
  // weight determines how much lighter the outer "eye" colors are
  const byte weight = 18;  
  // It'll be easier to decrement each of these colors individually
  // so we'll split them out of the 24-bit color value
  byte red = (color & 0xFF0000) >> 16;
  byte green = (color & 0x00FF00) >> 8;
  byte blue = (color & 0x0000FF);
  double sludge = 0.5;
  double a_offset = 0;
  double b_offset = 3;
  double c_offset = 1;
  double d_offset = 2;
  double e_offset = 4;
  double f_offset = 5;

  // Start at closest LED, and move to the outside
  for (int i=0; i<LED_COUNT*(STRIP_COUNT-1)*sludge+LED_COUNT*10; i++) {
    clearLEDs(false);
    double n = i % (int)(LED_COUNT*(STRIP_COUNT+1)*sludge-LED_COUNT*sludge);
    double led_count = (double)LED_COUNT;

    bool a_on = (sludge*a_offset*led_count) <= n && 
                n <= (sludge*a_offset*led_count+led_count);
    bool b_on = (sludge*b_offset*led_count) <= n && 
                n <= (sludge*b_offset*led_count+led_count);
    bool c_on = (sludge*c_offset*led_count) <= n && 
                n <= (sludge*c_offset*led_count+led_count);
    bool d_on = (sludge*d_offset*led_count) <= n && 
                n <= (sludge*d_offset*led_count+led_count);
    bool e_on = (sludge*e_offset*led_count) <= n && 
                n <= (sludge*e_offset*led_count+led_count);
    bool e_alt= (sludge*a_offset*led_count) <= n && 
                n <= (sludge*a_offset*led_count+led_count*sludge);
    bool f_on = (sludge*f_offset*led_count) <= n && 
                n <= (sludge*f_offset*led_count+led_count);

    if (!a_on && !b_on && !c_on && !d_on && !e_on && !f_on) {
      clearLEDs(true);
      break;
    }

    int a = n-a_offset*LED_COUNT*sludge;
    int b = n-b_offset*LED_COUNT*sludge;
    int c = n-c_offset*LED_COUNT*sludge;
    int d = n-d_offset*LED_COUNT*sludge;
    int e = n-e_offset*LED_COUNT*sludge;
    if (e_alt) {
      e = a+(LED_COUNT/2);
    }
    int f = n-f_offset*LED_COUNT*sludge;

    if (a_on) led_a.setPixelColor(a, red, green, blue);
    if (b_on) led_b.setPixelColor(b, red, green, blue);
    if (c_on) led_c.setPixelColor(c, red, green, blue);
    if (d_on) led_d.setPixelColor(d, red, green, blue);
    if (e_on || e_alt) led_e.setPixelColor(e, red, green, blue);
    if (f_on) led_f.setPixelColor(f, red, green, blue);

    // Now set two eyes to each side to get progressively dimmer
    for (int j=1; j<3; j++) {
      byte redWJ = red/(weight*j);
      byte greenWJ = green/(weight*j);
      byte blueWJ = blue/(weight*j);

      if (a-j >= 0 && a_on) 
        led_a.setPixelColor(a-j, redWJ, greenWJ, blueWJ);
      if (b-j >= 0 && b_on) 
        led_b.setPixelColor(b-j, redWJ, greenWJ, blueWJ);
      if (c-j >= 0 && c_on) 
        led_c.setPixelColor(c-j, redWJ, greenWJ, blueWJ);
      if (d-j >= 0 && d_on) 
        led_d.setPixelColor(d-j, redWJ, greenWJ, blueWJ);
      if (e-j >= 0 && e_on) 
        led_e.setPixelColor(e-j, redWJ, greenWJ, blueWJ);
      if (f-j >= 0 && f_on) 
        led_f.setPixelColor(f-j, redWJ, greenWJ, blueWJ);

      if (a-j <= LED_COUNT && a_on) 
        led_a.setPixelColor(a+j, redWJ, greenWJ, blueWJ);
      if (b-j <= LED_COUNT && b_on) 
        led_b.setPixelColor(b+j, redWJ, greenWJ, blueWJ);
      if (c-j <= LED_COUNT && c_on) 
        led_c.setPixelColor(c+j, redWJ, greenWJ, blueWJ);
      if (d-j <= LED_COUNT && d_on) 
        led_d.setPixelColor(d+j, redWJ, greenWJ, blueWJ);
      if (e-j <= LED_COUNT && e_on) 
        led_e.setPixelColor(e+j, redWJ, greenWJ, blueWJ);
      if (f-j <= LED_COUNT && f_on) 
        led_f.setPixelColor(f+j, redWJ, greenWJ, blueWJ);
    }
    led_a.show();
    led_b.show();
    led_c.show();
    led_d.show();
    led_e.show();
    led_f.show();
    delay(wait);
  }
}

Spiral

This routine is better in theory than in practice. The idea is to have a quick succession of LEDs light up in a spiral pattern. This would work a bit better with more LED strands wrapped around the dress.

In this case, I’m simply looping through the strands and lighting up successive LEDs. But the nice thing about this routine is that it has a dramatic crescendo to the top, at which point the hula hoop routine begins and it looks like the action started at the bottom and quickly worked its way up to the top, only to smoothly fall back down. It’s a mesmerizing effect.

void spiral(unsigned long color, byte wait) {
  const byte weight = 18;  
  byte red = (color & 0xFF0000) >> 16;
  byte green = (color & 0x00FF00) >> 8;
  byte blue = (color & 0x0000FF);

  for (int level=LED_COUNT-1; level >= 0; level--) {
    for (int strip=0; strip < STRIP_COUNT; strip++) {
      clearLEDs(false);

      switch (strip) {
        case 0:
          led_f.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_a.setPixelColor(level, color);
          led_b.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
        case 1:
          led_a.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_b.setPixelColor(level, color);
          led_c.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
        case 2:
          led_b.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_c.setPixelColor(level, color);
          led_d.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
        case 3:
          led_c.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_d.setPixelColor(level, color);
          led_e.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
        case 4:
          led_d.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_e.setPixelColor(level, color);
          led_f.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
        case 5:
          led_e.setPixelColor(level, red/weight, green/weight, blue/weight);
          led_f.setPixelColor(level, color);
          led_a.setPixelColor(level, red/weight, green/weight, blue/weight);
          break;
      }

      led_a.show();
      led_b.show();
      led_c.show();
      led_d.show();
      led_e.show();
      led_f.show();
      delay(wait);
    }
  }  
}

Random Colors

Since randomness is the spice that gives this dress its mesmerizing qualities, it’s important to have a good list of colors to use.

unsigned long COLORS[] = {
  NAVY, DARKBLUE, MEDIUMBLUE, BLUE, DARKGREEN, GREEN, TEAL, DARKCYAN, 
  DEEPSKYBLUE, DARKTURQUOISE, MEDIUMSPRINGGREEN, LIME, SPRINGGREEN, 
  AQUA, CYAN, MIDNIGHTBLUE, DODGERBLUE, LIGHTSEAGREEN, FORESTGREEN, 
  SEAGREEN, DARKSLATEGRAY, LIMEGREEN, MEDIUMSEAGREEN, TURQUOISE, 
  ROYALBLUE, STEELBLUE, DARKSLATEBLUE, MEDIUMTURQUOISE, INDIGO, 
  DARKOLIVEGREEN, CADETBLUE, CORNFLOWERBLUE, MEDIUMAQUAMARINE, DIMGRAY, 
  SLATEBLUE, OLIVEDRAB, SLATEGRAY, LIGHTSLATEGRAY, MEDIUMSLATEBLUE, 
  LAWNGREEN, CHARTREUSE, AQUAMARINE, MAROON, PURPLE, OLIVE, GRAY, 
  SKYBLUE, LIGHTSKYBLUE, BLUEVIOLET, DARKRED, DARKMAGENTA, SADDLEBROWN, 
  DARKSEAGREEN, LIGHTGREEN, MEDIUMPURPLE, DARKVIOLET, PALEGREEN, 
  DARKORCHID, YELLOWGREEN, SIENNA, BROWN, DARKGRAY, LIGHTBLUE, 
  GREENYELLOW, PALETURQUOISE, LIGHTSTEELBLUE, POWDERBLUE, FIREBRICK, 
  DARKGOLDENROD, MEDIUMORCHID, ROSYBROWN, DARKKHAKI, SILVER, 
  MEDIUMVIOLETRED, INDIANRED, PERU, CHOCOLATE, TAN, LIGHTGRAY, 
  THISTLE, ORCHID, GOLDENROD, PALEVIOLETRED, CRIMSON, GAINSBORO, PLUM, 
  BURLYWOOD, LIGHTCYAN, LAVENDER, DARKSALMON, VIOLET, PALEGOLDENROD, 
  LIGHTCORAL, KHAKI, ALICEBLUE, HONEYDEW, AZURE, SANDYBROWN, WHEAT, 
  BEIGE, WHITESMOKE, MINTCREAM, GHOSTWHITE, SALMON, ANTIQUEWHITE, 
  LINEN, LIGHTGOLDENRODYELLOW, OLDLACE, RED, FUCHSIA, MAGENTA, 
  DEEPPINK, ORANGERED, TOMATO, HOTPINK, CORAL, DARKORANGE, LIGHTSALMON, 
  ORANGE, LIGHTPINK, PINK, GOLD, PEACHPUFF, NAVAJOWHITE, MOCCASIN, 
  BISQUE, MISTYROSE, BLANCHEDALMOND, PAPAYAWHIP, LAVENDERBLUSH, SEASHELL, 
  CORNSILK, LEMONCHIFFON, FLORALWHITE, SNOW, YELLOW, LIGHTYELLOW, IVORY
};

unsigned long randomColor() {
  return COLORS[random(sizeof(COLORS)/sizeof(unsigned long))];
}

Dancing to 2014

And what good is a beautiful light-up dress without a well lit dance partner? Here I am decked out in blue EL wire. I spent the better part of three hours sewing this wire into the edges of one of my jackets. But while hand-sewing can take half a day, the result is a great fit and a capable match for Brittany’s dress.

The full source code for this dress is available on GitHub.

Building a living photo frame with a Raspberry Pi and a motion detector

2014-01-02T06:00:00+00:00

Every hardware hacker has a start, and this one is mine. My girlfriend bought me a Raspberry Pi for my birthday, and so I became determined to build something with it for her birthday two months later.

As you can see above, I built a photo frame that has a few interesting parts. For one, the software which runs the photo frame, which I explore below, keeps the photos fresh from Instagram and Flickr. It then displays a random photo for a configurable six seconds. Secondly, there is a motion detector, built using a PIR sensor, which only turns the monitor on when somebody walks by.

This photo frame is easy to build, but it does take a bit of know-how. Mainly, you should feel comfortable soldering wires and mounting the screen and Raspberry Pi to a board or other object. The hard part for me was figuring out how to turn the monitor on and off through the command line.

Everything else is gravy, from configuring wifi and autoboot/auto-login on the device to attaching and setting up the motion detecting PIR sensor. You can also use the eLinux guide to Raspberry Pi and its handy RPi Hardware Basic Setup wiki.

Parts

Raspberry Pi

I chose to use a Raspberry Pi for its simple wifi integration so that photos could be automatically updated. I didn’t want to have to load photos on to an SD card which could then be read by an Arduino.

Connecting the monitor was also trivial on a Raspberry Pi, where an Arduino, Maple, or Beagle Bone would require sourcing a connection between the monitor’s composite input and an output from the device.

Raspberry Pi, $29 on Adafruit.

Make note of the fact that you actually don’t see any of my connections on the top of the board (pictured below). In the below photo, where the Raspberry Pi is flipped vertically to show off the electrical connections, the monitor’s composite cable and the motion detecting PIR sensor’s red wires are soldered underneath.

This way the photo frame looks cleaner. If I had connected the monitor using the yellow composite cable, it would have to be with a male-to-male composite adapter, since both the Raspberry Pi and the monitor have a male RCA connection. This would jut out about 2 inches below the device, resulting in a messy look for the frame.

3.5” LCD Monitor

3.5” LCD Monitor, $45 on Adafruit

Note that if you do not plan to solder the composite cable’s two wires, you will need the ugly male-to-male adapter, sold for $1.50 on Adafruit.

There are a number of different sized LCD monitors:


1.5" LCD, $40	2" LCD, $40	2.5" LCD, $45


4.3" LCD, $50	7" LCD, $75	10" LCD, $150

4GB SD Card with Raspbian (Raspberry Pi + Debian)

4GB SD Card, $10 on Adafruit

This tiny SD card comes pre-loaded with Raspbian. If you prefer to use your own SD card and want to bootload it, just follow eLinux’s Easy SD Card Setup wiki.

Miniature Wifi on USB

USB Wifi, $11 on Adafruit

Unless you’re planning to use an ugly ethernet cable, this tiny wifi USB device works perfectly. It’s easy to setup as well. I followed Adafruit’s tutorial for setting up wifi on a Raspberry Pi.

Passive Infrared Motion Sensor

PIR sensor, $10 on Adafruit

This is a simple and inexpensive component that is responsible for turning the monitor on and off. The accuracy is great, as it never misses a beat, yet I haven’t found it to accidentally trigger in the night unless we walk by. It also has two adjustable dials on the back that allow you to control its sensitivity and delay before firing. Ladyada covers how it works.

Soldering Iron

Aoyue 937+, $60 on Amazon

In order to connect the PIR motion detector and the composite cables, without resorting to the ugly male-to-male adapter, you will need to use a soldering iron. I chose the Aoyue 937+ Digital Soldering Station. Works great and I’m quite happy with it. I should have bought more tips, though.

Frame

This is where you get creative. You effectively just need an enclosure, but I found that picture frames offer the greatest aesthetics-to-enclosure ratio. You just need something that can hold a Raspberry Pi and monitor taped to it. I used double-sided mounting tape as an adhesive, although the wires are being held up by the frame itself.

Software

Raspberry Pi setup

You’ll want to make sure you’re setup with the following:

Auto-login, so your Raspberry Pi doesn’t sit at a login prompt.
Auto-wifi, so you can download images automatically whenever your Raspberry Pi is turned on.
Disabled sleep, so your photo frame doesn’t shut off when you don’t want it to.

Downloading personal photos from Flickr

You’ll need to register your Flickr API app, which is a quick process. That way you can get a Flickr API key that you can then use to walk the photos from your account. You will also need your Flickr user id.

There are two Python library dependencies for this code:

pip install flickrapi
pip install requests

Once those are installed, save this script as download_flickr.py

#!/usr/bin/env python

import flickrapi
import requests

FLICKR_KEY = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
USER_ID = "25704617@N04"

def make_url(photo):
    # url_template = "http://farm{farm-id}.staticflickr.com/
    #                 {server-id}/{id}_{secret}_[mstzb].jpg"
    photo['filename'] = "%(id)s_%(secret)s_z.jpg" % photo
    url = ("http://farm%(farm)s.staticflickr.com/%(server)s/%(filename)s" 
           % photo)
    return url, photo['filename']

def main():
    print " ---> Requesting photos..."
    flickr = flickrapi.FlickrAPI(FLICKR_KEY)
    photos = flickr.walk(user_id=USER_ID)
    for photo in photos:
        url, filename = make_url(photo.__dict__['attrib'])
        path = '/home/pi/photoframe/flickr/%s' % filename
        try:
            image_file = open(path)
            print " ---> Already have %s" % url
        except IOError:
            print " ---> Downloading %s" % url
            r = requests.get(url)      
            image_file = open(path, 'w')
            image_file.write(r.content)
            image_file.close()

if __name__ == '__main__':
    main()

Downloading extra photos from Flickr by tag name

Part of the fun of this photo frame is that not only do all of my photos get shown randomly, but I introduced a hodgepodge of random photos by downloading photos from a specific Flickr tag. In this case, I added koala photos, which makes for a pleasant randomness.

Save the following command as download_koalas.sh or whatever you like as a tag.

FLICKR_TAG=koala && \
wget 'http://api.flickr.com/services/feeds/photos_public.gne?tags=$FLICKR_TAG' -O- \
| grep -Po 'http://[^.]+\.staticflickr[^"]+(_b.jpg|_z.jpg)' \
| wget -P /home/pi/photoframe/$FLICKR_TAG -nc -i-

Automatic downloading of new photos

In order to have the photos refreshed, you’ll need to have them download in the background. Add these two lines to your crontab with crontab -e if you’re using both the Flickr photo downloader and the Flickr tag downloader.

0 * * * * python /home/pi/photoframe/download_flickr.py
30 * * * * /home/pi/photoframe/download_koalas.sh

Slideshow

Now that we have the photos downloaded and refreshed at a regular interval, we need to get the slideshow running. We’ll use a simple app called the Linux framebuffer imageviewer. Stick this command into a slideshow.sh.

fbi -noverbose -m 640x480 -a -u -t 6 /home/pi/art/**/*

The option for time is set to 6 seconds, and it uses autozoom to automagically pick a reasonable zoom factor when loading images. The -u option randomizes the order.

Detecting movement

The slideshow is now running at fullscreen with a randomized assortment of Flickr photos, both your own and from favorite tags. But it’s running even when you’re not there! let’s use the PIR (motion) sensor to turn off the monitor after no movement has been detected for 60 seconds.

Save this file as pir.py.

#!/usr/bin/env python

import sys
import time
import RPi.GPIO as io
import subprocess

io.setmode(io.BCM)
SHUTOFF_DELAY = 60 # seconds
PIR_PIN = 25       # 22 on the board
LED_PIN = 16

def main():
    io.setup(PIR_PIN, io.IN)
    io.setup(LED_PIN, io.OUT)
    turned_off = False
    last_motion_time = time.time()

    while True:
        if io.input(PIR_PIN):
            last_motion_time = time.time()
            io.output(LED_PIN, io.LOW)
            print ".",
            sys.stdout.flush()
            if turned_off:
                turned_off = False
                turn_on()
        else:
            if not turned_off and time.time() > (last_motion_time + 
                                                 SHUTOFF_DELAY):
                turned_off = True
                turn_off()
            if not turned_off and time.time() > (last_motion_time + 1):
                io.output(LED_PIN, io.HIGH)
        time.sleep(.1)

def turn_on():
    subprocess.call("sh /home/pi/photoframe/monitor_on.sh", shell=True)

def turn_off():
    subprocess.call("sh /home/pi/photoframe/monitor_off.sh", shell=True)

if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        io.cleanup()

Turning the monitor on and off

There are two ways to turn the monitor on and off. Use the tvservice command to turn off the monitor port.

pi@raspberrypi ~/photoframe $ chmod 0744 monitor_off.sh 
pi@raspberrypi ~/photoframe $ cat monitor_off.sh 
tvservice -o

pi@raspberrypi ~/photoframe $ chmod 0744 monitor_on.sh 
pi@raspberrypi ~/photoframe $ cat monitor_on.sh 
tvservice -c "PAL 4:3" && fbset -depth 8 && fbset -depth 16

This method actually turns off the port, which works great except when you’re connected to an HDMI monitor and it shuts off when the port is turned off. When you walk into the room, the port is turned back on but the monitor is off, so it doesn’t come right back up. In this case, simply switch virtual terminals to blank out the screen using the chvt command.

pi@raspberrypi ~/photoframe $ chmod 0744 monitor_off.sh 
pi@raspberrypi ~/photoframe $ cat monitor_off.sh 
chvt 2

pi@raspberrypi ~/photoframe $ chmod 0744 monitor_on.sh 
pi@raspberrypi ~/photoframe $ cat monitor_on.sh 
chvt 7

Fixing the monitor edges

By default, the image won’t stretch to the edges of your monitor without cajoling.

Here’s the before photo:

And here’s with margin correction on the monitor:

To fix this, take a look at using RPiconfig. All you need to do is edit /boot/config.txt directly on the Raspberry Pi. The values you need to set are:

overscan_left=-6    # number of pixels to skip on left
overscan_right=-6   # number of pixels to skip on right
overscan_top=24     # number of pixels to skip on top
overscan_bottom=24  # number of pixels to skip on bottom

These are my values, but every monitor is different. In order to figure out the values, I would set the values using a binary search (set high then low then halfway between the two and repeat with the new halfway point being the high/low on the correct side), and then rebooting. Eventually I found optimal values.

Note that the values will be different from the boot screen to the photo viewer. Obviously, I optimized for the photo viewer, but that means the top and bottom of the boot screen is cut off. Not much better you can expect from a tiny $50 LCD monitor.

Also, if you need to rotate or flip the display, it’s easy.

display_rotate=0        Normal
display_rotate=1        90 degrees
display_rotate=2        180 degrees
display_rotate=3        270 degrees
display_rotate=0x10000  horizontal flip
display_rotate=0x20000  vertical flip

Automatic start of the photo frame software

You’ll want the software to start automatically on boot, so create a new init.d file at /etc/init.d/flickrd, and add the motion sensor and slideshow scripts to that new file:

sudo python /home/pi/photoframe/pir.py
/home/pi/photoframe/slideshow.sh

Then set the permissions with:

sudo chmod 755 /etc/init.d/flickrd

and finally register the script to be run at startup:

sudo update-rc.d flickrd defaults

Don’t forget to run the pir.py script as root, since you’ll need permissions to turn the monitor on and off.

Troubleshooting

Everything above should leave you with a photo slideshow that automatically updates your photos, displays them zoomed in and fullscreen in random order, shutting off the monitor when nobody is around.

If you used the code above with no issues, congratulations! You’re in a minority that can work with hardware and get everything right on the first try. For everybody else, we have to troubleshoot. Here are the issues that I ran into.

Test your LED

Just getting the Raspberry Pi to respond to my commands was tricky enough, so I wrote this basic program to just blink the onboard LED. This is the Hello, World of the Raspberry Pi.

import RPi.GPIO as GPIO
import time

LED_PIN = 18
def blink(pin):
    GPIO.output(pin,GPIO.HIGH)
    print " ---> On"
    time.sleep(.5)
    GPIO.output(pin,GPIO.LOW)
    print " ---> Off"
    time.sleep(.5)
    return

# to use Raspberry Pi board pin numbers
GPIO.setmode(GPIO.BOARD)
# set up GPIO output channel
GPIO.setup(LED_PIN, GPIO.OUT)
for _ in range(0,3):
    blink(LED_PIN)
GPIO.cleanup()

SSH’ing into your Raspberry Pi

You shouldn’t have to rely on an external keyboard and a tiny screen to debug your Raspberry Pi. I suggest using Pi Finder to locate the IP address, if it’s on your local network.

You can also use arp -a to find it.

Getting additional help

Turn to Stack Exchange’s new Raspberry Pi section. It’s still in beta as of early 2014, but there’s a whole lot of great questions.

Backbonification: migrating a large JavaScript project from DOM spaghetti to Backbone.js

2012-11-13T18:03:54+00:00

We’ve all done it. Our code base has one huge monolithic file, packed full of JavaScript spaghetti. It’s unwieldy, hard-to-debug, and has little to no separation of concerns. It is a nightmare to bring new engineers up to speed.

This blog post is about decomposing NewsBlur’s single-file 8,500 line JavaScript application into its component parts: 8 models, 12 views, 3 routers, 3 collections. This post explores patterns, techniques, and common pitfalls in migrating from vanilla JavaScript to Backbone.js. It covers moving routers, models, and views, and the process used to migrate a living app.

NewsBlur is a free RSS feed reader and is open-source. The benefit of being open-source is that you can see all of the changes I made in this migration by looking through the commit history.

As a bit of background, I worked on Backbone.js in its infancy, when Jeremy Ashkenas and I worked on DocumentCloud’s many open-source projects.

The Presentation

This post was written concurrently with a presentation. Depending on your style, you can either read on or flip through this deck. Both have the same content, but this post expands on every concept in the presentation.

There’s no need to go through the presentation. Just read on for the whole kaboodle.

Pre-reqs: Libraries

There are only two libraries you need to be intimately familiar with in order to make the most of your Backbone transition: Underscore.js and Backbone.js. That means not only being comfortable with reading the source code of these two libraries, but also knowing all of the methods exposed so you can reach into your grab-bag of tricks and pull out the appropriate function.

Underscore.js

Underscore.js is another DocumentCloud library that makes your code more readable and compact by providing useful functions that massage, filter, and jumble data.

One popular use of Underscore is creating short pipelines that take a large collection of models and filters it based on conditions. That much is easy. But there are other uses that are beneficial to know.

You should be comfortable with all enumerable methods. Think about all of your model collections as reduce-able, filterable, and selectable.

Here are two examples of Underscore.js at work:

// Get ids of all active feeds
_.pluck(this.feeds.select(function(feed) {
    return feed.get('active');
}), 'id');
// Returns: [42, 36, 72, ...]

// Count fetched/unfetched feeds
var counts = this.feeds.reduce(function(counts, feed) {
    if (feed.get('active')) {
        if (!feed.get('not_yet_fetched') || feed.get('has_exception')) {
            counts['fetched_feeds'] += 1;
        } else {
            counts['unfetched_feeds'] += 1;
        }
    }
    return counts;
}, {
    'unfetched_feeds': 0,
    'fetched_feeds': 0
});
// Returns: {'unfetched_feeds': 3, 'fetched_feeds': 42}

Backbone.js

The star of the show is Backbone.js. The entire backbone.js file is fewer than 1,500 lines long, and that’s with 228/1478 lines of whitespace (15%) and 389/1478 lines of comments (26%).

This is a basic example of the layout of the four main classes: models, views, collections, and routers. A fifth meta-class called Events is mixed in to each of these classes.

How to start

The first step is no easy task. Take your existing design and visually decompose it into its component views. Each view will be represented by either a single model or a combination of models. In fact, you can even have a view not be backed by a model at all.

Take the NewsBlur UI for example. It’s a standard three-pane view, with feeds, stories, and story detail:

Notice that there are multiple views inside other views. Some views are meant to be simple wrappers around other, more functional views.

On the left there is a list of feeds inside a list of folders. These folders and feeds can be embedded inside each other, creating a recursive structure that can be easily assembled by Backbone.js. Each feed view also contains an unread count, a feed title, a favicon, and a feed menu. All of these views are generated by their respective parents. Your job at this stage is to simply figure out what those views are so you can create the appropriate models, views, and controllers (routers).

Here’s another example, coming from the DocumentCloud workspace, the original Backbone.js site:

A bit simpler than NewsBlur, this is a classic dual-pane view, with an organizer on the left and a detail pane on the right. Notice that there is a view collection, the document list, that holds numerous document views. It’s important to consider each view as granular as possible and then bring them together in collections that are simply views of model collections.

Moving routers

You have routers, even if you don’t realize it yet. Not only that, but you probably have multiple routers. Routers are the smallest part of a Backbone.js project, but are vital because they serve as the entry point for execution.

Anytime a URL is involved, your router should be handling it. You can also have multiple routers in a project. Before version 0.5.0 routers used to be called controllers, if that shines a light on their purpose.

If an out-of-band AJAX call is necessary, and it doesn’t correspond to a specific model, then the router is a great place to put it.

There’s a lot written on conventions for writing your router. I suggest going directly to the source: the original router from the DocumentCloud workspace. This is the first router ever written and should give you as canonical an idea as possible for what your router should and can include.

// Main controller for the journalist workspace. Orchestrates subviews.
dc.controllers.Workspace = Backbone.Router.extend({
    
  routes : {...},
  
  // Initializes the workspace, binding it to body.
  initialize : function() {
    this.createSubViews();
    this.renderSubViews();
    Backbone.history.start({
        pushState : true, 
        root : dc.account ? '/' : '/public/'
    })
  },
  
  // Create all of the requisite subviews.
  createSubViews : function() {
    dc.app.paginator  = new dc.ui.Paginator();
    dc.app.navigation = new dc.ui.Navigation();
    dc.app.toolbar    = new dc.ui.Toolbar();
    dc.app.organizer  = new dc.ui.Organizer();
    dc.app.searchBox  = VS.init(this.searchOptions());
    this.sidebar      = new dc.ui.Sidebar();
    this.documentList = new dc.ui.DocumentList();
    
    if (!dc.account) return;
    
    dc.app.uploader   = new dc.ui.UploadDialog();
    dc.app.accounts   = new dc.ui.AccountDialog();
  },
  
  // Render all of the existing subviews and place them in the DOM.
  renderSubViews : function() {
    var content   = $('#content');
    content.append(this.sidebar.render().el);
    content.append(this.panel.render().el);
    dc.app.navigation.render();
    dc.app.hotkeys.initialize();
    this.panel.add('search_box', dc.app.searchBox.render().el);
    this.panel.add('pagination', dc.app.paginator.el);
    this.panel.add('document_list', this.documentList.render().el);
    
    if (!dc.account) return;
    
    this.sidebar.add('account_badge', this.accountBadge.render().el);
  }

});

The router is used for laying out all of the workspace-level subviews. Each of these subviews is then responsible for laying out specific instances of documents, collections, toolbar items, search facets, etc.

Moving models

Before you can even start playing with Backbone models, you’ll need to get your data in a format that Backbone can vivify. Your server should be sending arrays of dictionaries, each array consisting of a single parent model. This may cause versioning on your server end due to having to change the format of your API’s response.

Versioning: Objects as dicts vs. arrays

Perhaps you were giving data in a format that made it easy for you to key into the dictionary to retrieve a model, like so:

{
    64: {
        'id': 64,
        'title': "The NewsBlur Blog"
    },
    128: { ... }
}

However, in order to vivify these models, Backbone expects an array of dictionaries. We can modify the backend to provide models in this format, by adding a v=2 query paramter:

[
    {
        'id': 64,
        'title': "The NewsBlur Blog"
    },
    { ... }
]

Backbone reads through and finds all id attributes and hashes them into the _byId object on the model. You can do this client-side instead of versioning your API, but that would require you to write a custom parse method.

You can then override your collections fetch method to add in the version information. This transparently handles appending a version parameter to your requests.

fetch: function(options) {
    var data = {
        'v': 2
    };

    options = _.extend({
        data: data,
        silent: true
    }, options);
    return Backbone.Collection.prototype.fetch.call(this, options);
},

Notice, by the way, the last line is how you call super() in JavaScript. This is a clear demonstration of over-riding methods in Backbone and then calling super at the appropriate time.

Attributes

If your models were simple JavaScript object literals (dictionaries), then you were using one of these styles to work with attributes:

// JavaScript:
model.title

model['title']

var attr = 'title';
model[attr]

However, Backbone uses a get method to retrieve an attribute from a model:

// Backbone.js:
model.get('title')

The trick here is that during a large-scale refactor, you want to change as few things as possible. In this case, you can pass a Backbone model’s model.attributes to old Javascript methods. Then when done, clean up by looking for .attributes.

var iconSrc = $.favicon(socialFeed.attributes);
this.$('.NB-header-icon').attr('src', iconSrc);

This way you do not have to immediately rewrite all of your model attribute getters until you have tested the modified parts of your code.

Populating a collection that has side-effects

Looking at feeds and folders above, in order to populate the list of folders you need the feed models. But when populating the feed models, their view is bound to the reset event, which will try to render the feeds, but there are no folders yet!

Pass {silent: true} to the initial reset for feeds, then manually trigger the reset event after the dependencies are met.

Listening for events on a collection’s models

Any event that is triggered on a model in a collection will also be triggered on the collection directly, for convenience. This allows you to listen for changes to specific attributes in any model in a collection.

// Bind to all models
Documents.bind('reset',  this.reset);
Documents.bind('add',    this._addDocument);
Documents.bind('remove', this._removeDocument);

// Bind to specific attributes on the collection's models
Documents.bind('change:pages', this._renderPageCount);

The Documents collection contains all of the documents on the page, but you could also create specialized collections with a subset of those models that respond to change events without having to filter the change event on the bigger collection to only apply to those specific models.

Seeing changed attributes

In this case, a model is updated from elsewhere, so it needs to be refreshed on the page. Use model.hasChanged() and model.previousAttributes() to see what’s changed.

However, before you may have iterated over all new values and compared to existing values. Backbone has this built in.

// The collection is selective about changing attributes
this.bind('change', this._onModelChanged);
...
_onModelChanged : function(doc) {
    if (doc.hasChanged('access') && doc.isPending())
        this._checkForPending();
},
...
// The view is also selective about changing attributes.
// Re-renders the tile if an server-backed attribute changes.
_onDocumentChange : function() {
    if (this.model.hasChanged('selected')) return;
    this.render();
},

You can short-circuit the change event if you are looking for a specific attribute. But sometimes you want the change event fired only once yet you’re looking to do different things based on which attribute has been changed. So instead of relying on each attribute’s individual change event, you can wait for the bundled change event.

Naturally, you may be wondering what gets fired first? Each individual change event or the bundled change event? Well, to figure that out we just turn to the Backbone.js source code:

// Call this method to manually fire a `"change"` event for this model and
// a `"change:attribute"` event for each changed attribute.
// Calling this will cause all objects observing the model to update.
change: function(options) {
  ...
  for (var i=0, l=triggers.length; i < l; i++) {
    this.trigger('change:' + triggers[i], this, 
                 current[triggers[i]], options);
  }
  ...
  this.trigger('change', this, options);
  ...
},

Notice that the individual change attributes are guaranteed to fire before the bundled change event. This goes to show that the source code for Backbone.js is not as thorny and cumbersome to read as other libraries may have led you to believe about all libraries. Backbone.js’s source code is easy to follow and is written as close to plain english as possible

Intermediary models

Sometimes an active item needs a bit more meta-data than the non-active counterpart. Take the feed list, for instance. When a feed becomes selected, it needs to be referred to by many other components, each of which needs to know about the active feed. Storing a reference to this model, say ActiveFeed, then allows you to add view-specific meta-data that would be helpful in other views.

NEWSBLUR.Models.Feed.prototype.setSelected = function() {
    NEWSBLUR.app.feeds.deselect();
    NEWSBLUR.app.activeFeed = this;
}

NEWSBLUR.Views.FeedList.prototype.findSelected = function() {
    return _.pluck(NEWSBLUR.app.activeFeed.views, '$el');
}

If you are operating in a loop, then you’ll definitely want to cache a reference to a model like this.

Moving views

This part of the process is a bit more involved than moving models or simply constructing routers. This is where most of the cleanup is involved.

Writing Templates

The first thing that needs to be changed is how DOM fragments are constructed. In NewsBlur’s case, we’re moving from JavaScript element creation to interpolated templates.

Old style: Manual DOM element creation

This style is simply a wrapper around a variety of document.createElement calls, where $.make will take attributes and add them correctly to the newly created element, as well as appending each of the children in a easy-to-read function.

openSocialCommentReplyForm: function($comment) {
    var profile = this.model.userProfile;
    var $form = $.make('div', { className: '...' }, [
        $.make('img',   { className: '...',   src: profile.get('url') }),
        $.make('div',   { className: '...' }, profile.get('username')),
        $.make('input', { className: '...',   type: 'text' }),
        $.make('div',   { className: '...' }, 'Post')
    ]);
    $('.story-comment-reply-form', $comment).remove();
    $comment.append($form);

    $('.comments', $form).bind('keydown', 'enter, return', 
        _.bind(this.saveSocialCommentReply, this, $comment));
    $('.comments', $form).bind('keydown', 'esc', function() {
        $('.NB-story-comment-reply-form', $comment).remove();
    });
    $('input', $form).focus();

    this.fetchStoryLocationsInFeedView();
},

While it’s easy to read and write, it is not fast. This method is an order of magnitude slower than the better methods described below, each of which use string interpolation to inject data into the template.

Template option #1: inline strings

This is the option that I eventually chose, if only because it was the simplest, could be easily cached by the browser, and was inline with the view code.

render: function() {
    var $feed = $(_.template('\
    <<%= listType %> class="feed">\
      <img class="feed-favicon" src="<%= $.favicon(feed) %>">\
      <span class="feed-title">\
        <%= feed.get("feed_title") %>\
      </span>\
      <div class="feed-exception-icon"></div>\
      <div class="feed-manage-icon"></div>\
    </<%= listType %>>\
    ', {
        feed      : this.model,
        listType  : this.options.type == 'feed' ? 'li' : 'div',
    }));

    this.$el.replaceWith($feed);
    this.setElement($feed);
    this.renderCounts();

    return this;
},

Notice that this.setElement is used on the new $feed. The reason for this is because of listType changing the top-level element depending on the location of the feed. In some cases it’s part of a list, and in other cases it’s a stand-alone feed title. In order to make it semantically correct, different top-level tags are needed, so you can’t just use this.$el.html(), otherwise there will still be a top-most div wrapping your view (which can be customized by setting this.tagName).

Also, note that a better way to create these multi-line strings is to use the heredoc (multiline) strings in CoffeeScript. However, the template string still goes inline, which means you do not have to do any asset pre-compiling, which can be more or less difficult depending on your framework.

Template option #2: inline templates

These templates are just <script> tags that go in your HTML templates. The downside to this method is that your JavaScript templates are not cached by the browser and have to be downloaded as part of every page load.

<script type="text/html" id="feed-template">
    <<%= listType %> class="feed">
      <img class="feed-favicon" src="<%= $.favicon(feed) %>" />
      <span class="feed-title">
        <%= feed.get("feed_title") %>
      </span>
      <div class="feed-exception-icon"></div>
      <div class="feed-manage-icon"></div>
    </<%= listType %>>
</script>

…

render: function() {
    this.template = this.template || $('#feed-template').html();
    var $feed = _.template(this.template, {
        feed      : this.model,
        listType  : this.options.type == 'feed' ? 'li' : 'div',
    });
    this.$el.replaceWith($feed);
    this.setElement($feed);
    return this;
},

Not recommended, but easy enough to do without a pre-compiler or asset pipeline.

Template option #3: JSTs

This is the recommended method, but it requires you to have a pre-compiler that works in both development and production, referring to your templates individual in development and as a concatenated file in production. Not a big deal to implement, but many asset packagers do not handle JavaScript templates and allow you to wrap them in the appropriate interpolater, such as Underscore.js’ _.template.

window.JSTs['feed'] = _.template('<script type="text/html" id="feed-template">'+
                                 '<<%= listType %> class="feed"><img class="feed-favicon" '+
                                 'src="<%= $.favicon(feed) %>" /><span class="feed-title">'+
                                 '<%= feed.get("feed_title") %></span>'+
                                 '<div class="feed-exception-icon"></div>'+
                                 '<div class="feed-manage-icon"></div>'+
                                 '</<%= listType %>></script>');
...
render: function() {
    var $feed = JSTs['feed']({
        feed      : this.model,
        listType  : this.options.type == 'feed' ? 'li' : 'div',
    });
    this.$el.replaceWith($feed);
    this.setElement($feed);
    return this;
},

If you are on Ruby on Rails, you can use Jammit, another DocumentCloud project, to automatically handle JavaScript templates. Alternatively, node-jst and sprockets are worth a look.

Event delegation

The most common view change you’ll make is moving from event binding to event delegation.

// From:
$(".feed", $feedList).bind('click', function(e) { ... });

// To:
NEWSBLUR.Views.FeedView = Backbone.View.extend({
    ...
    events: {
        "click" : "open"
    }
    ...
});

One of the biggest benefits you’ll receive by moving to Backbone.js is going from event binding to event delegation. If you’re not already familiar with what this is, it is simply attaching all events to the top-level view element and then bubbling any events that happen to a child element up to the parent, where it is caught and delegated to the appropriate method.

This also means that you won’t have events bound all over the DOM. And when you destroy views, you know where all of the events are bound and will not have as much work to do in order to prevent memory leaks from events bound to missing elements.

Delegating the same object from multiple views

Sometimes an object on your page can be better represented by different views attached to the same element.

NEWSBLUR.Views.FeedView = Backbone.View.extend({
    initialize: function() {
        this.menu = new NEWSBLUR.Views.FeedMenuView({el: this.el});
    }
});

NEWSBLUR.Views.FeedMenuView = Backbone.View.extend({
    ...
    events: {
        "click" : "open"
    }
    ...
});

In this case it’s important to remember that both of these views will be listening for bubbling events. That means that it is possible to create a race condition if you do not know the order these views are instantiated. You will want to be careful in that the separated views do not step on each other’s toes.

In this instance the feed title view and the feed menu view are attached at the same place but serve completely different purposes. The feed title view is the “parent” of the menu view, even though they exist at the same level in the DOM hierarchy.

Which element to use

If your top-level element is complicated and you are creating it as part of your render, then you can use setElement instead of $(this.el).html().

var $feed = _.template('<li class="feed"> ... </li>', {
    ...
});

this.setElement($feed);
// Would include a surrounding <div>
// $(this.el).html($feed)

But you can’t just perform a setElement, because you need to replace the $el if it is on the page:

this.$el.replaceWith($feed);
this.setElement($feed);

This is meant for switching between element types. For example, a view that will sometimes go into a list as a list item, but then also be displayed solo, then you will want to control the tagName or just include it as part of your template and use setElement.

View collections

Models should not know about views. So in order to keep track of views, a parent view should encapsulate them and store references.

findFeedInFeedList: function(feedId) {
    var $feeds = $('.feed', $feedList).map(function() {
        var dataId = $(this).data('id');
        if (dataId == feedId) {
            return this;
        }
    });

    return $feeds;
}

[turns into a view collection on FeedListView]

Recursive subviews

This is a typical case where you want to have a recursive subview that can contain more of itself. In this case, we have feeds and folders, and both can be children of folders. To accomplish this hierarchy, we just have to descend down the chain, rendering each subview and keeping track of each child view.

NEWSBLUR.Views.Folder = Backbone.View.extend({
    render: function() {
        var depth = this.options.depth;
        var $feeds = this.collection.map(function(item) {
            if (item.isFeed()) {
                var feed = new NEWSBLUR.Views.Feed({
                    model: item.feed, 
                    depth: depth
                }).render();
                item.feed.views.push(feed);
                return feed.el;
            } else {
                var folder = new NEWSBLUR.Views.Folder({
                    model: item,
                    collection: item.folders,
                    depth: depth + 1
                }).render();
                item.folderViews.push(folder);
                return folder.el;
            }
        });

        var $folder = this.renderFolder();
        $(this.el).html($folder);
        this.$('.folder').append($feeds);
        return this;
    }
});

Traversing a view

When moving from story to story or feed to feed, you want to move in the order of what’s on screen. The order is handled by the collection, but keeping track of the active model is something you have to do manually.

// Go to the next feed. Old style:
$('.feed.selected').next('.next')

// New style:
Feeds.activeFeed = Feeds.next();
Feeds.activeFeed.set('selected', true);

The Feeds.next() method can be a complicated method that walks your recursive hierarchy. But that’s hidden away and you can just call that method idempotently.

Action hierarchy

Views handle their own actions, but what about cross-view actions? One view modifies another view. Propagate that up to the Router or parent view that is drawing the views. Have the parent talk to the necessary models, changing appropriate data.

Once the data is changed, the correct views will update, based on their triggers and bindings.

For instance, if you are deleting a feed, the context menu view, which knows which $feed is being deleted, sends that info to the model, which then scans its own views and triggers the removal on the correct one. Finally, an AJAX request is made (this is optimistic) in the Router.

NEWSBLUR.Views.FeedMenu = Backbone.View.extend({
    deleteFeed: function() {
        this.model.removeFeedFromFolder(this.folder);
    }
});

NEWSBLUR.Models.Feed = Backbone.Model.extend({
    removeFeedFromFolder: function(folder) {
        this.feedViews.chain().select(function(feedView) {
            return feedView.folder == folder;
        }).each(function(feedView) {
            feedView.animateDestroy();
        });
    }
});

No need for a model to back a view

Some views just don’t have models. They control a visual element on the page but have no corresponding server model. The closest object they have to a model is the page itself or the user.

This means you need to keep a reference to the view. You can’t just rely on the model to update the view. Other times you do have a model. If the model for the view would change depending on the model, you can just render a new view with the correct model and replace it on the page.

Common pitfalls

TypeError: ‘undefined’ is not an object (evaluating ‘func.bind’)

This error comes from trying to bind to a method that doesn’t exist. But you don’t get the name or line of the error, so the only way to debug it is to set a breakpoint and work your way up the stack.

_.bindAll(this, 'render', 'open', 'methodRemovedAndWillThrowTypeError');

Firing a change event while still setting up models and views

Add {silent: true} to a model.set() call if you’re not ready to handle the change events.

Selectively re-render/toggle Classes based on specific change events.

Sometimes an attribute change merely results in a changed class on the element, not a full render. One technique you can use is to bind to the bundled change event and then selectively look for attributes that only result in a class change.

onChange: function() {
    var onlyClasses = _.all(_.keys(this.model.changed), function(change) {
        return _.contains(['selected', 'has_exception'], change);
    };

    if (onlyClasses) {
        this.toggleClasses();
        return;
    }

    this.render();
}

Here, we’re checking that every changed attribute is one that results in a class change. Otherwise, do the full render.

Cleanup of ghost views

When removing a view, you need to both remove it from the DOM and then unbind it. The model still has bindings to the destroyed view.

// Parent view:
view.destroy();

// View:
initialize: function() {
    this.model.bind('change', this.render);
},

destroy: function() {
    this.remove();
    this.model.unbind('change', this.render);
},

This has changed in the latest version of Backbone.js, but it’s not yet released (the coming version 1.0), so you have to manually destroy both the views and view’s event bindings.

The disappearing view

Before Backbone, views would not automatically update from beneath you. Now that views are tied to models, check to see if you are modifying a view post-render, just as inserting a special sub-view that the parent view doesn’t know about. Because when the view re-renders, it won’t know to re-insert the subview.

Resources

A couple resources that I like are:

Developing Backbone.js Applications by Addy Osmani
Backbone Patterns by Rico Sta. Cruz

As always, make sure to read the source of Backbone.js to see if you can just figure out what’s happening under the hood.

I’m @samuelclay on GitHub, where you can follow me to watch the development of the NewsBlur front-end, back-end, iOS and Android apps. And I’m @samuelclay on Twitter where you can ask me further questions about Backbone.js.

For Good Reason, NewsBlur Will Not Compete With the Big Boys

2011-01-10T17:26:08+00:00

NewsBlur has and, for as far out as I can see, will be a side-project. It’s fun, but I can’t even begin to imagine the headaches I’d face if I had to support a living salary through NewsBlur. My goal is just to meet potential co-founders and to try to make a splash. And I’ve been meeting folks here in NYC who I would not have met otherwise. So it’s working quite well, so far. Fabulously well, in fact.

Raising money for something like this must be difficult and a huge crapshoot. There are a lot of fadish readers out there who have already sucked up most of the goodwill that the press is willing to give to this area, and even then, they have a design element that is extremely hard to compete with. Financial backers would much rather shut a site down than let it live a meager existence. They’re not out to support a site, they want a 10x return. Funding doesn’t make any sense for what I want.

Besides, now I can build fun features like social, the iPhone app, and river of news in peace. Who knows what markets I would have to chase if I had stakeholders. Enterprise! Aggregators! Ick.

I think any other business is a better business to be in, but who knows if my tune will change within the next 12 months, as I roll out bigger features.