Category: Edison

UPM library for MCP9808 in XDK.

If you have read my blog at all you may be beginning to think I have a fetish for the MCP9808. Well, maybe a little, but for a good reason. If we look it’s data sheet we see the MCP9808 is a surprisingly complex device. Some of the features the data sheet lists:

  • Accuracy:
    •  ±0.25 (typical) from -40°C to +125°C
    • ±0.5°C (maximum) from -20°C to 100°C
    • ±0.5°C (maximum) from -20°C to 100°C
  • User-Selectable Measurement Resolution:
    • +0.5°C, +0.25°C, +0.125°C, +0.0625°C
  • User-Programmable Temperature Limits:
    • Temperature Window Limit
    • Critical Temperature Limit
  • User-Programmable Temperature Alert Output
  • Operating Voltage Range: 2.7 V to 5.5V
  • Operating Current:  200 µA (typical)
  • Shutdown Current: 0.1 µA (typical)
  • I2C bus compatible

These features make the MCP9808 ideal for a variety of temperature monitoring applications when being precise would be an advantage.

The devices I have been using I got from Adafruit.  They have a driver library for the Arduino  that is useful, but I want to use the device with Linux based IoT platforms such as the Intel Edison or the Beaglebone Black. Both of these platforms support the Intel UPM library , so it made sense to add a driver for the MCP9808 to that. I implemented the driver and added a pull request to have it incorporated into the Intel UPM library. The MCP9808 was accepted in to version 4.0 of the library and should be available after upgrading the version of MRAA on your board. If not — I have a blog post that lists various ways to update MRAA/UPM on your boards. (UPM is very easy to compile).

I provided a C++ program to the UPM repo that exercises all of the implemented functions.  You can copy the code from that example into an Intel iotdk-ide project (Eclipse) and run it from there. But I didn’t include a very good example for Nodejs. That brings us to the purpose of this post — I want to go over how to use the MCP9808 in Nodejs with XDK on the Edison (or compatible) MRAA board.

In order to give a proper demo I created a Nodejs/Socket.io app that illustrates all the implemented features of the MCP9808 UPM driver. It is setup as an XDK project so you can download it and open it in the XDK ide to run it on your Edison. Before you run it open the server.js file and change the line

var temp = new mcp.MCP9808(1) 

to whatever i2c bus you are using. I generally use a handmade boardthat extends the Edison Mini breakout board so I use bus 1. It will be bus 6 on the Arduino or DFRobot breakout, 0 on the Galileo.

When you download and start the app on the board browse to it’s url :8085 (like edison.local:8085) and you should see something that looks like this:

mcp9808_default_celcus

This is a single page app that uses socket.io to communicate with the Edison. The Edison serves the app via Express and the UI is basic HTML with the  Bootstrap framework. The four sections of the app (from right to left) are:

Temperature:

The radial gauge will reflect the current temperature at the device. The MCP9808 reports temperatures as Celsius (C), but the driver provides a conversion to Fahrenheit (F). The F values are calculated, so when we switch between C and F there are sometimes rounding differences. All the other temperature values in the UI will convert to C or F except for resolution. Resolution is always reported as C. I have the temperature limited from  freezing to boiling range, but the MCP9808’s range is little wider than that — see the specsheet.

Temp limits: 

These reflect the state of the three temperature limit registers detailed in section 5.1.2 of the spec sheet. These registers are used to allow the setting of temperature limits the MCP9808 can monitor so that we don’t have to constantly check for out of limit temps in code. The limit registers will cause flags in the ambient temp register (section 5.1.3)  to set if a threshold has passed. The driver exposes these bits as flags that can be read (see lines 158 to 167 of the server code) via a simple function call.  The thing to remember with these flags is that they reflect the state of the bits as of the most recent getTemp() call, so you need to read the temp before reading the flags.

I use the state of the Temp limit bits to set the color of the subheadings in the Temp Limit section. Since at power on the temps are set at 0 C, so the bits for TCrit and TUpper are set. Using the sliders to set a value greater than the current temperature will allow the TCrit and TUpper values to go green:

MCP9808_alert_off

The temp limit registers are also used in the Alert functionality.

Alert Control: 

