Author Archives: bryanduxbury

Custom languages considered harmful

I use and contribute to a lot of open-source software projects, and one thing I see all over the place that drives me absolutely nuts is the prevalence of custom languages. In serialization frameworks, there are interface definition languages. In CAD tools, there are modeling languages. In the NoSQL and big data processing world, you’ll find my personal pet peeve, query languages.

Why are people making these custom languages? Abstractly, I get what they’re thinking: they have an application that would benefit from an expressive, terse, awesome set keywords and operators that will allow their users to be more productive. And this thinking isn’t fundamentally wrong. The productivity gain is real and definitely worth pursuing, and an intuitive language can go a long way towards making your product extremely accessible.

But here’s where I think these people go off the rails: aside from the very real NIH danger (Making your own language is cool, right? Guys?), there is a huge difference between a custom language – one in which you have to do the whole compiler contortion of lexing and grammars and whatnot – and a domain-specific language, which is more typically a set of functions and syntax that work from within another existing language to provide enhanced functionality. These two things seem a lot alike at first glance, but in my opinion, they couldn’t be more different. Why? Because when you decide to write a custom language – however simple it might seem to you right now – you are making the incredibly short-sighted statement that you know how to design a language better than all the people who have tackled this gargantuan problem before you. I don’t doubt that you know your domain better than anyone else, and that’s definitely what you need to get started, but what you probably don’t know is what you’re going to need later that will totally change your language. Or how best to implement recursion, scoped variables, memory management, or exception handling. The list could go on forever.

Let’s look at a concrete example. Lots of people in the 3D printing/maker community use OpenSCAD, an open-source 3D solid modeler with a decidedly programmer-tailored interface. Makers love it, because it’s powerful, fairly simple, and gives you really repeatable results. It uses a totally custom scripting language that is basically C-like: nesting, scope, function calls. But in combing through some of the syntax and reading the mailing list, I get the impression that a nontrivial amount of the developers’ time is spent reinventing features like variable assignment and for loops that could instead be spent actually developing the application itself.

To be totally clear, I love OpenSCAD, and I’m going to keep using it. That doesn’t mean that I don’t wish the developers had decided to write a DSL instead. If they had decided to embed their functions in a nice Ruby DSL, instead of having to figure out how to deal with the quixotic features of the native dynamic length lists, I could leverage all of the existing resources – community-vetted documentation, libraries, debugging and editing tools – and it would just work. As a user, I could just focus on learning the portion of the new syntax that applies to the specific domain, rather than also having to scramble to try and figure out how to do the things I already know how to do in other languages.

It’s clear that some folks out there get this right and some get it wrong. Thrift and Protobuf both have their own IDLs, which work well enough, though the code involved in analyzing IDL files is decidedly non-trivial. OpenSCAD and others like RapCAD have plowed tons of time on their own custom languages. Map/Reduce productivity tool Pig is a nightmare: since it’s not Turing complete, whenever you want to do something not imagined by the developers you have to make the significant development context switch into regular Java to make user-defined functions. Conversely, Cascading is a wonderfully usable and extensible pure-Java DSL for composing complex Map/Reduce workflows with arbitrary UDFs that don’t require you to context switch. (Even the splendid Clojure wrapper for Cascading, Cascalog, has the sense to use the existing Clojure language to give you an honest-to-god Turing complete language to work in.) Cassandra has CQL (which I admittedly haven’t used) while HBase has stuck with a solid functional API and has a JRuby REPL in which you can use it.

So next time you’re thinking about dusting off your context free grammar skills and busting out your favorite compiler compiler, just don’t do it. There’s an easier way.

Maker to Maker Business: Customer Service

When you start making something, there are a million things on your mind – minute design details, which parts to use, how to operate the tools, what it will take to assemble. All these problems are vital to the success of your product, and to a maker, they are inherently exciting: each decision is another tiny love letter to the unique awesomeness of your project, each an opportunity for error and complexity, but also for wonder and satisfaction.

Something you are probably not thinking about is customer service.

Ugh, customer service…

Let’s be very clear about this: selling your product involves a great deal of customer service. This might come as a shock to you, since so far you’ve been engrossed in the process of actually making your product, and it’s only when you list your first item for sale will it hit home just how much other work there is to do.

