• An Interview with Jay Henderson: Product Prototyping on Tessel

    Monday, February 23, 2015

    2/23/15– Kelsey Breseman

    Jay Henderson spills over with excitement, ideas, and passion. He’s building a code school and a hardware startup both from the ground up right now, trying to improve drought conditions in north Texas, working to bring together his community, and working to teach himself ever more about technology and programming.

    Just home from his day job, Jay sat on the couch to Skype me, all smiles and enthusiasm. His girlfriend’s dog, Dylan, jumped up more than once to try to join the call.

    Kelsey: What are the main things you’re working on right now?

    Jay: The main thing that I’m working on right now is a water barrel app. It was part of the North Texas Apps Challenge. During the summer months, there’s water restrictions in Dallas County. We wanted to create a rain barrel app that tracked how much water you got from your roof, and then how much water you started to dispense on your yard.

    The other thing I’m working on is, I’m trying to start a learning lab that teaches people how to do software, and then eventually, blend that into hardware.

    Kelsey: Can you tell me more about your water barrel app?

    Jay: We met with an environmentalist at the University of North Texas, and he told us about how he made these products for people who wanted them in their home. He said, if there was a way to calculate how much water they’re using, and have an app that displaces the water out as they use it, that would be cool. So we made Barrl.

    I went on Adafruit and bought a liquid flow meter, a soil / moisture temperature sensor, and a brass solenoid valve, which we plan to use with to tell us how much water is going into the barrel.

    We’re trying to work on that as our first product as a startup, as Intelliflux Labs. We’re hoping to bootstrap it. That’s why we love Tessel, because I have a frontend development background, so the JavaScript makes it quite easy for me.

    Kelsey: You said you have a frontend development background?

    Jay: My background is in front-end: HTML, CSS, JavaScript, user interface; user experience is my forte. In the last year, I have really immersed myself in full-stack development. Experimenting with that has been fun.

    The reason why I want to learn as much as I can is so that I can teach other people who are unaware of what’s going on with JavaScript, and see what they can make it do with physical computing.

    Kelsey: Can you tell me more about your learning lab plans?

    Jay: About three years ago, I was going to school and working at the Apple store, but courses became really expensive. I couldn’t go to school anymore, and then I lost my job. But then I started to teach myself during my unemployment. I created a Personal Learning Environment, a PLE, started navigating content, learning things that I was personally interested in for programming, and started to get an understanding.

    I’d started to see different code schools pop up, and I decided to have a trial run of a code school here.

    Eight people paid for it, and then we got ten scholarships from a company. It was really exciting meeting the different personalities. I had a gentleman who was developing in C#, who wanted to learn more about HTML, CSS, and JavaScript. I had a school teacher who knew nothing about programming or anything like that.

    I started the course with an introduction to PLEs; I asked each person, what do you want to build? What is it you’re passionate about every day? Your learning is going to grow based on your personal learning environment. I’m teaching you how to go out and find these tools, but in the end it’s going to be up to you. When you’re faced with a problem, you’ll need to reach out to others in the community to get answers.

    One gentleman was doing graphic design, and he loved the job, but it was so demanding, and he wasn’t getting a lot of compensation for the work he was doing. During the course, I had a speaker series where I had professionals come up. They spent most of their time answering questions and engaging with the students. One speaker came in and talked about the Myo, different human interactions that are coming out, and that really engaged him [the graphic designer]. He started prototyping UI with some of his graphic UI knowledge, and he just landed a job at the Dallas Morning newspaper here just from interacting with the course.

    I helped teach a man who was homeless, in the course. He took it on quite well, and now he’s working in a coworking space, and developing clients with a unique support system.

    The testimonials and success stories are starting to come out, and we only did just a trial course.

    Kelsey: That’s amazing. What are you planning to do differently with your next course?

    Jay: I think I condensed too much into five weeks. We covered a lot of UI and frontend, but I didn’t go into detail with programming logic. I think that the concept of doing something physical for that will be easier to grasp, because you’re dealing with physical components. You can actually see physical objects come to life coding physical elements, such as, if this is true, then have a led blink.

    I’m hoping to do more– from surveying students from the course, participants were more on the marketing side, more graphic artists and designers, and I’m starting to brainstorm about how I can help bridge the visual with the programming.

    Kelsey: Are you planning to use the Tessel for that?

    Jay: One of the things that I want to do with Tessel is to take two or three projects from the projects board and teach that to the class in workshops. Once they get a foundation with JavaScript, introduce them to the things that they can do outside of JavaScript. In which we’ll open up the possibility of creating products.

    [Tessel] is actually making it a whole lot easier for software developers to create real products with only a little bit of knowledge of hardware. That’s one thing that I’m trying to do, is give frontend developers and software developers a chance to interface with hardware.

    After you teach the foundational tools and introduce the projects, you can expand your creativity and your imagination. I’m excited to teach people that you can start making your own products and start making a profit from just an idea.

    #jay henderson #kelsey breseman #interview #tessel #technical machine #code school #barrl #education

  • Hacking Community: Interview with Dave Nugent

    Wednesday, February 11, 2015

    2/11/15– Kelsey Breseman

    I met Dave Nugent over Meetup several months ago. I’d been reaching out to various meetup organizers in the Bay Area, and his name kept cropping up. I’m continuously amazed at how active Dave is in the developer community, hosting events small and large both locally and internationally. He’s the face of the San Francisco JS meetup and of SF Realtime Coders, runs the upcoming ForwardJS conference, and is currently putting together a new conference called the IoT Stream Conference, scheduled for the end of April.

    Kelsey: How did you come to be such an active member in all of these developer meetups?

    Dave: I used to be a Java developer and a PHP developer. That was awful [laughs]. But I’ve really liked JavaScript. I started going to JavaScript meetups, and when the organizer of the JavaScript meetup stepped down, I stepped in.

    I started running meetups a few years ago, and now we’re doing a few every month. We have around 7,700 members. It just keeps growing.

    Kelsey: Can you tell me a bit about your role with PubNub?

    Dave: My title is Evangelist, and I do everything from helping with SDKs and client support to giving talks and organizing hackathons, meetups and conferences. I tend to handle the in-person stuff.

    We organize a ton of meetups that we hold here at the office, over 100 a year. [Ed. note: Dave wrote a blog post about this, which you can read here.]

    We try to focus on things that the developer community is interested in. We’re open to hosting any meetup as long as it’s technical in nature and we can spread the word about it as far as possible. JavaScript, iOS, Android, Ruby, Swift– those are our main meetup languages. We’ll do cryptocurrency and entrepreneur meetups every once in a while as well.

    Kelsey: What’s the purpose of holding all of these events?

    Dave: We usually try to do events where there’s an educational goal, a social goal, or just the goal of building something, where we can facilitate. And you don’t have to use PubNub; if you just want to come in and hack, that’s totally cool.

    We try to provide value to the developer community. And by the way, if you ever need real-time messaging, we’re here.

    That’s why we love Tessel. It’s really great to be able to say, come in and hack with Tessel and PubNub. You can use Tessel, you can use PubNub, you can use both, you can use neither, we just want to help you build something really awesome.

    What tends to happen is that people end up using both, but it’s not like they’re being forced to. They’re doing it because they’re actually getting value out of those tools.

    Kelsey: Why does Tessel make sense for you at these events?

    Dave: One thing that we really like about Tessel is that it’s so easy to just jump in and get started, and then, move from that getting started phase to building a full prototype. Depending on how much time people have, we’ve done hack nights where it’s three hours, and people are able to build a really cool prototype that does some visualization.

    There’s not many products where you can go from not knowing anything about something to a prototype in three hours. Especially in hardware.

    If you have more time, 24 hours, 48 hours, that just becomes more and more refined and polished. We’ve seen some things that come out of our hackathons where you’re like, this is a product. They could put this in a box, they could make a Kickstarter for this and sell it tomorrow. That’s really, really cool.

    Kelsey: Why is it useful for PubNub to bring in a hardware component?

    Dave: A lot of times, especially with software, people might not understand exactly what PubNub is. It’s sort of this ethereal PubSub realtime messaging framework.

    If you show them a demo with Tessel, using PubNub to exchange data with other Tessels, and a real-time dashboard, they say, oh, I got it. You’ve got an internet of things, and Tessel’s the thing, and PubNub provides the internet.

    It’s just really easy to comprehend. So instead of explaining what PubNub is, a lot of times, we’ll just point to the Tessel demo, and say, we power this.

    I point a lot of people to the Tessel projects page. Tessel is very modular, very plug-and-play. You can easily make a recipe where you’re like, Tessel, modules A, B, C, here’s your code that uses PubNub, and just plug it in, and you’ve got the same demo running on your local machine that somebody else built in Europe, or in Singapore or something.

    Kelsey: What do you see as the promise of the Internet of Things?

    Dave: The thing that excites me about the Internet of Things is this whole idea about an Internet of Things stack, where you can build a product by using multiple providers at different levels of the stack.

    When you go out and build websites these days, it’s not like you’re heading out to Best Buy, buying a webserver, plugging it into the internet. No, you say, I’ll spin up a server on Amazon or a Rackspace and use ready-made services on top of it.

    I like the idea of bringing that same stack architecture to the internet of things. Developers can take the components that they want, plug them all together, and build a super robust, high-reliability, low-latency application.

    You can have Tessel, that takes care of your hardware, PubNub, that takes care of your message bus, and on top of that, some big data analytics, visualization providers that store data and allow you to manipulate the data that’s already been communicated across your network.

    You can start to see huge enterprise applications and products being built on the internet of things, but where the company building the product doesn’t have to build the entire stack by themselves.

    Kelsey: That’s the focus for your upcoming IoT Stream Conference, right?

    Dave: That’s the idea: we want to get representatives from each area of the stack to talk about the difficulty of building things in that area that are reliable enough that you can launch products off of them.

    The audience is saying, I want solutions. I want to launch my product in three months. What can you do to help me today?

    [Ed. note: check out Dave’s upcoming conference at http://iot.streamconf.com.]

    #interview #Dave Nugent #Kelsey Breseman #hackathon #PubNub #Tessel #Technical Machine #hacking #meetup #community

  • Business solutions for the physical world: an interview with Jonathan Clark, Sine-Wave Technologies

    Thursday, February 5, 2015

    2/5/2015– Kelsey Breseman

    An expanding universe of connected devices means a huge influx of data– but how do you design to collect useful data, and then turn that data into insights? Jonathan Clark founded Sine-Wave Technologies in 2005 to help companies answer that question.

    From deploying safety sensors in underground mines, to collecting data on commercial fishing vessels, to controlling vast swaths of highway signs, Jonathan has been working with companies to deploy unique, connected solutions across the industrial and enterprise space. An early supporter of Tessel, he kindly made the time to speak with me about the space he works in, and how the company now uses Tessel to prototype these solutions.

    Kelsey: What does Sine-Wave Technologies do?

    Jonathan: We’re focused on building a server-side platform to allow companies to build applications that take advantage of data that comes from the physical world.

    We deploy smart devices to all over the physical world, especially in the enterprise. There’s tons of data out in the physical world, from tracking telematics data on moving vehicles, safety within a building, HVAC or lighting control, solar grids. Up until recently, it’s been very difficult to gather that data and to do anything meaningful with it.

    We’ve created a server platform which allows you to take data from any device, over any network, and let you build applications that use that data to solve business problems.

    Kelsey: Can you go into a little more detail about your stack? How does it work?

    Jonathan: We’re a full cloud backend with analytics. We have a couple of different layers– an open SDK so you can plug in the MQTTs and CoAPs of the world, you can roll your own protocol, you can connect to a wireless mesh network based on 6LoWPAN, or you can connect to your standard Iridium satellite or cellular network and have it communicate to your device.

    Above this layer is a database platform, where we’re storing all of the microtransactions coming from devices. Once we gather data, we normalize it into JSON. That allows us to deliver higher-order layers of functionality that all take advantage of this common data.

    Then on top of that, analytics tools. How do you look at temporal data over time? How can we slice and dice the data? How can we build rules to react to things, to fire off events and triggers?

    For example, let’s say you’ve got 8,000 thermostats deployed at a shopping chain all over the country. If we see that, generally speaking, the lights are left on for half an hour after everyone leaves and that increases the ambient temperature in the building unnecessarily. If the system was smart enough to shut the lights off, it will lower the ambient temperature by about two degrees, and if you do that, you’ll save an annual 6% in your heating costs. That’s the kind of application people want to build off of these datasets.

    The platform does a lot of the trend analysis automatically. We’re a micro-transaction engine with tools that are constantly sifting and looking through your big data sets, and generating the trends.

    Once you have the trends, you can have a human start to build algorithms against those trends and say, if I extract this piece of data from the billions of data points that come in, I can do something useful. I can save some money, or change the way we operate, or save a life.

    Our real goal is to provide a common platform to bridge the gap between the physical and the virtual world. We want people to build real business apps, or connect to their existing applications that they have, like hook up to your ERP, or your SAP deployment, or your Oracle financials, and feed it the data that otherwise has been very expensive for companies to input manually and try to find.

    Kelsey: When clients come to you, how do you help them solve their problems?

    Jonathan: A lot of our clients have physical-world problems, and they come to us and ask, can you help us design an application that’s specific to this business problem?

    We have a professional services team that will help prototype and design that application. A customer may have engineers on staff; if so, we’ll train up their engineers and maybe do some co-coding with them or provide them training materials, or make the first version of the app and then hand it off to them later on and they’ll maintain it and add new features.

    That’s where your team comes in; we’ve been using Tessel for early prototypes. It’s super expensive for us to get a hardware company to take a little sensor and put it on a board, and write some low-level code to control it. It’s so much easier for us to have one of our software folks take something like the Tessel, and for an early prototype, write a little bit of code that speaks to our platform.

    We can prototype in days what would usually take weeks, and show something to the customer. Rather than just the software app, Tessel has allowed us to really show off much more of the full stack at the prototype phase.

    Kelsey: Can you give an example?

    Jonathan: One of the examples that we’re using Tessel for is a customer who focuses on machine shops. There’s around 60,000 of these machine shops that do $15-25 million in business per year, all just in the US.

    One of the problems with those machine shops is that they don’t know who’s working on what, without having a person walk around and physically see it. They don’t know which employees are working on what job, they don’t know which machines are down, and for what reason, or how much throughput those machines are producing.

    This customer is going to market with something that will bring intelligence and get visibility into the people and the machines they are operating. We used your Bluetooth sensor to talk to an Android tablet that’s acting as the digital display at the machine to know how long that person is physically in proximity to that machine. That way, we can tell the ERP system to automatically log their hours for billing, tracking, etc.

    Kelsey: What did you do before you used Tessel?

    Jonathan: It was awful. Customers were typically heavily involved in having to build and design hardware. I’ve seen people spend millions on building out hardware and have to throw it away as it didn’t meet their requirements. I think that’s changing. Companies like Technical Machine are really proving that you can bring a software approach to an old, stodgy industry.

    In the past, it was your classic companies that were building out boards, writing firmware, writing code for PIC microcontrollers, doing battery analysis– that stuff still goes on, but we didn’t have a good prototyping platform before.

    You had to get the idea and requirements to the hardware guys, they would go off and perform some black magic for some extended period of time, and they’d come back with a product that was close to what you wanted, but it was never quite right.

    It was difficult unless you fully and perfectly spec’d out the requirements. And as non-hardware folks, it was tough to spec the requirements, because the hardware people would always come back and tell us every reason why those requirements would never work.

    Using Tessel, when we take it to our hardware partners, the requirements aren’t on paper anymore. They’re in code. We can hand them that code and a sample, and say, we want this, but we now need to make it low power, and vibration compliant, and it’s got to work in a waterproof case, and the radio needs to work underground, or in a noisy electrical environment.

    And the hardware guys are great at doing that. They say, now I’ve got to go off and build an antenna that works next to a diesel motor, how am I going to do it? But it’s not a software problem anymore. It lets everyone focus on their core strengths.

    Kelsey: What do you think is most exciting about getting all of these systems online?

    Jonathan: Every other evolutionary step in computing before us, whether it was the PC, the internet itself, mobile– each one of those had a technology component. But more importantly, it changed the way we solve a given problem. At each evolutionary step, we’ve reduced the latency of the interaction, the time it takes to get data from the interaction itself.

    The internet of things is trying to reduce that one more level. If we can have zero latency with all of the information in the things in the world, we can start solving problems differently.

    For example, rather than doing an audit for your inventory in a warehouse every six months or every year, and finding out things are lost or stolen, if we extend the concept of the internet into your warehouse, we now have real-time access to that information. The concept of an audit goes away because you know when something’s moving or getting lost before it’s even happened.

    Kelsey: What do you think is the biggest barrier to that connected future at the moment?

    Jonathan: I think everybody’s wasting their time on only connectivity, trying to gather way too much data. I think you’re going to see a mountain of connection products, a lot of the internet of things platform products out there, are just a giant siphon of data or data repository or connector.

    In my opinion, connectivity should be a given. Standards are evolving and will continue to evolve; that’s not the holy grail of this space. The holy grail is in the use of the data itself, in finding that digital needle in the haystack and putting it to use.

    Connectivity is a means to an end. Device agnostic, network agnostic, we want great people to invent great hardware.

    We want networks to evolve, we want their cost to be reduced, we want people to invent wonderful sensors, and then we want people to be able to take the data from those and build great applications.

    #Kelsey Breseman #Jonathan Clark #Sine Wave Technologies #Tessel #Applications #Interview #Industry

  • Upcoming Hardware from Technical Machine

    Thursday, February 5, 2015

    2/4/2015– Updates

    As a company, our goal has always been to make it easier for people to develop ideas into products as easily and smoothly as possible. To that end, we’re working on new hardware which should improve that process.

    We’re still working out the finer points of the design, but you can expect a product announcement around the end of February.

    Here are some of the points we’re working on addressing with the new hardware:

    • Node.js / IO.js compatibility
    • JS execution speed
    • Wifi stability
    • Cost
    • Ability to embed the board in a product

    We’d love your feedback on any particular specs you’d like to see in new hardware. Our module ecosystem and APIs will be forward-compatible with new products.

    If you’re currently developing a hardware product, on Tessel or another platform, we’d like to talk to you and make sure our next product fits your needs. Please email us and we’ll set up a call.

    If you’re in the Bay Area, we’d like to invite you to drop by our Berkeley office and try some hands-on user testing. Please email us and let us know if you’re interested!

    Looking forward to hearing from you,
    Kelsey, Kwyn, Ken, Jon, Eric, Jia, Tim, and Kevin

    PS You may have noticed that we’ve updated our projects page! It’s now hosted by our friends at hackster.io. This lets us keep our focus on making a great hardware experience, while they keep rolling out new ways to improve your project sharing experience. All of your old projects have been transferred to the new projects page– please claim them!

    #update #updates #new hardware #wifi #node #javascript #iojs #embedded #hardware

  • A Web Developer's Guide to Communication Protocols (SPI, I2C, UART, GPIO)

    Thursday, January 22, 2015

    1/22/2015– Kevin Sidwar, Kelsey Breseman

    This post is also on our docs page, where it will be kept up to date.

    This guide is meant as a companion to the Tessel DIY Modules and the DIY Module Guide.

    Each of the four ports on a Tessel exposes ten pins for use in creating custom modules. Two of the pins are for power (3.3V and ground) and the other eight are digital pins that can be used to communicate with your module.

    All eight communication pins speak in terms of simple on/off states, but only three of them (the GPIO pins) are meant to be controlled manually. The rest, when grouped in pre-defined ways, are capable of encoding complex messages by having their state rapidly toggled in accordance with various protocols. It’s a lot like Morse code, but for electronics.

    In embedded electronics, there are four common protocols and Tessel supports them all in JavaScript.

    This guide will provide a brief overview of the protocols and cover some of the strengths and weaknesses of each.

    Quick Reference

    Most of the time, you will choose your protocol based on the parts you are using when designing your module. Other things to consider are the pins you have available, as well as your communication speed requirements. The following table can be used as a quick reference for the more detailed explanations of each protocol below.

    Protocol # Pins Required Supported Ports Max Speed Example Modules
    GPIO 1 (G1,G2 or G3) A,B,C,D 1kHz All Modules
    SPI 3+ (MOSI, MISO, SCK + 1 GPIO pin) A,B,C,D 25MBit/s
    I2C 2 (SCL and SDA) A,B (shared bus I2C1) C,D (shared bus I2C0) I2C0 - 1Mbit/s I2C1 - 400kbit/s
    UART 2 (TX and RX) A,B,D - hardware C - software 8Mbit/s

    A Note on Level Shifting

    All of the diagrams and discussions below regarding communication protocols assume that the hardware modules you are communicating with operate at 3.3V, just like the Tessel.

    If you have a device on your custom module that operates at 5V, 1.8V, or any other non-3.3V voltage, be careful! Directly connecting components with different operating voltages can damage the Tessel and/or your device.

    You can use devices which operate at different voltages by employing a technique called ‘level shifting’. Sparkfun has a nice writeup on voltage dividers and level shifting that can be used as a starting point.

    The easiest way to avoid this complication is by trying to find module components that natively work at 3.3V.


    Pros: Simple, Requires a single pin

    Cons: Not good for sending complex data

    By far the simplest form of communication is via General Purpose Input/Output (GPIO). GPIO isn’t really a 'protocol’. It is a rudimentary form of communication where you manually (in code) turn a pin on and off or read its state.

    Each port on the Tessel exposes three GPIO pins that can serve as a digital input or output and are marked as G1, G2, and G3.

    GPIO pins available on a Tessel module port: G1, G2, and G3

    By default, Tessel’s GPIO pins are configured to be inputs.


    When acting as a digital input, a pin can be queried in software and will return a value indicating the current state of the pin: high (1 or true) or low (0 or false).

    The following code snippet is an example of querying the G1 pin on port A.

    var tessel = require('tessel'); // Import tessel
    var portA = tessel.port['A']; // Select Port A
    var myInputPin = portA.pin['G1']; // Assign the G1 pin to a variable
    var pinState = myInputPin.read(); // Query the state of the pin

    This is great for connecting things like switches, buttons, and even motion detectors. Just remember that the Tessel can only handle signals that are 3.3V or lower.

    The [MicroSD Card Module][sd_module] uses a GPIO pin acting as an input to detect whether a card is inserted or not.

    Determining digital state– a note for the curious:

    It’s pretty clear that if an input pin sees 3.3V it would be interpreted as a high state and if the pin is connected to ground it would recognize that as a low state. But what if the pin senses something in between, like 2V?

    Your first thought might be that a high state is anything 1.65V (halfway between 0 and 3.3) or higher, and anything lower than that would be considered the low state. However, this is not always the case.

    The high/low threshold is always determined by the main processor. In the case of the Tessel, that’s the LPC1830. The documentation on the LPC1830 tells us that the Tessel will consider an input to be high if it is at least 70% of the Tessel’s supply voltage (VDD) which is 3.3V. It also tells us that any signal that is 30% of VDD or lower is guaranteed to be read as a low state. That means anything 2.31V (referenced as VIH) or higher would be considered high, and anything .99V (referenced as VIL) or lower is guaranteed to be interpreted as a low state.

    What about the voltages between .99V and 2.31V? The read behavior is undefined and you are not guaranteed to get an accurate result. That’s one reason why it’s important to make sure that any module you connect to a Tessel input pin provides a high voltage that is between VIH and 3.3V and a low voltage between ground and VIL.

    More GPIO example code and information


    When acting as a digital output, a pin can be set to one of two states: high (on/1/true) or low (off/0/false). High means the main Tessel board will set that pin to be 3.3V and low means it will set it to 0V.

    Digital output is useful for connected hardware that understands simple on/off states. The following code snippet shows how you can set the state of the G2 pin on port B.

    var tessel = require('tessel'); // Import tessel
    var portB = tessel.port['B']; // Select Port B
    var myOutputPin = portB.pin['G2']; // Assign the G2 pin to a variable
    // Set the pin state with ones and zeroes
    myOutputPin.output(1); // Set the pin high
    myOutputPin.output(0); // Set the pin low
    // Or use booleans

    Some examples of using a GPIO pin as an output are simple LEDs and for turning appliances on and off with a relay.

    An output pin is perfect for controlling an LED. Image is licensed under the [Creative Commons Attribution-Share Alike 2.0 Generic](http://creativecommons.org/licenses/by-sa/2.0/deed.en) license.

    More GPIO example code and information

    Tessel Modules That Use The GPIO Protocol

    Every Tessel First party module uses the GPIO protocol in some fashion. The MicroSD Card Module uses a digital input to detect state on a module. The Accelerometer Module uses a digital input to detect a data interrupt from the sensor. The Relay Module uses digital outputs to turn things on and off.


    Pros: Fast, supports multiple devices on a single bus, allows two-way communication

    Cons: Requires at least 3 pins

    SPI stands for Serial Peripheral Interface. The SPI protocol allows data to be exchanged one byte at a time between the Tessel and a module via two communication lines. This is great for transferring data like sensor readings or sending commands to a module.

    SPI pins SCK, MISO, and MOSI on Port B of the Tessel

    The SPI protocol is known as a Master/Slave protocol, which means that there is always a single master device which controls the flow of communication with one or more slave devices. Think of the master as a traffic cop. It directs all of the connected slave devices so they know when it’s their turn to communicate.

    When you are creating modules, the Tessel will always act as the master device, and your custom module will be a slave device.

    The SPI protocol requires a minimum of three signal connections and usually has four (this is in addition to the power connections). The following diagram shows the connections (arrows indicate flow of data).

    The red lines constitute the shared bus connections used for talking to the slave devices. The green wire is the shared bus connection used by the slaves to talk to the master. The blue line is the chip select for signaling each slave individually.


    This is the clock signal that keeps the Tessel and the module synchronized while transferring data. The two devices need to have a mutual understanding of how fast data is to be transferred between them. This is sometimes referred to as the baud or bitrate. The clock signal provides that reference signal for the devices to use when exchanging data.

    Without a clock signal to synchronize the devices, the devices would have no way to interpret the signal on the data lines.

    One bit of data is transferred with each clock cycle (see the diagram below).


    MOSI stands for Master Out Slave In and is the connection used by the Tessel to send data to the module. It’s on this line that the Tessel will encode its data.


    MISO stands for Master In Slave Out and is the connection used by the module to send data to the Tessel.

    SS or CS

    This line, normally referred to as the Slave Select (SS) or Chip Select (CS) line, is used by the master device to notify a specific slave device that it is about to send data. We normally call it CS, but you may see it either way in datasheets and other references.

    When you create a Tessel module which uses the SPI protocol, the CS connection will be handled by one of the GPIO pins (G1, G2, G3) on the Tessel port.

    In the SPI protocol, the SCK, MOSI, and MISO connections are shared between all of the slave devices on a given SPI bus. For example, if you connect the MicroSD Card, Camera, and nRF24 modules to the Tessel at the same time, they will all be using the same SCK, MOSI, and MISO lines from the main Tessel chip.

    When the Tessel needs to send data to the Camera Module, the MicroSD and nRF24 will see that data but should just ignore it. To accomplish this, the Tessel will pull the CS line that is connected to the Camera Module low and leave the CS line high for the MicroSD and nRF24 modules. This lets the camera know that it is the active module and should pay attention.

    The following diagram shows how the various pins in the SPI protocol are toggled to create meaningful data. In this case, the master sends the ASCII character ’S’, and the slave responds with 'F’.

    Timing diagram of SPI data exchange. Modified [image](https://dlnmh9ip6v2uc.cloudfront.net/assets/c/7/8/7/d/52ddb2dcce395fed638b4567.png) from Sparkfun is [CC BY-NC-SA 3.0](http://creativecommons.org/licenses/by-nc-sa/3.0/)

    Remember that the master initiates all communication. When it is ready, the first thing it will do is pull the CS/SS pin low to let the slave device know that a data transmission is about to begin. The master holds this pin low for the duration of the data exchange as seen in the diagram above.

    With the CS/SS pin low, the master will start to toggle the clock pin (SCK) while simultaneously controlling the MOSI to represent the bits of information it wishes to send to the slave. The numbers in green on the diagram above delineate each bit in the byte being transferred.

    It sounds complicated, but remember that the Tessel takes care of all of this pin manipulation for you. All you have to do is write some Javascript like this code snippet, which demonstrates the use of the SPI protocol on port A.

    var portA = tessel.port['A'];
    var spi = new portA.SPI({
      clockSpeed: 4000000 // 4MHz
    spi.transfer(new Buffer([0xde, 0xad, 0xbe, 0xef]), function (err, rx) {
      console.log('buffer returned by SPI slave:', rx);

    More SPI example code and information

    Tessel Modules That Use The SPI Protocol

    Ambient, Audio, Camera, Micro SD, nRF24, and Infrared


    Pros: Only requires 2 pins, multiple devices on a single bus, allows two-way communication

    Cons: Devices can have address conflicts, not as fast as SPI

    I2C stands for Inter-Integrated Circuit and is pronounced “I squared C”, “I two C” or “I-I-C”. I2C is a protocol that allows one device to exchange data with one or more connected devices through the use of a single data line and clock signal.

    I2C pins SCL and SDA on Port B of the Tessel

    I2C is a Master/Slave protocol, which means that there is always a single master device which controls the flow of communication with one or more slave devices.

    I2C only requires two communication connections:


    This is the clock signal that keeps the Tessel and the module synchronized while transferring data. The two devices need to have a mutual understanding of how fast data is to be transferred between them. This is sometimes referred to as the baud or bitrate. The clock signal provides that reference signal for the devices to use when exchanging data. Without a clock signal to synchronize the devices, they would have no way to interpret the signal on the data lines.


    This is the data line used for exchanging data between the master and slaves. Instead of having separate communication lines for the master and slave devices, they both share a single data connection. The master coordinates the usage of that connection so that only one device is “talking” at a time.

    Since multiple slave devices can use the same SDA line, the master needs a way to distinguish between them and talk to a single device at a time. The I2C protocol uses the concept of device addressing to coordinate traffic on the data line.

    Every single I2C device connected to the Tessel will have an internal address that cannot be the same as any other module connected to the Tessel. This address is usually determined by the device manufacturer and listed in the datasheet. Sometimes you can configure the address through device-specific tweaks defined by the manufacturer. The Tessel, as the master device, needs to know the address of each slave and will use it to notify a device when it wants to communicate with it before transferring data.

    Flow of data between Tessel and multiple I2C devices.

    The following diagram illustrates how the SDA and SCL pins are toggled when transferring data with the I2C protocol.

    To begin a data transaction, the master creates what is called a start condition by pulling the SDA pin low before the SCL pin.

    The master then broadcasts the address of the device it wishes to communicate with by sending each bit of the 7 bit address. Notice the clock signal (SCL) is toggled for each bit. This toggling is how the slaves know when to read each bit of the address so they can determine with which device the master wants to communicate.

    Right after the address, the master sends a read/write bit which signals whether it will be sending data to the slave or reading data from the slave.

    After broadcasting the address, the master either transmits data to the slave or sends the address of a register (internal storage) on the slave from which it wishes to retrieve data.

    Finally, the master will issue a stop condition on the bus by pulling SCL high, followed by SDA.

    It’s a little complicated, but the Tessel takes care of all the details for you. Using the I2C pins on port A looks like this:

    var tessel = require('tessel'); // import tessel
    var portA = tessel.port['A']; // use Port A
    var slaveAddress = 0xDE; // This is the address of the attached module/sensor
    var i2c = new portA.I2C(slaveAddress)
    i2c.send(new Buffer([0xde, 0xad, 0xbe, 0xef]), function (err) {
      console.log("I'm done sending the data");
      // Can also use err for error handling

    More I2C example code and information

    Tessel Modules That Use The I2C Protocol

    Accelerometer, Climate, RFID, and Servo


    Pros: Widely supported, allows two-way communication

    Cons: Can’t share communication lines, slower than SPI and I2C

    UART stands for Universal Asynchronous Receiver/Transmitter and is really just a fancy way of referring to a serial port. It is really easy to understand as it only requires two lines: a transmission line (TX) and a receiving line (RX). The Tessel sends data to connected modules on the TX line and gets data back on the RX line.

    UART pins TX and RX on Port B of the Tessel


    Used by the Tessel to send data to the module.


    Used by the module to send data to the Tessel.

    When using a UART, it’s important to remember that the communication lines cannot be shared between modules. In fact, because of this, each Tessel port needs its own RX and TX line from the main Tessel chip (LPC1830) as seen below.

    Only ports A, B, and D have dedicated UART lines from the LPC1830.

    Since the LPC1830 doesn’t have 4 UARTs, only Ports A, B, and D have a hardware UART. A software UART can be implemented on Port C but is beyond the scope of this guide. If you need to use a UART for communication we recommend using Port A, B or D.

    A UART data transmission.

    UART transmissions begin with a start bit where the appropriate line (TX or RX) is pulled low by the sending party. Then 5 to 8 data bits are sent. The diagram above shows a scenario where 8 bits are sent.

    Following the data, an optional parity bit is sent, followed by 1 or 2 stop bits, where the sending module pulls the pin high.

    For this protocol to work, the sender and receiver have to agree on a few things.

    1. How many data bits are sent with each packet (5 to 8)?
    2. How fast should the data be sent? This is know as the baud rate.
    3. Is there a parity bit after the data, and is it high or low?
    4. How many stop bits will be sent at the end of each transmission?

    When you want to interact with a specific module via UART, the answers to these questions are found in the module’s datasheet. Using that information you can configure the UART in Javascript like this:

    var port = tessel.port['A'];
    var uart = new port.UART({
      dataBits: 8,
      baudrate: 115200,
      parity: "none",
      stopBits: 1
    uart.write('Hello UART');

    More example code using a UART

    Tessel Modules That Use a UART

    BLE, Camera, GPS, and GPRS

    This post is also on our docs page, where it will be kept up to date.

    #modules #tessel #kevin sidwar #technical machine #diy #diy module #new module #prototyping

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