Described in section 5.2.3 of the spec sheet,  the MCP9808 has the ability to control an alert pin when certain conditions arise.  On power up alerts are disabled. Default sets the device to comparator mode (section 5.2.3.1). The alert will assert (in this case pull low — you need to use a pull up on the pin) whenever one of the monitor temps are crossed. When the temp comes back within limits the alert will de-assert. In interrupt mode the just the TUpper and TLower are monitored. It the temp goes over a threshold the alert is asserted and will not de-assert until the temp goes back with range and the interrupt is cleared by code. These calls are illustrated in the server code.

Other:

The Other section contains controls for  resolution and hysteresis and display for device info, id and rev.

Resolution will always be reported in Celsius. Startup default is 0.0625 and equates to 4 temp measurements per second. Temperature resolution is detailed in section 5.2.4 of the spec sheet.

Hysteresis will be reported in either C of F depending on the driver settings. Hysteresis is detailed in section 5.2.2 and Figure 5-10. If the alerts are not clearing as you expect, check the hysteresis settings.

About:

The about menu item is a list of helpful links concerning the MCP9808.

What’s not Illustrated:

I didn’t use the sleep and wake function in this application. It is illustrated in the test file in the UPM library.

What’s not implemented: 

There were a couple of things that I did not implement. First: The temp monitoring registers can be locked by setting bits in the config register. It takes a power cycle to unlock them so I didn’t implement this. The alert can be set to assert active high. I didn’t add this functionality either. If either of these capabilities are needed you can just make an MRAA call directly to the device to do so. If you need help with either of these just ask me in the comments.

 

Debug Node js remotely on Intel Edison with Jetbrains Idea

This blog post will demonstrate how to configure Jetbrains Idea (or similar product) to remotely debug Node js applications on an Intel Edison. Though I will use Edison for this post these instructions should work for remotely debugging most Linux targets running Node.

I’m a big fan of using Node js to power my IoT applications on the Intel Edison. It has a lot of advantages — ease of use (once you get used to the node way of doing things), support for mraa and upm,  and it is pre-installed. Intel even provides a decent ide to code it with – the XDK for IoT.

Jetbrains makes several ide products for various languages. Most will support HTML5 and Node js via a plugin. I find Jetbrains tools are fairly reasonably priced and more than pay for themselves in productivity gains vs other tools. (No, I don’t work for Jetbrains, I’m just a fan). For the remainder of this post when I refer to one of Jetbrains compatible products I’ll refer to it as JB.

The XDK for IoT is a fine tool, but Jetbrains’ tools are an order of magnitude better. With Intellij I get better HTML5 support, Javascript debugging and Node debugging right in the ide. I prefer the Jetbrains ide for the bulk of the coding I do.

To use JB we need to do a little configuring. First – make sure the Node js plugin  is installed.  Jetbrains has detailed instructions on installing plugins on their website.  You should go ahead and install the “Remote Host Access” plugin too — we will need that to transfer files later.

We will be using a ssh tunnel to forward our host Node debugger port (default 5858) to our Edison device. We have a choice of ports to use so we have the option of working with more than one Edison. We will use port 5858 on one Edison in this example.

So — to configure:

On the Edison:

Allow port forwarding: 

SSH by default does not allow remote hosts to forward ports so we need to enable it. Edit /etc/ssh/sshd_config and find the following line somewhere in that config file.

#GatewayPorts no

Change it to this:

GatewayPorts yes

Shutdown the app running in .node_app_slot. 

I generally start my IoT apps from one of the templates included with the XDK (I’m lazy that way). I will also go ahead and use the node_app_slot directory to upload it to. This keeps the apps XDK compatible. I then open the local project directory in JB and setup the configuration for the project.

The problem here is that the Edison will autostart the project on a reboot. This makes us have to take the extra step of starting up the XDK, connecting to the Edison and stopping the running project.

Reboot the Edison to ensure the changes to our files are picked up. If you have code in node_app_slot go ahead and stop it.

On our host machine:

Setup ssh tunnel for port 5858:

The magic that makes our remote debugging work is ssh port forwarding. For Windows users this can be set up with Putty as described here. Just skip to the Putty config part and ignore the rest.  For Linux and Mac users this should work:

