How to Get Stuff Done

4/15/2014— Kelsey Breseman

As a company with six people and a lot of work to do, it’s a challenge to keep track of tasks and priorities. Six people is just big enough that you might not know what everyone is doing, and small enough that there are always more immediately important tasks to do than people to do them.

We’ve tried a few different ways to make sure things get done efficiently, and usually end up using some combination of all of these:

Post-it graphs

Post-its are visual and moveable. If you put them on a nearby wall, you’ll notice them. They’re some of our best productivity tools.

Jon came up with a really good graph:

Every yellow post-it represents a task to be done before we ship. The X-axis goes from low to high priority, and the Y-axis is completeness. A fully complete task can be moved to the top. The pink marks on some tasks are ripped pink Post-it denoting that the task is blocked until another task is completed.

This is much better than a binary list, because there are a number of almost-but-not-quite finished tasks, and so it more accurately represents the state of the project, and we move our tasks up the wall at the end of the day. Additionally, since they’re ordered by priority, it’s really easy to look at the wall and figure out what you should be working on. Ideally, your graph is y=x at any given time as you try to push up the lower right quadrant.

The blue and purple post-its are larger-scale categories of tasks, also ordered by priority.

We also tried post-its for public shaming:

The blog is important for all manner of reasons, but we still regularly neglect to write. We’ve tried various tricks (setting exact due dates, me personally reminding each person, etc.). This one is simple: everyone’s name is on a Post-it. The masking tape divides people who owe a blog post from people who have written recently. The objective is to get across to the safe side of the line.

We took this one down for fear of the tape bonding to the wall paint, but it’s intact in principle.


Bread o’clock is around 4pm, when we’re all kind of hungry. We stand up, look at and adjust the post-it wall, and informally discuss what we’re working on. This facilitates a “let me help you with your problem” exchange between team members so tasks get accomplished with a minimum of frustration.

Wednesday is “food day”: the company buys lunch and we talk about the bigger picture (where the company is going) and things that just take a while to talk about. This makes sure we continue to think about where we’re going as a company, and not just the day-to-day.

We eat lunch together anyway, but on Wednesdays we intentionally talk about work.


At the beginning of each day, in our company chat (Zulip), we each write what we’re planning to work on. At the end, we write what we’ve accomplished. This way we know what everyone is working on, and have a record of our own progress.


For the zillions of little tasks we need to complete, we use Asana. It lets you organize things into projects as a team, assign tasks to team members, and give due dates. Handy features include recurring tasks (I have one that reminds me to do accounting once a month) and emails/push notifications reminding you that your tasks are overdue.

The difficulty is, it’s a task in itself to keep Asana tasks up to date, and if you forget to check Asana or filter out the emails, it quickly piles up into a mess of outdated assignments.

We use Asana on-again, off-again. Mostly, I use it as my personal to-do list for company tasks.


It helps to have a deadline for any given task, and calendars are great visual tools to remind yourself exactly how long you have left.

We’ve found a giant calendar to be very helpful with long-term team milestones. Particularly last summer, when the founding team was still deciding whether they would continue when fall semester started back up, there were exact dates we needed to hit corresponding to board revisions– and if we didn’t hit them, the product wouldn’t launch.

This motivated us into more than a couple of all-nighters, because you can’t argue with a calendar.

All right, time to check the wall and see what’s next.


Tessel Progression

4/9/2014— Jia Huang

About 2 days ago we put Tessel in production. We just got back the time estimates from our manufacturer– it’ll take about 1.5 months for production to finish, and if we’re lucky, 2 months till ship.

One year ago Jon, Tim, and I set out to build what would become Tessel. Now that we’ve put Tessel in production (for real this time), I think it’s a good time to go through all the different revisions we made along the way.

Version 1, April 2013

