• 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

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