Monthly Archives: January 2014

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.
Advertisements

Hardware update –

We got another version of the boards this week. The basic design is the same. We decided to use 2×6 connectors instead of 2×10 to save on cost. These are high quality stackable connectors from Samtec. These are easier to insert and remove compared to the 2×10 connectors.

We also added two sensors to the RF host board. One is a temperature sensor (LM75B) and the other is an ambient light sensor (TSL4531).

We added a coin cell retainer to the bottom of the RF host board.  You can  use a standard 3.3 V, 20 mm coin cell to power the node.

The boards now have 4 mounting holes on the corners. These are 4 mm in dia. As you can see in the pics below, 4 standoffs provide a stable base to the nodes and protect the connector pins.

.

.

Sensor node with chip antenna

chip

 

 

 

 

 

 

 

 

.

.

Sensor node with whip antenna

whip

.

You can see the coin cell retainer holding a coin cell in this pic below.

coin_cell_view

Another update on the live feed from WiSense node

The live feed has been continuously running for 7 seven days now. The node on the terrace is solar powered. The solar cell trickle charges a NiMH button battery during the day. The node is sending temperature and battery voltage data to the gateway node every 5 seconds. You can see the live feed at https://xively.com/feeds/84250669.

seven_day_avg

 

 

 

The graph above shows the  temperature variation over 7 days.  There are some gaps in the data because of frequent power cuts in our area.

The solar cell is a “KXOB22-04X3” from IXYS.

  • Size – 22 mm x 7 mm
  • Voltage (open circuit) – 1.89 V
  • Current (short circuit) – 15 mA
  • Voltage (at max power output) – 1.5 V
  • Current (at max power output) – 13.38 mA

This solar cell produces a lot of power given it’s small size. As a result it does not come cheap.

The rechargeable NiMH battery is a “V80H” from Varta.

  • Nominal output voltage – 1.2 V
  • Usable capacity – 80 mAh
  • Weight – 4 grams
  • Diameter –  15.5 mm
  • Height – 6 mm
  • Charging
    • Normal –  7 mA for 14 – 16 h
    • Accelerated – 14 mA for 7 – 8h
    • Trickle – 2.1 mA

The battery output is around 1.2 V – 1.3 V which is then boosted by a DC-DC converter to around 2.5 V which is good enough for all the components on the node. The MSP430 and the radio (cc2520) have a minimum voltage requirement of 1.8 V. The temperature sensor needs at least 1.4 V. The DC-DC converter is a TPS61200 from TI. It has programmable under voltage lockout threshold function prevents the output from being supplied if the input voltage falls below the configured threshold value. This allows the solar cell to charge the NiMH battery if the latter is deeply discharged.

I will go into the details of the node’s power consumption / energy budget in another post.

The picture below shows the solar powered node on the terrace. I have removed the cardboard box which covers all the components leaving only the solar cell exposed to sunlight.  We will be building a pluggable board for the solar cell, battery and the DC-DC converter.

solar_node

WiSense Blog Goes Social

WiSense blog at WordPress is now linked with Facebook and Twitter. Visitors can now Like us or Follow us via these channels:

Please note that to access any Facebook page, you should have a Facebook personal account and be logged in.

Writing a simple app for a reduced function device (RFD)

A reduced function device (RFD) is usually battery powered and does not participate in routing. It sends and receives data/control packets through it’s parent node. The parent node is either the network coordinator or a fully functional device (FFD). Since RFDs are battery powered, they need to stay in low power mode most of the time and waking up only if it is absolutely necessary.

rfd_arch

 

 

 

 

 

 

 

 

Let us look at the implementation of a simple app which runs on a RFD.  I will start off with the requirements.

Sensing 

The requirement is to poll the ambient temperature every 5 seconds and send this values to the web (xively.com).  The temperature sensor is a TMP102  from TI. The MSP430 talks to this sensor over I2C.

Power

The RFD will be powered by a non rechargeable 3 V Lithium coin cell battery. This implies that energy consumption has to be kept as low as possible. The supply voltage requirement for the components on the RFD is –

  • Micro – MSP430  (1.8 V to 3.6 V)
  • Radio – cc2520 (1.8 V to 3.8 V)
  • Sensor – TMP102 (1.4 V to 3.6 V)

A 3 V Lithium coin cell is perfectly compatible with all these components.  There is no need for a DC-DC converter and the coin cell can directly power the board.  As the coin cell gets used up, its output voltage will drop. The  The RFD will be able to able to use up the battery capacity almost completely since the minimum voltage requirement for all the components is 1.8 V or less. Most coin cells are completely drained by the time their output drops to around 2.5 V.

Let us now look at the power consumption of these three components.

MSP430 -The WiSense stack  configures the MSP430 to run at 8 MHz (in active mode).  At this clock rate and at a supply voltage of 3.0 V, the MSP430 consumes around 2 mA . In low power mode (LPM3), the MSP430 consumes around 0.7 microamps. Our application should ensure that the MSP430 spends as much time as possible in LPM3.