Jon mainly designed this board for a class on electronics prototyping. I believe it was supposed to stream music. The main MCU was a Freescale chip and there’s a breakout for Arduino shields. There’s a population option for a second chip (probably as a programmer of some sort). The Wifi chip is already present.

Jon pretended that the LEDs could blink.

Version 2, May 2013

I started working on the PCB and electrical design at this point. The board is completely redesigned with the chips we are still using (although in different footprints). For this revision we were just trying to get the main LPC chip working on our own PCB. I messed up on the JTAG breakout that’s used for programming though, so I ended up having to splice on some wires in order to get the right pin connections.

We got the LEDs actually blinking.

Version 3, June 2013

This is basically the same as the previous version except we fixed all the previous mistakes. All the main components are populated at this point though I think we still had some problems with WiFi.

It was taking me about a day to assemble one of these things even with a stencil. Jon and I would sit side by side and make two of them, of which one would actually work. I think we only ever had two or three of these things working.

We were able to run “javascript” on this… to blink some lights.

Around this time I started getting really scared that WiFi would never work so I made all these WiFi breakouts. They look pretty similar but I was playing around with trace spacing and top and bottom copper.

Version 4, July 2013

We had Eric contracting for us at this point so I got lucky and didn’t have to lay out PCBs anymore. Obviously Eric is way better at it than me because this revision had us going from chips with visible pins (and solderable by hand) to Ball Grid Arrays. Worthington Assembly helped us make this batch.

You can see the beginnings of our 10-pin header modules start to form along with the final formfactor.

Wifi actually worked at this point. We could probably run the current Tessel firmware on these boards if we really wanted to.

Version 5, August 2013

Eric got fancy and rotated the chip which gave us room to add the GPIO bank at the back. We lost some room for the mounting holes though and ended up only having 2 in the middle. There’s also a WiFi debug port so we could debug that easier.

We had some USB issues with this revision, but were able to run it fully. This is the model shown in our crowdfunding videos.

Version 6, October 2013

We added some additional power regulation features on this board so that it could be powered externally. There’s also a breakout for the WiFi antenna so that a bigger external antenna can be attached if the chip antenna does not provide a good signal.

The boot selector pins (pins that determine if Tessel boots from USB or from internal Flash) are exposed so that we could revert bad firmware versions easily.

We still ran into USB issues with this version though, so we had to do another prototyping round.

Version 7, November 2013

We finally fixed the USB issue with this revision. We thought this was the version we were going to use for production, until we hit that reset issue.

We ended up ordering a bunch of PCBs for this revision and then scrapping them when we decided to push back production.

Version 8, March 2014

In order to fix the reset issue we added a chip that holds our MCU in reset until after our external Flash boots up. Since we had to do this revision anyway, we thought that we might as well add on another feature (bad idea). The extra feature involved changing around the power circuitry (all the chips on the bottom left) so that Tessel can be powered off of more than 5.5V externally.

We also removed the external boot selection pins because they were on our high speed RAM lines and messing with them would sometimes crash Tessel or prevent it from booting correctly. In its place we wrote a custom bootloader to recover from bad firmware.

We ended up having problems with the power chip though, so we did another revision to fix it…

Version 9, April 2014

Here we’re approaching maximum utilization of all available space. The power circuitry (bottom left) gets even more crowded.

This is the version we actually put into production about 2 days ago.

Originally Tim, Jon, and I thought that we would have this thing completed in 3 months over the summer, so we tripled the time (like everyone said we should) and gave ourselves an additional 6 months for the crowdfunding campaign to ship.

Well, it turns out it was harder than we thought, so now 3 months after that deadline we’re almost there. We’re still patching up our firmware and related tools, along with trying to provide everyone with a superb first run experience.


Tessel’s First Run

4/7/2014— Kelsey Breseman

I’ve been on-and-off designing the first run experience for Tessel since January, and wanted to share a bit of the process and thinking behind our first run/installation sequence.