ssh -f root@edison.local -L 5858:localhost:5858 -N

Where edison.local is your device mdns name or ip address. This starts the port forwarding session. We have to manage this manually. If we reboot our Edison we need to kill the current ssh tunnel connection and start a new one. To do this first run:

ps aux | grep ssh 

This will list all the currently running ssh process. We need to find the one that matches the signature of the tunnel. It is easy to spot — the output will be look like this:

This is the output of ps aux | grep ssh showing our ssh processes.

From the output we can see the process that matches our ssh tunnel. The process id is the first number from the right (on Mac any way) and is 8084 in this case. To end the connection we need to kill the process with this command:

kill 8084

Windows users will just close Putty. This connection will also be cleared after a reboot.

Create a remote Node debug configuration in JB:

This assumes you already have a project started. What I normally do is start the project using a template in XDK and then open it with JB. This keeps the code compatible with both applications.

In JB select Run/Edit Configurations. We will click the + button and select ‘Node.js Remote Debug’. Name it what ever you like and set it up like this:

Node-js-deployment

When we debug this app we will use this configuration. There is more info on setting up Node js configurations here.

Setup Deployment in JB:

JB will automatically upload our source files to the Edison via a deployment configuration. To access this Select ‘Tools/Deployment/Configuration’ from the JB menu. Click the + button in the upper left and create a configuration that looks something like this:

deployment-1-node-jb

To keep from uploading unwanted files setup some exclude paths (these are local paths):

deploy-exclude-node-jb

To enable autoupload select ‘Tools/Deployment/Automatic Upload (always).  Whenever we save a file in our project it will be automatically sent to the proper location on the Edison. More info on JB deployment settings can be found here.

Once we have the deployment setup, we upload everything to the Edison by selecting “Tools/Deployment/Upload to xxxxx”.  Select the option that works for you.

Now that we have everything configured we are ready to debug. To start the debugging session we first ssh to the Edison and start our app in debug mode like this:

node --debug-brk app.js

Where app.js is the file we want to debug. This will cause node to start up and pause. We then select “Run/Debug” from the JB menu and give the debugger a little while to connect to our target machine.

Then we simply debug and run the app with all the Jetbrains goodness.

References:

https://www.jetbrains.com/idea/help/running-and-debugging-node-js.html

http://stackoverflow.com/questions/8445534/how-to-remote-debug-node-js-with-phpstorm

http://blog.trackets.com/2014/05/17/ssh-tunnel-local-and-remote-port-forwarding-explained-with-examples.html

Updating MRAA and/or UPM on Intel Edison.

Update November 4, 2015

With the release of mraa 8.1 there is now support for Node. 4.X. Upm  4.0 now allows the installation of upm modules via npm. I have updated this post to account for the new capabilities of these libraries.

There is also the option of updating the libraries by using the XDK. Using version 2571 of the XDK for IoT select the device config drop down and click ‘Update libraries on board’. updata-lib-xdk

This has to be the easiest way.

End Upate.

 

This comes up for me quite often so I decided to add a post about it.

Here are some quick and easy to follow step for installing/updating MRAA and UPM on an Intel Edison. The Edison generally  has the prerequisites installed already so you should just have to compile. If you need more comprehensive instructions you can take a look at MRAA/UPM section of my Getting Started with Minnow Board Max post.

These instructions assume you have git installed. If not install git first following the instructions found here.

Install MRAA:

If we just want to update MRAA on an Edison we can use:

echo "src mraa-upm http://iotdk.intel.com/repos/2.0/intelgalactic" > /etc/opkg/mraa-upm.conf

opkg update
opkg install libmraa0

This will install the latest release version of mraa (8.1 as of 3 November 15) and would be the preferred way to go.  If you need something that is upstream from this release you will have to down load and compile the source.

The mraa library can also be installed by npm if you only want the Node js bindings. It’s as simple as this:

npm install mraa

How to install from source is described here:

First we need to clone the MRAA repo from git hub:

git clone https://github.com/intel-iot-devkit/mraa.git

This will download whatever the default branch and tag is currently set at (usually the latest). If you wanted to switch to another tag (like version 7.3 for example) now is the time to do so

Now we are ready to build. We will used the same out of tree build as described in the MRAA documentation.

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DBUILDSWIGJAVA=ON
make
make install

