matt meshulam

My Year of Making Stuff

2017-01-19T00:00:00-06:00

In 2016 I worked on a ridiculously broad range of projects, both for work and independently. Sometimes I forget projects or things I learned a while ago, so I decided to write up a summary of the highlights.

I started the year writing Scala and Javascript at TempoIQ, which was incredibly my first time working as an official software engineer. It was the perfect startup experience: constantly learning and building cool things and culminating in an underwhelming acqui-hire.
My brief time at the acquiring company was in Ruby on Rails. It was a fun throwback to my first-ever paid programming gig in 2007– building a course website for one of my professors when Rails was just a couple years old.
Since August-ish, I’ve been working with Hologram on Developer Experience. In November we released a brand new documentation site!
I had a small project helping a fellow member of Pumping Station One on some software for a 3D head-and-torso scanner. I didn’t get involved until late in the project, but it got me jazzed about 3D scanning technology.
Speaking of PS:1, I started teaching the ShopBot CNC class there back in January. Over the course of the year I authorized over 100 people on the farily complex piece of equipment.
Thanks to PS:1 and the ShopBot, I also had my first paid machinist job, helping a member make an enclosure for a product prototype he’s developing.
I was really all about the ShopBot last year–my Birdbath was probably my most involved CNC project to date. And it also marked my return to making videos; the last time I spent serious time in an editing program was in high school.
I played around with using Android devices as interfaces for embedded electronics projects (Arduino and similar). I got a prototype light controller working but lost momentum as I realized I don’t like developing Android apps.
On the more traditional craft/woodworking side, I made an end grain cutting board!
For Reverb, I developed an interactive tour of guitarist Joe Bonamassa’s home and studio.
I dipped my toe into Twitter bots with one that replayed FiveThirtyEight’s articles from eight years ago. Code here.
In order to learn more about the Rust programming language and the internals of Git, I started re-implementing Git in Rust. I didn’t get very far.
I designed and built some lampshades from laser-cut acrylic. Once PS:1’s new big laser cutter comes online, I’m hoping to revisit that project.
Toward the end of the year I started attending Chi Hack Night, where I’ve been working with the Chicago Justice Project on scraping and analyzing news coverage of crime in Chicago.
And my final project of 2016: Robby #1.

CNC Experiments: Baltic Birch Plywood

2016-09-23T00:00:00-05:00

I’m planning some projects involving CNCing shapes from plywood and wanted to get a better sense of what tools/feedrates/etc will produce the best results. There’s a near-infinite supply of anecdotal feeds & speeds advice online, but not nearly as much data from controlled tests.

I recently bought some new end mills and was doing some test cuts of my own, and figured the results might be helpful for others.

TL;DR

To cut parts from Baltic birch plywood, use a 1/4” 2-flute straight end mill at 10k RPM and a feed rate of 150-200 IPM. Use conventional milling and a max pass depth of 0.25”.

The setup

Material: 12mm (measured 0.470”) Baltic Birch plywood

Tools: Two brand new 2-flute 1/4” end mills:

Freud 04-110 1/4” straight
Freud 76-102 1/4” down spiral

CNC: 48x96 inch ShopBot PRS at Pumping Station: One

I modeled a small test shape in Fusion 360 and generated sevaral toolpaths with varying feed rate, number of depth passes, and milling direction. Spindle speed was a constant 10k RPM.

Fig 1: Fusion 360 model and toolpaths

Here are the 8 samples I cut:

Sample	Tool	Feed rate (IPM)	Passes	Milling direction
A1	Straight	75	2	Conventional
A2	Straight	150	2	Conventional
A3	Straight	225	2	Conventional
A4	Straight	150	1	Conventional
B1	Downcut	150	2	Climb
B2	Downcut	150	2	Conventional
B3	Downcut	225	2	Conventional
B4	Downcut	150	1	Conventional

Results

I swapped the slowest cut (A1) for medium-speed climb cut (B1) when I switched from the straight to the downcut bit. I originally planned to redo all 4 parts as climb cuts, but decided to just do one for comparison as I knew conventional was better for my purposes (more on that later).

Straight vs. Downcut