One of the major selling points of Tessel is its ease of use: the code should be intuitive to a web developer. Adding physical modules should be just like adding code modules. You should be able to get from idea to simple prototype very quickly, and without any frustration related to using our tools.

Therefore, in making the first run experience for Tessel, I want to show you how quickly you can make your code interact with physical hardware. I set a goal of two minutes maximum from unboxing to working code.

I started here, thinking about all of the different backgrounds of our users and how we might serve each individually. There were two main components of this:

  1. Different modules for different people: everybody gets a different set of modules. I didn’t want to waste people’s time with modules they didn’t have, but wanted to make sure everyone got the instructions they needed.
  2. Different skill levels: most of our users are experienced web programmers. However, we do have a few who have never used the command line or even written a line of code. I wanted to make sure that our first run didn’t alienate anyone, even absolute beginners (this is something I’m still trying to resolve– suggestions welcome).

This led me to make a first page with a lot of options:

Original Page 1

You could select any grouping of modules, and then click on one of the two big buttons. The “I’ve never programmed” option took you through a command line tutorial before proceeding on the main path of installation > tutorials > projects (filtered to show only projects involving your modules).

On the page teaching use of each module, I only showed the modules the user had selected. You could switch between relevant tutorials by clicking on the icons shown at the top:

Original modules tutorial page

On the face of it, this was a nice “choose your own adventure” tutorial: you get just the information relevant to you by telling the tutorial your unique situation. But when I showed it to users (one advantage of a coworking space is how often people who have no idea what you’re working on wander by), they were paralyzed by choice.

As I now recall, I hated “Choose Your Own Adventure” books as a kid. I always wanted to know what would happen if I made a different choice, and there were just too many choices to follow every forking plot line. Simultaneously, I felt boxed in by the choices I was allowed to make: I didn’t want to select from the multiple choice menu, I wanted to make my own creative decisions.

Something similar was happening here: people had to make choices right away, with no information. Not only was module selection unclear, but they worried that if they skipped the beginner button, they’d be in over their heads and might not be able to turn back.

So my next design made the choice a bit easier. The module icons were made more obvious with an increase in size, and I shrunk the text on the beginner button, adding explanatory text below on mouseover:

Clip from Rev. 2 of the first page

I implemented similar slight design changes throughout the first run experience in response to user feedback– and these changes did improve successive users’ flow through the process. However, there’s only so far you can go with a basically flawed design, and I realized that I’d become stuck in my original design paradigm. So I asked the team for a design review with a focus on improving the overall flow– somewhat inspired by this blog post.

Design reviews are great. I highly recommend going back and forth between talking to users and getting feedback from your team, because they provide different kinds of feedback. Users can show you that they have a specific problem or reaction. Teammates in a design review are more likely to assess your bigger picture design.

My team had some really good feedback as a group, and by the end of twenty minutes, I had some solid design paradigms and ideas for implementation, which have driven my next round of edits.

Here’s the current flow (still in development, so anything could change):

First page: install. (No, you can’t install tessel from npm yet. Soon.)

First code: blink some lights.

Modules page: an expandable list of each module, also navigable by the sidebar menu, which expands on this page to show each module.

Modules page with the accelerometer tutorial expanded

…and more to follow! I’m still messing with the tweet-from-a-Tessel tutorial and the page of projects at the end.

Suggestions welcome!

Is there anything you’d particularly like to see? Any particularly good first run experiences I should use as examples? Let me know.

Kelsey Breseman

Stress Testing 04

4/4/2014— Eric Kolker

Hey Tessellators, Eric here.

The pressure to ship is enormous. Every day that we take to verify or double check something related to the hardware means another day that you have to wait for your Tessels.

On the last version, the power plant wasn’t perfect.

Bye, bye black boxes

In my post last month, version three introduced a new voltage regulator and related support circuitry, including a new power multiplexer IC. When we fired up the boards, it became clear very quickly that the specific power mux part was, quite literally, throwing an error and shutting down during certain normal-operation conditions.

