Sending sensor node data to the cloud

This post describes how you can send data from one or more WiSense sensor nodes to the cloud (Xively.com).   You need the following equipment.

  1. A Laptop (Linux or Win/Cygwin)
  2. A WiSense node running in coordinator mode (LPWMN coordinator)
  3. One or more RFDs (reduced function devices) whose data needs to be sent to the cloud. Theses nodes will usually be coin cell (3V / CR2032) powered.
  4. One more FFDs which will provide connectivity between the coordinator and the above mentioned RFDs. These FFDs are not required if the RFDs are just 1 hop away from the LPWMN coordinator.
  5. A serial to USB converter which connects the coordinator node to the laptop.  Let us assume that this converter also provides power to the coordinator node (between 2.5 and 3.3 volts).

The basic development kit from WiSense includes the following –

  1. One WiSense node pre-configured to run as a LPWMN coordinator
  2. One WiSense node pre-configured to run as an RFD.
  3. One Serial to USB converter which can also power the LPWMN coordinator
  4. One TI MSP430 programming tool

WiSense sensor nodes come equipped with two external sensors. One is the LM75B temperature sensor. The other one is an ambient light sensor (TSL45315). In addition, the MSP430 microcontroller (on the controller board) can measure it’s voltage supply using the internal 10 bit ADC. The RFD in the basic kit runs an application which sends the output of these three sensors to the coordinator node once every 10 seconds.

Each WiSense node has a fixed 64 bit extended address. For example  “0xfc : 0xc2 : 0x3d : 0x0 : 0x0 : 0x0 : 0xf7 : 0xe5”. This address is stored on each RF board. When a node joins a network, it gets a 16 bit “short address” from the LPWMN coordinator.

To send data to Xively.com, you first need to create a “free” Xively account. Once you are logged in, you need to do the following –

  • Create a device (one per sensor node). Assuming you have two RFDs sending data in your LPWMN, you can name these two devices as “node_1” and “node_2”. You are free to choose any name.
  • When you create a device, note down it’s API key and feed id.  API key will look like “vOaWv1yA3WxC4Eer7xiEHY08OaCkhLFbbOePwW1Afj14VciM“. Feed id  will look like “1497366549“.
  • Now, you need to create three channels (one channel per sensor data stream) to handle the data from the three sensors on an WiSense sensor node.  Let us name the light sensor channel as “ALS_TSL45315_1”, the temperature sensor channel as “Temp_LM75B_1” and the voltage sensor channel as “Vcc_MSP430_1”.  Note that the channel name is also it’s id. You need to fill in some more info such as the description (tag) of the channel, units and symbol.

.

xively_1

.

.

.

.

.

.

.

.

.

xively_2

.

.

.

.

.

.

xively_3

.

.

.

.

.

  • The next step is to configure the Xively interface code which runs on the laptop. This code runs as a Linux app which reads data forwarded by the LPWMN coordinator and sends the same to Xively.com using the Xively API. The only file which needs to be changed is “datastream_update.c” in xively/src/examples”.  You need to update the array “GW_xivelyInfoList[ ]” with one entry per sensor node (or Xively device).  This array helps in mapping a WiSense node to its corresponding Xively device. Further, it maps each sensor on the node to it’s corresponding Xively channel. You can see three entries in the sensor list (one per sensor on the node). The first column is the sensor’s id and the second column is the Xively channel id.

GW_xivelyDevInfo_s GW_xivelyInfoList[ ] =
{
// Node/Device – fc:c2:3d:0:0:0:f7:c3
{
“Node_1”, // Xively device name
{0xfc, 0xc2, 0x3d, 0x0, 0x0, 0x0, 0xf7, 0xc3}, // Node’s 64 bit extended address
vOaWv1yA3WxC4Eer7xiEHY08OaCkhLFbbOePwW1Afj14VciM“, // Xively device API key
411445145“, // Xively feed
{
{0x09, “Temp_LM75B_1”, GW_XIV_CHANN_DATA_TYPE_INT_32}, // Temperature
{0x12, “ALS_TSL45315_1”, GW_XIV_CHANN_DATA_TYPE_INT_32}, // Light sensor
{0x78, “Vcc_MSP430_1”, GW_XIV_CHANN_DATA_TYPE_FLOAT_32}, // Node Vcc
{0x0, “”, GW_XIV_CHANN_DATA_TYPE_NA} // end of list
},
NULL
},
};

  • The data structure shown above is included by default in the file “datastream_update.c”.  You need to replace the API key and feed id with the values assigned to your device when you created it. If you have more than one sensor node, add one entry for each extra node.
  • You are ready to start sending data. Compile and run the app “datastream_update”. Connect the coordinator node to the laptop using the UART <-> USB converter. Power up the coordinator and then power up all the RFDs in your network (and any FFDs if required). All the RFDs should join the network within a minute. All the RFDs will then start sending sensor data periodically to the coordinator which will in turn forward all these messages to the laptop. The app “datastream_update” will read all these messages and post the encapsulated sensor data to Xively.com.  Each message received by this app contains the 16 bit source address of the RFD which sent the message. How does the app map a received message to it’s corresponding Xively device ? When a WiSense node joins the network, the LPWMN coordinator sends a “node registered” event to the app “datastream_update” containing two pieces of information. One is the 64 bit fixed address of the node which has joined and the second is the 16 bit short address assigned to this node. The “datastream_update” app now has a mapping of the node’s short address to its fixed 64 bit extended address. The “GW_xivelyInfoList[ ]” data structure maps each sensor node to it’s corresponding Xively device using the 64 bit extended address. When an RFD sends a sensor data message to the app, the latter maps the node’s short address to it’s 64 bit extended address and finally to the Xively device corresponding to this RFD. The app then parses the received message and extracts all the sensor data. For each sensor, the message contains the sensor’s id (an 8 bit number) and it’s data. The app is able to map the sensor to it’s corresponding Xively channel using the “GW_xivelyInfoList[ ]” entry of the sensor node/device.  For example, the device id of the LM75B temperature sensor is 0x9. For each sensor id, the app uses an Xively API to post the sensor’s data to Xively.com.

Posted on January 30, 2014, in Uncategorized. Bookmark the permalink. 3 Comments.

  1. What is the role of 64 bit addresses assigned to each node?

  2. I understand that until 16 bit address is assigned to the node it will use the longer fixed address to talk to the coordinator node. Once the 16 bit is assigned then it will that address for all further communication. Using shorter address reduces the per packet overhead. Is this the correct understanding?

  3. Hi Bhupinder,
    The 64 bit fixed address is the permanent id of a node. Short addresses are allocated temporarily. You are right. Short addresses reduce packet overhead.
    Ram

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: