• Power Upgrades, Back in Production

    Monday, March 3, 2014

    3/3/2014— Updates

    Good news! We have resolved the reset issue, and sent off files for manufacturing. We should have the first test batch of 10 Tessels in our office next week. As soon as we’re done testing those units, we’ll pull the trigger on manufacturing the first batch. If all goes well, production will take 1.5 to 2 months.

    Here’s a render of the new boards, sans through hole components:

    If you’ve been checking out Tessel’s old layout, you might notice that we changed quite a bit in the lower left hand corner which contains all of the power conversion stuff.

    Since we had to rework Tessel’s schematic to fix the reset issue, we decided to upgrade the power handling circuits while we’re at it. In short, we’ve switched from a linear regulator to a buck regulator. Here’s a handy chart to see what this means:

    Parameter/Thing Old value New value So what?
    Voltage regulator type Linear regulator Buck (switching) More current available on the 3.3 V rail, higher efficiency
    Max current from 3.3 V rail from USB 2.0 ~500 mA ~750 mA More current available to modules!
    Max current from 3.3 V rail when running on appropriate external power 1 A 3 A So. Much. Current.
    Maximum input voltage 5.5 V 15 V Tessel can be powered off lots of different kinds of batteries. Or even stack your batteries for extra fun.
    Reverse voltage protection 8 V 20 V Now we can be extra sure that Tessel won’t die if you plug in the power backwards.


    Note that increasing the maximum possible/available input voltage and output current doesn’t mean Tessel will necessarily consume more power, but rather that Tessel can now make better use of the power it draws. More specifically, upgrading to the switching regulator means we’re automatically about 20% more efficient than we were before under all conditions.

    All our best,
    Kelsey, Jia, Eric, Tim, Kevin, and Jon

    #tessel #update #technical machine #power

  • Transparency: Keeping an Open Company

    Friday, February 14, 2014

    2/14/2014— Kelsey Breseman

    Last Thursday, we sent out a difficult announcement. We had just discovered a bug mandating a re-run of our hardware. It was not just expensive, problematic, and disappointing to us, but was also likely to cause delays.

    It’s hard to announce bad news. It’s much more fun when we get to announce exciting progress. (Tessel can post over https! Tessel can now run Express!) But it’s our responsibility to tell our backers if their product might be delayed, and it’s their right to know why.

    So we pulled ourselves together and wrote about the issue as clearly as we could. Then, not without trepidation, we sent the email explanation out to our supporters.

    We couldn’t have received a better response. There was nothing but supportive emails and tweets, solicitous encouragement from people who had given us money for a product we would not deliver on time.

    Why did we receive such a positive response?

    I think the answer to that question has to do with transparency: openness and honesty as a company.

    Why keep an open company?

    Openness in a company’s relations with its customers, supporters, and public, is humanizing. It’s simple: We want to treat you– the mass of people who interact with our information– like people. That includes respect and forthrightness, and an assumption that you will treat us like people too. That’s the goal of transparency: mutual understanding and respect through shared knowledge.

    Undersharing and oversharing

    Transparency is difficult to achieve, just from a logistical standpoint. If we don’t share anything about ourselves, you won’t know anything about us. This is non-obvious. We think about Tessel 24/7; it takes conscious effort to remember that other people don’t. It takes a lot more effort to encapsulate our thoughts and state of affairs into information bytes which we can pass on to you.

    The other piece is trying to figure out what we should tell you. What information is important enough that you will want to hear about it? We don’t want to flood your inboxes with every small success or setback, but we also want you to feel like you’re in the loop.

    Our strategies for transparency

    People have responded well to our openness. We’ve had our backers tell us that they feel like a part of the team, which is an excellent compliment. Here’s what we’re doing:

    Emails

    We send update emails to backers every two weeks. These biweekly digests include technical progress, company news, and a list of recent blog posts. These go to people who have pre-ordered our products. If you’re waiting for your Tessel, you probably care about our progress towards getting it to you. Once in two weeks is low-key. It’s infrequent enough that you probably won’t get annoyed and unsubscribe, but frequent enough that you feel up-to-date.

    Major news, we send infrequently to our major mailing list. There are around 14,000 people who have signed up on our website to get updates about Technical Machine. Most of those people haven’t bought Tessels, so we assume they’re less invested than our backers. We reserve this list for announcements such as new products, retailers carrying our products, etc.

    Passive transparency

    If you want to stay informed on your own time, you can check out our status page. It shows how far along we are on our software and hardware. It’s not perfect, though. We try to keep it up to date, but don’t always remember. For the sake of simplicity, it doesn’t cover everything that needs to happen before we ship, such as the design and creation of a first run experience, or the minutiae of supply chain. But it is useful to have a page that always shows our approximate status.

    The blog. I’ve talked about the value of the blog before. It’s a quick insight into single subjects we’ve been thinking about lately. It’s also a choose-your-own-adventure into your engagement with us: if you love it, you can put it on RSS. If you only want the need-to-know, you can pretend the blog doesn’t exist.

    Social engagement

    People email us all the time to ask for more details surrounding our products. We respond with the most up-to-date information we have, and often in more detail than you can find on our website. If there’s something we haven’t posted, it is likely because we haven’t thought of posting it. We don’t want to have secrets; we want to be an open company. By answering your emails fully and your tweets publicly, we try to keep ourselves accountable to this standard.

    All the best,
    Kelsey Breseman
    kelsey@technical.io

    #kelsey breseman #technical machine #tessel #open company #company culture #open source #ethical company #startup #community

  • Reset: Electrical Engineering from the Front Lines

    Thursday, February 13, 2014

    2/13/2014— Eric Kolker

    Hey Tesselators, Eric here.

    As many of you have heard by now, we found a problem with the main Tessel board about a week ago related to how quickly different parts of the board turn on (we’re talking microsecond timing here). We’re hard at work gathering data about the existing system and testing out possible fixes.

    The “reset issue”

    When I started this post on Friday (after one or two days of data collection but before parts had arrived from DigiKey), we were pretty sure that the SPIFI flash chip’s boot time was to blame for the behavior we were seeing. The theory was that the LPC1830 (our main processor) was trying to communicate with the flash chip, which contains all user code, before the flash was ready. Because the flash was unresponsive, the code entered a 60-second countdown after which the LPC reset itself and tried again. Since the flash had stabilized by this point, the Tessel would boot normally and detect as a USB device in “application mode.” Translation: Tessel would work after it sat untouched for a minute, but not immediately after being plugged in.

    The easiest way to cut through the ridiculous 60-second timer was simply to hit the reset button on the board, which resets the LPC, thereby restarting the boot sequence. Assuming you hit the button more than about 300 microseconds after the board is plugged in (the time it takes the flash to init), the Tessel would boot properly and become usable. We decided, though, that the need for user intervention was unacceptable (read: not shippable), so we’ve been looking into other ways to make the Tessel reset immediately after being plugged in.

    Fast forward a few days and we’ve found that the flash is definitely to blame. For a variety of reasons (hysteresis, indeterminate state inside an IC during power up, etc.), we believe that the best way to fix this issue is to add a rest control chip to the board. All that this chip does is keep the LPC’s reset line asserted for a few milliseconds after the board is powered, thereby eliminating the need for the user to hit the reset button (although this may sound like a hack, trust me that this technique is very common).

    Pull resistors

    However, one additional change is also required in order to guarantee that the reset chip does the trick. Some of the lines the LPC uses to talk to the RAM (not the flash) can serve the dual purpose of controlling how the LPC boots. More specifically, when the LPC is in its default boot-mode configuration, these lines control what software runs when the LPC boots, a feature which we’ve been exploiting to make it easy to update the firmware on Tessel. This also makes the Tessel unbrickable, which is a really nice feature.

    In order to make use of the versatility of the default configuration, we have resistors on some of the boot lines to configure them to boot from flash and actually break out others to through hole test points. This allows us to switch between “normal” boot and DFU mode (“device firmware update” — a class of USB device that lets us do the firmware update) without permanently configuring the LPC one way or another. That is to say, this keeps it flexible and allows us to physically select the boot mode.

    However, the LPC also has internal resistors on these lines which are controlled programmatically. The trouble is, these resistors are not configured properly as the device is booting up (their control circuitry is turning on at the same time). Pair this with the fact that the internal resistors typically fight (pull in the opposite direction from) the external ones, and the device may inadvertently boot into an undesirable state from which it may or may not be able to recover without an external reset event.

    We have gotten good results with a workaround which involves removing the external resistors (which has the added bonus of allowing us to increase the clock rate for the entire board), but this requires that we permanently configure the LPC to boot into flash, as opposed to keeping the boot options open/configurable in hardware.

    The last piece of the puzzle is a bootloader that will live in a quasi-reserved section of the flash to ensure that the Tessel remains unbrickable (unless you try to load your own firmware…without using our tools, which will refuse to write to the restricted zones). I should also clarify that the Tessel can always be recovered using a JTAG programmer (so in this case “bricked” really means “you can’t get Tessel working again without a hardware debugger”), but that we don’t ever want to force you to use anything outside of USB and WiFi to program Tessel.

    What else is new

    We’d like to take this opportunity to tweak our power input stage. We’re looking to move from a low dropout regulator (a subset of linear regulators) to a switching regulator because it will give us more current available on the 3.3 V rail. A part swap may also allow us to increase our maximum input voltage (for powering the Tessel from an external battery/supply).

    A switching regulator would allow us to draw more current from the 3.3 V rail. The two families of voltage regulators (linear and switching) differ in how they deal with the power available to them. Linear regulators, for a given output voltage and load current (P = IV), burn any excess power by dissipating it as heat. In other words, for a given regulated voltage Vout:

    As you can see, these regulators dissipate the power that comes from “extra” voltage as heat, and are poor choices when there’s a large difference between the input and output voltages.

    Switching regulators, however, conserve power from input to output and can therefore provide a higher output current at a lower output voltage (or a lower current at a higher voltage):

    Here’s to physics! (NOTE: no process is 100% efficient, so we’ll always get less than the theoretical maximum.)

    In our case, dropping from 5 V USB 2.0 down to 3.3 V allows us to get ~750 mA out (in theory). The absolute maximum is, at that point, governed by the rating of the regulator, so as much as ~1.8 A might be possible with 12 V in.

    While we’re on the subject of input voltage, right now the Tessel can be powered from a maximum of 5.5 V, which is fine for USB and single cell LiPos. We’d be looking to move to a system that gets us up to 12 V in, which would let the Tessel run off of two-cell LiPos, 6/12 V sealed lead acid (SLA) batteries, and even everyday 9 V batteries. We’re in the midst of testing parts and propagating the necessary changes to the rest of Tessel, and should have a new design by the end of next week.

    Changes wrap-up/most recent state

    We’ve found a switching regulator we like, a reset controller, and have parts in the mail for a power multiplexer (one of those changes that needed propagating). We need to test everything together, update the design files, and then place an order. We continue to live in interesting times…

    The original post - or - “Eric, your handwriting is terrible”

    Finally, I leave you with the contents of my lab notebook, complete with the scope data I took as a way of showing you what the hardware debugging process can look like sometimes. Fair warning, what follows was copied verbatim from my notebook, so it’s dense, cryptic, and a lot of the supporting information elsewhere in my notes. The general pattern it follows is:

    • graph description/experimental setup
    • graph
    • notes/comments/musings on the most recent graph

    If you’d like to try your hand at interpreting the graphs, keep the following things in mind:

    • I only had a 2-channel scope; if I had had a larger one, many of these graphs would have been combined
    • Timing is important. Be sure to look at the values on the x axis.
    • Conditions inside an IC (voltages, memory state, etc.) are highly unpredictable during boot-up, so we can’t know what’s going on inside our chips until they tell us that they’re ready. This is why it’s important to turn things on in the right order.
    • On a related note, hysteresis exists in many of these chips

    Finally, as a refresher, we’re looking into an issue which we believe has its roots in when different chips on the Tessel turn on after the Tessel is plugged in. I’m measuring voltages.

    Enjoy, noodle, and hit me with questions.

    From my notebook

    10.26.27.14

    Want to diagnose boot behavior…

    01_chx.csv
    bootup
    ch1 - 3.3V
    ch2 - reset
    1V/div, 200us/div

    02
    w/ reset button
    1 - 3.3V 2- reset

    03
    ch1 - DFU
    ch2 - reset
    1V, 400us

    04
    1 - DFU
    2 - reset
    1V, 10s

    chip did not come alive
    reset chip to blame?


    chip power disconnected
    run it again!

    board instantly came alive on 3.3V wire cut to reset controller. …what?

    05 DFU/reset 1V, 200us

    06 3.3V/reset 1V/200us

    60 second timeout is definitely not working
    hypothesis: it is hysteresis. Cap time
    added 1uF to reset
    still no 60s boot…
    but the button works…
    button on power plug does not work.
    repeated plugging in rapid succession also doesn’t work…
    ~3s delay before button push works edit: no, it doesn’t
    long wait be
    plug + reset + 3s delay to lift works

    with or without the cap, plugging in + arbitrary delay + reset button works

    07 DFU/reset 1V, 100ms

    [ NOTE: data file unreadable and data omitted for CH1 (DFU) ]

    1uF cap button push after plug

    08 no cap, same as above

    Apologies

    …for using Excel. My D3-fu is weak but, frankly, I really just miss MATLAB right about now.

    Thanks!
    ~e

    e@technical.io

    #eric kolker #technical machine #tessel #setback #electrical engineering #nxp #debugging #startup

  • Potential Hardware Delay, Software Making Progress

    Monday, February 10, 2014

    2/102014— Updates

    It’s been snowing like crazy here in Boston, but we’re warm, indoors, and hacking away on Tessel and its modules.

    Last Friday we had one of the roughest days of our company’s relatively short existence. We discovered a bug in our hardware design just days before we were going to give our assembly house the go-ahead to start assembling all 1450 Tessel PCBs that were manufactured. The bug caused Tessel to hang each time it was plugged into USB, necessitating a push of the reset button to be able to use it.

    A Bug on the Hardware

    The tough part for us as engineers, was that we had known about this bug since July, but had diagnosed it as a minor “software issue” during several independent investigations. The root cause is a race condition between the bootup of the NXP chip (the main microcontroller) and the external flash chip. Our hardware debuggers attach to the reset pin of the Tessel, so we were changing the behavior during debugging.

    The microcontroller powers up around 100 to 200 microseconds before the flash chip, which contains the firmware. The NXP boot code (in read-only memory) checks for the firmware in flash, doesn’t find it, then only checks again 60 seconds later. We’re not the only crowdfunding team to hit NXP’s bug, and it’s not something we’re comfortable shipping out to our users.

    There is not an insurmountable problem, it’s just a matter of reconciling the consequences. Here are our options:

    Solutions and Consequences

    1. NXP has documented that they fixed the “60 second bug” on their recently manufactured Cortex M4 series chips. We’re currently trying to get in touch with someone at NXP who knows if it was fixed for the M3 series as well. If this turns out to be true, we’ll just need to make sure we have those newer chips, then we can still use the same PCB. This is the most ideal situation as our shipping schedule will likely stay the same. That being said, the current chips we have were all manufactured in the last weeks of 2013, so it is unlikely there would be newer chips with this bug fixed.

    2. We could add a reset controller to our main board, which will allow us to delay the propagation of the reset signal to the microcontroller, thereby eliminating the race condition. This will require another board revision, but allows for minimal changes to Tessel’s functionality and has the silver lining of allowing us to make a handful of incremental improvements to Tessel including making USB more robust and picking a better voltage regulator. This our most likely solution and will push our shipping schedule back to late March or early April.

    We’re still learning how to create a sustainable hardware company, and this issue was a real eye opener in terms of much more time and energy we need to dedicate towards testing prior to getting products ready for shipping. We have a lot of pressure on us to ship to you, our backers, as close to the date we expected as possible, but quality is more important to us than schedule.

    While we honestly can’t think of anything we could have done differently to avoid this specific bug (besides fix every existing software and hardware issue), we’re taking several steps to ensure the quality of our hardware and software in the future. Specifically, we’ve set up a continuous integration rig to automatically run any new firmware on every version of Tessel prior to consolidating into the rest of our code base. We’ll soon be setting up continuous integration rigs for all of our modules as well.

    Progress

    But we do also have good news! We’ve been making progress on several items recently:

    • We’re able to write JS programs to flash so that they will run as soon as Tessel is powered up.
    • We’ve fixed over 50 firmware bugs reported by our beta backers.
    • We’ve been interviewing folks for various positions within the company (want to be an intern or a full-time employee? We’re looking for engineers and designers.).
    • We’ve finished the Infrared Module hardware, driver, firmware, and testbench.
    • We’ve done a major overhaul of the Audio Module. Here’s the latest prototype:

    We now support headphones and line-out and, more importantly, the module can now record audio through an onboard microphone or a line-in jack.

    We’ll keep you updated over email as things progress.

    Yours,

    Kelsey, Jia, Eric, Tim, Kevin, and Jon

    #Tessel #Update #Technical Machine #NXP #bug #startup #setback #progress #hardware #hardware is hard

  • How to Write a Press Release

    Thursday, January 30, 2014

    1/30/2014— Kelsey Breseman

    Back in November, when we closed our seed round with True and others, it was a topic of some internal debate whether we should look for press coverage on the raise. On one hand, we wanted to share our excitement with our supporters, and it’s not that often you have news that interests an actual publication. On the other hand, news of a raise is honestly not that interesting most of the time. It meant a lot to us, but talking about it outside of the team is really close to bragging.

    One of the reasons we did decide to release the information across various news sources was to practice sending out a press release. It’s not as simple as it sounds.

    Press releases are extremely formulaic, concise ways to send pre-vetted information to several reporters at once.

    A press release looks about like this:

    Company Name

    (maybe your logo in or around this space)
    Contact:
    Contact Name (just one primary contact is best here)
    email
    phone (swap email and phone number if you prefer to communicate by phone)

    PRESS RELEASE: Your Catchy Headline Here

    EMBARGO until Date Time Timezone

    City, State, Date to be released— First paragraph of release. The meat of your announcement, in as few words as possible.

    Second paragraph. Explain the point of your company/product/whatever you’re announcing. Still keep it brief.

    Third paragraph. Quote from your CEO or whomever is most relevant to the announcement.

    Fourth paragraph. Quote from someone outside the company. In our case, a quote from one of our new VCs.

    Possibly mention a few salient traction metrics here. I’ve received conflicting advice on whether to include coverage by other media outlets; some reporters might recognize you as a vetted company, while others might be turned off if you seem like old news.

    Where to find more information about your company/project/whatever. Particularly, link to your website and a place they can find relevant images.

    More information, in smaller text, if relevant. We included labeled paragraphs “About Technical Machine” and “About Technical Machine’s Investors”.

    More notes on the press release:

    Headlines should be very specific. Ours was “Technical Machine Raises $1M to Make Hardware Development Tools for Software Developers”.

    The press release should be concise, but contain all vital information. Organize it clearly and fact-check it.

    Sometimes, reporters will copy/paste from your press release, so make sure the writing is suitable for publication.

    Note that you’ll want a quote from someone outside the company, so it might take a little time to finish the release. Plan ahead!

    Before the press release– contacting reporters:

    If you are releasing to multiple reporters, you’ll want to set an embargo. The date and time of the embargo is the exact time at which you’re allowing reporters to release their articles containing information from the press release. We set ours for a Wednesday at 11am EST, because Wednesday is a low-press day (so we might stand out as more interesting), and because we see the most engagement from our users around 11am EST (8am PST).

    You’ll want to contact reporters approximately one week ahead of the embargo time. Initiate contact with an email that does not contain the press release, but does contain the headline and embargo date. Actually, let me give you an

    Email template:

    Subj: Your Catchy Headline Here UNDER EMBARGO UNTIL Date Time Timezone

    One sentence that gets the reporter excited but doesn’t give away any details (mostly just your headline restated).

    Something along the lines of: I can send you the press release under embargo (until Date Time Timezone), and I’m free to speak with you over the phone (Times & Dates, ~two of them, a day or two before the embargo is lifted) for a pre-briefing.

    That’s it!

    Our press release had success with GigaOm and the Boston Business Journal, two out of the five media outlets I had emailed about the raise (all five had previously written about or been in contact with Technical Machine). We also sent the press release to our investors True Ventures and Rough Draft Ventures, who supported the release by publishing related blog posts on the same day.

    The news was then picked up by Startup Beat, Crowdfund Insider, the San Francisco Business Times, and Xconomy Boston.

    In the end, I’m glad we sought press on the raise. Our families, friends, and supporters were enthusiastic; we had good exposure on the raise; and now I know how to release any further announcements to media outlets.

    I hope this is useful! Please let me know if you have any questions.

    Kelsey

    kelsey@technical.io

    #tessel #technical machine #kelsey breseman #marketing #press release #startup #fundraising #venture capital #PR #PR tips #public relations #media relations #reporters

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