The side walls of the downcut cuts had subtle ridges, while the straight tool’s cuts were almost perfectly smooth. The downcut was louder when cutting, and I assume those two things are related. The shaft of the downcut bit is about 1/4” shorter than the straight bit, so it’s possible the collet didn’t get as good of a grip on the downcut, causing some chatter. Not sure what else could have caused it, I certainly didn’t expect such a difference in finish between two such similar tools.

Fig 2: Downcut parts. From top: B4, B2, B3

Fig 3: Straight flute parts. From top: A4, A2, A3

The straight flute parts had a slightly cleaner bottom surface, which is expected, but the difference was very minor. I wouldn’t consider the difference to be significant, and would probably disappear entirely with light sanding (I didn’t sand at all before these photos).

Feed rate

I varied the feed rate from a definitely-too-low 75 IPM (0.00375” chip load) to 225 IPM (0.01125” chip load). The ShopBot can comfortably go a little faster, but I stopped there because with such a small part, it would have been unlikely to ever accelerate much faster than that.

There was very little difference in cut quality over this 300% variation in speed. The slowest cuts were slightly louder than the others, and the chips produced were noticably smaller, but nothing too concerning. One of the biggest effects of changing feed rate is the lifetime of the tool, so perhaps there would be a noticeable difference in that regard between 150 and 225 IPM. But for hobbyist-level usage, I’d be comfortable recommending anything in that range.

I’d like to test even higher chip loads by reducing spindle speed below 10,000 RPM, but that will need to wait for the next round of experiments.

Climb vs. conventional milling & other dimensional variations

I’ve noticed that climb toolpaths tend to produce parts slightly larger than their specified dimensions, and conventional toolpaths are usually right on. I think this is because of the deflection of the bit from the difference in force between the two sides of the path.

On each part, I used calipers to measure the width of the two “teeth”:

Cut type	Min (inches)	Max (inches)	Count
As designed	0.940	0.940	-
Conventional 2-pass	0.937	0.941	10
Climb 2-pass	0.950	0.951	2
Conventional 1-pass	0.929	0.931	4

The climb cut was about 0.01” oversized, and the 1-pass conventional cut was about 0.01” undersized. Precise dimensioning in wood is always an uphill battle due to heat- and humidity-related expansion, but these 0.01” variations make a big difference for joinery.

The long slots on each part were designed to be as wide as the thickness of the material (0.470”) to allow two parts to slot into each other. The smaller 1-pass parts could slide into each other easily, with some wiggle when joined. The conventional 2-pass parts could be joined with some force, but were difficult to re-separate. The climb-milled parts were too big (resulting in a slot too narrow) to be joined at all.

Fig 4: Straight bit parts with dimensions

Fig 5: Downcut bit parts with dimensions

Pass depth/number of passes

The A4 and B4 tests cut a single ~0.5” deep pass instead of splitting the depth into two passes. It sounded like the spindle was struggling a little more than with the other cuts, but the quality of the finish was still great. In fact, some of the 2-pass parts had a visible line halfway through the part at the bottom of the first pass (see Figure 3 above), so the single pass actually had a better finish.

The different sound when cutting, combined with the smaller finished dimension, leads me to believe that cutting 1/2” deep is causing excess vibration in the tool. If you’re really in a hurry it works well enough, but I’d advise going a little faster and taking two passes instead.

Conclusion

These tests didn’t cover the full range of every CNC parameter I’m interested in, but I definitely learned a lot by this more scientific approach. Hopefully others will find these observations useful as well!

Worms! Worms! Worms!

2016-05-22T00:00:00-05:00

Last weekend I finished a project that’s been on my list for close to a year: I started a vermicomposting system. In case you aren’t familiar with the concept, vermicomposting is a composting technique that uses specific species of worms to turn food waste into a fantastic fertilizer (read: worm poop).

I’ve vermicomposted on and off for a few years in college and afterwards, using a plastic bin with drainage holes drilled in the bottom. This setup worked fine, but despite the holes the compost tended to stay very wet, which I suspect encouraged flies and unsavory smells to take hold more than they should. Vermicompost should not smell bad at all.