This realization can be a bit demoralizing initially, because in a lot of ways customer service isn’t actually part of making anything. It’s just a peripheral aspect of the process of selling your product, and as a maker, chances are that it’s the making part that got you started in the first place. But customer service is a crucial part of your maker business, and not something you can ignore.

This rest of this post is devoted to some practical tips we’ve learned in the process of operating our business. A lot of these concepts apply specifically to the DIY/maker business, but some of them are applicable to businesses in general.

Customer service is a product, too

It’s important to consider your customer service a product of your business. When your customers speak about their dealings with you, whether it’s on a feedback form or face-to-face with their friends, they’ll be rating both your product and their experience with you. 
Think of all the customer service interactions you’ve ever had. Chances are most of them were “good enough.” But those aren’t the ones you remember. It’s the amazing ones and the awful ones that stick with you. Don’t settle for a “good enough” customer service experience. After all, would you ship a “good enough” product, or do you want your business to be known for offering the best there is? If you try to go the extra mile to make your customer service excellent, it will pay for itself in a boosted reputation, happy customers, and additional sales.

Love your customers

It can be difficult to approach customer service with the right attitude. Every email you have to respond to takes time away from actually building your product.

The easiest way to get your head straight is to remember one simple thing: you love your customers. After all, they have a nigh-unlimited set of options, yet they eagerly forked over their hard-earned money to buy something you designed and manufactured. How cool is that? 

Once you’ve decided to love your customers, a lot of things get easier. In every interaction, you should always make it clear to them that you genuinely appreciate their business. When your customers have issues, you should always start off by apologizing, regardless of whether the problem is your fault. From their perspective, every problem they have with your product will be your fault, no matter what it is. Starting with an empathetic statement puts you on the same team as the customer. And then even if you have to give bad news later, you’ll at least have started out on a good foot.

Respond promptly

Responding to your customer service emails quickly is really important. A lot of times, surprising your customer by getting back to them within a few hours will really impress them and help you to reduce their irritation. When someone takes the time to send you an email with a complaint or question, it’s because of something that’s on their mind, and that’s going to stay with them for a while. The more quickly you can address it, the less of a strain it is for them.
When possible, try to reply to emails as they come in. If that’s too difficult, then you should at least answer all new emails every day, even if just to tell them you got the message and are working on a solution.

Take complaints to heart, but don’t take them personally

There is a 100% chance that you will get an irate email from a customer at some point. Your product will break in shipping, or get shipped to the wrong address, or be the wrong color, or one of a thousand other problems. They will be angry, they will be demanding, and sometimes they’ll even be downright rude. All of this can make you feel terrible, especially if what they are complaining about is actually your fault.
Feeling terrible is the last thing you want to do, though. This is something I learned back when I played a lot of online poker: it’s OK to feel bad intellectually about making a mistake, but you need to keep a fair amount of emotional detachment so you can make good decisions. Otherwise, you’ll find yourself making knee-jerk reactions that lose you both your customers and your hair.

When dealing with complaints, the first thing you should do is apologize and offer a remedy. Next, you should analyze the mistake and change your process so it doesn’t happen again next time. And then you should move on.

Stand up to your customers

Once in a while, you’re going to be up against a customer who is just plain being unreasonable. Some examples we’ve seen are customers asking for massive customization or complaining about our posted return policy after the fact. In our experience, these customers are really few and far between, but when you do run into them, they add a lot of stress.

Generally, I would say that you should go to lengths to provide a good customer experience, but sometimes that can go too far. In practice, only you will know the difference between making an exception to give someone a great experience and compromising your prior business decisions. But whatever you do decide, deliver the news clearly and calmly, and don’t let any irritation color your communication.

Laser cut hinge system – progress!

I wrote previously about the idea I had to make my wife Genevieve a jewelry box with the laser cutter at TechShop. In the last post, I showed a little physical mockup I made of the kind of hinges I wanted to use.  That proved it would work, but an hour with a pad an pencil and I still hadn’t unwound the math I needed to predict exactly where it would end up when it opened.

Luckily, the helpful commenters funneled through from the post on the Adafruit blog quickly answered my question. It’s called a four-bar linkage, and it’s pretty well studied in mechanical engineering. Still, I found the diagrams pretty baffling (lots of greek letters…), but ultimately I figured it out.

