Monthly Archives: December 2013

Update on the live feed from WiSense node

I let the sensor node send data to xively for a couple of days and noticed a couple of unexpected trends in the data. One was the drop in battery voltage during the night and subsequent rise in the morning. We expect the voltage to keep dropping as the battery discharges but the data showed a rise in voltage of around 0.2 to 0.3 volts. One explanation can be the  rise in the battery’s internal resistance with drop in ambient temperature.  The other trend was abnormally high temperature reading from the MSP430’s on board temperature sensor. The sensor was reporting around 40 degree celcius around noon. I moved the node around and saw the temperature drop and then climb back to more than 40 degree celcius. Surprisingly, the sensor was tracking the night time temperature well.

I replaced the Maxell coin cell  with a Sony coin cell. I also interfaced an external temperature sensor (TMP102) to the sensor node. This is a high accuracy (0.5 deg C) sensor with I2C interface. The sensor has a current consumption of less than 1 micro-amps in shutdown mode. The sensor stays mostly in shut down. Every 5 seconds, the app layer on the RFD node triggers a single temperature conversion during which the TMP102’s power consumption increases to around 10 micro-amps. The conversion takes around 26 milli-seconds after which the TMP102 goes back to shut-down mode. The node is now reporting the TMP102’s data to Xively.

I also measured the sensor node’s current consumption . It  is around 1.2 micro amps when the micro (MSP430), the radio (cc2520) and the temperature sensor (TMP102) are all in low power mode.  The node is sending data to the coodinator/gateway once every 5 seconds.

Snapshot of data streamed to Xively.com

xively_snapshot

Live sensor data feed from a WiSense node

You can see temperature and voltage reported by a WiSense node in real time here – https://xively.com/feeds/84250669.

The sensor node is located on the terrace.  It is operating in reduced functionality mode (RFD) and reporting the ambient temperature and the battery voltage. The temperature sensor is on board the MSP430G2955. The battery is a lithium coin cell (CR2032 from Maxell). The node is reporting both values every 5 seconds and it is two hops away from the network coordinator (located in my home office). The latter is connected to a Linux laptop through a USB to serial converter. The sensor data is being sent to the coordinator which forwards it over the serial port connected to the Linux laptop. A simple Linux app is reading the data from the serial port and posting to Xively using a “C” library API provided by Xively. You can download the library (libxively) here –  https://github.com/xively/libxively.

Xively is really easy to use. I was sending data to Xively within an hour of signing up for a developer account.

I created one device (Terrace_1). Every device has exactly one “feed” associated with it. A feed is a collection of channels (data streams) and associated metadata. This device “Terrace_1” has two channels. One channel reports the ambient temperature. This channel’s id is the string “TempSnsr_msp430”. The other channel reports the battery voltage. This channel’s id is the string “battVoltage”.

 

WiSense RFD  (source of temperature and voltage data)

rfd_terrace_pic

 

 

 

 

 

 

 

 

Router node (also on the terrace) relaying data between the RFD and the coordinator

router_terrace_pic

WSN application – networked solar lamps

I live in Bangalore. We have been suffering frequent power cuts this week.  I have couple of solar table lamps from Ikea . They have a detachable solar panel, led light source  and 3 rechargeable batteries (NiMH / NiCD).  I leave the panels in the sun and they are good to go after a full day’s charge. You can place these lamps anywhere since they don’t have a power cord. On the flip side, if a power cut leaves you in the dark, how do you switch these on ?

I would like these lamps to be intelligent. Whenever power goes in the evening, the lamp should switch on automatically  and switch off when power is restored.  This can be done by adding a low power wireless node to the lamp (call it L).  Another wireless node (call it M) can monitor the mains.  M can be battery backed or have a large enough capacitor which can power the node while it broadcasts a “power failure” message to the mesh network before shutting down.  Any “L” node which receives this message can switch on it’s lamp.  “L” can use time of day information and/or ambient light sensing to decide whether to switch on the lamp or not.  Similarly, when mains power supply is restored, the “M” node will broadcast a ” power restored” message.  Any “L” node which receives this message can switch off it’s lamp. The mesh network mentioned above is a network of wireless nodes covering the whole house.  Once a lamp has a radio interface, it can be switched on/off through a smart phone provided there is a Wi-Fi <-> low power sensor network gateway in the residence.

Such requirements are common to developing countries such as India where public infrastructure such as the electricity grid and roads are not in good shape. Fortunately, there is technology to compensate (to some extent) for bad governance.

Reference: http://www.ikea.com/us/en/catalog/products/90154371/

Hardware update – stacking boards

