• Layout Updates

    Friday, October 18, 2013

    10/17/2013— Updates

    Redesigning Tessel

    We’ve been hard at work the past week redesigning Tessel. We just sent in the design files yesterday here’s a render of the new board:

    Besides making the board red (to match our logo), there are several other changes we’ve made:

    • added an optional* place to plug in external power besides the USB cable
    • added an optional* external antenna
    • 4 mount holes instead of 2
    • moved the buttons to a much better location
    • exposed the reset pin so that Tessel can be reset by an external signal
    • added ESD protection to the USB lines so that the board doesn’t fry

    *optional: we’ll leave through hole mounts in case you want to add these things

    Sourcing Issues

    We just got done talking to a supplier for the main chip on Tessel, the LPC1830FET180, and they are estimating a 15 to 20 week lead time. We’ve been told that there is zero inventory in the distribution channel and none at NXP either. This is a new part, and before choosing it we talked with NXP representatives who assured us that it was in full production.

    We made estimates of a 12 week lead time at the latest. The lower volumes that we’ve been using for the test batches of Tessels we have been making have been readily available, so we thought that this estimate was reasonable. The beta batch is not affected by this as we were able to get those chips just fine.

    At the moment, Dragon is still processing the payments from backers, but we’ve taken out a line of credit in order to make the purchase as soon as possible. Assuming a 15 week lead time from this week, we’re looking at getting the LPC1830 around the 2nd or 3rd week of January. This puts the ship date of Tessel around mid-February.

    We’re doing our best to make sure this doesn’t turn into a delay and will continue to keep you updated on any manufacturing issues we run into. Meanwhile, we’ll continue to push on this issue with NXP to get a more accurate date on when we can ship. 


    We’ve also changed the module layouts a little. Here’s what the new accelerometers look like:

    We moved all the detailed information to the back of the board. This serves the dual purpose of leaving more room for us to put components on the front, and also gives you an easier way to find information about the module by flipping it over.


    Audio playback (with MP3) is working, with an internet streaming demo on its way.


    We’re still in the process of selecting a proper camera module. We have a few samples coming in so we can test which is best.

    2G (GPRS)

    We’re designing the 2G module this week and will hopefully have a design ready to prototype by the end of the week.


    We are switching from the BLE112 to the BLE113 module. The major differences between the 112 vs 113 is that the 113 is smaller and has better power consumption.

    #Tessel #updates #layout #update

  • JavaScript is a fixed point

    Friday, October 11, 2013

    10/11/2013— Tim Ryan

    Since JavaScript was publicly announced in 1995, there have been an enormous amount of manhours put into retaining its backward compatibility. Barring some false starts (<layer>s and document.all are so fresh) your middle school GeoCities website from 1999 might even still run today.

    Lost in the noise of cross-browser compatibility is how significant this is to JavaScript’s history: since 1996, there have been at least two mainstream implementations of JavaScript. Of the top programming languages, many of those released in the mid-90’s didn’t start seeing multiple implementations until much later, and many stil only have one major distribution. (Python, Ruby, and especially Perl are much different today, with many exciting research and production VMs available)

    This approach to change shapes the community in interesting ways. The transition from Python 2 to 3 to usher radical changes in the language was designed to take five years, a change that took a lot of manpower from the community to make happen (including tons of massive codebases). This type of radical restructuring never worked with JS. Changes made in JavaScript 1.2 (1997) were undone once IE3 was released, so Netscape could retain compatibility. In the 2000’s, the major restructuring that was JavaScript 2.0 collapsed after failing to reach consensus (surprisingly spinning off ActionScript 2.0, Flash’s programming language, in the process).

    Since 2008, ECMAScript Harmony has been the new direction for JavaScript, and it takes the same path the web always has: incremental improvement. We’ll have yield operators and new collections in every engine rather soon, all without breaking legacy code.

    After announcing Tessel (our development board programmable in JavaScript), one of the biggest questions we’ve received is why we didn’t pick Python, a language that’s very popular in the OSHW community already. Our first motivation was more technical than ideological: Node’s package manager made it easy to install modules for a single project, and the majority of Node modules are written in JavaScript itself, rather than in C.

    In “The Future of Programming in Node.js”, Isaac places a strong emphasis on Node’s backward compatibility and how code written today should work years from now. At the same time, the V8 API changed significantly between Node 0.10 and 0.12, requiring changes to the binary API.

    We’re definitely paying attention to the questions of running other languages on Tessel, as well as supporting native modules. But for now (to steal from Jeff Atwood) we think any application that can be written in JavaScript, will continue to work. We’re pretty excited by the choice to use JavaScript at a low level, for devices that run today and those that need to run for the next ten years.

    —Tim Ryan

    #javascript #Tessel #programming #programming language #web development #web developers #oshw #tim ryan #python

  • var eric = require(“electrical”);

    Thursday, October 10, 2013

    10/9/2013— Eric Kolker

    Hey, readers! My name is Eric and I’m an– scratch that– the quasi-dedicated electrical engineer on the team. I joined Technical Machine as a consultant in June, and was thrilled to be offered an official spot.

    First, some electrical engineering creds. Prior to creating next-gen, web-ready microcontrollers, my portfolio included audio visualizers (analog and FPGA-based variants), a switched-mode current source, a class D audio amplifier integrated circuit (design files and bare metal layout shown below), a “self-balancing, two-wheeled, rideable platform” (coughsegwaycoughcough), and an ultra high bandwidth, high speed wireless data link for next generation CT scanners. My name may even be in space soon, on a few PCBs I designed in high school for a picosatellite that’s finally supposed to be launching in a month or two.

    image   image

    I’ve worked with NASA, Boston Dynamics (have you seen the new Wildcat video? Holy clockballs.), and Microsoft, and have helped build things like reactive night lights and high precision tactile feedback sensors over the years as an independent contractor.

    Since joining up, I’ve owned the redesign of the Tessel hardware and have been the primary force behind bringing modules online and pushing them out the door. I’ve also been busy enforcing best practices on the electrical side and working to help make sure the leap we encourage and enable from software to hardware has a gentle and well-documented landing.

    In the coming weeks I’ll be taking another pass at the Tessel board and continuing to make our physical offerings as nice as our digital ones. I’ve also got another post in the works about what it’s been like to join a team of software developers as a guy who, until very recently, didn’t speak JS. Stay tuned!


    #Tessel #electrical engineering #hello world #eric kolker #company culture

  • Project Statistics from Backers

    Monday, October 7, 2013

    10/7/2013— Kelsey Breseman

    One of the most important pieces of starting a company is understanding your audience. At Technical Machine, we’ve been really impressed by the number of people who reach out to us. People ask us about the specifics of how Tessel works, whether we can integrate with their products, or even asking if they can help. Keep it up! We enjoy hearing from you.

    We sent out a few surveys to our backers throughout the course of our Dragon Innovation campaign to ask them what stretch goal modules we should offer. This was really useful in helping us decide what to do immediately, but we also took the opportunity to ask our backers why they had purchased a Tessel:

    (Take this graph with a grain of salt; not all of our backers responded here.)

    What does this graph say to us? Here are the main insights:

    1. “JS and Node-compatibility on a microcontroller is a childhood dream of mine.” Our backers probably come from a web development background– hence the excitement about JS and Node.

    2. “The tech seems cool and I wanted to try it out.” Backers on crowdfunding platforms, as expected, are inherently excited about new technologies. No one is surprised.

    3. “I’m excited about where I think you guys are going” is interesting because it seems almost like an investment. We’ve had a few verbal/email reactions from people who think Tessel might be the next evolution in democratizing hardware. Thanks for believing in us– we’re trying to make sure you’re right!

    4. “I don’t know hardware too well, but I want to build and this project gives me hope.” Personally, I had expected more backers to be in this category. The fact that this wasn’t a main self-categorization suggests that some of our initial audience is from people who have at least tried hardware before. Perhaps this is not so surprising; Jon, Jia, and Tim came up with the idea for Tessel after becoming frustrated with existing platforms for making internet-connected hardware– likely many of our backers are coming from a similar place.

    5. “I want to incorporate Tessel into a professional/corporate project.” This is a category we’re keeping an eye on. Tessel’s OS is designed so that the same code can be run from prototype to full-production product, and we’re excited about working with other entrepreneurs in the Internet of Things space. Some of these backers have already reached out to us to tell us their stories, and we’re really excited to work with them!

    Through the same backer survey and by email, we’ve been asking people about what projects they’d like to do with Tessel. Here’s what we know:

    (Take this graph with an even bigger grain of salt; sample size is small and categorizations are my own.)

    By far the largest portion of the backers surveyed were interested in home automation projects– ranging from energy conservation applications to automated barbecues. Additionally, you could arguably lump the (surprisingly large) percentage interested in pet-related applications into that category for a whopping 40% of the pie chart.

    This is one place where we see a bit of data skew. The Project Plans chart incorporates data from a backer survey and from emails we have received. The people with the most incentive to reach out to us directly are entrepreneurs with industry-type applications. (My categorization of “industry” rather broadly stands for any application you could make a business out of– though you could arguably add RC into that category for a combined 32.7% of the pie.) Most of the “Smart home” category comes from survey data and most of the “Industry” category comes through emails. Thus, since the Smart home and other categories have little reason to reach out to us, there are likely even more of them than are represented here.

    Oh- and in case you were wondering, that >10% “Joke” wedge is just our backers having a sense of humor… or at least, we assume they aren’t really plotting Skynet or world domination.

    What does this mean for us?

    The main reaction here is that these statistics are interesting, but they don’t mean much– at least not quantitatively. Partly, the data collection is hard to trust. Coming from a scientific background, I would throw out the results here as “not enough information”, since the sample size is so small– on the order of 300 respondents out of our over 1,000 backers, and easily self-selecting.

    We’ve also been warned that our backers on crowdfunding might not be representative of our long-term audience. This makes sense; early adopters understand the value of a project before it is fully realized, and often back on crowdfunding campaigns because they want to be a part of that project’s future. We love our early adopters precisely for this reason, but it also means that not all of our backers had specific plans in mind when they backed us. Thus, it’s hard to gauge what the long-term uses of Tessel will be based solely on backers’ responses.

    On the whole, these results are a good reality check for us; mostly, nothing too surprising has shown up in these graphs, and we’ve enjoyed hearing about specific projects from our supporters. Keep in touch!


    #statistics #Tessel #smart house #smart home #rccar #rcplane #remote control #dragon innovation #backers #crowdfunding #skynet #data #drones #diy #kelsey breseman

  • 8 Tips For Jumpstarting a Hardware Startup

    Friday, October 4, 2013

    10/4/2013— Jon McKay

    I’m Jon McKay, co-founder of Technical Machine. Just over 100 days ago, in June of this year, two of my best friends and I started a hardware company - totally new territory for us. Today our startup has nearly $200k of backing in crowdfunding revenue, and we’re working with investors to make sure we can deliver an awesome product to hundreds of thousands of customers.

    Despite our web development background, we decided that making hardware was the right venture for us because there was no hardware that existed that would have the functionality our software required. Granted, we are making hardware more accessible to our fellow web developers, but it’s a hardware company nonetheless. We’d all worked at startups before and knew how to move fast with software, but making a hardware company just as agile was a completely new experience.

    There are eight ideas that helped us move fast, and if you come from a web background and are looking to build a hardware company like I did, hopefully they’ll help you move faster too:

    1. The Lean Startup Still Applies

    All the rules for lean startups still apply for hardware companies. Make the easiest, quickest prototype and get user feedback on it. Once you can prove you’re heading down the right path, iterate as quickly as you can. We prototyped with an Arduino for the first few weeks to get developers’ feedback on our direction. Only after ensuring we struck a chord did we start using more specialized hardware.

    2. Use Evaluation Boards to Save Money

    A great way to create hardware prototypes iteratively is to order “evaluation boards” for the chips you’re going to use. Most integrated circuit (IC) manufacturers sell pre-made circuit boards for some of their chips that include all of the support circuitry the chip needs to work, along with nice connectors for integrating the board into a more complete system. As you build up your prototype, you can just wire those eval modules together. The major draw here is that you can put off designing your own circuit board as long as possible. When small manufacturing runs and assembling your own boards cost you thousands of dollars, eval modules can really spread out your runway.

    3. Use Reference Designs to Maintain Sanity

    You’ll have a lot less trouble with weird hardware bugs if you stick to reference designs. Every (good) manufacturer will release documentation with their ICs that contains a section with a reference design. The reference design gives you an idea of all the other components (resistors, capacitors, etc.) that you’ll need to support the IC (see example for our WiFi chip below).  Stick as close to that design as possible (especially for high frequency chips) and your technology will work much more reliably.



    4. Use the Web for Validation

    Driving traffic to your hardware’s website is crucial for gaining early mindshare and validating your ideas. When we got started with Tessel, we felt like we couldn’t get an accurate picture of how our users would like the device by reading about it on a website. We felt that they wouldn’t “understand the experience”. As if there was something magical about using the device that words just can’t describe. The fact is, if you can’t get across the value of your product with words, then you’ll never be successful. Almost no one will have the opportunity to try your product before they buy it. Make a website and get it out there as soon as possible (well before you’ve finished actually making it). When our website was picked up on HackerNews (a month before we planned to launch ourselves), we got over 10,000 awesome, excited people on our mailing list that we could notify when our crowdfunding campaign began.

    5. Crowdfunding Is Not For Revenue

    Crowdfunding is completely revolutionizing the hardware world, especially hardware startups. By gauging interest and essentially eliminating the need for up-front inventory, crowdfunding has changed the way entrepreneurs start (and even run) their hardware companies. But for the time being, crowdfunding isn’t so much a means of making money on a finished product, as it is a way of getting the most important pieces of validation: how many people (and who) will click the buy button, how many won’t, and why. You’ll hear it in comments, tweets, articles, and blogs, and you’ll need to analyze the feedback to make your product better. An entire crowd of early adopters become accessible to help you grow your business in the right direction. Crowdfunding makes you data rich, not money rich – use it to grow.

    6. Test Driven Driven Development

    Test Driven Development is not just a software development process; it speeds up hardware development as well. When the start date for our crowdfunding campaign was approaching, we had a two-week turn-around time for each hardware revision. Hardware companies in China can get that turn around time down to days, but for U.S. manufacturing (at least in Boston), two weeks is fairly fast. Since it takes so long to get the boards, the key is to reduce the amount of time manufacturers are not spending making your boards. Here is Technical Machine’s process:

    1. Create a test suite. Before you have even sent out a board revision to be made, you should have a document describing each feature that needs to get tested, each test for each feature, and how to run those tests. When you begin manufacturing thousands of units, you’ll also need to create hardware test rigs.

    2. Know what you want to get out of each test. Taking the time to decide exactly what you want to measure and how you plan to measure it before powering on the device will save you time, tears, and inventory. In hardware it’s exceptionally rare that “it’ll be different next time” you power it unless you change something physical on the board. More importantly, if the product on your desk breaks, you often need to go out and build a new one from scratch, not just hit compile.

    3. Create a F*#!-Ups Document. There is something wrong with every revision. Expect it. Stop crying. It’s just going to happen. Create a document to keep track of every problem with the board, because as soon as you plug it in, you’ll find them. Run through the whole suite of tests, adding every problem to the list.

    4. Revise continuously. While one engineer is testing the revision and noting mistakes, another should be fixing those problems in the design.

    Each board revision consisted of about a week fixing the previous revision and a week waiting for the new boards to come in. During the manufacturing week, we would write all the firmware for new features and the test suites firmware.

    7. Free Samples (Shhh!)

    Most manufacturers will give you free samples of their ICs if you just ask for them. Some manufacturers even offers samples on their website and will overnight ship them for free. Take advantage of it – they will dramatically cut prototyping costs. We’ve probably used hundreds of dollars worth of WiFi module samples alone.


    8. Open Source Hardware Is Growing

    As most software developers know, the ability to use open source code dramatically increases productivity and learning. The same principle holds true for open source hardware. Great open source hardware companies like Sparkfun and Adafruit allowed us to
    adopt their designs for Tessel so that we didn’t have to come up with the billionth RFID antennae on our own. In turn, we give all of our hardware designs back to the community so that we can grow and innovate together.


    Those eight ideas helped us keep our overhead low and get our minimum viable product in front of potential customers as fast as possible. Of course, Tessel is only a circuit board with no industrial designed casing or external components so I can’t speak to the problems you’ll encounter there. As (open source) hardware startups become more and more popular, I hope that we’ll hear from more entrepreneurs who will shed some light on those topics and how we can work to make hardware as agile and iterative as software development has become.


    #Tessel #technical machine #hardware #startup #lean startup #tdd #samples #crowdfunding #internet of things #internet of everything #pervasive computing #jon mckay

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