This time around I decided to build a wood box with a better engineered drainage solution. I’ve heard mixed reviews of using wood containers, but my thinking is that the exposed wood would help regulate moisture by absorbing water when it’s overly wet, and release it if the compost dries up too much.

Finished worm box (sans lid)

The drainage system is a ~1-inch deep “tray” in the bottom of the bin, covered with a fine screen (actually some sheer polyester fabric). All the composting action happens above the screen, but if it becomes oversaturated then water should drain through the screen into the bottom.

I also added a sealable spout for easy draining of the excess water, by repurposing the top of a plastic soda bottle and using tons of silicone.

Inside view of tray and drain spout, with screen removed

I bought 1/4 pound of red wigglers from a very nice local woman selling worms from her own composting system, but realized it would take too long for them to repopulate to fill the bin. So I re-upped with another half pound or so from a live bait shop. Hopefully the hippie organic worms will get along with the more rough-around-the-edges bait worms.

I’ve been slowly ramping up feeding them scraps this week, and will be figuring out what a good steady-state amount to feed them while they grow into the container. But I think they’re happy so far.

For anyone considering setting up a vermicomposting system like this, I highly recommend reading Red Worm Composting. It’s a great combination of anecdotes and more scientific information about this style of composting.

Introduction to CNC Routing

2016-02-08T16:58:11-06:00

Last week I taught a new class at Pumping Station: One, an introduction to CNC routing, focusing on our 4’x8’ ShopBot and Vectric VCarve. In the past we taught the concepts and did a hands-on authorization in a marathon 3-hour session. This wasn’t ideal for a few reasons: it’s hard to absorb so much information in that format, and the authorization aspect meant the sessions had to be capped at 3-4 people since everyone needed to get hands-on time. This led to many members needing to wait a long time before they could get into an auth session.

This was the first time we split up the authorization into a 2-hour classroom portion, and then a shorter authorization session. I was able to cover concepts in more depth, and people who were casually interested in CNC could attend to learn more without committing to a full authorization.

The class was about 2/3 concepts and 1/3 a demo of VCarve. I’m not in love with VCarve: it’s not free for hobbyists and is Windows-only, but it has basic vector design and CAM in one package, so it’s good enough. In the future we’ve discussed teaching a different toolchain, but the majority of the class would still stay about the same. I made some slides for the concepts portion, and I figured they might be valuable to post publicly. So you can download the slides here.

They will probably evolve as we teach more sessions of the class, I will try to keep the PDF up to date.

Dotfile Makeover 2016

2016-01-18T18:16:49-06:00

For the past couple years, I’ve halfheartedly maintained a dotfile repository where I keep config files for the Unix-style applications I use on a regular basis. Most of it was naïvely adopted from convincing-sounding commenters on Hacker News, who mandated using the hottest Z Shell frameworks, Vim plugin managers, and other configuration esoterica.

A lot about it was kind of magic to me, and I had a suspicion that some of the configuration was unnecessary for my own use, or was even resulting in poor performance. So I finally decided to give my configs a once-over.

Objectives

I use a small number of computers and OSes on a regular basis: personal and work OS X laptops, personal Ubuntu server, plus the fleet of CentOS servers that I need to log into occasionally. While the specific breakdown will change over time, I wanted my personal configuration to reflect some aspects of how I use computers:

OS neutral - My configs should be relatively portable across different Unix-like OSes.
As simple as possible, but no simpler - Just like in real software development, every additional component has an intrinsic cost in complexity and future maintenance. Before adding a new tool or changing something, evaluate whether it’s worth the cost.
Enrichment over redefinition - There will always be times when I need to log onto a box that doesn’t have my configs installed. This should ideally not be a miserable experience. Changing keybindings and stuff is fine, but my own environment shouldn’t differ too dramatically from a “stock” setup. No need to reinvent the wheel, after all.

There were two main areas I wanted to focus on: my shell and Vim configs.

Shell

Most people get on perfectly well with Bash, but I chose to stick with ZSH, which I’ve been using for a couple years. This was mainly because I’ve gotten used to the awesome tab-completion, but re-reading this presentation reaffirmed my conviction.