With the equations in hand, I used OpenSCAD to produce a set of drawings.

Clown colors for contrast only. 

I’m pretty pleased with the fidelity of the four-bar calculations. Once I became friends with the Law of Cosines (and corrected all my mistakes), the numbers started working out like I expected them to, and I had good positions for my pieces. I have an angle variable that I can tweak to see where the lid would be at various places in the full motion. And it proved valuable, too: after I saw the lid angle produced by my first random set of parameters, it was clear it would have to be adjusted.

The next step is to take the panelized version to TechShop and cut out a cardboard prototype. Here’s hoping my hinging system works out!

The Roominator – What I Learned

I’ve previously written about the Roominator, my project for combating conference room hijacking. In the end, it didn’t work 100%, which was disappointing. However, I learned a lot in the process, both about how to architect a system like this and about doing design projects like this one in general. I think that this project deserves a proper post-mortem so I can share some of the insights I gained.

What went well

Dumb displays, smart application server

Right from the start, we decided we were going to put most of the actual logic in an application server written in a high-level language like Java or Ruby. Even so, it took us a while to embrace this concept fully. As developers who mostly work in high-level languages, we went down the road of making lots of little classes and interfaces in the display code that proved to be distracting overkill.

Once we got past that problem, though, we ended up with our displays doing basically nothing but showing exactly what the app server told them to. This freed us from writing complicated Arduino code for things like what to print on the display and instead focus on the crucial components – communicating with the app server and making it easy to configure the display on startup.

DIY Power over Ethernet

Of all the things that could have gone wrong with this project, our power distribution strategy turned out not to be one of them. Admittedly, it’s a bit basic, but it turns out that sending 12V out over the unused pairs in an Ethernet cable and then knocking it down to 5V in the display unit worked fine. I would however probably add some fuses and protection diodes to each port so that it’s harder to accidentally fry some part of the system.

Professionally produced PCBs are a huge productivity booster

During the first week we worked on the Roominator, I spent at least 20 painstaking hours  hand-soldering the circuitry of two display units. Only two! There were just too many connections – and opportunities to make mistakes – for it to be sane to do any more like that.

Before the second hack week, I had the sense to order some professionally-produced PCBs of our circuit, and the difference in productivity was unbelievable. Two of us assembled the remaining 10 displays in one day! And only one or two of them required any rework.

Getting PCBs made can seem kind of daunting when you are starting out, but once you learn your way around Eagle, you can easily get boards produced by BatchPCB or Seeed Studio. Particularly with Seeed Studio’s pricing, I think the threshold of when you should opt for professional boards is pretty low.

What went poorly

I2C over long range

Early on in the planning for the project, I decided to use I2C for the communication between the display units and the central master. Despite the fact that this protocol is built into Arduino devices, this proved to be a bad choice for a number of reasons.

The first and perhaps most significant is that I2C is only designed to operate over a range of about one meter. Sure, there are extender and buffer ICs out there (which I ended up using), but this lead to the creation of an extremely complex master unit. And even with the extender ICs, there were some cable runs in our building that were too long. (My suspicion is that when cabling companies come in to wire up a building, they pre-cut lengths of Cat5 to the max ethernet spec and don’t trim the excess, since it doesn’t affect the performance of actual ethernet devices. But it does muck up funky extended I2C communication.)

The other problem with using I2C in this fashion is that it’s a truly shared bus, and if one of the nodes had weird behavior, it ends up blocking the whole bus. In practice this meant that the whole system kept working great until I plugged in the one unit that was too far away from the rest and the whole system crashed to a halt. For projects where all the parts connected by I2C are really one logical device, this is OK, since you can tightly control for issues like cable length. But for systems that are distributed over a wide physical range, there are much better tools for the job.

Focusing on the wrong costs

Aside from purely technical mistakes, the overall biggest mistake I made in developing the Roominator was being too focused on the wrong costs in the project. From the get-go, I was very interested in keeping the cost of parts for each individual display unit down as low as possible, since we were eventually planning to multiply the whole thing by 12. I gave myself a target price of $50 each, which I thought was achievable. And my initial design and research led me to believe this was possible.