Details can be found on the mraa github page.

 

Install UPM:

Upm will be installed with mraa. If you have just installed the latest mraa you should have the latest upm also (4.0 as of Nov. 4, 2015).

As of version 4.0 upm can also be installed via npm. Of course you will only get the node bindings.  It’s as simple as:

npm install jsupm_<module-name>

If there are sensors in the upstream branch you want to use you will have to compile all or part of upm by hand as described here:

UPM can be cloned with the following:

git clone https://github.com/intel-iot-devkit/upm.git

Switch to the desired version (or just use the default). Ensure the version you select is supported by the version of MRAA that is installed.

Now is also the time to add any libraries that you need that are not currently in the release. Just add the directory of the driver to the /src directory with the required support files.

We will again be using the out of tree build as described in the documentation. Enter these commands to build and install:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr

If you want to only install a specific driver change to that drivers directory in build/src and then run:

make 
make install

If you want to install all of upm just run make and make install in the root of the build directory.

Building UPM on an Edison can take a while, so be patient.

That should do it. If there are no error messages you should be ready to utilize the new libraries.

Details can be found on the upm github page.

SSD1306 i2c UPM Library with the Intel Edison

UPDATE October 6, 2015.

The current version of UPM (4.0) includes this driver. However, UPM 4.0 requires MRAA 8.0. It is pretty simple to install both of these on your Edison. I have updated this guide to use the latest library.

End Update.

The SSD1306 is a very common display driver. There are tons of SSD1306 based devices to be found on Ebay and Amazon – some very inexpensive. Adafruit has several versions for sell that can easily be added to a Edison project. The main stumbling block to using these low cost displays has been the lack of an easy to use driver. Well that problem has been solved. I have recently contributed to the intel-iot-devkit UPM library an implementation of an i2c driver for this device. As of 1-Sept-15 I have been told it will be accepted and be available in the next release.

Why the UPM library? The UPM library provides a set of commonly used drivers that can be used in multiple languages. Each driver can be made available for C/C++, nodejs, java and python. The library I implemented is configured for all supported languages but only tested on C++ and nodejs. If someone uses the driver on java or python I’d like to hear about the results.

But what if we want to use the library in node before the next release? Well that is the topic of this blog post. We will go through the steps needed to compile the driver and install it on an Edison.

For C++ utilizing the driver is simpler than nodejs, python and java. All you need to do is add the source files to your iot dev kit project. The files needed are:

  1. hd44780_bits.h
  2. lcd.h
  3. lcd.cxx
  4. ssd.h
  5. ssd1306.h
  6. ssd1306.cxx

All are available in the repo  in the src/lcd directory. There is a C++ test file in the examples directory. (Make sure you are in the ssd1306 branch). If you need help configuring the iot dev kit check out this link.

If we want to use nodejs or one of the other languages we have a little more work to do.

As always, lets unsure we have the latest version of the Yocto on our system. To check your version login to your Edison and run the following:

configure_edison --version

You will need to be on version 159 to use this driver. If you need to update I find it is really easy to use the flash tool for Edison.

Once we are up to date we need to install git on our Edison. The instructions for installing git are here.

Install MRAA

Next we need to clone the MRAA repo from git hub:

git clone https://github.com/intel-iot-devkit/mraa.git

Change to the mraa directory and  checkout the 8.0 version.

git checkout tags/v0.8.0

Then we are ready to build. We will used the same out of tree build as described in the MRAA documentation.

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr 
make
sudo make install

Install UPM:

Change back to your home directory and run the following:

git clone https://github.com/intel-iot-devkit/upm.git

Then cd to the upm directory and checkout the 4.0 version with this command:

git checkout tags/v0.4.0

We will again be using the out of tree build as described in the documentation. Enter these commands to build and install:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr
make 
sudo make install

There is a test script for nodejs in my repo.  Simply load this up in the XDK and run it on your device. This script will run through all the functions available in the SSD1306 driver.

Installing the SSD1306 driver is a little complicated but not that difficult to accomplish. I hope these instructions make it easy for you do get this working. If you have problems feel free to let me know in the comments and I’ll see if I can help.

