Category Archives: Open-Source Hardware

Cellular Chronometer Part 2: The PCB

Leave a reply

I’m designing an LED matrix clock that plays Conway’s Game of Life to evolve a representation of the current time. See the whole series of blog posts about the project here.

At the heart of this project is the PCB. I set out to push my limits a bit, and I certainly succeeded at that. This is by far the most complex board I’ve ever worked on, owing mostly the sheer number of components (132 LEDs, 14 resistors, 4 capacitors, a crystal, a microcontroller, and a linear regulator) crammed in such a small space (25 x 100 mm).

The basic layout is that the front of the board is the LED matrix, while the back hosts all the support circuitry. Let’s look at each of those in turn.

The matrix

top

Laying out a grid of LEDs should be easy, right? Well, not that easy. Immediately after I got done drawing the schematic for the matrix, I discovered that the LEDs I selected simply weren’t going to fit in the available space. Faced with the prospect of 132 separate REPLACE commands, I quickly developed the beginnings of what I’m now considering my EAGLE secret weapon: what I’m calling external scripting. I wrote a simple Ruby script that generated all the names of the LEDs, and then piped that through some bash magic to compose the commands I needed. Once I pasted the results into the EAGLE command bar, boom, all LEDs replaced in one fell swoop.

Not an easy schematic to draw. Yes, I did it by hand.

Not an easy schematic to draw. Yes, I did it by hand.

This technique worked so well that I knew I’d take advantage of it again. I didn’t have to wait long. As soon as I switched from the schematic to the board, I found myself needing to actually position the LEDs. I tried making the grid match my desired spacing, but that was proving too tricky, especially when combined with having to position all the LEDs in a precise order. Scripting to the rescue!

A word on the LED layout scheme

A quick aside: at this point in the project, I had to decide on a layout scheme for the LEDs that both made it easy to route the board as well as write code to map the LEDs into a 2D grid. Charlieplex LEDs are addressed by (high pin, low pin) pairs, but I’ll need to interact with them from a more (x, y) perspective. This would not be something easy to change later, as its encoded in the hardware itself.

I elected to go with a strategy that put high/low pairs and their inverse next to each other, thinking that this would limit the number of far-flung connections needed. These pairs are laid out in a sort of round-robin fashion so that they’re all exercised. The result ends up looking like this:

charlie_scheme_illustration

Anyways. Using the earlier technique, I wrote another Ruby script that generated EAGLE commands to position all the LEDs according to this scheme. The scripting here was really crucial, because I had to try out multiple tweaks before I got everything just right, and without a script, I would have been committing to several hundred clicks per experiment!

Supporting electronics

board_bottom

The ATMEGA is the centerpiece of the back of the board. Nearby is the 16MHz crystal, and to either side are the momentary switches that allow the setting of the time. The top edge of the board is the bank of current-limiting resistors needed to drive the LEDs. Finally, on the edges of the board, there’s a 6-pin ICSP programming header and your standard LM317 linear regulator circuit set up to output 5V.

A note on the power supply. I don’t think this thing is going to be a power hog, and I’d ultimately like it to be pretty compact and beautiful, so I’m planning to just stick a 9V battery in there and call it a day. This is sorta phoning it in, but since the ICSP header breaks out the 5V bus, I figure I can always solder in a USB cable and power it from a wall wart if I have to.

Putting it together

I sent the Gerber files off to Seeed Studio’s FusionPCB service for production. About a month later, the boards turned up, and I couldn’t wait to assemble them.

2013-09-11 18.55.49

When reading about other folks’ LED matrix projects online, a common complaint was that it was difficult to get all the SMD LEDs aligned properly without some sort of jig. I didn’t want to mess around with creating a special fab tool, so instead I made the conscious choice to go with solder paste and hot air reflow. The idea was that I’d get the automatic alignment effect that solder paste + hot air exhibits.

Here, I made a miscalculation. Instead of making a solder paste stencil and applying it with a putty knife (which I’ve done before!), I decided to just dispense the paste directly from the syringe. This was a disaster. The paste I have has gotten kind of old, making it less apt to flow out the tiny syringe tips I have. Plus, I somehow lost the plunger that came with the paste, and was stuck using a Sharpie marker as a makeshift plunger. Not what I would call ergonomic. Still, this might have been OK for a few tens of pads… but I was applying paste to both sides of 125 LEDs! It took well over an hour, and by the end, I was in a lot of pain and didn’t have the patience to do it correctly. Consequently, a lot of the later LEDs got a huge glop of paste that sometimes bridged their pads and was just generally poorly done.

Populating the board was painstaking, but nowhere near as difficult as the pasting. When it was done, I fired up my trusty heat gun to reflow the board. About 85% of the LEDs did exactly what I was hoping for and sucked themselves right into place, but the rest pulled away from their pads, tombstoned, or clearly bridged under. I ended up spending another hour or so just going through and doing rework on the bad LEDs.

matrix_populated

With the matrix side behind me, I turned my attention to the back of the board. At this point I was pretty done with solder paste, so I switched over to the iron. First up was the microcontroller. I used the “flow and wick” technique, which worked like a charm – after I refreshed my memory from this excellent SparkFun tutorial. (Heres a better video that illustrates the technique more closely.) The rest of the components were no problem – I just tinned the pads, positioned the components with tweezers, and then reflowed the pads until the pieces stuck. The one exception here was the crystal, which doesn’t have any exposed leads. For this guy, I just tinned the pads, then positioned the crystal and hit it with the hot air gun. I was relieved when I saw the crystal shift and adjust itself into place. Phew.

back_populated

Turning it on

With the board fully populated, it was time to turn it on. It’s always scary to do the first power on test of a new project, particularly one where it’s impossible to do incremental tests. I flashed a spare Arduino with with ArduinoISP sketch, hooked it up to the programming header, and proceeded to burn a bootloader. Astoundingly, it worked the first time!

Next, it was time to test the matrix itself. I had already developed a Charlieplex matrix driver during my minimal prototyping stage, but the new board was really different and needed a new driver. But before I dove into porting the complex logic onto the new board, I wrote a trivial sketch that just exercised all the LEDs in sequence by manually toggling the pin pairs according to the scheme described above.

Guess what? It didn’t work. At least, not all of it. There were numerous spots in the matrix where LEDs were skipped, and a few spots where instead of a single LED lighting, multiple LEDs would glow dimly. It turns out there were a few problems here. The first was that my test sketch accidentally referenced the same pin twice, making it do a weird rewind-stutter thing during the test sweep. That one took an embarrassingly long time to find. With that software error out of the way, I proceeded from one LED to the next, debugging each misbehaving one. A few of the LEDs were in backwards – a population error. Some just seemed to be busted, and worked after replacing with a spare. Whether they came off the reel that way or were damaged during reflow, who knows.

By the end of the night, I was done debugging and all the LEDs worked as expected. Hooray! No disastrous issues! Now, I could finally start on the actual production sketch.

Laser cut hinge system – progress!

Leave a reply

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

Leave a reply

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

Leave a reply

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!

Lasercut hinge mockup

2 Replies
 

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.