• Friday, June 13, 2014

    #kelsey breseman #ubiquitous computing #sensors #oreilly #solidcon #o'reilly #neurosky #myo #emotiv #tessel #hue lights #EMG #embedded devices

  • Intern Introduction: Paige

    Thursday, June 12, 2014

    6/12/2014– Paige Cote

    Hi there!

    I’m Paige, and I hail from the great northern land of Maine. I’m currently working towards a degree in Electrical and Computer engineering at Olin College, with a bunch of bio-engineering classes thrown in for a good measure.

    In my free time, I do engineering education research at Olin, read cookbooks, and go to an excessive number of concerts (three, including a music festival, in the last week and a half!)

    I decided to join Technical Machine because I really wanted the experience of working for an early stage startup where I could have significant impact on the product. So far, following my inclination to work for a start-up has been an extremely positive decision; it would be an understatement to say that I’m never bored.

    This summer, I get to code quite a bit, but I am not exclusively focused on coding. As the summer goes on, I hope to use my newfound Tessel skills to make the experience of using Tessel even better for our users. This means I am doing everything from finding bugs in the codebase to helping define the style guide for all the documentation that an open source project requires. Plus, I get to come up with all sorts of awesome projects for the Tessel, and then get paid to make and document them. Pretty cool, right?

    My work this summer is guided by the goal of understanding all the ways Tessel can fit into and improve the the world of connected devices. I’m having a blast so far, and I can’t wait to see where my experimenting takes me.

    Expect updates on my projects and what else I’ve been up to in the near future! Until then, you can always say hello on twitter @paigereads, or by email at paige at technical.io.

    Paige

    #paige cote #tessel #technical machine #intern #intern program #hiring #olin #student

  • JS on MCUs – Only Getting Better From Here

    Friday, June 6, 2014

    6/6/2014– Jon McKay

    As the boxes start rolling out of our fulfillment house, the “pre-order” button switches to a “buy now” button, and I shave my “no-shave shiptember” “beard”, it’s slowly dawning on me what an accomplishment our team has made.

    We’re certainly not done polishing, but I’m enormously impressed that the our team of six (plus 3 new interns!) was able to combine the useful qualities of a microcontroller, the internet, JavaScript, and Node.js onto a single device -each of which has already made a significant impact on the direction of technology.

    We owe a huge portion of our progress to the entire open source sphere, both hardware and software. We were fortunate enough to use code and hardware designs from the folks at Adafruit, Joyent, and the creators of hundreds of discrete NPM repos. So, thank you and feel free to make use of or contribute to our recently open-sourced code.

    The release of Tessel is only the start. We have a roadmap of features and improvements that we plan to release over the coming weeks when we’re not busy fixing bugs:

    WiFi Reliability & Wireless Code Pushing: At release, Tessel can be programmed over USB. In the next few weeks, we hope to introduce wireless code pushing so that users can push code to Tessel over the internet. We have already built out the backend server and security infrastructure; we just need to improve the reliability of our WiFi connections and finish writing the client code that runs on Tessel.

    Execution Speed: As you might expect, running an interpreted language on a microcontroller is pretty slow compared to a compiled language. The good news is that Tessel’s runtime is just about as slow and bulky as it ever will be. Programming microcontrollers with JavaScript is only going to get faster, lighter, and more reliable. We’ve got some tricks up our sleeves, primarily switching to a LuaJIT architecture, to drastically improve the speed of execution. It’s one of our top priorities as we prove out the viability of higher level languages on microcontrollers.

    Node Compatibility: The most common and applicable Node libraries will all be available on Tessel (Streams, HTTP, EventEmitter, etc.). However, some less applicable libraries are not yet available. We will add support for vm, child_process, readline, repl, tty, debugger, and zlib over time after shipping. We don’t plan to support the cluster (you’ve only one core) and domains library. You can follow our progress on our compatibility page and if you’re interested in helping out develop our open source software, shoot us an email (team@technical.io). We’d love the help.

    As a young company that has yet to hit it’s first birthday, feedback from the community is the most important factor in the direction of our company. If you see something you like, something you want changed, or something you want removed, please, please, please get in touch. We’re available on our Forums, Twitter, Email, or in person:

    1101 Cowper St
    Berkeley, CA 94702
    United States of America

    –Jon

    #jon mckay #update #updates #shipping #milestone #javascript #javascript on hardware #node #node.js #compatibility #speed #microcontroller #javascript on microcontrollers #wifi #wireless code #open source #open company #internet #iot

  • Hardware is *different*

    Thursday, June 5, 2014

    6/5/2014– Eric Kolker

    You hear the phrase “hardware is hard” a lot these days, usually when someone is new to hardware, and often in the context of what it takes to build it. Without forcing words into peoples’ mouths, the speaker is generally trying to convey the sense that building hardware feels more difficult than building other things because there’s so much to keep track of and think about.

    As someone who designs hardware but is joining the world of software, I have some problems with this shorthand dismissal and what it implies. I’m also making a conscious point of saying this just as the first Tessels are hitting your mailboxes and as some of you are getting your first taste of hardware.

    “Hardware is hard”

    No, it isn’t. Really. If anything, software is just incredibly easy. However, because many people who started off in software are now interested in hardware (hopefully you!), it behooves us all to try to understand what they’ve gotten themselves into and how it’s different from what they’re used to.

    Allow me to back up, explain, and then offer some advice before we all leap headfirst into the world of hardware.

    Context

    Where I come from, this is what robots look like

    My background is in electrical engineering. In previous lives, I built and programmed robots small and large – everything from LEGO MindStorms to Boston Dynamics’ LS3, which, at the time, was arguably the most advanced quadruped robot in the world. I’ve designed large portions of a small satellite, an ultra-high bandwidth, medical-grade wireless data link for CT scanners, and my own integrated circuit. I’m used to, and indeed completely comfortable with, creating entire systems which work correctly the first time, due in large part to careful architecting, simulation, and a firm grasp of innards of every would-be black box and pitfall in the system. I’m accustomed to spending enough time planning that the implementation goes off largely without a hitch, which is typically the expectation for electrical engineers.

    All that goes to say that hardware engineers must be considerably more careful about the work they do than web developers because the costs of a second chance are so much higher. Case in point: I have never met an EE who would even entertain the notion of “FISI” because doing so is unforgivably irresponsible and expensive on so many levels.

    Don’t get me wrong, there are certainly programmers who are more risk-averse than I and whose systems cannot afford to fail. My point is just that many web developers have luxuries which allow them to be a little more cavalier than hardware engineers can typically afford to be. In the end, these luxuries allow for the buildup of bad habits for dealing with hardware.

    What’s actually different?

    Hardware and software happen at different speeds and require different skill sets. In a nutshell, hardware requires more caution, attention to detail, patience, and knowledge of a broader range of topics than software because most of the time, the building blocks are, admittedly, harder to assemble. The black boxes in hardware are less ideal than those you encounter in software because they exist physically in the real world (as opposed to merely as instances of ideas), and are therefore more sensitive to their neighbors.

    Unless you’re talking abot inside an IC, 10 picofarads is a miniscule amount of capacitance

    A few choice examples come to mind:

    • Things cost more money and time. Supply chains, fabrication time, shipping, and calibration all have very different definitions and consequences for hardware. Missteps as a result of any of these can destroy companies alltogether.
    • More fundamentally and ironically, because computers start off as electrical systems, each of their operations happen on electrical timescales (the timescales of chemical reactions and light), while electrical systems begin their lives as mechanical systems, which necessarily move much more slowly.
    • In hardware, debugging is not as easy as console.log. Instead, it often requires additional equipment that can cost thousands of dollars and takes time to set up, adjust, and calibrate. Fractions of a millimeter and millionths of a second matter, often tremendously; sometimes electrical systems are so sensitive that measuring the system will change the way that it behaves.
    • On top of all that, a thorough grasp of the system’s physics is often tremendously important, if not essential, to understanding its subtleties (read: pitfalls, failure modes, etc.). This may sound weird, but the simple fact that modern computers are treated as discrete and digital devices with well-defined interfaces is simultaneously one of their most valuable traits and largest liabilities. Because software typically assumes that we can draw hard lines that place things firmly in one of two states, we rarely account for the fact that physical systems are actually analog and asynchronous. These assumptions are therefore implicitly built upon approximations rather than absolutes. …And without getting too meta, the crux of the issue is that problems typically arise due to the approximations we make at the intersections between digital and analog.

    Eye diagrams are neat, but if you need to capture one it’s already too late...

    So what?

    We’ve done our best with Tessel to make sure that you don’t need to do or worry too much about any of the really nasty hardware bits, but you’ll still need to come the last 10%. Understand that the consequences are more real than they are with software if you don’t read the documentation and/or do something careless with the product.

    Think about what you want to build, understand your system’s requirements, and set specifications that are both physically possible and sensible. Do research into what goes into anything you build, and ask lots of questions on the forums. I promise we’ll do our best to answer them.

    Last but not least, come to terms with the cost of developing embedded systems in JS: performance. Fundamentally, you’re working with an interpreted language (JS) that has been transpiled to another (Lua), which is being interpreted by something other than V8, which is running on a 180 MHz processor. Tessel is certainly no iPhone, but we’re confident that it’s more powerful and more versatile than similar products which run JS because it’s node-compatible and doesn’t need a lifeline to the PC. You’ll be fine so long as you don’t try to stream video, run intensive algorithms, load 14 different node modules, or demand that your loops run at 100Hz.

    Call to action

    …So what I ask of you is actually pretty simple. Appreciate that Tessel has been about a year in the making and that in order to use it properly you may need to learn a little bit about what goes on under the hood. Together we can make hardware prototyping easier, but doing so will require that we do more than admire electrical systems when they walk by (guilty parties typically include “LED all the things!” and “OMG quadcopters!”). Read our documentation before you run into trouble, then look up anything that continues to misbehave.

    Once your projects take you to the edge of what our modules can do, I hope you’ll take the plunge and try your hand at building hardware, and in doing so start to see why the people on my side of the table have the habits we do.

    Most importantly, I hope you learn a lot and have a lot of fun, so get out there and start building!

    Thanks!
    ~e

    #eric kolker #electrical engineering #hardware is hard #hardware #software #tessel #expectations

  • Tessel Shipped! And Other News

    Wednesday, June 4, 2014

    6/3/2014— Updates

    Tessel has shipped!

    Our friends at Rush Order (our fulfillment house) just sent me pictures of the first boxes going out to customers:

    There are a lot of packages to send, but our fulfillment house estimates that all pre-orders will be shipped by June 14th.

    We are shipping continuously from now on, so you will be able to order online and have your new order shipped right away.

    What else is going on?

    You should see some updates to our website in the next several days as we improve our installation, tutorials, and documentation. Keep an eye out!

    We have interns! Expect to see blog posts and projects soon from Paige, Evan, and Nathan, who have joined us as engineering interns this summer.

    In addition to continued improvements on Tessel’s firmware and software (expect a blog post soon with more details on R&D), we’re working on a site specifically designed for people to share their Tessel projects. Please take pictures and videos of what you make– and while you’re waiting for our projects site to come alive, feel free to share your ideas and your projects on our forums. We’re eagerly anticipating the first projects from our community, and what you make and share with us will guide where Technical Machine goes next.

    Keep in touch!

    You may already follow us on Twitter, but we also have company Instagram and Vine accounts, which we usually don’t cross-post onto other platforms. Get the inside scoop, from my camera phone to yours. (We also have Pinterest, Facebook, and Google +, if you’re into that.)

    Still cranking on Tessel,
    Kelsey, Jon, Jia, Tim, Kevin, Eric, Paige, Evan, and Natty

    #update #updates #shipped #shipping #crowdfunding #pre-orders #celebration #fulfillment #interns #happy

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