This should be considered the initial implementation of this driver. I have plans to add further functionality to the driver after I get a few other things done. I’d like to have the driver handle multiple display geometries (currently it only accommodates 128*64) as well and add some graphics drawing abilities. The current implementation is very functional though, and fits my requirements pretty well.

Scanning i2c bus 6 on Intel Edison

In a previous post I discussed using the LMSensors project programs to scan I2C buses on the Intel Edison. As I mentioned in that post, I only had luck scanning bus 1 on the Edison (which is only available on the mini breakout board).

Generally, when using i2ctools to scan bus 6 on the Edison the scan will run very slowly and no devices will be found. I have been a little confused by this in the past because occasionally I would find that I am able to scan the bus normally with those tools. I even went so far as to create a tool using the MRAA libraries to implement similar functionality with a Nodejs script. But I have found something interesting.

What I found was that i2c bus 6 is not configured when the system is started. If I have a node application running that uses i2c (which most of mine do) I find I am able to scan the bus with i2c tools without a problem. Also my tool — m2ctool — can serve to configure the bus so that it can be accessed by i2ctools.

To see what I am talking about try this:

  1. Start up your Edison and login. Ensure no programs are running.
  2. Enter the command i2cdetect -r 6. Press enter when prompted.
  3. The bus should scan very slowly and show no devices.
  4. Download and install m2ctool. See instructions on the read me to install.
  5. Enter the command m2ctool scan 6.
  6. The bus should scan normally and show any devices that are installed.
  7. Enter the command i2cdetect -r  6.
  8. The bus should scan normally and show any devices that are installed.

So if you need to probe i2c bus 6 on Edison but don’t have a program running that utilizes i2c, just run ‘m2ctool scan 6’ and then use i2ctools as you normally would. I have only tried this on Edison, I don’t know if this is true on other MRAA based systems.

The m2ctool has other features, I had intended it to stand in for i2ctools when dealing with MRAA based i2c buses. But given that all I need to do is initialize the bus by running a program once I could have saved myself a bit of work. For more info on m2ctool see the read me in the git hub repo.

Using a Rotary Encoder on Intel Edison, XDK

Rotary Encoders are supported by the UPM library. There is already example code that can be leveraged when we want to use one.  The code was created for the Grove Rotary Encoder but in reality we can use it for any rotary encoder we choose to implement. The Grove encoder  would be a good choice if you are using Seed Studio’s Grove Starter Kit. But that could be a problem if we wanted to use the encoder on and Edison project for the mini breakout board or wanted to access the switch in the encoder (you can not access the switch in the Grove Encoder). In my case, I intend to use the encoder to drive a menu for controlling an Edison on a mini breakout board. To accomplish that I will need to have access to the encoders built in switch so I will roll my on implementation.

Since we are going to use the Grove library for the encoder we will implement ours like theirs. If we look at the schematic for the Grove encoder we can see that it is not really that complicated.

Grove Encoder Schematic
Grove Encoder Schematic. Don’t connect  4 and 5 of the switch this way.

We can also see why the switch is not available on the Grove device – not enough pins available on the connector. (Though it does look like activating the switch will pull SIGA down, which we could look for in code. But the UPM library for this doesn’t have any provision for it.) We will wire up our encoder this way but we will wire the switch a little differently.

For the switch we will wire it so the we get a high value when it is actuated. So pin 4 goes to ground via a 10k pull down resistor and to the signal in for our Edison. Pin 5 will go to VCC.

So we need:

1     Encoder — I used these: 360 Degree Rotary Encoder w Push Button

1     Ceramic Disk 100 nf Capacitor (that is 0.1 micro farads, marked 104 on the cap).

4     3.3k Resistors. I used 2% 1/4 watt.  

And for the switch:

1     10k Resistor – also 2% 1/4 watt.

Optionally:

1     Arduino stackable header.  I plugged the encoder into this so it would fit in a breadboard better.

Wiring it up on a bread board gives us something like this:

Wired to a bead board side view
Side view
IMG_20150814_175210
Overhead view
Connected to an Edison Arduino.
Connected to an Edison Arduino board.

I used my Edison Arduino Board to prototype this, so the connections are:

SIGA —> D2

SIGB —> D3

Switch ( encoder pin 4) —> D4