But in reality, this whole line of thought was wrong. I thought I was designing an end-user system. In actuality, I was designing a one-off prototype system. What this means is that instead of being focused on how much it would cost to “manufacture”, I should have been focused on how much it would cost to develop
This change in mindset makes all the difference in the world. Yes, using Ethernet to connect the displays to the app server would have cost an additional $20-$50 per display. But if I hadn’t needed to spend so much time developing my super-complicated I2C hub, I would have saved hours and hours of development and fabrication time – time which could have been spent actually building the functionality of the system instead. And even if circumstances had lead to a desire to redesign the whole system for lower costs, I still would have had a fully functional prototype to work from.

This reasoning can be extended to a lot of the decisions in this project. I was concerned that display unit PCBs were too expensive (at around $25 for the two prototypes) and so I only bought them after I made the first two by hand. In retrospect, I could have ordered them early, learned firsthand whether they were flawed, and then ordered more, saving me hours and hours of work. Another thing I could have done would have been to use plain old 5-12V wall warts to power the display units instead of doing pseudo-PoE, obviating the master unit altogether.

As dismayed as I am that the system wasn’t a complete success at the end of the project, I am pretty pleased that there was such a general lesson to be learned from it. To restate it another way, when designing products at this stage, you should make design decisions that allow you to focus on the important parts first, and the unimportant parts later, if at all.

The Roominator

There are a lot of little things that can cause friction in an office, but one of my personal pet peeves is conference room hijacking. We have twelve conference rooms in our office these days, and even though we use Google Calendar to schedule access, we still struggle with rooms being hijacked.

It’s almost always an accident – two people start chatting, one inevitably says “Let’s grab a room,” and then they just walk around the office until they happen upon an unoccupied room. Unfortunately, it’s often the case that while the room is currently unoccupied, another meeting is scheduled there in the near future. In a few minutes, the rightful occupants show up and discover that someone is already using their room! If the squatters are just using the whiteboard, it’s easy to boot them out, but if they’re taking a phone call, the people who actually reserved the room have to find a new one. The ability to do ad-hoc meetings is something we want to keep. We just want to help room-grabbers know when it is OK to grab and when it isn’t.

To try and ameliorate this problem, I spent a few of my company’s hack weeks last year working on a system I decided to call The Roominator. I originally announced it over on our dev blog, but since then I’ve been pretty sparse on the updates. I wanted to summarize the design and status of the project here for posterity. (The actual code and schematics can be found on my GitHub account.)

The Design

The arrangement that I came up with involves three key components: a display unit, to be posted outside each conference room; a “master” unit, to be stashed in our wiring closet, that distributes power and data to the displays; and an application server, hosted wherever, that does all the heavy lifting as far as the Google Calendar things go. Let’s take a look at each component in more detail.

The Display

The display component of the Roominator is actually very simple. From a UI perspective, it’s nothing more than a 20×4 character LCD, a pair of big, arcade-style pushbuttons, and three status LEDs. (And a handsome laser-cut acrylic enclosure!) The LCD displays details about who has booked a room and until when, while the LEDs give you a quick way to tell if a room is available when you’re standing at the end of a hallway. 
The two buttons allow you to make and modify ad-hoc reservations. When there is no existing reservation, the left-hand button lets you make one, with a default duration of 15 minutes. If there is an existing reservation, then the left-hand button becomes an “extend” function, allowing you to add 15 minutes at a time, while the right-hand button offers you the ability to cancel the reservation. 
Basically, the workflow I imagined is the following. You are walking around the office looking for somewhere to have a quick ad-hoc meeting. You look down the hallway and see a room with a Roominator that’s illuminating it’s green LED, meaning it’s open for at least the next 15 minutes. You walk up to the room for more information, and see that the next reservation isn’t for an hour, so you press the “Reserve” button once to get the room, then again to reserve it for a total of 30 minutes. You get done with your meeting early, so on your way out of the room, you press the “Cancel” button, which frees up the room for someone else.

The Master

