• Community Feedback

    Tuesday, October 7, 2014

    10/7/2014– Kelsey Breseman

    In order to be successful, a startup needs to know its customers. The company needs to talk to users, try to understand their needs, and react accordingly.

    I’ve talked to a lot of our customers, largely because I’ve been taking lead on support since we started shipping product. But most of the time, I’m talking to prospective customers, customers who have questions about the delivery of their packages, and the self-selecting few who reach out to the team.

    Jon decided, sometime in September, to individually email 100 users and personally ask for their thoughts. I decided to follow up Jon’s effort with one of my own: I sent out over 500 individual requests for feedback to our early backers, asking them what they thought of Tessel so far, what they’d made, and what they might like to see in the future.

    Requesting feedback

    I sent the emails out one at a time, and adjusting the wording a bit where I could; if I’d had previous contact with a customer, I’d try to follow up on that interaction. I tried changing around my tone so I wouldn’t sound automated. Ultimately, I did everything I could think of to invite genuine conversation and useful feedback.

    Around 16% of the people I emailed responded. Where useful and appropriate, I kept up the conversation. For some respondents, feedback requests funnelled into support, tracking down packages or finding examples and documentation. Others had very specific ideas for our company direction, and I discussed with them individual use cases and specific design concepts they needed.

    Understanding responses

    In order to keep track of the body of correspondence, I worked through the whole process in Zendesk. I tagged each email that I sent with one tag, and had Zendesk automatically add another if a customer responded. I could then add my own tags to try and break down response types.

    With one set of tags, I broke user reaction into five mutually exclusive categories:

    • Has not yet used Tessel
    • Happy with Tessel
    • Has not yet received Tessel
    • Unhappy with Tessel
    • No opinion stated

    I also added a set of descriptive tags for things I saw mentioned regularly:

    • Has run across bugs
    • Hasn’t used Tessel much
    • Called out first run experience as good
    • Has plans for big projects
    • Called out docs as good
    • Doesn’t know what to do next
    • Seems to have hardware experience
    • Developing a product
    • Using Tessel in education
    • Using Tessel in a workplace setting

    My tagging wasn’t rigorous enough to merit statistical analysis, but it was useful to pull out these specific, common reactions. However, these lists are in order from most frequent to least.

    I also pulled out quotes of specific feedback from emails, for example describing a use case or project, or details regarding a desired case or module. These, I collected in another sheet. After pulling out quotes, I categorized them thematically (e.g. “cases”, “product development”, etc.). If a specific piece of feedback spanned multiple categories, I broke it out onto multiple lines, to keep the feedback focused. This let me grow themes from feedback snippets in an organic way.

    The feedback quotes were extremely useful. By filtering for different categories, it’s now easy to see several views on how people feel about our documentation, or about Tessel’s performance. Keeping the original wording and context also has great value; the way a user talks about a feature gives insight into their expertise in hardware and software.

    Interestingly, the key themes were different in this set than the specific reactions I’d tagged:

    • Modules
    • Product
    • Ease of Use
    • Cases
    • Project
    • Compatibility and Integration
    • Performance
    • Documentation
    • Remote deploy
    • Features
    • Size
    • Powering Tessel
    • Cables
    • Tessel 2
    • Education

    Of course, I must again stress that the feedback from these categories was specific and often conflicting. But even when reduced to mere categories, it highlights what’s on our users’ minds.

    Taking it to the team

    Feedback from users should be pervasive in a startup, especially one as small as we are. So I took this distilled version of the many feedback response emails, sent it to the team, and scheduled a discussion.

    Everyone read through the feedback, then we opened the meeting with each person silently writing post-its of the things that stood out or surprised them. We then followed up by trying to identify the strongest user needs.

    The two strongest areas that stood out were:

    • Users felt the need to make a “final” project: in the form of a case, a specific form factor, external power, etc. They felt that this need was not yet met.
    • Users were often unsure where to go next. Nearly all agreed that the first run experience was excellent, and were impressed by how quickly they could get a light blinking and a sensor collecting data. However, they weren’t sure how to take next steps– say, combining different modules, using the GPIO port, or taking ideas closer to productization.

    There were also some less abstract and very clear wants:

    • More modules– though there were few repeats on requests for specific modules. (We have a module suggestion form here if you’d like to weigh in)
    • Cases– ideally with a power source built in
    • Remote deployment of code

    We continued to discuss for an hour or two, putting our company plans and vision in the context of user feedback. Ultimately, I think we’re headed in the right direction, but it’s useful to factor user needs into the current design phase for the specifics of features and interface.

    I’d also like to call out a bit of specific follow-up:

    • Tim is taking point on a docs page redesign. We’re hoping to make it more navigable and complete, and to add more tutorials in the vein of start.tessel.io.
    • Kelsey and Jon will be working together to put up a page offering support for those of you who want to take your prototype and turn it into a product. (But don’t wait for the page to go up; email team@technical.io if you’d like to discuss.)
    • Eric is working on more modules. He’s also working on a way to make hardware components of tessel more modular, such that we might be able to scale a PCB that’s more specific to a given use case.
    • Jia and Eric have been working with manufacturers to produce module extension cables. We’re making sure the quality is good before we mass produce and sell them.
    • Ken is working on bug fixes and compatibility issues.
    • Jia is working on Wifi bug fixes.
    • Kevin is working on Fractal, which should help streamline product development. It’s under development.
    • Kelsey will look into modular case solutions.

    We really appreciate your feedback! If you’d like to add your opinion, I’m listening: kelsey@technical.io

    #kelsey breseman #community #feedback #backers #startup

  • Tessel Near You: Events and Conferences

    Thursday, October 2, 2014

    Some of the events we’ll be at this season– come find us! We’ll have Tessels you can play with:

    Events we won’t be at, but Tessels will:

    • PragueJS in the Czech Republic has a presentation by Ladislav lined up for October 23rd.
    • CampJS 10/31-11/3 in Australia looks like an amazing event. We wish we could go, but Glen has kindly agreed to run a workshop with quite a number of Tessels at the event.
    • Node One-Shot in Budapest (11/20) is running a Tessel Nodebots meetup hosted by the marvelous Matteo
    • MLH Hackathons USA have Tessels as part of their hardware library all fall.
    • CodeMash in Ohio in early January features a talk about Tessel by Adam.

    Other ways to play with Tessels near you:

    Want to host your own Tessel-related meetup or event? We’d like to help! Reach out to kelsey@technical.io

    Also send me an email if you’re giving a Tessel talk or workshop and would like me to list you here!

    #events #conferences #updates

  • The Unintended Cost of Shipping

    Tuesday, September 30, 2014

    9/30/2014– Jon McKay

    Note: The opinions voiced in this retrospective are Jon’s. Other Technical Machine team members may or may not share the same thoughts.

    The Low Point

    Anyone who has started a company will inevitably tell you “it’s an emotional rollercoaster”. True to the maxim, Technical Machine hit its first real valley just after we shipped Tessel, a crowdfunded, JavaScript programmable microcontroller platform. The months of June and July at Technical Machine were the most difficult times I’ve experienced as both an engineer and as a CEO.

    We had some legitimate problems: when we shipped we had nearly a third of customers contact us with fulfillment issues, we missed a critical GPS module hardware issue, and most of our software testing infrastructure was decrepit when we shipped rushed code, to name a few. But those issues aren’t difficult to solve. Those issues have been more or less fixed with a combination of engineering time and money.

    But we had a scarier issue: our motivation to keep pushing was dwindling. Before shipping, we had this single, unifying, direction-full goal of getting this novel product out the door. But after Tessel was in the hands of users, all there was to do was feel burnt out from the 16 hours days, fix those difficult bugs that had been haunting us (and now our customers) for months, and try to track down lost shipments. Sure, there was the joy of hearing from our customers how much they loved our getting started experience but, between those snippets, it was hard to not feel demoralized. Surely, there had to be more to it than this?

    During my one-on-one meetings with everyone on the team, they each independently explained that they felt that we were now directionless. Why wasn’t I providing more direction for the company? “We need to be working on the next thing by now”, they all said. What was the grand vision for Technical Machine?

    The truth was, I didn’t have one yet. I felt that this was our time to learn as much as we could from our product being released into the wild. I thought that the future of our company depended on what our customers taught us about how they build hardware with Tessel.

    It turns out, as is usually the case, I was partially right and mostly wrong.

    The Cause

    We started Technical Machine with the idea that developing hardware should be as easy for a web developer as deploying to a server. Whether or not it’s possible, it is an ambitious technical and social engineering challenge. These types of lofty goals attract the type of people that want to work on very hard, unsolved problems every single day. We were all comfortable working towards solving looming, unanswered technical questions. But after we shipped Tessel, there weren’t many architectural questions left. We had proven that JavaScript and Node on microcontrollers could make for a great prototyping experience; all that was left was (a lot) of polish.

    Myself excluded, the entire team consisted of “research-heavy” engineers. Engineers who want to build entirely new things as quickly as possible and aren’t as interested in polish. Nobody on our team strongly identified as the type of engineer who likes to sit down and make a code base shine. The desire to fix bugs and maintain the product after it was released was not as high as developing a prototype to begin with.

    To compound the problem, we had little testing infrastructure in place while developing Tessel, so our product was buggier than it could have been (an artifact of having just graduated from college, where testing code was rarely discussed or practiced).

    In short, there were more bugs to fix and nobody interested in fixing them. Asking our engineers to continue preening over our existing code base after months of working on it wasn’t making anyone happy or productive.

    At this point, we had two related but distinct issues: the company had little sense of direction, and what we did have to work on wasn’t making anyone excited to come in to work.

    The Lessons

    In an effort to give our company more direction, we started having long brainstorming sessions about what we wanted to build and where we wanted the company to go. We talked about what we had learned from customers using Tessel in the wild. We talked about what we were interested in as individuals.

    Ultimately, we arrived at a couple of key points:

    • Prototyping tools and manufacturing tools have traditionally been disjointed. There has always been a leap from the device that proves out the viability of an idea and the device that eventually gets to market. Creating a sustainable funnel for customers to progress from prototype to a product at scale is a business opportunity worth pursuing.
    • As a company, we’d like to head further away from the toy/hobbyist market and closer to being a trusted provider of embedded hardware tools – not just for web developers but eventually electrical engineers and seasoned product developers as well.
    • We’re not interested in being another hardware platform that succumbs to building the “IoT cloud” to rule them all. We feel that, while cloud platforms have their intricacies, the technical and social engineering challenges are not appealing.
    • Tessel’s getting started experience is top-notch. Integrating npm with the hardware modules provides for (in our opinion) the fastest prototyping platform available. Users could go from unboxing with no hardware experience to serving pictures from the camera module in a web app in under 5 minutes. It’s important to us to continue enabling that type of interaction.
    • While we do believe Tessel is the best way to prove out an idea’s viability, it leaves the user further from a technical prototype than they could be if they used other hardware platforms like Arduino or Launchpad. Working in JavaScript and Node land doesn’t scale well in hardware because of the unavoidable consequence of working with components that are overpowered.

    Focusing our attention on Scalability

    We reframed the problem as “How can developers leverage the speed of development of JavaScript and Node while still making the transition to a technical prototype as simple as possible?”. In order to get an idea of the areas of opportunity in the space, we drew up a checklist of all the task items that have to be complete before a developer is ready to ship a product (the topic of an upcoming blog post) to get a better idea of where we can add value.

    Based on what we’ve heard from users of Tessel, one of the most important and opaque transition points from the “idea viability” stage to the “technical prototype” stage is picking out the actual components (integrated circuits, sensors, etc.) that are to be used in the final design.

    We held quite a few brainstorming sessions as a whole team but didn’t make much progress until Kevin, Eric, and I were casually discussing the hardware development process.

    Kevin, our lead firmware engineer and previously a co-founder of a hardware tools company called Nonolith Labs, started explaining an idea he had for how hardware development should be done. I’m not sure how much of it was formed before our brainstorming meeting, but it came out in a fairly cohesive stream. Kevin’s idea was largely focused on software defining hardware interfaces in such a way that it becomes possible to automatically generate more components of a hardware device.

    Imagine embedded hardware development as being composed of six levels of abstraction:

    1. Data Flow: A description of how data flows between different inputs (sensors) and output (network) blocks, as well as code blocks (JS, Rust, C, etc.) of various languages.

    2. Firmware: A verbose and precise description of machine-readable code that dictates how the hardware works at the lowest level to allow that flow of information. Boilerplate configuration code, for example, setting up registers to communicate with external memory, can be autogenerated if parts are known.

    3. Part Selection: The actual integrated sensors and integrated circuits that comprise the system. There is a dependency between the code that is generated and the microcontroller that is used.

    4. Schematic: How the pins should be connected together. If parts are known, then this becomes an datasheet scraping problem.

    5. PCB: How components are physically laid out on a circuit board. If a schematic is known and context of each signal is known (is this power, ground, a high speed usb signal, RF signal, etc.), then a PCB becomes easier to automatically route. Auto routing has traditionally been considered a bad practice and nobody has done it well yet.

    6. Manufacturing: Who actually manufactures the PCB and/or assembles the parts.

    In theory, the hardware development process could be described from any of the above levels of abstraction (besides manufacturing) and a circuit board could be generated as precisely as it was described. Each level of the process should be optimizable so that a seasoned firmware engineer could tweak the firmware or an electrical engineer could add necessary passive components and modify the size of any sensitive traces.

    The idea of “software defined hardware” resonated with the team as a solution space worth attacking. An accessible but powerful hardware development tool that would take years of development work aligned very well with the personal interests of everyone on the team. The question turned from “what are we building next?” to “how do we approach such a giant, complicated system?” Once we we were able to frame the problem around solid technology choices that could accomplish the goal of “software defined hardware”.

    As a first step towards that goal, we’d like to enable a user to program a single application in both low-level and high-level languages. This means developers can prototype an idea quickly in JavaScript, and if it proves viable, start breaking the component parts into C or Rust. It’s a much easier path to a technical prototype than starting from scratch when moving to a technical prototype.

    Tessel is just the first development board which would be the target of this new hardware development tool. Over time, we hope more and more microcontroller targets will be contributed so that our open source tool can extend past just the Tessel ecosystem. We’ll be releasing more information about this new tool as we start speccing it out.

    Maintaining Tessel

    As for maintaining Tessel’s architecture, we’ve made a huge amount of progress. By having each person in the company split their time between working towards these new engineering goals and working on maintaining the released Tessel platform, we’ve reinvigorated our collective enthusiasm for our vision. We’ve also started hiring people who would be well-suited for support positions. In that vein, we’ve hired Ken, who is one of the most patient and detail-oriented people I know, to work on improving Tessel’s JS and Node compatibility. We’ve also hired an external contractor to work on some of the finer points of JS compatibility like the unicode implementation.

    Unanswered Questions

    We’re really excited about our new direction but we still have a few questions to answer:

    • Who are our customers? Tessel’s customers are usually web developers interested in hardware. But now that we’re starting to prototype tools for the wider user group of product developers, how do we market our product and who do we approach about user research? We also need to gather more information about how much of our current customer base is interested building scalable devices and how many are building one-off solutions.
    • Is this user group big enough and growing fast enough to be sustainable? Tessel itself hasn’t yet answered the question of how big the group of hardware-interested web-developers really is and it’s unlikely that traditional product developers will use our system until it’s more proven.
    • How do we go about automating the “human” parts of hardware development? The deals with manufacturers and working with suppliers, smoothing out issues with contract manufacturers, and debugging issues with field application engineers all currently require face to face interactions.

    Going Forward

    We’re continuing to dish out more Node and JavaScript compatibility for Tessel and make WiFi more robust. We’re pushing forward with enabling more programming languages on Tessel, enabling more microcontrollers and microprocessors to take advantage our runtime, and looking into more diverse wireless hardware. We’ve released the Project Portal to share Tessel-based projects and we’re working on remote code deployment. More and more Node Modules are starting to work out of the box, like Twilio and MQTT.

    We’ve still got a lot of work to do before we start making the hardware development experience we’ve been dreaming up. In the past year we’ve learned a ton about what it means to build a company but we need to start talking to users to get these new questions answered. If you have experience or suggestions you’d like to share, please email me at jon@technical.io. I’d love to hear it.

    We also have open, full-time positions that we’re hiring for, including web developers, HR/recruiting, business development, and firmware engineers. If you’d like to contribute to our vision of reimagining hardware development, don’t hesitate to reach out!

    #tessel #motivation #startup #vision #reinvigorate #hardware #scaling #node #prototyping

  • MQTT on Tessel

    Wednesday, September 24, 2014

    9/24/2014– Jon McKay

    Using MQTT on Tessel

    MQTT is a lightweight publish/subscribe protocol designed for machine to machine communication. The architecture features one central server that manages the subscriptions and publications from each of its numerous clients. Clients can publish data without having to be aware of who is subscribed (much like Node’s EventEmitter class).

    source: Eurotech

    MQTT is also designed to require minimum protocol overhead for each packet in order to preserve bandwidth for resource-constrained embedded devices. It’s a really simple framework for managing mesh networks of TCP-enabled devices.

    Tessel-MQTT Compatibility Backstory

    As far as I could tell, there is only one MQTT implementation in Node (surprising, right?!) and it’s really well maintained. Up until a few weeks ago, the library couldn’t run on Tessel due to a couple of Node and JS incompatibility issues. The biggest problem was the use of Function constructors, used primarily for speed improvements, which isn’t supported on Tessel yet.

    In JavaScript, the Function constructor accepts a string of JavaScript code which it processes into an actual function:

    var f = new Function(foo, bar, “console.log(‘the arguments are’, foo, bar)”);
    f(‘a trivial’, ‘example’); // prints ‘the arguments are a trivial example'
    

    It’s often used as a faster way to template a function, replacing Function.prototype.bind which runs abnormally slow on V8.

    Tessel’s runtime translates JavaScript to Lua on a host PC before being pushed to Tessel and run on a Lua Virtual Machine. We’ll need to push compilation functionality over to Tessel before Function constructors (or eval) can work on the device. Tim has made stready progress on a compiler written in C (as opposed to JavaScript) that will reside on Tessel itself and compile JavaScript to LuaJIT bytecode. But it isn’t quite ready yet, so we looked for another way around the issue.

    Matteo Collina, one of the primary maintainers of the MQTT.js library, and I started a discussion about the MQTT library’s compatibility with Tessel. He was kind enough to accept a pull request that replaced the Function constructors so that we wouldn’t have to wait for the C-based compiler to be complete to use MQTT on Tessel. I just had to fix one more issue with Buffer parsing and the library worked without a hitch on Tessel!

    Code Example

    Tessel can act as either an MQTT server or a client, and the client code is impressively simple in practice. In this code snippet, I publish the current temperature to an MQTT server every five seconds:

    var mqtt = require('mqtt')
      , host = '192.168.8.102'
      , port = 1883
      , client = mqtt.createClient(port, host, {keepalive: 10000})
      , tessel = require('tessel')
      , climate = require('climate-si7020').use(tessel.port['A']);
    
    climate.on('ready', function ready() {
      console.log('climate ready');
      setInterval(function() {
        climate.readTemperature(function(err, temperature) {
          if (!err) {
           // You can only publish strings
            client.publish('temperature', temperature.toString());
          }
        });
      }, 5000);
    });
    

    You can find the entire example on this Github Gist.

    If you have a project that requires the use of multiple data gathering clients interacting through a single server, consider trying out MQTT because it’s one of the simplest protocols for M2M communications.

    -Jon

    #mqtt #js #javascript #node #tessel #technical machine #temperature #home automation #climate #jon #mckay #matteo #collina #mqtt.js #node.js

  • How-to: Adding Buttons to Tessel

    Wednesday, September 24, 2014

    9/24/2014– Kelsey Breseman

    A number of users have requested a button module on Tessel. We welcome this and other module suggestions here, but in the meanwhile, I thought you’d find a tutorial on adding your own buttons (of any size and shape) useful.

    I’ve put this up on the Projects Page, so I encourage you to also check it out, access the repo, and comment there!

    But as long as I’m going into the details of how buttons work, I thought you all might appreciate it on the blog.

    Quick start: I just want a button.

    Your button should have two wires sticking out of it. Plug in one side to ground, and the other to pin G3.

    Install:

    npm install tessel-gpio-button
    

    Use:

    var tessel = require('tessel');
    var buttonLib = require('tessel-gpio-button');
    var myButton = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    
    var i = 0;
    
    myButton.on('ready', function () {
      myButton.on('press', function () {
        i++;
        console.log('Press', i);
      });
    });
    

    Congratulations, you now have a button!

    How it works, and why

    Why add a button over the GPIO?

    Buttons are a nice, easy way to make your project interactive. Tessel comes with API access to the Config button on the board. For many use cases, this is enough. But perhaps you want more buttons, or buttons with a certain look or feel. That’s where this tutorial will come in handy.

    What is a button, in terms of circuits?

    Electrically, a button is nothing more than a switch. One wire goes into the button; one wire comes out. When the button is pressed, the wires are connected. When not pressed, the wires are not connected.

    Making a button talk to Tessel

    Tessel communicates over 3.3V. That means that its pins operate between 0V and 3.3V. For a digital pin, 3.3V evaluates to “high” or 1 (truthy), and 0V evaluates to “low” or 0 (falsy).

    Tessel has six digital pins along the GPIO bank, marked G1-G6. Each of these pins is pulled high (3.3V) by default. In order to change the state of these pins from high to low, all you have to do is connect a digital pin to ground (GND).

    If you have a wire, you can try it out– plug in a wire (ideally black, for ground) in to the GND pin on Tessel’s GPIO bank. While running the code below, try sticking the other end of the wire into G3:

    // tutorial/polling-read.js
    // Read Tessel's GPIO pin G3 every 100ms
    
    var tessel = require('tessel');
    var myPin = tessel.port['GPIO'].pin['G3'];
    
    setInterval(function readPin () {
      console.log(myPin.read());
    }, 100);
    

    You should see a stream of ones while the wire is not plugged in, and a stream of zeroes when it is plugged in.

    Okay, now let’s try it with a button. It’s basically the same thing. Unplug your Tessel (it’s bad practice to mess around with wires while your Tessel is powered). Your button should have two wires sticking out of it. One of them should plug into GND; the other into pin G3.

    Run the same code, and try pressing the button. You should see zeroes when the button is pressed, and ones when the button is not pressed.

    Button events

    Tessel has events for its pins. It fires an event each for rise, fall, and change.

    Since the signal falls to low when the button is pressed, and rises to high when the button is released, it seems like you should be able to just use pin.on(fall, function () {}). Let’s try it and see what happens:

    // tutorial/simple-event.js
    // Logs a message each time the pin falls
    
    var tessel = require('tessel');
    var button = tessel.port['GPIO'].pin['G3'];
    
    var i = 0
    
    button.on('fall', function buttonPress () {
      i++;
      console.log('You pressed the button!', i);
    });
    

    If you have a really nice button, this might just work. However, if you have a cheap button like mine, the fall event will be emitted more than once per button press. This is because you are dealing with a mechanical system, and the electrical contact is actually bouncing a little bit on contact and messing up the signal. You can read about this phenomenon here.

    In order to correct this problem, we need to do some software debouncing.

    Debouncing can be a very complicated problem if you need the ability to read the button several times a second (read a few approaches here). However, for most applications, you can simply reduce the rate at which your events can fire.

    Let’s try adding a delay timer to the event:

    // tutorial/debounced-event.js
    // Logs a message at button presses that are sufficiently spaced
    
    var tessel = require('tessel');
    var button = tessel.port['GPIO'].pin['G3'];
    
    var delay = 500; // Let's try every 500ms
    var ready = true;
    
    var i = 0
    
    button.on('fall', function () {
      if(ready) {
        buttonPress();
      }
    });
    
    function buttonPress () {
      i++;
      console.log('You pressed the button!', i);
      
      // Set a delay timer
      ready = false;
      setTimeout(function () {
        ready = true;
      }, delay);
    }
    

    500ms worked well for my button, but feel free to adjust the delay and see how long it takes for your button to stop bouncing.

    Wrapping the events

    For the sake of consistency, I’ve set up index.js of this folder the same way we set up every module, to emit an event on press. press and release are individually easy, but harder to have both due to our simple debouncing method. I’ve left that as an exercise for the reader (PRs welcome).

    Here’s some example code requiring index (or just npm install tessel-gpio-button):

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

    Multiple buttons

    Say you want more than one button. Maybe you’re making a game controller, or a musical instrument or something. So you have several buttons to connect.

    All you have to do is connect one side of each to ground, and the other side to a different digital pin.

    Then make different instances for each button. Like this:

    // examples/two-buttons.js
    // Log button presses from two different buttons
    
    var tessel = require('tessel');
    var buttonLib = require('tessel-gpio-button');
    
    var button1 = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    var button2 = buttonLib.use(tessel.port['GPIO'].pin['G2']);
    
    button1.on('press', function () {
      console.log('Pressing button 1.');
    });
    
    button2.on('press', function () {
      console.log('Pressing button 2.');
    });
    

    Pressing the different buttons will give you different messages.

    Note that I used a breadboard to connect several buttons to the same ground. If you’re interested/want to know more about breadboards, this is a really good place to start.

    That’s all! Enjoy.

    I’ll keep this tutorial up to date on its projects page

    #tessel #button #kelsey breseman #tutorial #how-to #electrical engineering #electronics

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