VCC –> 3.3 Volts.

Don’t forget the ground connection.

The code to test this is pretty simple since we are using the UPM Libraries. We will use the Grove Rotary Encoder library for, of course, the encoder. We will use the Grove Button Library for our button functionality.

We will use socket.io to monitor our encoder with a webpage. Our server code looks like this:

//Setup express 
var express = require('express');
var app = express();
app.use(express.static(__dirname));
var server = app.listen(8085);
var io = require('socket.io').listen(server);



var mraa = require('mraa'); //require mraa
console.log('MRAA Version: ' + mraa.getVersion()); //write the mraa version to the Intel XDK console

//var myOnboardLed = new mraa.Gpio(3, false, true); //LED hooked up to digital pin (or built in pin on Galileo Gen1)
var myOnboardLed = new mraa.Gpio(13); //LED hooked up to digital pin 13 (or built in pin on Intel Galileo Gen2 as well as Intel Edison)
myOnboardLed.dir(mraa.DIR_OUT); //set the gpio direction to output

//Require the encoder and button libraries. 
var rotaryEncoder = require("jsupm_rotaryencoder");
var groveSensor = require('jsupm_grove'); 
// Instantiate a Grove Rotary Encoder, using signal pins D2 and D3
var myRotaryEncoder = new rotaryEncoder.RotaryEncoder(2, 3);
//Set up a button on D4
var button = new groveSensor.GroveButton(4); 
 
//We will send data to our client with this object. 
var data = {}; 

//When we get a socket connection we will monitor the switch. 
io.sockets.on('connection', function (socket) {
 
 //Every 100 milli seconds we will send an update to the client. 
 //You won't want to monitor encoder this way for a real project
 //but it will demonstrate the encoder and switch. 
 setInterval(function () {
 //See what the switch value is.
 readButtonValue(); 
 //Sample the current position of the encoder. 
 //Since this is an incremental encoder we will
 //get increasing or decreasing int values from 
 //the encoder library. 
 data.position = myRotaryEncoder.position();
 //For the porposes of this demo, if we go lower than -40
 //or higher than 40 we will reset the encoder init to 0. 
 if(Math.abs(data.position) > 40 ) {
 myRotaryEncoder.initPosition(0);
 data.position = 0; 
 }
 //Send the position in a json encoded string. 
 socket.emit( 'position' , JSON.stringify(data));
 }, 100);

 //Toggle the on board led on or off. 
 socket.on('toggle_led', function(data){
 if(data === 'on'){
 myOnboardLed.write(0);
 } else {
 myOnboardLed.write(1); 
 }
 });
 

});

//A fuction to read our button value
function readButtonValue() {
 //If our button is pressed set the 
 //encoder init to 0. 
 if(button.value() === 1 ) {
 myRotaryEncoder.initPosition(0); 
 } 
}
 


// When exiting: clear interval and print message

process.on('SIGINT', function()

{

 clearInterval(myInterval);

 console.log("Exiting...");

 process.exit(0); 
 
});

A Github repo with working code is located here.

When you load this on your Edison and browse to the web page it will look something like this:

Or demo page contains a gauge the reads from -40 t- 40.
Or demo page contains a gauge the reads from -40 to 40.

Rotating the knob on the encoder clockwise will increase the reading on the dial. Counter clockwise will decrease it. Activating the button on the encoder will reset the dial to 0. If we go below -40 or above 40 the dial will reset to 0. This code is based on the socket.io demo I posted about previously.

So there we have it. Using a rotary encoder in our projects will give us the ability to add controls with out the need of using potentiometers and switches. With an encoder we can implement multi-level menus to enable our end users to configure and control our devices even if they are not connected to wifi or a usb port. Implementing a menu such as this will be the subject of an up coming post.

Implementing the MICS-VZ-89T gas sensor on Intel Edison i2c

On my current project I have the requirement to monitor indoor air quality. What is of interest are the levels of Volatile Organic Compounds (VOCs) and CO2.  There are specific thresholds that we are looking for that when exceeded should trigger an action. For VOCs it is when the concentration is greater that 0.9 ppm. For CO2 it is when the concentration is 1000 ppm above ambient out side C02 — which is generally around 400 ppm. The links above out line the dangers of these indoor pollutants. When the threshold is reached we want to start the ventilation system and optionally message a user.

