• 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

  • Creating Your Own Tessel Module

    Wednesday, January 21, 2015

    1/21/2015– Kevin Sidwar, Kelsey Breseman

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

    What Is a Module?

    Modules should be devices with clear-cut functionality. That is to say, they should have a single, well-defined purpose or a set of closely related functions, rather than an eclectic mix of capabilities onboard. This requirement is designed to reduce complexity, cost, and power consumption and maximize reusability in hardware and software.

    –Tessel hardware docs

    One of the main goals of the Tessel platform is “connected hardware as easy as npm install.” If you need an accelerometer, Bluetooth Low Energy connection, SIM card capability, or any of the other 14 first-party modules available, you can literally plug, npm install, and play.

    There is also a growing library of community-contributed third-party modules: npm libraries paired with some simple wiring instructions, built for specific pieces of hardware.

    But what if your project needs functionality that can’t be provided by one of the existing first- or third-party modules? You make your own, of course.

    This guide will walk you through the basics of creating your own Tessel module using our new DIY Modules.

    A Quick Note of Encouragement

    Making your own module might seem like an overwhelming task best left to those who know things like Ohm’s Law, how to solder, and why licking a 9V doesn’t feel very good. But while having some electronics knowledge doesn’t hurt, it’s not a hard and fast prerequisite. If you know how to program, you are smart enough to figure out the basic concepts and make awesome things happen. Just trust us and read on.

    Module Design Basics

    Before you venture into the world of custom module creation, we need to cover some basics that will help guide you along the way.

    Every module created for the Tessel involves 5 parts:

    1. Power
    2. Communication
    3. Software
    4. Documentation
    5. Sharing

    If you understand how each of these fit into the module creation process, you will be well on your way to creating your own custom module. Let’s start with power.


    When dealing with anything in electronics, whether it be sensors, displays, buttons, or servos, you have to provide power. Everything needs a power source, and Tessel modules are no exception. In its simplest form, you can think of a power source as two connections; a positive voltage and a ground connection. These connections are provided on each Tessel port as seen in the image below.

    Power connections on Tessel’s Port B

    The main Tessel board can be powered several ways, but regardless of how you provide power to the main board it ultimately turns that source into 3.3V. That’s the native “voltage language” of the Tessel. It likes to speak 3.3V to everything if possible.

    One of the nice things about the proto-module is that the 3.3V and ground connections are exposed as two rails that run along each side of the module as seen below. This allows you to easily power your module components.

    Proto-module power rails

    Special Considerations

    If all of the components on your custom module operate at 3.3V, then your power design is extremely simple. You just use the 3.3V and ground rails and connect your components accordingly (the custom screen module below is a good example). Sometimes, however, you may encounter a situation where 3.3V is not what you need, like in the case of the servo module.

    Many servos like to operate at 5V. That’s their native “voltage language” and so the 3.3V provided by the Tessel isn’t ideal and, in many cases, just won’t work. Servos can also draw a lot of current, which may overwhelm the Tessel’s power supply. To solve this problem, you’ll notice that the servo module has a DC barrel jack on it that allows you to plug in a 5V adapter to provide sufficient power to the connected servos.

    DC Barrel Jack on the Servo Module

    From the servo module schematic, we can see that communication is accomplished with the normal I2C lines, which operate at 3.3V, but servo power is provided via schematic component J2, which is the barrel jack.

    This guide isn’t meant to be a comprehensive power reference, but we just want to point out that if you have any components on your custom module that work outside of the 3.3V realm, you will need to design for it. To simplify your module design, we recommend using 3.3V components where possible.

    The Power Warnings

    Here are some items to remember when working with power in electronics.

    • ALWAYS unplug your Tessel and any external power before making or altering connections.
    • Don’t mix voltages unless you know what you’re doing. For example, if you put 5V on any of the module pins, you can ruin your Tessel.
    • Never connect the positive voltage directly to ground. This is called a short circuit and can ruin components and your day.
    • Always exercise caution and verify that you have hooked everything up correctly before plugging in your Tessel.


    Once you have decided how you are going to power your custom module, it’s time to decide how the main Tessel board will talk to it.

    In the world of web communication, there are standards like HTTP, HTTPS, and FTP that allow different systems to talk to each other in well-defined ways. The same concept exists in the hardware world and the Tessel supports four standard communication protocols for talking to modules.

    Because the Tessel does most of the heavy lifting for all of these, you don’t need to be an expert to use them in your custom module. However, if you’d like to learn a little more, we’ve provided a simple overview of each.

    So Which Communication Protocol Should I Use?

    Knowing that there are four communication options available to you, which should you use for your custom module? The good news is that this will usually be decided for you based on the type of module you are creating. For example, most PIR sensor modules will set a pin high when motion is detected, which can be read with a simple digital input (GPIO). The same applies to sensors. For example, the Si7005 temperature and humidity sensor on the Climate Module communicates via the I2C protocol. Usually sensors will only support one protocol– so the decision is easy, you use that one.

    You will find some modules that support both SPI and I2C, and either will work just fine with the Tessel. As a general rule of thumb, we recommend you favor the SPI protocol in these scenarios as it eliminates the risk of I2C address collisions with other connected I2C modules.


    Once you have the power and communication all worked out and connected, it’s time to start writing JavaScript to talk to your module. This is where the open-source nature of the Tessel really comes in handy. We’ve already used all of the possible communication protocols in our modules and the code is free to look at and copy.

    Design an API for working with your module so that it’s easy for others to integrate into their projects. As a general rule, top priority is intuitive interaction. Second priority is exposing as many features as you can. You can find a lot of great information about organizing your project and writing an API in Making a Tessel-style Library for Third-Party Hardware.

    Documentation and Sharing

    Once you have a working module, it’s time to share the good news with everyone so other people can build amazing things with your work. We recommend doing a few things to share it with the community as outlined below. This helps create a consistent feel across all Tessel modules, whether they are official modules or submitted by the community.

    Create A Git Repo

    Having your code in a git repo and available online makes it easy for others to grab your code and start using it in their projects. To help you get started we’ve created a template repository that you can use as a starting point.

    Custom Module Git Repo Template

    Document It

    You may have just created the world’s most amazing Tessel module, but how is anybody going to know about it or use it? Once you’ve hashed out the API and everything is working, it’s important to document its use so others can easily apply your work to their projects. The best way to do this is to use the README template, which includes things like how to install the module, example usage, and API information.

    Publish Your Code on NPM

    Once your git repo is ready and you’ve documented your module, this step is really easy and makes your module fit the Tessel motto of “connected hardware as easy as npm install.” If you’ve never published code to NPM before, you can get started with just four lines of code (run in a shell window).

    npm set init.author.name "Your Name"
    npm set init.author.email "you@example.com"
    npm set init.author.url "http://yourblog.com"
    npm adduser

    This sets up your NPM author info. Now you’re ready to create your package.json file. There is one in the repo template but we suggest creating it by running npm init from within the project directory.

    npm init

    Edit your package.json file to include a name, version, and description. We also highly recommend adding “tessel” as a keyword so that other Tessel users can easily find your work. Most of the package.json file is self-explanatory and follows the npm package.json standard with the exception of the hardware member.

    **hardware** section of package.json

    This is a Tessel-specific item that you must add manually and is a list of files and folders in your project that you would like to exclude when code is pushed to your Tessel.

    Once your package.json file is complete you’re ready to publish your code. Run the following command from the top level directory of your project.

        npm publish ./

    Create a Project Page

    The Tessel Projects page is a way to share your module directly with the Tessel community. You simply provide a few pieces of information, a picture, and can even use your README.md file from your Git repo as the contents.

    Submit Your Module

    We’re always looking to add modules to our third-party module list so if you’d like your custom module to be listed at tessel.io/modules then fill out this form and we’d be happy to review it.

    Third-Party Module Submission Form

    A great example of using this module-creation pattern can be found in Making a Tessel-style Library for Third-Party Hardware.

    Your First Custom Module

    So now that we’ve described the pattern for making a custom module, let’s walk through creating a very simple module using that pattern. The Tessel has a spare button on the main board, but maybe you’d like to add one as a module. Kelsey did a great writeup on adding a button to the GPIO bank so let’s use her work to take it one step further using a proto-module.


    You might not think of a button as needing power, and you’re right, sort of. While the button itself doesn’t need power to function, we can connect our button in such a way that it uses the power connections to create high and low states on a GPIO pin.

    GPIO pins on the Tessel will always read high/truthy with nothing connected, because internally (inside the main Tessel chip), they are pulled up to the 3.3V supply. That’s our positive connection.

    The other power connection is ground, which we’ll connect to one side of our button. It doesn’t matter which side, because a button is just a momentary switch that creates and breaks a connection. You can’t hook it up backward. We’ll get to connecting the other side of the button in a minute.


    As mentioned above, normally your communication protocol is determined by your module. In the case of a button, we use a GPIO pin because we want to read the state of the button.

    Each port on the Tessel has 3 pins that can serve this purpose, and you are free to pick any one you like because it doesn’t matter.

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

    We’re going to choose G1, which is what we will hook up to the other side of the button. When the button is not pressed, our input pin will read high, or true. When we press it, we are making a connection between our GPIO pin and ground, which will cause a low state to be present on the input pin. This is what the design looks like.

    Schematic of button connections

    Soldered together on a proto-module board.

    Don’t let the soldering part scare you. Soldering components like this onto a proto-module is a little harder than learning to use a hot glue gun, but not a lot harder. This tutorial from Sparkfun is a great place to start learning soldering.

    Let’s go ahead and plug our module into Port A. Remember to never make connections while your Tessel is powered up. Always unplug it first.


    With everything hooked up, it’s time to write some Javascript.

    Actually, we’re going to reuse the code from Kelsey and modify it just a bit. Since she followed the style guidelines and shared her work on NPM, we actually don’t have to write the bulk of the code. She’s even provided a Quick Start guide in her documentation, so we’ll use that.

    1. Install the tessel-gpio-button package. This will allow us to reuse Kelsey’s work.

      npm install tessel-gpio-button

    2. Create a file named myButton.js and copy her Quick Start code into it. It should look like this:

        // examples/button.js
        // Count button presses
        var tessel = require('tessel');
        var buttonLib = require('../');
        var myButton = buttonLib.use(tessel.port['GPIO'].pin['G3']);
        var i = 0;
        myButton.on('ready', function () {
          myButton.on('press', function () {
            console.log('Press', i);
          myButton.on('release', function () {
            console.log('Release', i);

    This almost works right out of the box. We just need to make two small adjustments. Do you see them?

    First, to include her module we won’t use “require(’../’).” Instead we’ll include the module directly with require(‘tessel-gpio-button’).

    Second, she hooked her button up to the G3 pin on the GPIO bank, but we’ve hooked our proto-module up to Port A and used the G1 pin. So all we have to change is the line where myButton is defined. We’ll change it to be:

    var myButton = buttonLib.use(tessel.port['A'].pin['G1']);

    Save your changes and test it out.

    tessel run myButton.js

    Every time you push your button it should log to the console.

    Congratulations! You just created your first custom module for the Tessel.

    Custom button module connected to the Tessel

    Documentation and Sharing

    We sort of cheated for our first module; Kelsey had already created an NPM package that we could reuse, so there wasn’t really anything to document or share on the software side. There is nothing wrong with that. In fact, the less code you have to write, the better. This is a great example of how taking the time to document and share your work benefits the entire community.

    What we can do though is create a project page showing how we took Kelsey’s button to the next level in the form of a plug-in module. We created the physical module. It’s a simple module, but we should document it in case someone else wants a button module like ours.

    Custom Button Module Project Page

    Custom Screen Module

    Now that you have a simple module under your belt, it’s time to level up. To date, the module that people have requested the most is a screen module. Displays are tricky because they come in so many flavors. There are simple 7-segment displays, LCD displays, OLEDs, resistive touchscreens, capacitive touchscreens, and more. This is a great use case for a custom module.

    One of the popular screen modules in embedded projects is the Nokia 5110, because of its simple interface and low cost. Let’s see how we’d create a module for it by following the same pattern as before.

    For this example we’ll use the Nokia 5110 breakout from Sparkfun, but you could also use the Adafruit version of the screen or just try to snag one on Ebay

    Nokia 5110 Graphic LCD


    The 5110 has a listed power supply range of 2.7V to 3.3V, which means any voltage in between (inclusive) is sufficient to power the screen. Since the Tessel ports have a 3.3V supply pin we don’t have to do anything special to hook it up. All we need to do is connect the screen VCC, or positive pin, to a 3.3V rail on the proto-module and the GND on the screen to a GND rail.

    Because of the screen’s size, we’ll use one of the double-wide proto-modules this time, even though we’ll only use a single port to connect everything.

    Double-Wide Proto-Module


    Just like in the button example, the communication protocol for the screen has already been chosen for us. The Nokia 5110 uses a slightly modified version of SPI to communicate with a parent controller, namely the Tessel in our case.

    In addition to the normal SPI protocol, the 5110 has an extra pin involved (D/C) that tells the screen whether the data we are sending via SPI is a special command or actual screen data.

    The D/C pin is controlled by a simple high or low signal, which is a perfect job for one of the GPIO pins.

    The following table shows all of the communication connections available on our screen and how we’ll attach them to the Tessel port.

    Nokia 5110 Pin Proto-Module Connetion
    SCE G1
    RST Connected to 3.3V through 10K resistor
    D/C G2
    LED Connected to G3 through 330 ohm resistor
    Design Note

    The Nokia 5110 has 4 connections that can utilize GPIO pins for functionality. The D/C (data/command) and SCE (chip select) pins have to be used to get data to the screen. That leaves just one GPIO pin on the port with RST and LED left unconnected. You have a few options here.

    1. Wire RST to 3.3V through a 10K resistor which prevents you from resetting the screen in code. This allows you to control the backlight with the free GPIO pin.
    2. Wire LED to 3.3V through a 330 ohm resistor (to limit current) which will permanently turn on the backlight. This leaves a GPIO free that can be used to reset the screen via Javascript.
    3. Since we’re using the double-wide, you could use a GPIO pin from the adjacent port and have use of both LED and RST
    4. Connect SCE (chip select) to ground, which frees up a GPIO so you can control both LED and RST. Holding the chip select low, however, makes it so that no other SPI device (including other Tessel modules that use SPI e.g., the Camera module) can be connected to the Tessel on any other port.

    We decided to go with option 1 because there isn’t really a need to reset the screen in most cases and it allows control of the backlight with a GPIO pin. This is another great thing about custom modules. You can design it however you want to fit your project needs.

    We hooked everything up using the Graphic LCD Hookup Guide. We recommend testing everything with a breadboard before you solder everything in place, just to make sure it works the way you expect it to.

    Here is what the module looks like soldered to the double-wide proto-module.

    Nokia 5110 soldered to a large proto-module board


    With the screen hooked up, it’s time to start writing code. We’ll follow the pattern found in the Git Repo Template and start by creating a directory called tessel-nokia5110 and cd into that directory. Next, we’ll create index.js which is where we’ll write our API using the example index.js template as a guide.

    Because this screen is so popular, there are lots of code examples and libraries online for interacting with it. We don’t need to reinvent the wheel; we just want to control the screen with JavaScript.

    We took a simple Arduino library for this screen and ported it to JavaScript. Our API is very simple and exposes just one event and a few methods.


    Nokia5110.on('ready’, callback(err, screen)) - Emitted when the screen object is first initialized


    Nokia5110.gotoXY(x,y,[callback(err)]) - Sets the active cursor location to (x,y)

    Nokia5110.character(char, [callback(err)]) - Writes a single character to the display

    Nokia5110.string(data, [callback(err)]) - Writes a string to the display

    Nokia5110.bitmap(bitmapData, [callback(err)]) - Draws a monochrome bitmap from bitmapData

    Nokia5110.clear([callback(err)]) - Clears the display

    Nokia5110.setBacklight(state) - Turns the backlight on if state is truthy, off otherwise


    Now that the module is connected up and the software is working, it’s time to document its use.

    We can’t stress enough how important this is, and it really only takes a few minutes once you’ve defined everything. Just think of all the times you’ve needed a piece of code and found a beautifully documented example that had you up and running in minutes. Share that love with others when you create your own modules, no matter how trivial you think they are.

    In our case, we’ll take the template README.md file and add some notes for getting started as well as document our API.

    We’ll also create an examples folder to show how the module can be used.


    Now it’s time to share our new creation with the world by:

    Finished screen module

    Resource List

    To help you get started creating your own custom modules, here is a list of the resources we used to put this tutorial together.


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

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

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