I’ve been using oh-my-zsh since I started using zsh, but have been thinking about dumping it for a while. It seems to make new terminal sessions start up slowly, and I wasn’t sure I needed a whole plugin system to configure the few things I actually use from it.

I made a simple .zshrc that sources all files in a given directory, letting me split up my config into separate files for aliases, prompt, etc:

ZSH=~/cfg/zsh
GLOB="${ZSH}/*"
for sourcefile in $~GLOB
do
    source "$sourcefile"
done

This seems to be a good compromise between a framework like oh-my-zsh and a single monolithic .zshrc. I started with a totally blank slate and have been re-adding aliases and options that I’ve noticed not working the way I want or expect.

Notable things I did:

Replaced oh-my-zsh’s git prompt with Git’s provided git-prompt.sh
Learned how to configure history sharing between shell sessions so I know why it sometimes doesn’t behave how I expect it to

I really like that I’ve either written or explicitly added everything that gets sourced. I think I’ll be much less likely to be surprised by behavior or performance problems in the future.

Vim config

I wound up sticking with Pathogen as a Vim plugin manager and using Git submodules to pin to plugin versions. There are newer frameworks that help with stuff like auto-updating, but I don’t add/update plugins too often so I wanted to stick with the simplest thing. I don’t use submodules in Git too often, so I made a command cheatsheet for adding/updating them.

I still went through my existing plugins and vimrc and made some changes:

Set spacebar as the leader key and started using it in custom keybindings. I never got too crazy with adding key mappings but I can see myself using it more now that I understand the leader is basically a user-owned “namespace” for shortcuts.
Mapped ‘jk’ to exiting insert mode: inoremap jk <esc>. This one has been a life-changer. Hitting escape has been in my muscle memory for years, but after a day I was totally used to it and will never go back. It’s so fast!
Got rid of MiniBufExpl as a way to display open buffers like tabs. I still get the urge to cycle through buffers, but I’m trying to break that habit and figure out a more vim-like workflow that works for me. For now, listing buffers and switching by number is working okay.

Further changes

At some point I’ll tackle my tmux config, since I’m sure I could be using more of its power day-to-day. I’d also like to write an install script to automatically symlink the config files from the repo to their expected locations. But for now I’m happy with where things are at, and being more familiar with my configs will make me more likely to dive in and change stuff if I feel the need to.

Carbonation Rig

2015-10-02T01:24:40-05:00

I recently got the itch to make my own sodas and other carbonated beverages. So I did what any reasonable person would do and bought a large CO2 tank, a regulator and various fasteners and tubing.

Why DIY instead of use a popular off-the-shelf solution like a SodaStream? I’m not forced to buy CO2 refills through a single source, plus I can carbonate stuff other than pure water (though apparently newer, more expensive SS models are OK for pre-carbonation mixing). Not to mention, now I’m just a few short steps away from having a kegerator setup as well (step one: cut a hole in a fridge).

The rig

I’ve been using the rig for about a month now, and it works like a charm. Here’s how I did it.

The build

I bought everything but the CO2 cylinder itself from Amazon:

Taprite Regulator - Hooks onto the canister and allows you to adjust the output pressure
Hose and ball lock valve - Hose connects to the regulator and the lock mates with the …
Ball lock to threaded cap adaptor - Screws onto any standard plastic bottle and allows for easy connect/disconnect of the hose without depressurizing

I got a brand new 5lb aluminum cylinder filled with food-grade CO2 from a local welding supply store. Now that I own the cylinder I can trade it in for a refill for about $20. But I expect this one to last around a year unless I start going soda-crazy.

The assembly was pretty straightforward: screw the regulator onto the tank, and slip the hose onto the barbed output of the regulator. I put the end of the hose into hot water for a minute to soften it up, then lightly tightened the hose clamp onto it.

The regulator

I always keep the valve on the tank fully opened, but when not in use I close the output valve on the regulator. That seems to strike a good balance between convenience and not losing CO2 to leaks.

Using it

I’ve accumulated various sizes of plastic soda bottles that I re-use. The process is pretty simple:

Mix your drink, chilling it as cold as you can. Cold water absorbs CO2 better.
Fill the bottle, leaving a few inches at the top to make agitating it more effective.
Squeeze the bottle so that there’s almost no air left at the top, then screw on the carbonation cap.
Open the regulator valve and set the regulator to 32-40psi. The ball valve will prevent gas from actually coming out until you connect it to the cap.
Connect the ball valve to the cap and agitate the bottle for about a minute. I braced for an exploding bottle the first few times I hooked it up, but no disasters so far.
Let the bottle sit pressurized for another few minutes. This can be with the hose still connected, or the cap should maintain pressure even when disconnected.
Open the bottle and enjoy your DIY soda!

Tips

I’m still experimenting with recipes and such, but a few things I’ve learned so far:

The biggest challenge for me is getting the carbonation to “stay.” It’s almost always well carbonated right when I open the bottle, but often if I leave a glass out for over 20 minutes or so, it’s mostly flat. A few things mitigate this problem: keep the water as cold as possible; avoid carbonating liquids with particulate like fruit pulp; and using clean bottles and glassware. Not sure if there’s anything else I’m doing wrong to cause this problem.
I find most flavors taste better with at least a little sweetness, even if it’s not traditional soda-level sweet. I mixed up a batch of simple syrup and toss in a few teaspoons before carbonating.
Certain flavors come out more after carbonating and others seem to get overshadowed. Luckily this process is ideal for micro-batches, so iteration is cheap and easy.

I also just ordered Dave Arnold’s Liquid Intelligence, which has a whole chapter on carbonated drinks. So I’m sure that will yield more inspiration.

Coriander seeds

2015-08-14T02:10:58-05:00

Did you know that coriander and cilantro are the same thing? I remember how my mind was blown when I first discovered that. Anyway, I was growing some cilantro on my balcony and neglected it during a particularly hot and dry period. It bloomed and went to seed, so I picked it and let it dry out inside for a week or so. I figured I could use the seeds as a spice; I’d never grown my own spices before!

Coriander seeds on the stem

Compared to the Swad brand seeds I normally use, these were larger and lighter colored, and didn’t have as strong of a flavor. So while a fun experiment, I’ll stick with store-bought coriander seeds.

Side by side seed comparison

Homegrown on the left; store bought on the right

Dusting off the old web-log

2015-07-07T01:41:49-05:00

I’ve been meaning to start writing again for a while, and before I did that I wanted to refresh my blog design and ultimately my web presence. Did that mean delaying writing instead of JFDI-ing? Yeah, but here we are finally.

I moved off my stuffy, passé WordPress site onto these shiny new Ghost digs. I had taken a time-consuming detour through the land of static site generators, specifically Pelican, but after hours of tweaking templates and CSS, Ghost won out for its plethora of high-quality modern themes. Currently I’m trialing Ghost’s hosted service, and have been pretty happy with it so far (granted, I’m only partially through writing my first post).

So why the renewed interest in blogging?

I’ve been working on various creative projects lately, and figured I should really get in the habit of documenting the stuff I’m doing; personal marketing and all that. So here we go again.

Archiving a website with Amazon S3

2013-08-24T16:14:16-05:00

About five years ago, my friend Zach and I made the EnerJar, an open-source hardware design for a power meter. We created a website, enerjar.net, to document the design. We used the Drupal CMS framework so that we could easily update the content and allow users to comment on it.

After a few months, the site sat pretty much unchanged, but it was still backed by a database, PHP, and a bit of configuration on a shared hosting environment. After having to fix the site a few times after surprise upgrades and configuration changes, I decided to transition it to a static website where it could live reliably for the rest of time.

Static websites have many benefits over ones which rely on server-side scripting: they’re cheaper and simpler to host, have virtually no risk of security breaches, and are much more scalable. Of course the downside is that users can’t really interact with static websites, so they only work if you’re okay with a simple read-only product.

Here’s how I transitioned enerjar.net into a static site hosted on Amazon S3:

Step 0: prepare the site

You’re effectively taking a picture of each page on your website, so any dynamic features will no longer work. This includes comments, searching (sometimes), and submitting new content. If you’re transitioning a site that uses a framework like WordPress or Drupal, you’ll want to disable any of these features in advance so that visitors don’t even see them. Otherwise they get an error message when trying to actually submit a comment or something.