When I need a sensor my first choice is to find one that implements i2c. In this case I found a good candidate for the job in the SGX Sensortech MICS-VZ-89T. The VZ89 product is a small board with a MICS SMD device integrated with an i2c controller. The board comes in both 5 volt (VZ89) and 3.3 volt (VZ89T) versions that are are easy to implement using a logic level shifter with the Edison on a mini breakout board. (For an example of using a logic level shifter you can see my article Intel Edison and I2C sensors with XDK.)

There was no driver that I could find for implementing the board with my setup so I had to roll my own. This wasn’t too hard, but I did have to break out the logic analyzer to get it right. If we examine the MICS-VZ-89T I2C Specification page  we see that the device only has two commands. These are Set ppmC02 and Get VZ89 Status. According to the MICS-VZ-89T Data Sheet the device comes calibrated from the factory so we don’t need to implement Set ppmC02. That leaves us Get VZ89 Status. The code that follows here is available in an XDK project on git hub.

To read the status we have to perform a two step process. First we write a command byte of 0x09 to register address 0x70. We follow this by writing two data bytes to the same register. I write 0x00 twice.

We then read 6 bytes immediately after writing the command byte. The bytes are decoded as follows:

Data byte 1 = CO2-equivalent value. 
Data byte 2 = VOC_SHORT value. 
Data byte 3 = VOC_LONG value 
Data byte 4 = Raw sensor 1st byte (LSB). 
Data byte 5 = Raw sensor 2nd byte 
Data byte 6 = Raw sensor 3rd byte (MSB).

To implement the functionality I created the following class in a node module:

//Import mraa 
var mraa = require('mraa');

//Constructor -- set defaults and populate tx_buf
function VZ89(bus , address){

 this.bus = new mraa.I2c(bus || 1); 
 this.bus.address(address || 0x70); 
 
 this.tx_buf = new Buffer(3); 
 this.tx_buf[0] = 0x09;
 this.tx_buf[1] = 0x00;
 this.tx_buf[2] = 0x00; 
 
}

//Add a function to get the device readings. 
VZ89.prototype.getReadings = function() {
 this.bus.frequency(mraa.I2C_STD);
 this.bus.write(this.tx_buf); 
 return this.bus.read(6);
 
};
//Export as a node module 
module.exports = VZ89;

The MRAA library is used to access the i2c bus, so it is imported at the top or the file. There is a constructor that optionally takes a bus number and a devices address. The VZ89 is addressed at 0x70 so we don’t really need to change that. If the Edison mini-breakout is used we have a choice of busses. I have set this to bus 6 as I am using the Edison Arduino for this example.

A class function is added to implement named getReadings to perform the measurements and return data from the device. In this case the buffer is passed back to the calling program for use.

To use the class the code in the server file would look like this:

//Import our sensor file from the file system
var Sensor = require('./VZ89.js'); 
//Create an instance of the sensor object. 
var sensor = new Sensor();
//Create a var for the receive buffer.
var rx_buf; 

//Call the readBuf function every minute. 
setInterval(readBuf , 60000); 

//A function to read the sensor data, perform data conversions and display on the console every minute.
function readBuf(){

    rx_buf = sensor.getReadings();
 
    console.log("Co2_equ: " + ((rx_buf[0] - 13) * (1600/229) + 400) + " ppm"); 
    console.log("VOC_short: " + (rx_buf[1])); 
    console.log("tVOC: " + (rx_buf[2] * (1000/229)) + " ppb"); 
    console.log("Resistor Value: " + 10 * (rx_buf[3] + (256 * rx_buf[4]) + (65536 * rx_buf[5])) + " ohms"); 
}

The details of converting the rx_buf data to usable values are in the data sheet.  The ones we are most interested in are Co2 equivalent (rx_buf[0]) and total VOC (rx_buf[2]).

As you can see, the MICS-VZ89T is a pretty easy to use device once you know how. There are only a couple of gotchas to be aware of. First, the device can only be polled once a second. I find if I try to get the readings faster than that the device will return nulls. Secondly, care must be taken when handling the device. It contains organic material that is susceptible to solvents.

