• Tuesday, March 25, 2014

    #hardware #jia huang #tessel #technical machine #manufacturing #presentation

  • Monday, March 17, 2014

    #fluentconf #javascript #embedded devices #tim ryan #tessel #technical machine #presentation

  • BLE Module & Mooshimeter

    Monday, March 10, 2014

    3/10/2014— Jon McKay

    For the past few weeks, I’ve been head-down in technical development on our Bluetooth Low Energy module driver. We’re using the BlueGiga BLE113 chip for our bluetooth communication and it receives commands over the UART bus from Tessel.

    The Status of Bluetooth Hardware

    Our Bluetooth Module has undergone a several revisions since our first attempt:

    You’ll notice that there are several through-holes on the bottom of the final revision.

    As in many of our modules, we wanted to expose some extra functionality for more hardware-savvy users without getting in the way of folks who don’t need it. We’ve exposed an I2C port, two GPIOs, and an ADC on the module itself. The GPIOs are important for making the module use less power (discussed below).

    We made a difficult decision regarding the assignment of the third GPIO pin on the module port. We were running into an issue where if the reset button on the Tessel was pressed while the BLE module was plugged in, it would pull the UART transmit line low, causing the BLE113 UART parser to freeze when it parsed what it perceived as an invalid array of zeros.

    It wouldn’t unfreeze until the module was physically reset. After contacting BlueGiga support (who are exceptionally responsive, by the way), we came to the conclusion that the problem wouldn’t be solved until BlueGiga’s software engineer got around to fixing it.

    Making the success of your hardware dependent on the schedule of another company’s engineer is rarely a good idea. We had little choice but to assign the third GPIO pin directly to the BLE113 reset line so that we could automatically reset the module in software between code deployments. The downside is that third GPIO was originally assigned to the wake-pin, which allowed the module to go to sleep and save energy when the Tessel wasn’t communicating with it.

    In order to preserve that functionality, we exposed the wake-pin on the bank of extra through holes so that those who need to make BLE as lower power as possible can still access that functionality.

    Testing with Mooshimeter

    Our good friends over at Mooshim Engineering were kind enough to lend us an early version of their new Mooshimeter, a bluetooth-enabled multimeter. It was a perfect chance to test out our bluetooth module and its driver. Integrating with the Mooshimeter was incredibly easy. After connecting to the device, I simply had to tell it to turn on its analog-to-digital converter and I could start receiving asynchronous notifications with voltage values. Check out the JavaScript code below to start printing out voltage values in the terminal (gist):

    var tessel = require('tessel');
    var blePort = tessel.port('a');
    var bleDriver = require('../');
    
    bluetooth = bleDriver.use(blePort, function(err) {
      if (err) {
        return console.log("Failed to connect");
      }
      else {
        // Connect to moosh
        connectToMoosh(function(moosh) {
          // Tell the meter to start reading, pass back char to read
          setMeterSettings(moosh, function(meterSample) {
            // Start reading that char
            startReadingMeter(meterSample);
          });
        });
      }
    });
    
    function startReadingMeter(meterSample) {
    
        meterSample.on('notification', function(value) {
          var voltage = 0;
          for (var i = 0; i < 3; i++) {
            voltage += value[3+i] << (i*8);
          }
          voltage = (0x1000000 - voltage)  * (1.51292917e-04);
    
          console.log("Voltage", voltage);
        });
    
        meterSample.startNotifications();
    }
    
    function setMeterSettings(mooshimeter, callback) {
      if (mooshimeter) {
        // Find the characteristic with meter settings
        mooshimeter.discoverCharacteristics(['ffa2', 'ffa6'], function(err, characteristics) {
          var meterSample = characteristics[0];
          var meterSettings = characteristics[1];
          // Update meter settings struct to start reading...
          meterSettings.write(new Buffer([3, 2, 0, 0, 0, 0, 0, 0, 23]), function(err, valueWritten) {
            callback && callback(meterSample);
          });
        });
      }
    }
    
    function connectToMoosh(callback) {
      bluetooth.filterDiscover(mooshFilter, function(err, moosh) {
        bluetooth.stopScanning(function(err) {
          moosh.connect(function(err) {
            callback && callback(moosh);
          });
        });
      });
    
      bluetooth.startScanning();
    }
    
    function mooshFilter(peripheral, callback) {
      for (var i = 0; i < peripheral.advertisingData.length; i++) {
        var packet = peripheral.advertisingData[i];
    
        if (packet.type = 'Incomplete List of 16-bit Service Class UUIDs'
            && packet.data[0] == '0xffa0') {
          return callback(true);
        }
      }
      return  callback(false);
    }
    

    Output:

    See it work on Vine!

    I’m really excited to build out the Mooshimeter example to be able to read out both channels on the multimeter.

    Almost There

    The Bluetooth Driver is about 60% done at this point. I still need to add security functionality (pairing, encryption, etc.), hardware functionality to be able to use the through-holes at the bottom, and the ability to update the firmware of the BlueGiga module itself over UART. Then I’ll be polishing up a comprehensive test suite so that we can continuously integrate any new changes to the driver. It’s a lot of work for one module, but totally worth it.

    –Jon
    jon@technical.io

    #jon mckay #tessel #technical machine #ble #bluetooth #bluegiga #ble113 #uart #i2c #mooshimeter #mooshim engineering #javascript

  • The first day with TM-00-03

    Friday, March 7, 2014

    3/7/2014— Eric Kolker

    Hey Tesselators, Eric here.

    Every once in a while I just feel like writing. I have the urge to get thoughts out of my head and onto paper, into a keyboard, whatever. When the feeling strikes, I braindump, and right now I’m in one of those moods.

    New boards!

    One thing that’s super important to us is openness, as Kelsey recently discussed at length, so enough of our feelings and more of our status.

    Thursday was a big day because the small batch of Tessels with the updated boot circuitry and power plant arrived from our assembly house. Here’s one in all its glory:

    This isn’t our first time bringing up new boards, and by now we’ve gotten pretty good at it. Kevin and Jia finished adapting the firmware to the new hardware and had it running blinky.js (the “Hello, World!” of hardware) in under an hour. For reference, that’s fast for first contact with a complex digital system.

    Meanwhile, I was testing the power plant in situ, and what would bringup be without its share of troubles? (Answer: a lot less exciting)

    VCO = voltage-controlled…Oh, no.

    I completely reimagined the power plant for this version of the board (mockup above, schematic below), and one of the types of chips we’re using (U1 in the schematic, part number FPF2700) allows us to select which power source, USB vs. an external supply, powers the board. It can also limit the current we draw from the external supply, in case you accidentally short something. In fact, the specific chip we used even has a feature that shuts off the output by temporarily disconnecting external power if it detects an overcurrent condition (TL;DR, short circuits allow a lot of current to flow, which is usually very bad for whatever said current is flowing through).

    Now that everything is together, though, our 3.3 V rail sometimes behaves like a voltage-controlled oscillator. After an 11-hour day of testing, we’re pretty sure that the chip thinks that it’s in an overcurrent condition for input voltages above about 8 V (note that voltage and current are unrelated quantities and besides, it’s designed to withstand at least 15 V).

    Weirder still is that the speed with which the chip makes this decision seems to be proportional to the input voltage (I have my theories here… Read my post on the GPRS module for a hint). In any case, the faster it all shuts off, the sooner the 3.3 V rail drops down, and the sooner the system reboots and goes through the cycle again, hence the apparent “VCO”.

    Once you get over all of that behavior, the notion that such a system would also exhibit hysteresis and wouldn’t break the death spiral until the input voltage drops below about 6 V is trivial to accept. (Note: some sarcasm present in the otherwise objective analysis of above paragraph).

    We have good reason to believe that the chip is not, in fact, in an overcurrent condition, or, at the very least, not in the type of overcurrent condition against which the feature is designed to protect. Needless to say, we have our suspicions as to what we can do to fix it, and parts are already in the mail. The easiest fix would be a partswap on the controller chip; there’s one made by the same manufacturer in the same family that relies on internal thermal protection circuitry to safely handle short circuit conditions.

    Lunch

    Every Wednesday we go out to lunch, get out of the office, and talk about what we’ve been doing, what we should be doing, future directions, you name it. This week we actually just got take out from a wings place, but whatever, the kernel is the same: kick back a little and talk about the things that get pushed to the back of our minds when our heads are down in technical development.

    This week, the conversation spanned hiring, housing, and the state of our blog. The consensus is that we really like the blog (and hope you do too) and consider it to be one of our signature features, but that we need to push to keep high-quality and genuine content flowing. We made a point of enacting a policy (to the extent we have such a thing) of consciously writing things down when we’re excited or worked up about something, so here goes.

    As a side note, coming attractions include…

    • Jon has been grinding away on the BLE module
    • Tim is the exterminator to the our runtime’s bugs
    • Kelsey has been cranking on the first run experience
    • Kevin is knee-deep in rewriting our entire USB stack
    • Jia is busy juggling manufacturing
    • I’ve been cutting my JS teeth on the GPRS module and redesigning our power input stage.

    Expect posts from them soon thanks to Kelsey’s new wall of shame/indebtedness to the blog:

    D’aww

    We’re sometimes pulled out of the sea of technical challenges by you, our…well, what do I call you? “Adoring fans” is patronizing, “customers” is far too impersonal. “Community” and “friends” is where we hope we’re headed. If you hadn’t noticed, I tend to sidestep the issue and use the highly technical, specific, endearing, and official term “Tesselators.”

    But I digress. One of the things I was trying to say is that sometimes someone reaches out and we all stop what we’re doing and read their email. The commentary runs the gamut; sometimes someone tells us that they’re disappointed with the Beta program, sometimes it’s a feature request or compatability question, and other times, like yesterday, we get subject lines like “What I like about your team”. I cannot begin to describe how important all of these interactions are to us. We’ve said this before and we’ll say it again: we’re incredibly fortunate to have such an energetic, excited, and appreciative community, so we do everything we can to keep a pulse on what everyone (yes, everyone) has to say. We love you, we really, truly try our best to show it, and we hope that the system exhibits positive feedback.

    Thanks!
    ~e

    e@technical.io

    #tessel #updates #technical machine #tm-00-03 #internet of things #electrical engineering #power #eric kolker #community #startup #update

  • Thursday, March 6, 2014

    #update #tm-00-03 #tessel

August 2018

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013