Step 1: download the site

From any Unix/Linux/OSX command line, you can use wget to recursively download all the resources on your site. I used the following command:

wget --recursive --page-requisites --html-extension --convert-links --domains enerjar.net http://enerjar.net/

“recursive” says to follow links on the page and continue to follow any links on the sub-pages. “page-requisites” tells wget to download not just the page itself, but resources like CSS and Javascript files. “domains” limits the recursive link-following to the enerjar.net domain, so it doesn’t try to download external links.

I begrudgingly used “html-extension” and “convert-links” to rename every downloaded page file so that it ends with the .html extension. *This could break outside links to your site, but it means you don’t need to manually configure content types for these files on S3. **If a page URL doesn’t end with a file extension, for example, *something.com/blog/entry1, wget will download it without an extension, to a file called entry1. The problem is that S3 doesn’t know that entry1 is an html file, so when visiting the re-hosted page, your browser will download the file instead of displaying it as an actual page. By adding the .html extension on download we avoid this problem. Maybe someone knows a better way to do this, but I was lazy and this was good enough for me.

Step 2: Test the downloaded site

Open the HTML files that you downloaded with wget and make sure that everything shows up correctly and that links still work. For some reason wget didn’t download some of the images on the site, so I had to manually get them and put them in the proper directories. Once everything looks good, you are ready for the fun parts.

Step 3: Create a new S3 bucket

If you don’t already have one, open an Amazon Web Services account and create a new S3 bucket. Put it in whatever region you want, but the name of the bucket must be exactly the same as your root domain name. So I named my bucket “enerjar.net”.

Step 3: Upload the site contents

After fiddling with various command-line tools for AWS, I gave up and used Amazon’s Java uploader in the browser. You need to use the Java one to upload directories, otherwise you’ll need to manually recreate the directory tree and upload files into each folder separately. Be sure to upload the site into the root directory of the bucket.

Step 4: configure static website hosting

In “properties” for the bucket, select Static website hosting->Enable website hosting. Set your root and error documents as necessary.

Step 5: Custom domain

Follow Amazon’s tutorial for setting up DNS for hosting a static site with your own domain. The only snag I hit was that it didn’t autocomplete the domain name for the alias. I thought it needed to be the domain of the actual S3 bucket (e.g. enerjar.net.s3-website-blahblah), but it actually just expects the root domain for the region where your bucket lives. In my case, s3-website-us-west-2.amazonaws.com.

Step 6: DNS and finishing up

As covered in the linked tutorial in step 5, you’ll need to set up your domain to use Amazon’s name servers. Make sure you also transfer any other DNS records (mailservers, subdomains, etc) to your Route 53 configuration.

That’s it! You should now have a rock-solid, super-cheap hosting setup for your now-static website.

A way-too-deep look at Ubuntu Edge’s Indiegogo numbers

2013-07-31T16:07:58-05:00

TL;DR: Prospective Ubuntu Edge buyers are ridiculously sensitive to changes in pricing.

If you follow tech news you’ve probably heard quite a bit about Ubuntu’s crowdfunding campaign, which is trying to raise $32 million to build a cutting-edge smartphone called the Ubuntu Edge. In the 9 days since the campaign began, there’s been a lot of speculation on whether it will fall short of its all-or-nothing funding target. One site, ubuntu-edge.info, shows the amount raised over time:

Judging from the red on-target line, they aren’t looking too good. But that’s boring. Let’s take a closer look at the rate of the funding so far:

The weird shape is at least partially due to Ubuntu’s pricing scheme. They began the campaign with two price levels: a limited number of units for $600, and the rest being sold for $830. Then, after a few days, they introduced limited quantities available at lower price points: $625, $675, $725, $775, $780, etc. See here for the full distribution. What struck me from looking at this graph is how clearly you can see the slope changing when a price level sold out. I speculated the story looked like this:

Fortunately, we don’t need to rely on our eyeballs when there’s data involved; the dataset is available from the site above if you know where to look. I manually picked a single point around each of the kinks I observed and put them into Excel, since I’m not cool enough to use R for this kind of thing.

