• 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

  • Friday, April 4, 2014

    #update #eric kolker #testing #voltage #power #tessel #technical machine #electrical engineering #test

  • Final Hardware Testing

    Thursday, April 3, 2014

    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 #Jon McKay #Electrical Engineering #Tessel #Technical Machine #Revision #Hardware #Testing #Test #Power #USB

  • Update: Shipping Schedule

    Tuesday, March 25, 2014

    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

    #update #updates #tessel #technical machine #manufacturing #electrical engineering #reset #power

August 2018

January 2018

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