• 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 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.


    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!


    #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

  • Designing for Humans

    Wednesday, May 21, 2014

    5/21/2014– Kelsey Breseman

    Travis Huch from Zuora sent me a few questions leading up to my talk at SolidCon, Beyond the Screen: Humans as Input-Output Devices. Zuora published snippets of my responses alongside those of some thought leaders in the Internet of Things space.

    I encourage you to read their piece here: Internet of Things: The Big Picture

    Below are my full responses to their questions.

    How have connected devices already evolved beyond mere devices to completely interactive tools feeding and responding to human inputs and outputs? Specifically how do currently available devices already improve and enhance our lives providing more freedom, comfort, improving safety and health, etc?

    A completely interactive tool, one that seamlessly incorporates humans as a piece of the system, is a tool that people don’t even think about. That’s the end goal: Ubiquitous Computing as Mark Weiser imagined it. Every object is an embedded device, and as the user, you don’t even notice the calm flow of optimization.

    The Nest thermostat is a good example of this sort of calm technology. The device sits on your wall, and you don’t spend much time interacting with it after the initial setup. It learns your habits: when you’re home, when you’re not, what temperatures you want your house to be at various points in the day. So you, as the user, don’t think about it. You just live in a world that’s better attuned to you.

    There aren’t a lot of devices yet that interact seamlessly with humans in this way– as a society, we’re just beginning to explore ubiquity in computing. Smartphones and wearable devices are reaching in that direction, but I think within five years, we’ll find most of these interfaces fairly clunky.

    What groundbreaking human applications of these technologies are still on the horizon? What are some ways these can be used to make our environment more interactive, and responsive?

    I think that one of the most interesting things we’ll see in the near future is the creation of non-screen interfaces. Interacting with technology, we rely almost solely on screens and buttons. But in the physical world, we use so many other interfaces.

    Although it might be a while before consumer tech does much with the olfactory or gustatory sensations, audio and haptic device outputs are already interesting and fairly accessible. Lechal embodies a simple haptics concept: shoes which vibrate left or right navigational directions as you approach a turn. And though audio has also been used for a long time, innovations such as audio spotlighting open up possibilities for personal/non-disruptive audio without the need to put a plastic device (headphones) on your head.

    Those are all inputs into humans, but there’s a lot of fascinating work going on to receive outputs from humans. The consumer-oriented Myo armband uses myoelectrics– the electrical signals from human muscle impulses– to read gestures. Or you could spin your own myoelectric device with this much cheaper muscle sensor. Similarly, you can buy an Emotiv headset to read your brainwaves, or you could DIY it. The implications there are amazing: you can wire up your own body as an electrical input into any electrical system– like a computer, or a robot, or whatever else you might build. You can control physical and digital things just by thinking really hard or by twitching your fingers.

    Current electrodes with long wire leads are a bit impractical for everyday wear, but research labs are working on that in a field called epidermal electronics. This field puts electronics right on people’s skin, for example in the form of a temporary tattoo or more like a band-aid. A circuit adhered to your skin could monitor and wirelessly transmit your heartbeat, temperature, motion, location, or any of various other sensor data, 24/7, while keeping a low profile on your body. Graphene is another move in that direction.

    Epidermal electronics photo from ucsd.edu

    Meanwhile, systems in the consumer space explore accepting input from humans without requiring physical attachment. The simple motion detectors on lights, on automatic faucets, on self-flushing toilets are good examples of simple and intuitive interfaces. These accept natural human motions to perform previously manual tasks. More complex interactions move up to gestural control, such as on the Leap or Kinect controllers, or even facial emotion recognition with Emotient.

    On the whole, I think (hope) we’re about to get a lot better at interfacing machines with people outside of computer screens.

    Kelsey Breseman

    #kelsey breseman #solidcon #internet of things #iot #zuora #connected devices #ubiquitous computing #mark weiser #design #interaction

  • Update: Modules are in, Tessels starting to come off the line

    Thursday, May 15, 2014

    5/15/2014— Updates

    Manufacturing update:

    We have all of our modules back from manufacturing as of yesterday.

    The last Tessels are going through assembly as of this morning, so they’re moving full-force into the process of programming and testing. The testing process actually uses a Tessel and a Raspberry Pi to program the new Tessel boards and live stream their test results to an internal webapp that Jia wrote. You can read more about it on her blog post.

    When they’re done, they go in a bag with some stickers and a cable. This is the first one off the line:

    Our manufacturers made a really cool video of the whole process, which you can see here.

    Software update:

    We’re cleaning everything up to get ready for release! We’ve open sourced the module drivers for Accelerometer, Ambient, GPS, Relay, and Servo. Enjoy, and pull requests welcome!


    While all of this was going on, we also moved to California! Feel free to visit at our new address: 1101 Cowper Street in Berkeley CA. Jon blogged about it.

    Until next time,
    Kelsey, Jon, Eric, Tim, Kevin, and Jia

    #update #updates #tessel #technical machine #manufacturing #progress #modules #open source #module drivers

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