WiSense hardware architecture supports stacking. A typical stack will have these boards –

  • A single micro-controller board (MSP430G2955 or MSP430G2553)
  • A single radio board (Chip antenna, Whip antenna or PCB antenna)
  • One or more sensor boards
  • One battery board with rechargeable coin/button cell and associated with DC-DC converter (if required) and solar cell connector.  The other option is a simple 3 Volts Lithium coin cell.

We recently built and tested our first stacked node with two boards. One is a controller board with the MSP430G2955. The other is a radio board with a chip antenna. The MSP430 talks to the cc2520 transceiver over the SPI bus and a few GPIOs.  This SPI bus is available to all boards in the stack (not just the radio board) . For example, we can plug in a sensor board equipped with the  “MPL115A1” barometer sensor. This sensor has an SPI interface.

All “stackable” boards have two 2×10 self nesting connectors. The boards can be plugged in any order (radio board on top of the controller board or vice versa).

 

Radio board with chip antenna

rf_board_to

 

 

 

 

 

 

 

 

 

Controller board (top side)

controller_top

 

 

 

 

 

 

 

 

 

 

Controller board (bottom side)

controller_bottom

 

 

 

 

 

 

 

 

 

 

Stacked node (radio board plugged into controller board)

stackable_boards

Hardware update – new boards

We are testing three types of radio boards. All three are based on the TI cc2520 802.15.4 transceiver. The difference is the type of antenna used. The approximate range in the open (at 5 dBm power output) is more than 100 meters for the PCB and chip antenna versions and almost 200 meters for the whip antenna board.

Cost comparison : Whip antenna > Chip antenna > PCB antenna

Size comparison: Whip antenna > PCB antenna > Chip antenna

Range comparison: Whip > PCB antenna > Chip antenna

 

RF board with PCB antenna

rf_board_pcb_ant

 

 

 

 

 

 

 

 

 

 

RF board with chip antenna

rf_board_chip_ant

 

 

 

 

 

 

 

 

 

 

RF board with whip antenna

rf_board_whip_antenna

Hardware update – new radio board

We got the radio board assembled and mated to the controller base board. The radio board measures 27.5 mm by 27.5 mm. It has an external antenna (reduced height 1/4 wave monopole whip). The radio transceiver is the IEEE 802.15.4 compatible cc2520 from Texas Instruments. This transceiver requires a 32 MHz external crystal.

The pic below shows the radio board soldered to the controller base board through two 1×7 2.54 mm pitch headers.  Another alternative is to solder the radio board (through the two 1×7 connectors) to a dummy base board and plug this dummy base board on the controller base board. This allows you to interchange the controller and radio boards.

rf_msp_ed

 

 

 

 

 

 

 

 

 

 

 

rf+msp+exp

WSN application – monitoring water consumption

This is another low hanging fruit in terms of finding applications of sensor networks in residences.

We waste water when we leave taps on.  We need a sensor which can determine how much water is flowing out of a tap and raise an alarm if too much water is being used or wasted. One can get a rough idea of how much water is being used by determining the extent to which a tap is open. This can be done by using a rotary encoder.

I have a “Wil Pillar” tap from American standard.  This tap is more suitable to this idea compared to other taps.  The tap handle needs to be turned horizontally to open or close the  tap.  If we can attach a rotary encoder to the shaft below the handle, then we will know exactly to what extent the tap is open.

wil_pillar_tap_pic

 

 

 

 

 

 

Wil Pillar Tap from American Standard

 

tap_profile

 

 

 

 

 

 

 

 

 

Technical drawing (Wil Pillar Tap).  All dimensions in mm.

 

A rotary encoder can give the angular position of a shaft relative to a fixed start position. There is a lot of information on the web on how to choose  a suitable encoder.  Here is one “http://www.digikey.com/us/en/techzone/sensors/resources/articles/motion-sensing-via-rotary-shaft-encoders.html“.

We need a simple, low cost and low profile encoder with enough resolution. It will be really nice if it can work at 3.0 volts or below and has a simple interface (logic / i2c / spi / uart etc).

The next step is attaching the encoder to a tap like the one shown above.

 

tap_with_belt_node

 

 

 

 

 

 

Tap with attached Encoder + Wireless node

 

In the figure above, I have shown one way of attaching the tap’s shaft to a rotary encoder. The tap’s shaft rotates along with the handle. A timing belt can be used to couple the tap’s shaft to the encoder’s shaft. You may need to glue a plastic sleeve to the tap’s shaft so that the belt does not slip. When the tap is opened or closed, the encoder’s shaft will rotate allowing it to determine the extent to which the tap is open.

