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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s