• Delivery Schedule

    Friday, January 10, 2014

    1/10/2014— Updates

    A few weeks ago we gave an update that we had put 9 out of our 14 modules in production. Tessel is already in production at the moment, and is due to be done in February.

    We’ll be sending in the rest of the 5 modules into production at the end of this week/beginning of the next.

    Module manufacturing is delayed for a little over a week due to the upcoming Chinese New Year at the end of January (our modules are manufactured in China). This puts the delivery date from our manufacturer around mid-February for the 9 modules that we have already sent in.

    Depending on when we’re able to send in the rest of the 5 modules (audio, BLE, ambient, IR, and GPRS), the delivery date for our Dragon backers will be late February to early March. For pre-orders taken over our website (rather than crowdfunding), unless something unanticipated arises, we plan on shipping shortly thereafter.

    Once the modules are made, they will be shipped to our fulfillment partner Rush Order. Rush Order will begin shipping immediately as soon as they receive Tessels and modules.

    This is about two weeks later than we had originally anticipated shipping to Dragon backers: changed from mid-February to late February/early March. We underestimated how much of a delay Chinese New Year would have in our schedule, but we hope that this will be the last delay we run into.

    Oh, and here’s a picture of 1,500 unpopulated Tessel PCBs, sent to us this morning by our Tessel manufacturer Worthington Assembly:

    Cheers, and please reach out (team@technical.io) if you have any questions.

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

    #tessel #technical machine #delivery #schedule #manufacturing #shipping schedule #backer update #update

  • Ideas for Next-Generation Tessels

    Wednesday, January 8, 2014

    1/8/2014— Jon McKay

    Every once in a while, after a long day of work, the Technical Machine team will sit down, grab a couple of beers (except Jia… or else she’ll fall asleep), and bounce ideas off of each other about aspirations for our future products.

    Most of our ideas are flat out ridiculous and will never come to fruition (I’m looking at you edible Tessel) but there are a handful of major underlying trends in the embedded space that we think could be important as a guiding principle for one of the next versions of our products.


    source: http://ghostradio.wordpress.com/tag/robotics/

    You’ve probably already heard all the news about Google scooping up Robotics companies left and right. And with good reason, too. Robots are expected to start generating huge amounts of valuable data within the next few years. But on top of that, they’re a ton of fun to build and play around with.

    In order to make a version of Tessel that’s ideal for robotics, would need to make some major changes including allowing for a beefier power supply up to 48V, more digital input and output pins, and a coprocessor with a realtime clock.

    Wearables & Biofeedback

    source: www.medgadget.com

    Wearables, are the obvious next step in making computers more mobile and closer to our senses. Some great examples of these kinds of projects are the MYO armband for controlling devices around you with your forearm muscles or Sensoria socks that improve your running style. Wearables can be more personalizable than other kinds of devices because they are so intimate with how your body works and what you physically spend your time doing. A wearable Tessel will need to be smaller, lower power (probably using BLE instead of WiFi) and maybe even flexible like a Limberboard.

    Biofeedback driven products are even closer to the senses and often overlap with wearables. My favorite example of this is this is the Emotiv headsets for gathering EEG data and controlling devices with your mind. There are a ton of other biofeedback sensors that could be used to gather data about the body. You can bet that once we finish making Tessel, I’ll be working on a node Emotiv library.


    source: reviews.cnet.com

    If we’ve learned anything from the massive increase in photo and video production and consumption on mobile platforms, we know that there will be a huge demand for A/V technology on embedded devices. The camera module that we’re working on can only run between 10 and 15 frames per second so we’ll need much higher end camera hardware to get anything close to GoPro or Parrot Drone quality. To have a great user experience at higher resolutions we would need to make a pretty different version of Tessel with higher-bandwidth wireless transmissions, more on-board memory, and video codecs .

    We still have a lot of work to do on Tessel V1 but the time to start planning or even prototyping our next products start now. Are there any hardware directions you think we should go? Let us know! team@technical.io


    #jon mckay #tessel #technical machine #future #plans #upnext #startup

  • Designing the First Run Experience

    Friday, January 3, 2014

    1/3/2014— Kelsey Breseman

    I’m designing the first run experience for Tessel, and I want it to be excellent.

    It needs to do well with:

    Highly varied audience: Most of the people purchasing Tessel are used to writing code– but not all of them. This presents an immediate challenge: I don’t want to bore our main audience by including too many basics (“what’s the command line? How do I use it?”). People will skim, skip, roll their eyes, and probably miss important information.

    At the same time, I don’t want to alienate our beginning users; I’m all too familiar with technical sites that assume you have a lot more knowledge than you actually do, resulting in anger and frustration.

    Variation in product: Every user will have a Tessel and at least one module. That’s on purpose: we didn’t want people to get their Tessel, push the blinky example, then wonder what to do next. Instead, we want people to immediately plug in the modules they chose and try out their functionality. You’ll plug in your accelerometer module, wave it around, and see values changing on the screen. And then you’ll think, “What if I taped it to a ping-pong paddle?” “Can I use it to make my servo module move?” “How hard would it be to implement gesture control?”

    That’s all very good, but people have different modules or sets of modules, and it would be best if the instructions on the screen matched what you had in your hands. What’s more, the first run in my head ends with you on a page full of projects which use the modules you have.

    Other considerations: The first-run experience, first and foremost, needs to get a user from unboxing to up-and-running as seamlessly as possible– providing all necessary setup and orientation instructions. Users should also be introduced, via the first run experience, to the site’s project and community features, if these can be integrated into the setup.

    Here are some ideas on the subject:

    • Eric style, I could add in links every few sentences to (e.g.) a tutorial page for working with the command line.
    • Choose your own adventure: users select what modules they have, leading them on a customized first-run featuring their new abilities. This could also be extended to a customized-by-experience.
    • Adventure pre-chosen: since we have information on everyone’s orders, we could in theory give you a login or special key which would serve a first run tutorial based on your modules. This has the added benefit of logging you in to our site, which might make it easier to join the community.
    • Have login involving GitHub accounts. This would be useful generally, as we’d like to have GitHub integration with Tessel projects we’ll display on the site generally (more on that in another post perhaps; I’m also working on Tessel’s community aspects, including a way for the community to share their Tessel projects on the site). The other benefit of GitHub login could be to separate out experienced web programmers from people who might need a more detailed introduction to using node modules on Tessel– slyly serving up a customized first run.

    What would you like to see? Do you have any examples of particularly stellar first run experiences?

    Kelsey Breseman



    #technical machine #tessel #kelsey breseman #community #github #first run experience #user experience

  • Testing Hardware

    Wednesday, January 1, 2014

    1/1/2014— Jia Huang

    In a few months we’ll be shipping over 1k Tessels and 4k modules. We want to make sure that every product we ship will work, so we shipped some test benches to our module manufacturer in China.

    These are the test benches for the RFID, Servo, Climate, nRF24, MicroSD, Camera, Relay, and GPS modules. Try and guess which are the ones we did closer to the deadline…

    The majority of the test benches are just Tessels. The Tessels can switch between multiple module tests so that our manufacturer can keep testing modules even if a few test benches break. For some modules we ended up using Arduinos since the C to JS firmware ports aren’t done yet.

    In all of the tests I tried to aim for the following:

    • Tests should cover core functionality
    • Tests should have clear instructions
    • Test benches should have minimal configuration

    Testing core functionality

    Each module test goes through a core use case (or multiple use cases), and tries to approximate how an end user would use the module.

    For example, our RFID module testbench has a 3 inch standoff with an RFID card taped to the top.

    If the module cannot detect from this distance, than the module has failed.

    Similarly, the nRF24 module goes through sending and receiving messages to another nRF24 module. The camera takes a picture and the test is to check whether or not the image is good.

    Clear instructions

    I tried to make the test benches as consistent and self explanatory as possible. All tests pass with either Green or Blue LEDs and fail on Red. Ideally, we would like these tests to be able to be run years from now if needed.

    I originally wrote the instructions in English, but then I realized that the tests are going to be run halfway across the world by workers whose primary language is Chinese. Most Chinese manufacturers have an English speaking rep or project manager, but the level of English proficiency varies pretty drastically. So I ended up translating the instructions to Chinese as well and having both on there.

    Minimal Configuration

    For some of our modules, it’s annoying to set up the test: the servo module can connect up to 16 different servos, and each servo takes 3 pins (ground, power, and signal). Testing all this by plugging in a servo into each position would take a long time. Relay testing takes a similarly long time since the tester needs to connect wires to the module.

    For these kinds of tests we made module testing PCBs designed to test all the pins at once. So instead of plugging in 16 different servos, the test can use just 1 Servo test PCB. This also has the added benefit of being able to see a clear pass/fail (is the LED on?) versus having to keep track of 16 servos.

    Coming in January

    We still have 5 more modules to get into manufacturing in early January: Ambient, IR, Bluetooth, GPRS, and Audio.

    Back to work.


    #jia huang #test benches #testing #hardware #quality #tessel #technical machine #modules #hardware hacking

  • Hell Week

    Monday, December 23, 2013

    12/23/2013— Eric Kolker

    I haven’t had the bandwidth lately to sit down and write another one of my long, deep technical dives. Instead, I’ll debrief a little on what I’ve been juggling lately (read: this past week). Here goes a braindump in reverse chronological order.

    Friday- Saturday: Move out

    For the holidays, Jon and Kelsey had gone to California on Tuesday, and Kevin had shipped out to Colorado. That left Tim, Jia, and me the task of packing up and moving everything out of Tim and Jia’s dorm. Let’s just say that the only sleep I got in the surrounding 48 hours was in the card ride home from Boston. Tim gets most of the credit here because he’s the lucky guy who got to transport all of our gear:

    Tuesday - Friday: Test benches

    Everything we make needs to get tested before it ships, including each and every module. To do this, we build dedicated hardware, which typically takes the form of either a Tessel or an Arduino with a custom PCB or protoboard. We write some firmware that verifies that the device under test (DUT) is working properly (I’ll save the juicy details for another blog post), and the test benches usually look something like this:

    Since we’re ready to ramp production on around nine of our modules, this meant that we had to design, build, and test the same number of test benches before shipping them off to one of our manufacturers. Specifically, I needed to verify that our camera and RFID designs were sound before we could ship them (spoiler: they are). This meant building a few boards and running them through the paces.

    Wednesday - Thursday: Beta round 2

    We pushed out the second round of boards to Beta backers on Thursday. This culminated in the $500 USPS charge that Kelsey showed you last week:

    Before we could send out the hardware, though, we had to build and program it.

    • The new Tessels (model TM-00-02) needed to be one-time programmed (OTP’d) with the proper serial numbers, bootloader, etc., then tested to be sure blinky.js runs smoothly
    • We needed to build around 80 modules for Tessel’s Beta backers (first and second round alike). Specifically, we built…
      • A fresh set of Micro SD modules
      • A full batch of GPS and Ambient modules
      • A trio of IR modules (for us to test/develop firmware on, not to ship, but we were already in the lab…)
      • At least 25 BLE modules (these in particular are very difficult to assemble by hand and until very recently our yield rate was unacceptably low. We ended up tweaking the layout, praying, and I spent hours carefully building the modules one by one. All told, I think Jia and I spent at least six hours in the lab on Wednesday.
    • Everything had to have firmware flashed, be tested, then ESD bagged, and packed for shipping.
    • Last but not least, on Thursday, Jia and I spent three hours in not one, and not two, but three different Post Offices to try to ship seven internationally-bound Beta packs (one Post Office couldn’t ship internationally, one legitimately closed while Jia was filling out forms, and the third finally worked out). We ended up holding up one of the lines filling out paperwork for the better part of an hour. Fulfillment is a chore I’m grateful to be rid of (thanks, Kelsey!).

    Monday - Tuesday: Probably the Camera

    I think I was working on the camera at this point. We decided around a week ago how we wanted to go about converting the camera we’ll be using into a Tessel-compatible module. The full story will make a good blog post, but the summary is:

    • Pick an existing camera
    • Establish that we can communicate with it
    • Ask the manufacturer to do one part swap so we can mount it to our own board
    • Mount it to said board, which includes the standard Tessel module header and some support circuitry

    Once we had a homebrew prototype, we needed to test the new board, verify we could still bring it online, and generally vet the communication protocol we’ll be using to interface with the device.

    Sometime before Monday: GPRS, but I don’t even remember anymore

    It turns out that you sometimes lose track of time when you work weekends, don’t sleep much, and have a bunch of looming deadlines. (Kelsey says I’m “depressing,” but I really do like my job and if you’d like to work with us, check out our jobs page.)

    I was likely working on the GPRS module at this point. I had an Arduino shield from Seeed Studio that we had rebuilt so it would play nicely with the Tessel, but I hadn’t brought the board online yet. Luckily, this proved to be a painless process (well, after I fixed the antenna path and attached the antenna).

    A minute or so later, I was able to send a “Hello, world! I miss Jialiyaball…” text to Tim using Jia’s SIM card (note: when a thing you built with your own hands sends an SMS it’s really freakin’ cool). The first half of the message should be self-explanatory. The back half is a game we play where we shout “Jialiyaball!” and throw a plush Jake doll at Jialiya. By “we” I mostly mean “Tim.”



    #tessel #technical machine #eric kolker #update #updates #company culture #jialiyaball #camera #test benches #tests #moving

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