Next – Write the code (which will run on the micro) to interface with the encoder. The software design has to make sure that power consumption is kept to a minimum. Depending on the encoder, the software may need to poll the the encoder to determine if the tap is open or not. We may have to use a limit switch to wake up the micro whenever the tap is opened. It all depends on the encoder.

References:

http://www.americanstandard.in/Category/Fittings/Wil-Deck-Mounted-Kitchen-Tap/213/

Hardware update – MSP430G2955 board

We got a few PCBs of the stackable version of the controller board. Today we assembled and tested two boards. This version of the controller board is populated with –

  • An MSP430G2955 (16 bit micro from TI’s value line series)
  • An AT24MAC602 (2 kb serial eeprom, 64 bit MAC/EUI and 128 bit serial number)
  • A 32 KHz crystal
  • 2 LEDs
  • Two stackable (self nesting) 2×20 connectors
  • Two 1×7 connectors for the radio board
  • 3 pin right angled UART connector (rx, tx and gnd)
  • 4 pin rigjt angled SPY-BY-WIRE connector (vcc, gnd, tdio and tck)

100_0956

 

 

 

 

 

 

Top view

 

100_0957

 

 

 

 

 

 

 

Bottom view

 

The MSP430G2955 is a 38/40 pin device with 4 KB RAM and 56 KB of flash.

The WiSense sensor-actuator network protocol stack is built on top of 802.15.4. This protocol requires each node to have a unique 64 bit IEEE assigned “extended” address. The AT24MAC602 provides this address. According to the device data sheet, each AT24MAC602 contains a unique IEEE-provded 64-bit pre-programmed MAC/EUI address to enable a connected device to connect to the Internet or local network.

The 32 KHz cystal provides a high accuracy clock to the micro. In addition, it allows the MSP430 to use  low power mode 3 (LPM3) when it wants to sleep. In this mode, the micro’s power consumption is less than 1 micro-ampere. It is so low because (in LPM3) the CPU and all internally generated clocks are off.  The micro can only be woken by an interrupt (including interrupts from on-board peripherals such as timers).  The on board timer modules remain active in LPM3 if they are clocked by an external clock. This allows the micro to start a timer and then go to sleep in LPM3. When the timer expires, the corresponding interrupt from the timer module will wake up the micro out of LPM3. LPM3 is essential for implementing reduced function nodes (RFNs) which need to operate on low capacity batteries (such as non rechargeable button/coin cells).

Except for the pins used to connect to the external crystal, the remaining 36 pins of the MSP430 are available on the two 2×10 stackable connectors. These 36 pins include –

  • 2 pin UART interface
  • 3 pin SPI interface (SIMO, SOMI, SCLK)
  • 2 pin I2c bus (implemented in software)
  • 2 pin SPY-BY-WIRE interface
  • GPIOs / ADC channels / Comparator channels
  • Analog  voltage supply and ground (AVCC / AVSS)
  • Digital voltage supply and ground (DVCC / DVSS)

I will explain the need for separate digital and analog supply/gnd pins in another post.

Next up – Stackable RF boards and lots of sensor boards.

WSN application – insulin dosage monitor

Insulin dependent diabetics often face this problem . Sometimes they forget to inject insulin and other times they inject insulin but cannot remember that they have done so.  If  a diabetic forgets to inject insulin then her blood sugar will shoot up (a medical condition called hyperglycemia) and if she injects too much insulin, her blood sugar can quickly drop ( hypoglycemia). Both conditions are dangerous.

Let us take the case in which a person is not sure that they have taken insulin.  Given the fact that even fast acting insulin takes some time to act she would have to wait for a while and re-test her blood sugar level couple of times (using a glucometer) before she can be sure that she has taken an insulin shot or not. This can be a frustrating experience if you are busy at work or are about to go out somewhere.

In the other scenario, a diabetic can completely forget to take insulin.

A simple insulin dosage monitoring system can be built using a low tech reed switch and couple of wireless sensor nodes. It can help in both the scenarios mentioned above.

This idea will work with the “NovoPen 3” and other insulin pens which have similar delivery mechanism. According to Novo Nordisk, the “NovoPen 3 is one of the most widely used durable insulin pens in the world”. It seems to be the preferred delivery mechanism today in India.

The “NovoPen 3” s has three components. One is a disposable needle, the second is a replaceable insulin cartridge and the third is a dose dialing mechanism consisting of (among other things) a knob at the end of the pen.  This knob has be turned/dialed according to the number of units needed and then pushed in to deliver the dialed dose. This knob is more like a screw head. When a screw is turned, the screw head moves in and out depending on the direction of rotation. This knob can only be turned in one direction such that it moves out of the pen. It can only be pushed in to deliver the dosage.