At the time of my last post, we knew of another part in the same family that would theoretically allow us to sidestep the issue. Mr. Murphy and his law had other plans, however, so we did what we always do: overnighted parts for a new design, stripped down the latest board, and patched in the new design. Here’s what the patched-in version looks like (disconnected from the Tessel):

The new design is as simple as possible and to eliminates the more specialized ICs I had been using before. I wanted to know exactly what was inside of the chips I was using, not rely on someone else’s fancy (and unpredictable) design. The result has a larger solution size (EE jargon for “it takes up more space on the board”), but is much more transparent. Fortunately, it also works like a charm. Our power input stage now looks like this:

Stress tests

Just as software must pass its unit tests, hardware has its own suite of tests that need to be run to make sure it’s ready for prime time. These include a traditional burn-in, as well as lots of different scenarios related to how the device is powered.

Part of the initial power plant redesign gave Tessel the ability to run off of more than just USB power, giving you the freedom to use virtually any battery under the sun to power your Tessellations. However, with great power comes great responsibility, so I knew I had to be sure that, no matter what you do to Tessel, it won’t give up on you. This means that I spent all of Thursday abusing the input power path. It’s been terrifying but, honestly, a lot of fun. Here’s where we are right now:

  • Tessel can be powered off up to 15 V on the VIN pins by the USB port (~3.4 V is probably the lowest you’d want to go)
  • It can also withstand power being applied backwards to the same VIN pins and live to tessel push myCode.js another day
  • Tessel switches automatically between USB and external power (depending on what’s available and with a preference for USB) without rebooting or halting code in any way.
  • The voltage in to the DCDC converter tracks the input voltage beautifully (read: within ~0.3 V and better with for higher input voltages). This voltage is broken out at the GPIO bank, but should not be used as a source of significant current.
  • If you accidentally short the pins which provide power to the DCDC converter (the voltage regulator that takes in up to 15 V and gives us 3.3 V out), Tessel does not care, and will turn on again once the short is removed.

As an aside, even though that’s a pretty good list, I’m going to ask that you please read the docs if you plan to power Tessel through the VIN pins, never power Tessel through the GPIO bank, and try to avoid shorting anything. At the end of the day, I can do my best to protect the Tessel from abuse, but there are a lot more of you than there are of us.

Running the tests

Testing hardware is, frankly, a lot more exciting than testing software. With software, the worst that’s likely to happen is a BSOD or a string of error messages, after which you track down bugs and try again as quickly as a minute later. With hardware, there’s a very real chance that something burns, melts, catches fire, or generally releases its magic smoke.

Sometimes, the testing is deliberately destructive. This poor -03 was my guinea pig for many of the power plant hacks.

Other times, the goal is to test things over and over again, like the self-input-switching Tessel Jon rigged up. Sometimes, though, repetition and boundary-pushing are combined, like in this video, where I repeatedly short out Tessel’s input power and the board keeps chugging along.

What this means for you, patient reader

Pending any fires at TMHQ (Greentown Labs), Jia is in the process of talking to our manufacturers about making 2500 of these boards (pre-sales are a little below 1500 right now, but we wouldn’t want to run out a month or two after launching, would we?). As we said in a recent post and backer email, we’d have about a month between signing off on the run and the first batch of boards hitting our desks.

At this point, we’re ready if you are.


4/4/2014— Eric Kolker

Stress testing the TM-00-04 hardware by shorting the input power to ground…repeatedly.

Notice how the bootup light show happens each time the short is removed and how Tessel runs blinky from flash at the end of the clip. Also note that the fuse cuts current draw within a second to < 200 mA.

