• 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

  • PRISM Could Change the Internet of Things For The Better

    Tuesday, October 22, 2013

    10/22/2013— Jon McKay

    At this point, I would hope that everyone has become aware of the inexcusable violation of human rights committed by the NSA and the US government so I won’t go into details here. However, as they say, there is a silver lining to every cloud, and I think the silver lining to this dark cumulus is an order of magnitude more attention being given to new encryption techniques.

    I attended RealtimeConf in Portland this weekend and was impressed by the browser-side cryptography methods being presented by Martin Bosslet and Kyle Drake to keep servers from storing private information in plain-text. One attendee was planning on offloading his encryption to his Tessel by gathering ambient sound/temperature/accelerometer sensor data which would generate more random input. Such entropy-based cryptology enables stronger protection against decoding algorithms that seek out deterministic patterns.  

    As more and more devices get connected to the internet, the potential for invasion of privacy from dragnet programs like PRISM or companies like insurance firms[1] become increasingly more serious and complex. Digital trespassers won’t just have the chance to know what websites you visit and emails you send, they can know what you say, what doors you open, when you drive you car, or how much you weigh. It’s like being followed around by a  ghost– a ghost with the power to arrest you until you prove your innocence.

    Obviously, we’ll need many more sophisticated security techniques and trust mechanisms than what currently exists to make the internet of things truly secure, but our attention is finally being drawn to how important it is to protect the amazing treasure the web (and our data) has become. Making the Internet of Things secure is becoming less about protecting our users from leaks and more about protecting users from the platforms themselves. At Technical Machine, we’re committed to building an Internet of Things platform that developers can implement a secure system on top of as easily and robustly as possible.

    I’m thankful that PRISM happened now instead of ten years from now and I’m optimistic that we, as a community, will get the chance to make our future more secure.


    P.S. If you’ve got ideas of how to build secure platforms on open source microcontrollers,  we’d love to hear from you: team@technical.io.


    [1] http://www.mckinsey.com/insights/high_tech_telecoms_internet/the_internet_of_things

    #Tessel #prism #snowden #cryptography #iot #internet of things #jon mckay #realtimeconf #microcontrollers #nsa #martin bosslet #kyle drake #encryption #security

  • Introducing Kelsey

    Friday, October 18, 2013

    10/18/2013— Kelsey Breseman

    Dear readers,

    Following up on Eric’s introductory blog post of last week, it’s time for me to introduce myself as well.

    I’m Kelsey Breseman, and among other roles on the team, I write most of the content for our blog, website, and emails. I wrote our first company blog post this summer, introducing Jon, Jia, and Tim under the alias of “the Ghost in the Machine”. Since then, my role has expanded to cover all of marketing, and is also leaning over into human resources and community engagement.

    Like the four other members of the team, I’m a 2013 graduate of Olin College. My degree is in Neural Engineering, which at an undergraduate level means I have taken a few neuroscience classes and done some electrical engineering and programming, but I probably won’t be designing Skynet or installing mind control devices in humans for at least a couple more years.

    In the meanwhile, I’m useful to Technical Machine because I have a few characteristics unusual for an engineer: I ran a newspaper, have some experience in HR, and previously worked as a community manager for an online community of makers.

    You can see a great number of my projects here– mostly non-technical– but I think you’ll find these most interesting:

    Lately, I’ve been going to conferences, talking to investors, maintaining Accounting, keeping up our blog/Twitter/Facebook presence, and taking crash courses in Finance and Node.js (courtesy of Tim & Jia). Soon, I should be working out our hiring practices, researching potential integrations, and generally thinking about the future of the company. That is, when I’m not badgering my teammates to contribute their own thoughts to the blog.

    Stay in touch! I’m @selkeymoonbeam on Twitter, or kelsey at technical.io.

    Kelsey Breseman


    #tessel #Kelsey Breseman #technical machine #company culture

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