The Master unit is a back-office component that serves as a go-between for the displays and the application server. The Master has a little bit of smarts in it, but not too much. It has an Ethernet jack on it which it uses to communicate with the application server over standard HTTP. Every second or so, the Master pings the app server to see what each display should display and to report in about button presses gathered from the displays. 
To communicate with the individual displays, the Master has an array of RJ45 jacks. They look just like Ethernet, but actually carry a protocol called I2C. It’s a very low-level serial protocol that doesn’t require all that much in the way of microcontroller smarts, but nonetheless supports master/multi-slave architecture, which is just what we need. Plus, it has built-in support on Arduino!
In addition to a network connection, the Master also provides power to the displays. Each of the jacks on the Master has a 12V pin and a ground pin. This allows the displays to have exactly one plug and work 100% with existing wiring. This prototype is built out of the remains of an old Ethernet switch, which we gutted for the case and the power supply, and a pair of lovingly hand-soldered port arrays.

The Application Server

Rather than work hard to write all the Google Calendar interaction code on an Arduino, we chose to put all of our complex logic in a Ruby on Rails application that we would run on a spare computer in our office. (We already have other random applications running on the same computer, so it’s not really am additional cost.) The HTTP web interface of this Rails app serves a two-fold purpose: first, a particular URL that the Master will ping constantly, and second, a place for us to configure and monitor the system as a whole.
Since this app doesn’t involve very much data, we used the default SQLite database to hold a few simple tables for mapping displays to room names and Google Calendar IDs. The calendar integration did turn out to be a bit dicey, though – the APIs have strange behavior, particularly surrounding recurrent events and deleted events, and they can be REALLY slow to return. To work around the slowness issue, we do all the calendar API stuff in a separate thread, sharing a lot of state between the calendar thread and the update requests via the database.

But… does it work?

The answer is: kinda. 
We fought through lots of problems and got as far as installing all 12 displays outside the conference rooms in our office, and while we did a pretty decent demo, we aren’t using it today. It came down to two key problems. The first problem was I2C. I2C is limited by the total amount of wiring in the network, and a few of the cable runs in our office were much longer than I expected. This meant that some of our conference rooms just couldn’t be served by the system. Additionally, the protocol proved fragile – if any one display had an issue, it would cause the entire I2C bus to freeze up, which could only be fixed by restarting all the units. 
The other problem was in the application server. As I previously mentioned, the Google Calendar API didn’t prove easy to work with. There were edge cases we discovered that caused certain events to be displayed incorrectly through the system. And if our users couldn’t trust what the displays had to say, then the whole system would be useless.
Both of these problems are, of course, surmountable with more effort. However, the amount of effort required to redesign around a new communication protocol and to fight against an external API is pretty monumental in comparison to the actual value of the project. As much as it pains me to quit after so much effort, for now, this idea is going to be relegated to the back burner. I’d love to work with others who are interested in the concept to develop it into something everyone can use!

A Software Man In Hardware Land

My whole career has been spent working on software, first as a small-time consultant in high school and now as a software engineer and manager at Rapleaf. Though I’ve always harbored an intellectual soft spot for more physical engineering pursuits, I’ve never had more than passing occasion to indulge them.

That is, until recently, when Adam and I founded 8 Bit Lit, our little lamp-making business. Together we took what we thought was a really cool idea from concept to prototype to limited production run, and I have to say that while in some ways engineering is engineering, in other ways, the work I’ve done up until now did not prepare me for the stark differences between producing a software project and a hardware one. This post outlines the three of things I found most interesting between hardware and software projects: time, scaling, and repeatability and undoability.


The first of what would turn out to be many parts orders.

There is a fundamental difference in the amount of time consumed by a hardware project and a software one. Everything ends up taking far more time than I expected: design and development, prototyping, assembly, packaging, delivery.

I could go on and on about each of these, but for the sake of brevity, let’s just look at the development idea as a concrete example. When you decide you want to make a little electronic widget that does something, even something trivial, you design the circuit and then figure out what parts it will take. And then, since they’re actual, physical things, and often quite specific ones, you have to wait for those parts to show up. That means waiting a for another person somewhere else in the world to put the thing you need into a box, hand it to another person who will drive it somewhere else in a truck, and so on until it arrives at your door. Even if you pay exorbitant shipping costs, you’re looking at many hours to a few days of latency between when you decide what you want to build and when you can even try it for the first time!

Contrast this with the software world. In most cases, there is no difference between your “design” for the thing and the thing itself: the source code for a website is already a website. Everything you need is already on hand in infinite supply – you can have as many for loops as you’d like, and your personal computer is usually sufficient to test what you want to accomplish. Occasionally you might find yourself needing a specialized piece of code written by someone else, but even in these cases, it usually just means downloading a library from the internet, which takes seconds to minutes.

