• Technical Machine is Growing!

    Monday, December 16, 2013

    12/16/2013— Jon McKay

    Today, we’re happy to welcome Kevin to his first day of work at Technical Machine!

    We originally met Kevin when he joined Olin College back in 2010 and were blown away by his talent and knowledge of both hardware and software. Since then he’s only honed his skills and already caught a few bugs in our firmware during his on-boarding process.

    Kevin already has experience starting a company focused on making great developer tools. He co-founded Nonolith Labs which makes an awesome little analog electronics multitool called the CEE.

    He will be working on improving our USB communications, helping Tim make the runtime faster and more robust, and give us the velocity to (hopefully) ship on time.

    I’m really excited to have Kevin on the team and can’t wait to see the magic he works on Tessel.


    #technical machine #hiring #kevin mehall

  • Updates: Accelerometer, Camera, GPS

    Monday, December 16, 2013

    12/16/2013— Updates

    We got in our newest batch of Tessels this week!

    We’re testing them now but it’s likely that this will be the same design used in our production run.

    We also got in 300 Accelerometers from our manufacturer. We’ll be pushing more modules into production soon.



    The GPS module now has working firmware! Here is our first coordinate data:

    (Don’t worry, I fixed the timestamp issue shown here.)


    It’s been a while since we gave an update about the camera module, but here’s a Tessel selfie we took with one of the cameras we’re testing:

    The camera can send data over two different protocols, UART and SPI. SPI is much faster than UART as you can see from the signal readings we did.

    This is sending an image at 38400 baud. It takes… a few seconds. Realistically this can probably go up to 115200 baud and have the transmission time cut down to ~1s.

    This is transmitting over SPI. It takes ~26ms with a 500KHz clock.

    Sooo we’re going to be using SPI.

    Till next time,

    Jia, Kelsey, Eric, Jon, Tim


    #technical machine #tessel #updates #accelerometer #camera #update

  • Zero to Tessel: Teach Yourself Node

    Tuesday, December 10, 2013

    12/10/2013— Kelsey Breseman

    At this point, I consider myself a connoisseur of online learning programs. Coursera, edX, Boundless, Codecademy, Khan Academy– I’ve tried them all. Because I’ve tested out many of these paths, I now feel qualified to offer you a three-step plan to JavaScript and Node.JS fluency– whether or not you plan to use these skills to work with Tessel. There are no prerequisites.

    (image via nodeschool.io)

    1. Codecademy [~3 hours] for JavaScript syntax. If you’ve never coded in JS before (or even never coded at all), head over to Codecademy and spend a few hours in the JavaScript lessons. You need to know about if statements, for loops, how to make a function. If you’re new to JS but not to code, you could probably skip this step and just google things like “JavaScript function”, but it’s nice to get in a bit of practice so you can recognize bad grammar in your code.

    2. Nodeschool: learnyounode [~2 days] is a nice transition. Nodeschool is an all-offline set of courses, where each lesson is a puzzle to complete in your terminal. Learnyounode will take you from a “Hello World” to parsing information from multiple websites asynchronously. If you focused, you could complete Learnyounode in two days. By the end of this, you’ll know how to use Node and npm, and you’ll be more than prepared to start hacking on Tessel.

    3. Olin.JS [~8 weeks] is a class Tim and Jia created and taught last semester at Olin. All the lessons are here on github, so you (like me) can work through them at your own pace. It will take your newfound knowledge of JS and Node and show you what it can really do. It’s designed to take eight weeks, and will introduce you to git, Heroku, Express, JQuery, AJAX and many other useful tools: essentially, it’s zero to hireable for Node. I recommend this course because you’ll make a lot of cool projects, because you’ll become a legit web programmer, and because Jia’s writing is entertaining.

    You don’t need to do step 3 in order to hack on Tessel. Really, you could just use example code to get it working, and by the time we release we’ll have all the necessary information up on a start page. But to unleash its full potential, you’ll probably want the full arsenal of web programming tools at your beck and call.

    Happy coding!

    Kelsey Breseman


    Enjoy this post? Based on this blog post, I’m curating a similarly styled but more detailed pathway for learning to code over at my website ifoundthemeaningoflife.com/learntocode. Check it out! It contains everything from this post, plus a bit more.

    #kelsey breseman #tessel #technical machine #learn to code #programming #node.js #nodeschool #olin.js #olin #hourofcode

  • Power work is never over

    Monday, December 9, 2013

    12/9/2013— Eric Kolker

    We get a lot of questions over email, so today my goal is to answer the question we get asked most frequently: how much power does the Tessel use?

    More specifically, the question usually takes the form of:

    “Hey, guys, just saw Tessel the other day and it looks sweet! I want to use it to build a [ six word description of the project ]! How much power will it use?”

    At which point half of me jumps for joy (cold calls about using Tessel are always appreciated) and half of me rolls up my sleeves. A complete answer touches on power consumption vs. current draw, the role USB can play, and things to be conscious of when designing a Tessellation.

    Power vs. Current

    As it turns out, power consumption is difficult to calculate, and often people actually care more about current draw. In our case, the two are closely related:

    P = IV

    The electric power used by a circuit at steady state is equal to the current flowing through the circuit multipled by the voltage across it.

    Although most devices are in truth limited by power consumption (rather than current output), it’s good practice to never draw more than a power supply’s rated current. On a good day, an overloaded supply will simply sag its voltage (brown itself out) until P=IV, but on a bad day it could become unstable and damage components connected to it. In order to avoid either scenario, most computers will cut power to a USB port if it draws more than 500 mA (2.5 W of power).

    In a world ruled by USB…

    Because the Tessel is most commonly powered off its USB connection, it turns out that current draw is usually the more important number to keep track of. As such, the data points I rattle off quickly are as follows:

    • A bare Tessel, that is, one without any modules attached, draws about 110 mA of quiescent current .
    • We ran a test with a 3.7 V, 350 mAh LiPo battery where the Tessel pinged Tim’s laptop once per second and the device ran for almost exactly two hours.

    The next information I offer is that use of the onboard WiFi radio, flash, and RAM can draw additional currents of 275 mA, 175 mA, and 100 mA, respectively. The astute mathematician will note that 110 + 250 + 175 + 100 > 500, which suggests that the Tessel should constantly be browning itself out and rebooting.

    Although it is probably possible for the Tessel to do that to itself, the reality is that those current draw numbers, like many others, represent the peak draw of the chips in question, as opposed to average continuous draw. This suggests that:

    1. The chips usually draw much less current than that (low quiescent current).
    2. When the chips do draw that much, they do so for a very short period of time (high peak current).
    3. Therefore, it’s very unlikely that the Tessel will do that to itself (we’ve never had it happen to us and triggering such event would likely require that high power WiFi transmission and complete wipes of both the flash and RAM happened exactly simultaneously).
    4. Bypass capacitors on the power rail are really important! They help keep the 3.3 V and 5 V rails at their respective values, instead of sagging miserably during bursts of high current draw.

    When you think about it, all of these make sense: the WiFi radio is only going to use a lot of power when it’s transmitting or working to decode an incoming packet and the memory will need the most power during read/write operations, both of which shouldn’t be happening all of the time (there’s a difference between “every time” and “continuously”). Last but not least, always decouple your rails!

    Plan accordingly

    But I digress… Allow me to explain why I often need to take a minute to collect my thoughts before typing up a reply.

    In order to estimate of power consumption, you need to know what goes into your device and how you plan to use each part. Here are a few key things you’ll want to figure out:

    What modules do you plan to use?

    All of the modules are marked with their peak current draw, but the notion that “they don’t really draw that much” rule doesn’t always apply.

    • Sensor modules (ambient, accelerometer, climate, GPS, camera) tend to use the same amount of current all the time.
    • The nRF and BLE modules (low power wireless communication) use a modest amount of power over a short amount of time to transmit packets and little power for the rest of the time.
    • The GPRS module follows a similar pattern, but draws a truly exorbitant amount of current during transmission and has a higher quiescent current.
    • Because RFID must generate an RF field in order to read tags, it has a relatively high quiescent current. Consumption during transmission is even higher.
    • The relays we chose latch (save their state), so they only draw current when their state is switched, but don’t provide power to whatever they’re hooked up to. On a related note, please be very careful when dealing with wall power. Unplug everything before inserting anything into the relay module and wrap things up with electrical tape when you’re done.
    • Servos connected to the servo module are powered externally, so their power draw is not included in the peak power consumption for the module.

    NOTE: Although most hobby servos can be powered off 5 V, we strongly recommend against powering them off the Tessel’s 5 V rail (more on this 5 V rail later). The inductive kick from the motors could brown out or permanently destroy the Tessel. The module ships with a 5 V power adaptor for the servos. Please use it.

    Does your project have any moving parts?

    This is typically only an issue if you have a relay or servo module onboard, but if it’s an issue it will likely be a serious one. I already mentioned the dangers of inductive kick, and it’s worth noting that a standard hobby servo will stall out (maximum torque = maximum current draw here) at upwards of 1 A. If you know you need a motor of some kind, do some research to figure out what kind of motor makes sense based on what you need to move, how quickly you need it to move, and how accurately you need it to move. A good rule of thumb from the field of robotics is that actuators use an order of magnitude (or three) more power than anything else in the system, so plan accordingly.

    Plan ahead

    Figure out how often everything will be on vs. in standby. See if you can predict how often you’ll need to communicate with the web, and if that will require a long series of back and forths or a simple handshake. Is a live stream of data necessary all the time, or just occasional polling? Can you offload heavy processing or JSON parsing to a back end somewhere?

    Finally, before you go spend hundreds of dollars on parts, I’ll remind you to start small and to iterate. If you’re new to hardware, keep in mind that things break and don’t always work the first time, so leave room in your budget for spares, replacements, upgrades, and jumper wires (somehow, they always seem to wander off).

    Using the 5 V in pins

    Another thing to consider is where the power physically enters the Tessel. The Tessel can be powered either from the micro USB port, or through a pair of 5 V in pins right near it.

    • Either way, the absolute maximum voltage those pins can accept before you destroy your Tessel is 5.5 V (I only mention this because officially the party line is 5 V, but some phone chargers output 5.1 V and I’d like to let you all know that using such an adapter will not trigger the apocalypse).
    • The Tessel will use USB power preferentially over the power supplied to the 5 V in pins . This is likely only relevant if you will need a USB data connection to the device some, but not all of the time, and therefore cannot devote the USB port to power alone.
    • Circuitry onboard the Tessel allows seamless switching between power sources.
    • Last but not least (and sometimes very important), the external power that goes into the 5 V in pins is whatever you put there. That is, if you attach a 3.7 V LiPo, don’t expect to get 5V out (we’re good, but not that good). The only place on the board which exposes the 5 V rail (be it from the USB port or the 5 V in pins) is on the GPIO bank.

    In closing

    The more you know about your design the easier it will be to estimate power consumption. My offhand guess for most Tesselations is that a 1A cell phone wall charger will be enough, and it’s not worth your time to worry about it any further. If you can’t afford to be tied down to a wall socket, grab a battery above 5,000 mAh and you should be able to run all day so long as you don’t have any moving parts, try to stream YouTube, or calculate the millionth digit of pi. If you have anything more complicated than that, or just want someone to bounce an idea off of, drop me a line to ask questions.



    #tessel #technical machine #eric kolker #power #current #power consumption #electrical engineering

  • Ambient and Infrared, Layout Updates

    Tuesday, December 3, 2013

    12/3/2013— Updates


    We sent out a new design for a test run about a week ago.

    The major changes are: UART is now on every port. A lot of commonly used chips use UART for communication. Every port now supports UART, SPI, and I2C communication protocols. We have hardware UART on three module ports and software UART on the fourth module port and the gpio port. We have two different I2C ports. Port banks A, B, and the GPIO bank use one I2C port, while banks C and D use another. Because I2C uses the same two lines to talk to all the ports, this can create a problem if you want to hook up two of the same I2C devices to Tessel. For example, two Accelerometer modules would clash with each other trying to talk at the same time. Now one Accelerometer module can be hooked up to bank A and another can be hooked up to bank C without clashing. USB power and external power now switches smoothly. In our last revision we had an issue where Tessel would brown out during power switches.

    We’ll be getting back the new Tessels late this week/early next week from our manufacturer.



    We’ve split up Ambient into two different modules, one for sound/visible light, and another for infrared (IR) sending/receiving. Everyone who ordered an Ambient module before now will get both the Ambient and the IR modules.

    We felt that combining these into one module stuck too many features together, and most people we talked to either wanted ambient sensing or IR transmissions. Our goal for Tessel is to make hardware abstractions that make sense, and combining low precision data (such as ambient) with data that needed signal processing (such as IR) felt that we were trying to do too many things at once.

    Splitting the modules up frees up space on the ambient module, which we’re using to compute the “loudness” in hardware, as opposed to doing so in software. This means that the ambient sensor will let you quickly determine the ambient noise level or run your own algorithm on the incoming analog signal.


    We’ve made the switch from the BLE112a to the BLE113a module. The BLE113a is not only smaller in size, but it also has a lower power draw, so you have a little more wiggle room with your other modules.


    We sent out the Accelerometer about a month ago to a manufacturer for the production run. They’re done making them and are now testing them. We should get them back in the next week or so. If these turn out well, we’ll begin to do production runs of the other modules we’ve finished.

    As always, you can see our progress here http://tessel.io/status

    –Jon, Kelsey, Tim, Jia, and Eric

    #tessel #technical machine #updates #layout #communications protocols #infrared #ir #ambient #sensor #module #manufacturing #update

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