Intel Edison and I2C sensors with XDK

The Intel Edison is becoming a popular system to use for IOT devices. Despite its small form factor it is a surprisingly capable platform. This makes the Edison a good choice for interfacing with sensors.

I like the Edison mini breakout board over the Edison kit for Arduino because of the form factor. The  mini breakout board provides USB connectivity, power input and a battery charging circuit to the Edison that covers most the of my requirements for devices.

The drawback of the mini breakout is that you need to either solder in some wires or add a header to the break out board to access i/o for the Edison. Also, the Edison I/o on this board operates at 1.8 volts while most sensors operate at 3.3 volts or higher so a level converter is needed.

The Intel Edison, on the mini breakout, supports various types of i/o but the one we are interested in today is I2C  Inter-Integrated circuit is a two wire serial protocol that is used by components to transfer data between one-another. On the mini-break out board we will be using I2C bus number 1.

Here the Edison is connected to a breadboard containing the MCP9808. There are other devices on the board.
Here the Edison is connected to a breadboard containing the MCP9808. There are other devices on the board.
Here is one way to make the i/o needed for connection available.
Here is one way to make the i/o needed for connection available.

Parts list:

  1. Intel Edison mini breakout board kit.
  2. Sparkfun bi-directional level shift converter.
  3. Adafruit MCP9808 temperature sensor board.
  4. Mini bread board.
  5. Solderless bread board jumpers. 
  6. Dupont male to female cable. 
  7. 90 degree dual row header. 

Items 6 and 7 are optional – you could just solder some wire onto the Edison if you prefer, or use some other type of pin headers.

Connection:

Edison                     Level Shifter                     MCP9808

J17  – 8                          LV1

NC                                 HV1                                  SDA

J18 – 6                           LV2

NC                                HV2                                   SCL

JP19 – 2                         LV — 1.8 volt

JP20 – 2                         HV — 3.3 volt                   VDD

JP19 – 3                        Both grounds                  Ground

The connection looks something like this. The level shifter and MCP9808 are in the center of the yellow board.
The connection looks something like this. The level shifter and MCP9808 are in the center of the yellow board.

With this connection we are ready to code.

I will be using the Intel  XDK IOT edition  to read values from our temp sensor. If you have not used the XDK you can learn how to get started here. Just create a blank project and paste the following code in. Running the code will display the temperature in the console every second.

function char(x) { return parseInt(x, 16)}; // helper for writing registers

var mraa = require('mraa'); //require mraa
console.log('MRAA Version: ' + mraa.getVersion()); //write the mraa version to the Intel XDK console

var x = new mraa.I2c(1); //We will use a device in I2C bus number 1
x.address(0x18); //Default for MCP9808 is 0x10

//x.writeWordReg(char('0x01'), char('0x0100')); // Controls sleep mode for the temp sensor.

periodicActivity();

function periodicActivity()
{

var t = x.readWordReg(char('0x05')); // 0x05 is the register for the current temp.
//The byte order of words is not the same between Edison and the MCP9808
//The edison stores the most significant byte first - big endian, where the
//MCP9808 stores the lowest byte first -- little endian.
//Here is a wikipedia article on endianness. 
var s = ((t & 0xFF) << 8) | ((t >> 8 ) & 0xFF); //swap the bytes.
var r = s & 0xFFF; // Mask of the control bits to get the temp value
r /= 16.0; // dividing by 16 will give us the temp in celcius as long as the temp is above 0.

s = r * 9 / 5 + 32; //get the farenheit value.

console.log(r + " C " + s + " F"); //log the values

setTimeout(periodicActivity,1000); //do it again in a second.
}

For a more thorough explanation of the MCP9808 control registers see it’s data sheet.

And there we have it. It is not a very complex thing to interface an I2C sensor with the Intel Edison. We just need to use a level shifter and connect the thing up. Using the XDK it is fairly easy to read the temp data and control the MCP9808. The complexity comes in when more complex devices are integrated. It can take some time studying the data sheet of a device to figure out how to get everything working correctly.

There are other options for interfacing with I2C and other devices, but MRAA is the easiest in this case as it is already installed. If our sensor had been in the UPM library we could have used a predefined class to operate it.