First I wanted to confirm that the funds raised in each time interval roughly equaled the corresponding price level*available quantity. It’s not going to be exact since there are some other contribution levels (e.g. $20 just to support them, $10,000 if you are rich and like having Limited Edition things), but most of the money is coming from people just wanting to preorder a phone so this will get us in the ballpark.

For each interval I drew on the graph above, I took the ending timestamp and cumulative amount raised (columns A and C) from ubuntu-edge.info. By subtracting each dollar amount from the previous row, I got the amount raised per interval (column D). Then I entered the cheapest price level at each time and the quantity available, assuming my hypothesis was correct. Note that we don’t know how many suckers bought the $830 device before Ubuntu added lower price tiers, but they did state that the “hundreds” of them would get a refund for the difference.

For the rest of the time intervals, we can easily calculate the amount we expected to raise assuming all revenue came from the cheapest presale price level (column I). Then we can see the amount (column J) and percentage (column K) that this estimate differs from the actual amount. Our initial model is actually a really good fit; the first three intervals we have error %’s for are hovering at 5%. Without looking at the numbers, it feels about right that 5% of the revenue is coming from altruistic contributions.

Before going any further I want to point out that the math is actually a little fuzzier than it looks. There’s nothing to stop someone from buying a more expensive phone when a cheaper level is still available, thus throwing off our Quantity column. Indeed we can see this is happening on the campaign site, since 34 phones have been bought for $830 even with the lower prices available. But we’re just going for ballpark numbers here, and the ballpark looks about right.

Since intervals 1, 3, and 4 all have a deviation remarkably close to 5%, let’s assume the same holds true for the time period when just the $830 phone was available. To get column K to result in a value of ~5%, there must have been about 740 suckers:

But what’s going on with our error during the $725 and $775 periods? We shoot up to 14% and then 25%. Did people suddenly start buying $10k phones? Did we miss the real points when the price levels sold out?

Actually, there’s an explanation. When introducing the new price levels during the campaign, Ubuntu also added a “Double Edge” deal, where you can preorder two phones for $1400. Which works out to $700 apiece. Which just happens to be a worse deal than the $675 level but a better deal than the $725 level. So naturally, when the $675 phones sold out, the Double Edge started to get picked up. Let’s keep calibrating our model to a 5% altruism rate and solve for the # of units sold as a double deal:

Note that the equation for column I has changed to account for the new component.

Our model estimates that 414 phones (207 units) have been sold as doubles. When I grabbed this data, the actual total was 264 double packs. Not terribly far off.

Finally, let’s look at the rate of unit sales during each interval to get a feel for price elasticity and the effect of time. It’s pretty obvious that sales slowed down after the initial cheap phones ran out, and we can see a distinct slope change when each subsequent level was depleted, so we know there’s some correlation with price. We also know that sales are probably going to be faster at the beginning when there’s more hype and will slow down after that, at least until it gets very close to the end of the campaign.

Column B is just each timestamp subtracted from the previous. Column H is what we’re interested in: total unit sales (cheapest single price level+doubles) normalized over time.

I’m staggered by how much price affects the rate of sales. After the initial $600 level sold out, sales trickled in at just 6% of their previous velocity. When the price went from $625 to $675, only an 8% increase, the rate slowed by almost 60%. This corresponds to a crazy-high price elasticity of demand of 7.3. Any way you cut it, prospective Ubuntu Edge buyers are ridiculously price-sensitive.

What about the effect of time? Early on in the campaign a $830 price point yielded a sales rate of 23.6 units/hour. Later on, this rate was crossed again when the price went up from $725 to $775. Let’s split the difference and speculate that if the price only increased to $750, the sales rate would have once again hit exactly 23.6.

This would mean that the passage of 3.5 days (from the start of the $830 interval to the start of the $775 interval) has about the same effect on sales as increasing the price by $80 (9.6%).

Of course it’s hard to conclude anything from this limited set of data. But perhaps these observations can inspire future crowdfunding projects to experiment with different pricing schemes. Personally, I like the idea of surprise price decreases. You can recapture some of the natural time decay as the campaign goes on, and whoever does this first could get some extra media coverage as well. But it may not be worth it if your early adopters feel like they got screwed.