novopen3_actualsize

 

 

 

 

 

 

 

 

 

 

The idea involves –

  • Sticking a tiny magnet to the knob at the end of the pen.
  • Attaching a snap on wireless node to the Pen body.  This node will have a reed switch as close as possible  to the knob but not touching it.  This wireless node should be removable. It has to be very low profile and should not impact the pen’s handling in any way.

How does it work  ?

Knob in default position (reed switch is closed)

pen_with_node_not_dialed_pos

 

 

 

 

 

 

 

 

 

 

Knob in dialed position (reed switch is open)

pen_with_node_dialed

 

 

 

 

 

 

 

 

When a dose is dialed, the knob and therfore the magnet moves out of the pen and away from the reed switch. When the knob is pushed in the magnet goes back to its original position (right next to the reed switch). Assuming we have a normally open reed switch, the switch will stay closed when the pen is not in use since the magnet will be positioned next to the switch. When a dose is dialed, the switch will open since the magnet will move away from the switch. The dose amount will determine how much distance the magnet will move away from the switch. The switch and magnet should be carefully positioned to ensure that the switch opens even when small doses are dialed. Now we have a way to detect insulin delivery.

  • The switch is initially closed
  • When a dose is dialed, the switch opens
  • When the dialed dose is injected, the switch closes

The micro in the node can detect these switch open/close events using interrupts.

The wireless node can simply send an SMS whenever it detects insulin delivery. It can also send an SMS if it does not detect insulin delivery during the portions of the day when insulin is expected to be injected.

This sensor node can be enhanced to do other things such as monitoring ambient temperature and light. I have written another article describing the same in detail.

WSN application – proper storage of medicines like insulin

Type 1 diabetics take multiple injections of Insulin every day to control their blood sugar level. Insulin has to be stored properly otherwise it looses its efficacy. High blood sugar level is highly detrimental to health and should be avoided at all costs.

Unopened insulin (in vials or cartridges) should be stored in a refrigerator between 2 to 8 degrees celcius. Once in use, insulin can be used for up to 4 weeks as long as it is stored below 25 degrees celcius and it does not have to be kept inside a refrigerator. Insulin must not be frozen, or exposed to excessive heat or light.

3_NP3

Usually a patient keeps multiple unopened insulin vials or cartridges in the fridge and uses a single vial/cartridge at a time.  We need a small form factor detachable wireless node with a temperature sensor and ambient light sensor.   This is achievable if we populate a single PCB with a microcontroller, radio and a chip antenna. In fact integrated micro + radio chips are already available. The node can be powered using a very small form factor lithium button/coin cell or a rechargeable NiMH button/coin cell.  The obvious trade off is between size and capacity. Another important factor is maximum allowed burst current draw before the battery’s output voltage drops below the minimum required by the micro/radio. All this information will be available in the battery spec.

insulin_pen

This node should operate in reduced functionality mode (RFN) to keep energy consumption to a minimum. WiSense nodes use the MSP430G2553 microcontroller which has an on board temperature sensor. It is accurate enough for our purpose which means you do not need an external one  which will impact both the cost and size of the PCB. The node needs to wake up periodically and sample the temperature sensor. The periodicity will depend on the battery capacity. If the measured temperature is within the allowed range, it can go back to sleep immediately. If not, it can send an alarm message to the gateway node directly or through one or more intermediate nodes if necessary. The gateway can then send an SMS to the person using the insulin. A  light sensor can be used to monitor ambient lighting. The node can send an alarm if the insulin is subjected to excessive light. A small audio buzzer can also be added to aid in locating the insulin vial/cartridge around the house.  The node should also monitor the battery voltage and raise an alarm if it falls below a threshold. The MSP430G2553/G2955 micros have an ADC channel dedicated to measuring the micro’s supply voltage. This allows the micro to monitor the battery voltage without any external components assuming that there is no dc-dc converter between the battery and the micro’s supply pins. This voltage value should be sent in every message sent out by the node.  In the case that ambient conditions are good for an extended time,  the node should still send a few messages to the gateway periodically (in the absence of alarm messages)  to show that it is alive. A few messages per day should be enough. If the ability to locate the insulin vial/cartridge is required, then the design becomes more complicated and prone to battery failure. The node needs to wake very frequently to check if the gateway is looking for it.

A network to monitor insulin is highly feasible in a house. A small number of sensor nodes should be enough to cover the whole house.  The sensor node will work inside  a refrigerator too as long as there is a relay node close to the fridge. We have tested WiSense sensor nodes inside a refrigerator.

References:

http://www.novonordisk.com.au/media/CMI/InshPfcmi11.pdf