• Tessels are in production!

    Monday, April 21, 2014

    4/21/2014— Updates

    Tessel PCBs are in manufacturing as of about two weeks ago.

    Meanwhile, our modules have been coming in:

    That’s about 1700 modules in bags on our desk, and more are rolling in all the time.

    On the software side, we’ve begun continuous integration for all Desktop tools on Windows, Linux, and OS X, thanks to Travis CI and Appveyor. We’re also running continuous integration for our firmware builds on ARM. Look for details in an upcoming blog post.

    Additional improvements:

    • We’ve completed major firmware infrastructure improvements & bug fixes
    • Eric updated hardware design documentation
    • Jon has the camera module taking pictures:

    And here’s what we’re working on:

    • Building out community site
    • Improving Wireless communications
    • Finishing module drivers
    • Improving power consumption and event loop
    • Moving to our new office in Berkeley, CA!

    #update #manufacturing #tessel #technical machine #pcbs

  • How to Get Stuff Done

    Monday, April 14, 2014

    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.

    Meetings

    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.

    Idonethis/Igonnadothis

    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.

    Asana

    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.

    Calendars

    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.

    Kelsey
    @selkeymoonbeam

    #kelsey breseman #organization #project management #pm #technical machine #tessel #asana #post-it #tasks #task management #company culture

  • Tessel Progression

    Wednesday, April 9, 2014

    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.

    Jia

    #jia huang #update #updates #tessel #technical machine #revisions #iterative design #electrical engineering #technology #pcb #pcbs #history #company culture

  • Tessel's First Run

    Monday, April 7, 2014

    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
    kelsey@technical.io

    #first run #first run experience #installation #fre #kelsey breseman #technical machine #tessel #frontend #design #user testing #user oriented collaborative design #design reviews #design review

  • Stress Testing 04

    Friday, April 4, 2014

    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.

    ~e
    e@technical.io

    #update #eric kolker #stress #testing #stress testing #power #tessel #technical machine #tessel 4 #test

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013