This is a huge difference in terms of your ability to iterate quickly and try out ideas. In software, you can go from no idea at all to a functional prototype in as long as it takes you to figure out what you want and code it up. In hardware, there’s a built-in latency barrier that makes more forethought a requirement. This means your prototypes have a higher inherent cost, slowing you down.

Some would point out that this problem can be solved by “libraries” of development parts: resistors, capacitors, and ICs of all different values and function stored in boxes on shelves. In practice, though, this part library has to be vast and a little expensive to give you more than basic coverage, and even with such a library, you’re unlikely to be able to carry any of the really specialized stuff that’s coming out all the time. Again, in the software world, you get this kind of library almost for free through the internet, and even when you can’t always be connected, the sheer number and variety of libraries you would be able to keep trivially accessible is enormous.


In many ways, the scaling process is one of the things that is most challenging to me. In software, much of scaling is handled by just throwing more processing power at the problem. Your website will have 2x as much traffic next year as this one? Double your number of servers. (Certainly there are ways in which software projects must be constructed to allow for this kind of scaling, but there are lots of frameworks designed to help you do this.)

Contrast that against the construction of a physical object. Need to make 2x as many? Does that just mean hiring 2x as many people to assemble them? Well, maybe. But it also means training those new people, and they’ll have an efficiency ramp-up period where they’ll produce less units or unshippable units or probably both. Or should you change your assembly process to be twice as efficient to create each unit in the first place? Do you have the tooling for that? Can your facility even handle 2x as many people or machines working on the products?

Software projects face some of the same problems, but the slope of their curve is so much flatter. Many, many computers can fit into a very small space and serve a great deal of requests, and as long as you’re operating from a colocation facility, there’s likely to be a large amount of space available to grow into. And that’s not even considering so-called cloud offerings, where you can trivially add more capacity to your systems with the click of a button.

Repeatability and Undoability

Try un-etching a circuit board.

I think these two are especially poignant. First, repeatability. I think of repeatability as the ability to have a process you’ve designed produce the same output from identical inputs over and over again without problems. In software, this is almost a given. It’s so intrinsic that we use it to make automated tests for ourselves to make sure things keep working – if the results all of the sudden come out differently, then we must have broken something. And generally speaking, the outputs of computer processes don’t degrade over time, even though their hardware does – they’ve been designed to tolerate errors or to fail very noisily when it’s impossible to keep going gracefully.

With physical processes, though, especially those done by hand, repeatability is not to be taken for granted. Even though a process may be designed in a perfectly repeatable pattern, reality insists on imposing random failures. This is because in the real world, there are far more variables than we can reasonably take into account. For instance, let’s say you’re hand-gluing the sides of a box together. Maybe this time, you didn’t use enough glue. Or maybe the clamp you’re using is wearing out, so the sides don’t get good contact. Or maybe one of the sides was made from raw materials with intrinsic flaws, invisible little cracks that doom the part to failure. These problems arise even when a person is not responsible for the actual labor – maybe your milling bit finally snaps from wear or material variations give you an unacceptable result. The bottom line is that these things are difficult to account for.

Similar to repeatability is undoability. I think of undoability as the ability to reverse an erroneous process such that you can fix things and move on. When you are working on a software project, mistakes are often almost trivial to reverse: you click the “undo” button, or you revert your changes in your source control manager, and you’re back to where you were. Because your actual work output is data – either code or the results of your processes – making copies is fundamentally cheap or free, which means that with a little care, you can trivially protect yourself from losing everything to mistakes. This makes your mistakes very cheap – so cheap, in fact, that its often reasonable to just try something that might not work out, since you can always just go back.

The real world is not so forgiving. Many physical processes are not trivially reversible, if at all. If you glue a box together inside out, then there’s a good chance it’s going to stay that way and be a total loss. Sure, a $4 plastic box may not be a big cost for a random experiment, but what about a $50 ethernet module? Now you have to think carefully about how a failed test could be made reversible. This has significant implications for design and production, if you’re used the software way of thinking of cheap mistakes. In the long run, this slows down the design process and costs you money during production.

