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

    –Jon

    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

  • Layout Updates

    Friday, October 18, 2013

    10/17/2013— Updates

    Redesigning Tessel

    We’ve been hard at work the past week redesigning Tessel. We just sent in the design files yesterday here’s a render of the new board:



    Besides making the board red (to match our logo), there are several other changes we’ve made:

    • added an optional* place to plug in external power besides the USB cable
    • added an optional* external antenna
    • 4 mount holes instead of 2
    • moved the buttons to a much better location
    • exposed the reset pin so that Tessel can be reset by an external signal
    • added ESD protection to the USB lines so that the board doesn’t fry

    *optional: we’ll leave through hole mounts in case you want to add these things


    Sourcing Issues

    We just got done talking to a supplier for the main chip on Tessel, the LPC1830FET180, and they are estimating a 15 to 20 week lead time. We’ve been told that there is zero inventory in the distribution channel and none at NXP either. This is a new part, and before choosing it we talked with NXP representatives who assured us that it was in full production.

    We made estimates of a 12 week lead time at the latest. The lower volumes that we’ve been using for the test batches of Tessels we have been making have been readily available, so we thought that this estimate was reasonable. The beta batch is not affected by this as we were able to get those chips just fine.

    At the moment, Dragon is still processing the payments from backers, but we’ve taken out a line of credit in order to make the purchase as soon as possible. Assuming a 15 week lead time from this week, we’re looking at getting the LPC1830 around the 2nd or 3rd week of January. This puts the ship date of Tessel around mid-February.

    We’re doing our best to make sure this doesn’t turn into a delay and will continue to keep you updated on any manufacturing issues we run into. Meanwhile, we’ll continue to push on this issue with NXP to get a more accurate date on when we can ship. 

    Modules

    We’ve also changed the module layouts a little. Here’s what the new accelerometers look like:



    We moved all the detailed information to the back of the board. This serves the dual purpose of leaving more room for us to put components on the front, and also gives you an easier way to find information about the module by flipping it over.


    Audio

    Audio playback (with MP3) is working, with an internet streaming demo on its way.


    Camera

    We’re still in the process of selecting a proper camera module. We have a few samples coming in so we can test which is best.


    2G (GPRS)

    We’re designing the 2G module this week and will hopefully have a design ready to prototype by the end of the week.


    BLE

    We are switching from the BLE112 to the BLE113 module. The major differences between the 112 vs 113 is that the 113 is smaller and has better power consumption.

    #Tessel #updates #layout #update

  • JavaScript is a fixed point

    Friday, October 11, 2013

    10/11/2013— Tim Ryan

    Since JavaScript was publicly announced in 1995, there have been an enormous amount of manhours put into retaining its backward compatibility. Barring some false starts (<layer>s and document.all are so fresh) your middle school GeoCities website from 1999 might even still run today.

    Lost in the noise of cross-browser compatibility is how significant this is to JavaScript’s history: since 1996, there have been at least two mainstream implementations of JavaScript. Of the top programming languages, many of those released in the mid-90’s didn’t start seeing multiple implementations until much later, and many stil only have one major distribution. (Python, Ruby, and especially Perl are much different today, with many exciting research and production VMs available)

    This approach to change shapes the community in interesting ways. The transition from Python 2 to 3 to usher radical changes in the language was designed to take five years, a change that took a lot of manpower from the community to make happen (including tons of massive codebases). This type of radical restructuring never worked with JS. Changes made in JavaScript 1.2 (1997) were undone once IE3 was released, so Netscape could retain compatibility. In the 2000’s, the major restructuring that was JavaScript 2.0 collapsed after failing to reach consensus (surprisingly spinning off ActionScript 2.0, Flash’s programming language, in the process).

    Since 2008, ECMAScript Harmony has been the new direction for JavaScript, and it takes the same path the web always has: incremental improvement. We’ll have yield operators and new collections in every engine rather soon, all without breaking legacy code.

    After announcing Tessel (our development board programmable in JavaScript), one of the biggest questions we’ve received is why we didn’t pick Python, a language that’s very popular in the OSHW community already. Our first motivation was more technical than ideological: Node’s package manager made it easy to install modules for a single project, and the majority of Node modules are written in JavaScript itself, rather than in C.

    In “The Future of Programming in Node.js”, Isaac places a strong emphasis on Node’s backward compatibility and how code written today should work years from now. At the same time, the V8 API changed significantly between Node 0.10 and 0.12, requiring changes to the binary API.

    We’re definitely paying attention to the questions of running other languages on Tessel, as well as supporting native modules. But for now (to steal from Jeff Atwood) we think any application that can be written in JavaScript, will continue to work. We’re pretty excited by the choice to use JavaScript at a low level, for devices that run today and those that need to run for the next ten years.

    —Tim Ryan

    #javascript #Tessel #programming #programming language #web development #web developers #oshw #tim ryan #python

  • var eric = require(“electrical”);

    Thursday, October 10, 2013

    10/9/2013— Eric Kolker

    Hey, readers! My name is Eric and I’m an– scratch that– the quasi-dedicated electrical engineer on the team. I joined Technical Machine as a consultant in June, and was thrilled to be offered an official spot.

    First, some electrical engineering creds. Prior to creating next-gen, web-ready microcontrollers, my portfolio included audio visualizers (analog and FPGA-based variants), a switched-mode current source, a class D audio amplifier integrated circuit (design files and bare metal layout shown below), a “self-balancing, two-wheeled, rideable platform” (coughsegwaycoughcough), and an ultra high bandwidth, high speed wireless data link for next generation CT scanners. My name may even be in space soon, on a few PCBs I designed in high school for a picosatellite that’s finally supposed to be launching in a month or two.

    image   image

    I’ve worked with NASA, Boston Dynamics (have you seen the new Wildcat video? Holy clockballs.), and Microsoft, and have helped build things like reactive night lights and high precision tactile feedback sensors over the years as an independent contractor.

    Since joining up, I’ve owned the redesign of the Tessel hardware and have been the primary force behind bringing modules online and pushing them out the door. I’ve also been busy enforcing best practices on the electrical side and working to help make sure the leap we encourage and enable from software to hardware has a gentle and well-documented landing.

    In the coming weeks I’ll be taking another pass at the Tessel board and continuing to make our physical offerings as nice as our digital ones. I’ve also got another post in the works about what it’s been like to join a team of software developers as a guy who, until very recently, didn’t speak JS. Stay tuned!

    ~e

    #Tessel #electrical engineering #hello world #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