TMP102 This sensor consumes a maximum of 10 microamps (even at Vcc of 3.6 V) when it is actively sensing (also called conversion). The sensor supports a shutdown mode in which it consumes less than 1 microAmp. Note that in shut down mode, the TMP102’s I2C interface remains active. We will ignore the energy consumed due to activity (logic transitions) on the I2C bus.

cc2520 – The radio consumes around 26 mA when transmitting at a power output level of 0 dBm. At +5 dBm, the current consumption increases to 33.6 mA. When the radio is receiving a packet at an RSSI of around -50 dBm, it consumes around 18.5 mA.  The WiSense stack puts the radio in its low power mode 2 (LMP2) when requested by the app. In this mode, the cc2520 consumes less than 1 microamp. Clearly, the radio is the most power hungry component on the board. It is really important to keep the radio in LPM2 as much as possible. The software should switch the radio on only when it is ready to send or receive and immediately put the radio back to sleep.

Log battery voltage

Since the RFD is battery powered, we will add another requirement. The RFD needs to report the battery voltage  aloneng with the ambient temperature. This information will allow us to track the RFD’s energy consumption and make sure it is as expected. Further, we will know when to replace the battery.

The battery voltage will be measured using the MSP430’s on board Vcc  conversion channel (Channel #  11 in the ADC10 module).  This channel can be used since the battery powers the micro directly. If there is a DC-DC converter in the middle, we would need to dedicate a port pin to measure the battery voltage.

I will look at the app in detail in another post. Stay tuned.

References:

Using sensor networks to speed up accident response

On Sept 29th, twenty six people died  when an air conditioned coach of the Bangalore-Nanded Express caught fire.

According to the media, Indian Railways is cash strapped. It cannot afford expensive fire fighting equipment. The other major problem is maintenance. Even if expensive equipment is installed, poor maintenance will render the equipment useless within a short time. Indian railways transports over 25 million people daily. Shouldn’t it be the world leader in railway technology and related aspects such as safety, accident response etc by now ?  The only thing which has changed over the years is that the passengers these days have expensive smart phones. You would not know it is 2014 otherwise since our trains are still as filthy and unsafe as ever.

There is scope for cheap low power wireless sensor networks to help in quickly detecting fires and relaying the information to the train driver and other personnel.  In the event of a fire on a moving train, it is really important to stop the train since air movement helps spread the flames. On a moving train the fire can quickly move from one coach to another. Further, passengers can get killed or seriously injured when jumping out of a moving train.

In India, trains have an alarm chain which can be pulled to stop the train. This mechanism is prone to failure. In this particular accident, the passengers were not able to alert the train driver to the fire. Quoting the Indian express – “Though the attempt to halt the train failed, it was a call by a passenger to the Bangalore control room that saved many lives. The officials at the control room alerted their counterparts at Puttaparthi, who notified the driver “.  Imagine if the train had caught fire in the countryside outside of cellular network coverage.  Lot more lives could have been lost.

A simple low power wireless network can be installed on trains to notify the driver. This can be used alongside the existing chain system. As a first step, low power wireless nodes can be installed on the roof of every coach.  This network of nodes can relay an alarm message in a matter of seconds to the train driver.  Since the radio on these nodes will be active all the time, these need to be solar powered.  Wireless alarm buttons can be installed inside a coach in different places. These battery powered alarm buttons will then communicate with the nodes mounted on the roof. The latter will relay the alarm to the driver. Since low power wireless nodes can be really cheap in volumes, the roof top network can have a high degree of redundancy to make sure that any alarm message always makes it to the driver. To cut down on misuse, the alarm button can be equipped with a camera which can help in identifying the person who pressed the alarm button.  The next step will be to install wireless sensor nodes equipped with different sensors for measuring temperature, humidity, carbon monoxide, carbon dioxide etc. These sensors will keep monitoring the environment in the coach and raise an alarm in the event of a fire. The roof top network can then relay the alarm to the driver. If the train is equipped with GPRS / satellite links etc, the alarm can also be sent out.

The problem with the chain system is that the driver does not know if there is a genuine problem or not. Train drivers even disable the alarm system when passing through areas prone to misuse of the alarm system. When sensors are deployed inside coaches, the driver will have enough information (smoke, temperature etc) to decide on the course of action. One more advantage is that the wireless sensor network can periodically self test to make sure all coaches are being monitored properly.

The sensor nodes inside the node need to be recharged periodically (once in a few months). Theses sensor nodes can be made available for purchase to the general public.  Passengers can bring their personal sensor nodes on the train and switch them on  at night before going to sleep.  The personal sensors will join the train’s network. At the end of the journey passengers take their personal sensors with them. Sensor nodes can optionally have a bluetooth interface and can use this to send alarms to all cell phones within range. Cell phones can then wake up the passengers as well as send information to the railway authorities using the cellular network if it is available at that time/location.

Reference:

http://www.irfca.org/faq/faq-ops2.html

http://www.newindianexpress.com/nation/26-Killed-as-Train-Catches-Fire-in-AP/2013/12/29/article1970664.ece

http://www.thehindu.com/todays-paper/tp-in-school/get-serious-on-safety/article5531327.ece

http://www.thehindu.com/news/cities/Hyderabad/railways-illequipped-to-tackle-fires/article5520010.ece