• The Making of a Module: The Dive from Hardware to JS

    Wednesday, November 6, 2013

    11/6/2013— Jon McKay

    The Technical Machine team is hard at work designing, assembling, programming and testing all the components of Tessel and its modules (see our status page for details). Personally, I’ve been spending a lot of time getting the Bluetooth module ready for release.

    In a previous post, we talked about what goes into the hardware design and assembly of a module. But that’s only the beginning. After we put the module together, there’s a long process of testing the hardware works and writing the entire library.

    The first step is to make sure that hardware works like it’s supposed to. The chances of it working 100% right with the first revision is infinitesimally small, so we make it easier on ourselves by breaking out any questionable connections with headers so that we have more flexibility when we start testing. Headers give us the option of easily changing connections (with jumpers or soldering on wires) or verifying the signals on those lines with a logic analyzer. We use and love Salae’s logic analyzer which will decode any signals we send over the wire so we can be sure our communications are working as expected. On our first Bluetooth module, we broke out a block of headers (see picture below) for all the communication signals so that we can easily test the receive, transmit and wakeup lines on the BlueGiga chip.


    The BlueGiga Chip is what’s known as a System on a Chip (SoC), which means it has a microcontroller as well as a Bluetooth chip (the TI CC2540) and all the passive hardware like capacitors and resistors to make it all work reliably. The smaller group of headers at the bottom of the module exists so that we can program the BlueGiga chip with their proprietary toolchain. That’s right, we not only have to program the Tessel to communicate with the Bluetooth module, but we have to program the Bluetooth module itself to be able to respond. But don’t worry, if we need to update the firmware on the BlueGiga chip once we ship out the module, we can update it from the Tessel.

    The next step is to make sure we can communicate with the module. Tessel initially supported only the SPI and I2C communication protocols, but the BlueGiga chip that we’re using communicates over UART. Each communication protocol has its pros and cons but these three are by the far the most common. To be able to interact with the BLE chip, we threw a SPI to UART bridge onto the module. I began making sure communication worked with the bridge over SPI, but soon after, we decided to add UART support to Tessel modules, rendering the bridge useless. Luckily, the fact that we add headers on all the communication channels meant that I could bypass the UART bridge by just adding some wires from Tessel’s UART to the header block, so we didn’t have to pay to manufacture more test module boards.

    Next, I started working with the UART library and writing the bluetooth driver in C. I started working in C as opposed to JavaScript because BlueGiga provides a C library called BGLib that makes it easy to prove out the BlueGiga functionality quickly. I had to write and test the UART library in C anyway. We make heavy use of logic analyzers at this point to make sure the waveforms that are being sent between Tessel and the module look exactly how they should.

    Once the UART library was finished and proved out with the BGLib library, it was time to move on to JavaScript land. In order to do that, we tell our Lua runtime what UART JavaScript functions correspond to which UART C functions. It’s the layer of glue between the two worlds.


    Now we’ll need to update the Tessel Node Package with the new UART function calls that we’ve made. The Tessel command line tools automatically inject the Tessel library as a dependency when we push code, so we don’t have to worry about updating any references.

    This takes us up to about where I am now. I still need to port the BGLib library to JavaScript (or some variation of it) and write some abstractions on top of it to make Bluetooth transmissions as simple as possible. From there, it will just be revising the hardware schematic with any problems I found and squashing any bugs in the UART code. Easier said than done.


    #tessel #technical machine #bluetooth #ble #jon mckay #js on hardware #javascript #hardware hacking #open source #oshw

  • The Making of an Ambient Sensor

    Tuesday, November 5, 2013

    11/5/2013— Jia Huang

    We sent this out to our backers more than a month ago, but somehow it never made it to the blog! For those of you who weren’t backers by 9/27: enjoy!

    We announced the Ambient Sensor module as a Class A module a few weeks back (as always you can get yours here). We put it together this past week and thought you guys might be interested in the process.

    We first draw out the schematic and PCB layout in DipTrace.


    Then, we get a small number (usually 2) PCBs made for the prototype run of a module. The parts are sourced from Digi-Key. 


    Our modules use surface-mount components, which means that they are soldered onto the top of the board, with no wires poking through. Because of this, we use solder paste, place components with tweezers, and then heat the whole board to attach all the components at once.

    We apply solder paste to the pads on the board using a syringe. Then, we use dental picks to scrape off excess paste. (Basically, all of our tools are repurposed medical equipment; if it’s good enough for humans, it’s good enough for our PCBs.)


    Next, we place the components. This squishes down the solder paste and makes the board a little messier. But despite it looking like it’ll fuse into one metal blob, the solder paste always ends up working somehow…


    In order to make the components bond to the board, we heat everything up until the solder flows. This summer, we used a $20 electric skillet and literally fried our boards. Lately we’ve been able to use a reflow oven at Olin College, which has helped tremendously.


    After baking the board, we set it out to cool before putting on the headers by hand. Remember how the solder paste looked really terrible three images up? Since solder paste is made out of unicorn blood tiny balls of solder and a liquid cleaning compound called flux, it pretties itself up magically in the oven.


    All of the module header pins you’ve seen in other photos have been through-hole mounted (the pins go through holes in the board). The headers on this batch of modules are surface mounted instead; we’re experimenting with how different header types feel when attaching and detaching modules.

    And there it is, ready to go! You can read more about the ambient module here: http://tessel.io/modules#module-ambient.

    Now we just have to test it and make sure it actually works.


    #tessel #technical machine #jialiya huang #ambient module #electrical engineering #hardware #jia huang

  • Progress

    Monday, November 4, 2013

    11/4/2013— Updates

    We just got in the redesigned version of the boards, check it out! 

    (More pictures)


    We’ll be making another version before manufacturing with some additional routing changes. We’ll send out an update with all the changes as soon as we’re done testing all the new units.

    We’ve also solved the lead time issue with manufacturing that we mentioned in our last backer update. This means we’re on track to ship in February.

    There’s now a dedicated status page for Tessel and all its modules up on tessel.io/status. Check it out and see what we’re working on! Tweet this.


    GPRS (2G)

    We’re waiting to get the PCBs back from our fab house so we can assemble and test the module. The interesting challenge for GPRS is that the peak current draw is 2A during transmissions (USB 2.0 only gives us 500mA). We hope to get around this with careful power conversion and really big capacitors. 

    In this first round of PCBs we’re hoping to test several things:

    • Actual current draw of the SIM900 GPRS module
    • The logic level translator chip. The SIM900 is a 3.0v device instead of the 3.3v that Tessel outputs. So in order to properly talk to the SIM900 we have to step our signals down.
    • Different antenna options
    • Different power conversion and power input options

    Here’s what the schematic looks like to test all that (click for larger version):



    We’ve had a prototype working for a while now, but it was only able to read RFID cards at a distance of about half an inch (1 cm), which was too small for our liking. Over course of the last few days, we’ve gotten its range up to around 3 inches (8 cm), and are happy to report that the module is basically done at this point. Look for a blog post about the debugging and tuning process next week.


    We’ve nearly decided between using the BlueGiga chipset versus Panasonic; we’re leaning towards the Bluegiga. The BlueGiga module has been verified to be detectable by BLE devices and we’re working on getting reliable communications between Tessel and the module.


    We’re still getting some more samples in, but it looks like we’ll be using the VC0706 as our main signal processing chip. This means the camera will be able to give back compressed JPEGs for snapshot.

    As always, thanks for reading! We’re always available on twitter.com/technicalhumanshttps://www.facebook.com/technicallyamachine, or team@technical.io

    Jia, Kelsey, Tim, Eric, and Jon

    #tessel #technical machine #modules #schematic #testing #jialiya huang #gprs #2g #sim #rfid #camera #bluetooth #update

  • Startup Marketing Tips from an Engineer

    Wednesday, October 30, 2013

    10/30/2013— Kelsey Breseman

    I had never done marketing before working for Technical Machine, but I stepped in to fill the role, mostly because everyone else had their hands full with technical development (and also didn’t want to do it).

    I can’t claim absolute success,  but things have gone better than I expected– and since it’s all new to me, the learning curve is huge. What I hope to present here are a few pieces of advice you might not have seen before. I hope you find them useful.

    Know your product.

    When I first joined Technical Machine, not much had been written down as far as company mission and value proposition. Tim, Jia, and Jon had a united vision that they’d talked about a lot, but it wasn’t enumerated in words. So in order to understand what I was selling, I had to ask a lot of questions.

    What drove Technical Machine? It didn’t make sense to sell the product without the vision, or the vision without the people. So I started by researching and writing one-paragraph biographies of Tim, Jialiya, and Jon. Tim lives and breathes software. Jia cringes to see automatable tasks done by hand. Jon can keep his head above the daily development and see big futures down the road.

    Next, I wrote a sort of statement of purpose. This was complicated; it’s hard to get someone else’s vision on paper, so I made some educated guesses– internet of things, Arduino-type thing for webdevs– and passed it back to the founders for a few rounds of corrections.

    By the time I went through this whole process, I had a much better idea why Technical Machine mattered, and was able to start asking the more trivial questions: What differentiates Tessel from other microcontrollers? I had to know why before I could adequately explain and sell what. And since all of these writing-and-correcting processes occurred between all of us together, minor discrepancies in founders’ vision came to light, and we all finished the exercise with clearer understandings of exactly how we were presenting Technical Machine.

    Be honest and open.

    We’re open source hardware, open source software, and we’re also trying to be an open business: we’re reaching for transparency not just within the company, but also with our broader audience. This is partly because, as a company, we’d like to encourage other web developers to start hardware companies. It’s part of our core mission. Thus if we can use ourselves as an example, we can help other companies like us to learn and grow.

    One surprisingly difficult facet of openness is to be honest within the culture of your company. For example, at Technical Machine, we’re just five 22-year-olds who like free food, jokes steeped in nerd culture, and spending time together. We’re working on Tessel because we really want it and think the world could use a better hardware prototyping experience. Sometimes we get ahead of ourselves and try to sound distinguished and professional, but our best reactions come from just being ourselves and trying to openly connect with our users (albeit politely).

    Connect with the people who impress you.

    Early on, Technical Machine decided on a core user group that we wanted to design for: entrepreneurial web developers. We picked JavaScript, and we admire the Node community. So we designed for them, and that’s who we set out to tell about Tessel.

    Fortunately, people are pretty easy to find online (especially web developers). I found lists of the people I thought would care most about our project, and I started to follow them on Twitter: the most active node.js authors, people who work at Github, etc. Because I hand-selected each of these people, they’re the ones who learned about Technical Machine first. And because we had designed for them, their excitement lent us a good introduction to the internet when they passed the word along.

    Be prepared.

    You never know when you’ll suddenly be exposed to the public eye. With all my Twitter following, we accidentally launched a couple of weeks before we meant to. Although we had planned to launch with more detailed information and clearer design, we had a website up with the basic information and a big, obvious “join our mailing list” field. We panicked a bit to find ourselves at the top of HackerNews, but then we spun up a few more dynos on Heroku to manage the traffic, regularly backed up the flood of email addresses coming in through MongoDB, and by the end of two days, had a mailing list 10,000 strong to reach out to with our crowdfunding launch.

    Put up your MVP of a website, and make sure of all the core functionalities in case people find it. You can perfect your design and finish filling out details later.

    Connect with the people who support you.

    Pay attention to everyone who has backed your crowdfunding campaign, joined your mailing list, followed you on Twitter. Certainly, it’s tedious to read through lists of thousands of people– but it pays off. We read through our lists regularly and reach out to interesting people. This is how we meet investors, get invited to conferences, and arrange tech talks at different companies. Your supporters are invaluable, and some of them are also well-connected.

    Even easier, sometimes people email you. Talk to them! Start a discussion! Whenever we get a chance, we ask people how they want to use Tessel. This helps us make the product our customers want most.

    Responding to every email and tweet is important. There are few faster ways to annoy a supporter than to ignore them; likewise, a clear, speedy, and thoughtful response can make a loyal supporter.

    With that advice, how can I end this post any other way than by asking you to write? Please reach out to me: @selkeymoonbeam, or kelsey at technical.io.

    —Kelsey Breseman

    #technical machine #tessel #marketing #startup #outreach #kelsey breseman

  • "It is Known"

    Tuesday, October 29, 2013

    10/29/2013— Eric Kolker

    Hey readers, Eric here again. Last time I promised some thoughts on how joining a team of webdevs as an EE has been, so here goes.

    The short answer is “ethnographic.” I stepped into the world of the web for the first time when I joined Technical Machine, and doing so has forced me to see things from new perspectives as I immerse myself in a new culture. There’s been a sharing of jargon, best practices, and design metrics which has helped us synergize and ship a web-based platform that bridges hardware and software. …Oh, and we learned some buzzwords, too.

    The long answer is a metaphor surrounding “it is known,” a quote from Game of Thrones. The phrase is typically used by the Dothraki to inform Daenerys Targaryen that, in their eyes, she’s wrong (Dany, like me, is a minority in a foreign land). In general the phrase pops up in conjunction with cultural, procedural, or aesthetic disagreements, and has the effect of shutting Dany down, forcing her to reevaluate or re-express her beliefs.

    Taken in a technical light, the phrase can simply be interpreted to mean “there exists a known best practice here.” However, the tone of the quote also conveys a sense of “no, sorry, you’re wrong, end of story.”

    As a newbie stepping in, there’s a lot that I don’t know about the way the web works (as of June,  the extent of my JS experience was a page that I hacked together from D3 examples and only ran on localhost). I quickly learned about services, scaling, and callbacks, but also about new syntax, the names of key players in the space, and (surprise) a whole slew of best practices. To my team’s credit, my introduction thus far has been surprisingly gentle. Whenever I encounter a teachable moment, Tim and Jia show me the best practice, squash my ignorance, and eliminate the sting of “you’re wrong, end of story.”

    It’s the “you’re wrong, end of story” side of the quote which ultimately guilt-trips me into clarifying why I’m inclined do things a certain way. It empowers me to convey important, often overlooked information in a way that’s easy for my team, and ultimately you, our users, to digest. As the guy who owns the hardware, it’s my job to tell my friends when something’s not right electrically, even if it means an impromptu lecture on why we need to keep that specific type of “big, ugly capacitor.”

    I often find myself defending/explaining what I would consider to be the norms of electrical engineering against/to teammates with varying experience in hardware. Analogies serve reasonably well here:

    • Integrated circuits (anything more complicated than a transistor, and “ICs” for short) should be decoupled with capacitors,often large ones, for optimal performance (would you want an unstable library as a core dependency?)
    • The silkscreen on a board should be informative (some combination of tooltips, helper text, and nicely placed UI elements)
    • Schematics should be on a grid (consistent use of whitespace)
    • Subsystems should to be placed in certain places on the board (don’t write it all in main)

    The list goes on, but you get the idea. (And while I cede that these are ultimately “nice to haves” rather than “must haves,” what kind of reputation would you want to establish and what kind of example would you want to set for your new users and budding community?)

    In essence, Technical Machine is closing the gap between two worlds, and I’m the one who’s designing the physical bridges. To do so effectively, I’ve had to enforce best electrical practices, but simultaneously question the rationale for my own ideals as I learn more about the foundations on the web side. It’s not that one culture is better than the other, but rather that it takes time to grok something new and strike effective compromises.


    #tessel #technical machine #Electrical Engineering #web development #it is known #best practices #eric kolker #company culture

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