Sometimes you can design undoability into your processes from the beginning, which can pay off big time. For instance, instead of a box you glue together, you make it fastened together with screws so you can always just take it apart if you make a mistake. However, this approach introduces its own set of costs: more complex design, more actual parts, more steps for assembly, and aesthetic compromises. You just have to balance all these factors when you’re deciding how to make your product.

You might think from this discussion that this experience has shown me the absolute superiority of software projects over hardware ones. Nothing could be further from the truth. Despite the difficulties, there’s definitely an element of satisfaction I’ve found from this project that isn’t something easily gotten from software, even from the coolest projects I’ve done. There’s something about producing an actual, tangible thing at the end of the day that will keep me striving to get better at the process and hone my craft, no matter how difficult it is.

Lasercut hinge mockup


I’m designing a laser-cut jewelry box for Genevieve, and one of the features I’m hoping to integrate is a cool hinge system that makes the lid sort of float back instead of just flap open. Basically imagine the trays  you find inside of those unfolding tackle boxes, only with asymmetrical connection struts. I looked around the internet trying to figure out what this is called, but came up short. I can’t imagine I invented this – anyone have any leads on what this kind of construction is called?

Anyway, I’ve had a pretty clear idea of what I wanted for a few days now, but I was stuck puzzling over how to conceptualize all the trigonometry involved to predict the motion of the lid. I finally decided it wasn’t worth waiting for complete understanding and that I should just make a mockup instead. The video above is some cardboard and some #4-40 screws I had laying around thrown together with complete guesses for the dimensions.

To my surprise, it actually worked the way I hoped it would! I think I’ll be able to use this to connect the lid to the box with all laser-cut parts and possibly with no fasteners at all. Stay tuned for further details as I get farther into the design.

One-transistor audio amplifier for Arduino projects

For my recent Question Block Lamp project, I wanted to be able to play sound effects. Initially I was a little concerned that it would be difficult, but after I found the awesome Mario Piano Sheet Music project and Arduino’s tone library, it looked like everything was going to be super easy!

However, after writing the code and wiring up the circuit, I ran into a little problem: the sound that came out of the speaker was too quiet. It was audible, but wasn’t exactly robust, and that was with it into my breadboard. Installed, the speaker was going to be stuck on the inside of a 3mm acrylic box, so it seemed like there was significant risk of the sound effects being inaudible.

Sound volume is directly proportional to current. When you’re hooking up a speaker to an Arduino as described above, the reason for the softness of the sound comes down to the fact that the digital out pins on AVR microcontrollers (ATMegas for official Arduino boards, or the ATTiny in my case) can only source or sink around 50 mA, which is why the tone examples have you hooking up the speaker through a 100-ohm resistor. Most speakers, including the cheap ones at RadioShack, can handle a lot more current than that, and without the resistor you’d probably fry the pin on your microcontroller.

So the problem has an obvious diagnosis, but what about the solution? I’ve read about audio amplifiers in the DIY context in the past, but truth be told all that did was make me nervous. I thought it was likely to be complex, require a number of additional components on the board, and would add cost to the project.

Yet again, it turns out that I was over-thinking the problem. In most cases where you need to use a professionally designed audio amplifier, the audio is a complex waveform, and the way you amplify it can radically change how it sounds. But when you’re using Arduino’s tone library, your waveform is actually incredibly simple: it’s nothing more than a square wave that swings from +5v to ground on the frequency of the note you’re playing.

What’s so great about that? All you need to do to amplify the current of a square wave is a single transistor. It’s really easy to wire up: just connect the Arduino’s output pin to the transistor’s base pin through a 100-ohm resistor, then the collector pin to +5v and the emitter pin to the speaker’s + lead.

This solution costs almost nothing and is staggeringly effective. When I tested it, there was a clear, significant volume increase. Even from inside the sealed box, it was more than loud enough to get the job done. Isn’t it great when things work out so well?

My Machine of Death stories as an Amazon Ebook

Unfortunately, I was rejected from the Machine of Death anthology. But I still liked my stories a lot, and decided that I would use their existence and an opportunity to learn about the Amazon Kindle self-publishing option. It was a very smooth process and I will definitely be using them again in the future with my other pieces.

Check them out on Amazon, or if you would rather just read them for free, the Google docs are here and here.