The tools, left to right:

  • The power supply, which is set to 15 V and/or a maximum of ~3 A. When the Tessel is not being shorted, it draws about 70 mA, but during the beginning of a short condition this number spikes very high before the fuse kicks in.
  • An oscilloscope, which lets us see what the electronics are up to. The red line is the input voltage (5 V/div resolution) and the yellow line the 3.3 V rail (1 V/div). The timescale is 50 us/div.
  • My multimeter, which I used to measure the resistance of the fuse post-short.

Final Hardware Testing

4/3/2014— Jon McKay

Tessel version nine arrived at our office yesterday. It came in yesterday straight out of Worthington Assembly’s ovens.

Each new hardware revision means a whole slew of tests to make sure we fixed any known problems and haven’t created any new ones.

Eric is testing out how robust the board is after merciless shortings on both USB input and external power lines. He had designed new power circuitry to try and prevent the board from being fried in the event of a short and preliminary results are looking promising.

I have a test rig to put our power switching circuitry through the hoops. Tessel can be powered off of USB or external power (up to 15V). We want users to be able to program Tessel over USB, then detatch out the USB cable and have their program continue running off of external power (if it’s connected) without a hiccup.

Yes, the header on the old relay modules were assembled backwards and yes we are embarrassed. This relay module is plugged in upside down, and if you do that with the production models they won’t work.

My test rig (above) has both USB and an external LiPo battery connected to Tessel at the same time. The USB power is intercepted by a debugging circuit board (below) that allows us to splice off USB power into a relay connected to Tessel.

That allows Tessel to tell the relay to either connect the USB circuit or disconnect it. That is, Tessel is testing its own power regulation circuitry by switching its input power between USB and the LiPo. If the switch fails, Tessel will stop blinking lights because the program is stored in RAM and will be erased on power failure. Tessel testing itself is a beautiful thing.

It both terrifies me and excites me that this revision of the board seems to be working to spec (knock on wood). If all goes well, we can be set to start up production early next week.

Jon McKay

Update: Shipping Schedule

3/25/2014— Updates

Where we’re at on the reset issue:

We got the pre-production boards back and have confirmed that the reset issue is fixed. But one of the parts used in the updated power plant did not perform to spec when placed on the Tessel (off-board tests worked fine, even when wired directly into the Tessel). The issue is only apparent when Tessel is powered over external power (not USB), but we don’t feel comfortable shipping something that is not working perfectly.

We did another redesign of the power plant to fix the issue, and have sent out Tessel to the manufacturers for another test batch.

What this means for scheduling:

  • Test batch: We’ve pushed out a new design to fix the power plant. We expect to get it back in about 1 to 1.5 weeks.
  • Manufacturing: Once we’ve determined that the new design works, we tell our manufacturers to go ahead. They start making them and then send us the batch in about a month.
  • Fulfillment: We send everything over to our fulfillment house, and they start packing up and sending off orders right away.
  • Shipping: Our fulfillment house will send you tracking numbers when they put your package in the mail. After that, domestic orders (USA) should receive Tessels in 2-7 business days; international orders should arrive within 2-3 weeks.

Then you’ll have your Tessel!

We’re working on making an excellent installation/first run experience, and we are currently setting up a forum, in addition to improving and finalizing firmware.

Other news:

We’ve added a link to the top of the status page that will take you to the latest updates-related post on our blog, so you can check there to make sure your information is current.

Back to work!
Kelsey, Jia, Jon, Eric, Kevin, and Tim

BLE Module & Mooshimeter

3/10/2014— Jon McKay

For the past few weeks, I’ve been head-down in technical development on our Bluetooth Low Energy module driver. We’re using the BlueGiga BLE113 chip for our bluetooth communication and it receives commands over the UART bus from Tessel.

The Status of Bluetooth Hardware

Our Bluetooth Module has undergone a several revisions since our first attempt:

You’ll notice that there are several through-holes on the bottom of the final revision.

As in many of our modules, we wanted to expose some extra functionality for more hardware-savvy users without getting in the way of folks who don’t need it. We’ve exposed an I2C port, two GPIOs, and an ADC on the module itself. The GPIOs are important for making the module use less power (discussed below).

We made a difficult decision regarding the assignment of the third GPIO pin on the module port. We were running into an issue where if the reset button on the Tessel was pressed while the BLE module was plugged in, it would pull the UART transmit line low, causing the BLE113 UART parser to freeze when it parsed what it perceived as an invalid array of zeros.

It wouldn’t unfreeze until the module was physically reset. After contacting BlueGiga support (who are exceptionally responsive, by the way), we came to the conclusion that the problem wouldn’t be solved until BlueGiga’s software engineer got around to fixing it.

Making the success of your hardware dependent on the schedule of another company’s engineer is rarely a good idea. We had little choice but to assign the third GPIO pin directly to the BLE113 reset line so that we could automatically reset the module in software between code deployments. The downside is that third GPIO was originally assigned to the wake-pin, which allowed the module to go to sleep and save energy when the Tessel wasn’t communicating with it.

In order to preserve that functionality, we exposed the wake-pin on the bank of extra through holes so that those who need to make BLE as lower power as possible can still access that functionality.

Testing with Mooshimeter

Our good friends over at Mooshim Engineering were kind enough to lend us an early version of their new Mooshimeter, a bluetooth-enabled multimeter. It was a perfect chance to test out our bluetooth module and its driver. Integrating with the Mooshimeter was incredibly easy. After connecting to the device, I simply had to tell it to turn on its analog-to-digital converter and I could start receiving asynchronous notifications with voltage values. Check out the JavaScript code below to start printing out voltage values in the terminal (gist):

var tessel = require('tessel');
var blePort = tessel.port('a');
var bleDriver = require('../');

bluetooth = bleDriver.use(blePort, function(err) {
  if (err) {
    return console.log("Failed to connect");
  else {
    // Connect to moosh
    connectToMoosh(function(moosh) {
      // Tell the meter to start reading, pass back char to read
      setMeterSettings(moosh, function(meterSample) {
        // Start reading that char

function startReadingMeter(meterSample) {

    meterSample.on('notification', function(value) {
      var voltage = 0;
      for (var i = 0; i < 3; i++) {
        voltage += value[3+i] << (i*8);
      voltage = (0x1000000 - voltage)  * (1.51292917e-04);

      console.log("Voltage", voltage);


function setMeterSettings(mooshimeter, callback) {
  if (mooshimeter) {
    // Find the characteristic with meter settings
    mooshimeter.discoverCharacteristics(['ffa2', 'ffa6'], function(err, characteristics) {
      var meterSample = characteristics[0];
      var meterSettings = characteristics[1];
      // Update meter settings struct to start reading...
      meterSettings.write(new Buffer([3, 2, 0, 0, 0, 0, 0, 0, 23]), function(err, valueWritten) {
        callback && callback(meterSample);

function connectToMoosh(callback) {
  bluetooth.filterDiscover(mooshFilter, function(err, moosh) {
    bluetooth.stopScanning(function(err) {
      moosh.connect(function(err) {
        callback && callback(moosh);


function mooshFilter(peripheral, callback) {
  for (var i = 0; i < peripheral.advertisingData.length; i++) {
    var packet = peripheral.advertisingData[i];

    if (packet.type = 'Incomplete List of 16-bit Service Class UUIDs'
        &&[0] == '0xffa0') {
      return callback(true);
  return  callback(false);


See it work on Vine!

I’m really excited to build out the Mooshimeter example to be able to read out both channels on the multimeter.

Almost There

The Bluetooth Driver is about 60% done at this point. I still need to add security functionality (pairing, encryption, etc.), hardware functionality to be able to use the through-holes at the bottom, and the ability to update the firmware of the BlueGiga module itself over UART. Then I’ll be polishing up a comprehensive test suite so that we can continuously integrate any new changes to the driver. It’s a lot of work for one module, but totally worth it.