Monthly Archives: February 2015

WiSense network for monitoring water level in big tanks

Any large community/campus in India usually has a network of water tanks to store and supply water. Community managers in Inda are very interested in knowing the water level in these tanks at all times thanks to erratic water supply (municipal or private tankers). One of our customers requires an SMS to be sent every time the water level in any tank goes above or below fixed threshold. They also want to have a history of the levels in every tank. This customer has tanks in multiple locations across the campus and most locations have multiple co-located tanks. One location has five tanks. Since It is not practical to have a GSM modem for each tank, we proposed a network of WiSense nodes in each location. The WiSense gateway node in each location will interface with a GSM modem. Locations which are close enough can also share a single GSM modem. This week we showed a POC using three WiSense nodes. Two were sensor nodes which used pressure sensors to continuously monitor the water level in two separate tanks. The third was a gateway node connected to a GSM modem. This sensor network was successfully able to track the water levels in both tanks. We configured the gateway node to send an SMS every 5 minutes to a campus manager’s cell phone. Each SMS reported the water level (in inches).

The sensor nodes were powered by two AAA batteries. Both nodes were configured to operate as reduced function devices (RFD). The water level sensing was done using the Freescale MP3V5050GP ported pressure sensor. A flexible food grade tube (tied to a weight) was lowered into each tank such that one end rested at the bottom of the tank. The other end was attached to the MP3V5050GP’s port. The sensor then measured the pressure of the water column.

Here are some pics of the POC.

wl_poc_3

wl_poc_2

wl_poc_1

Advertisements

Building “Smart Communities” in India

We are all aware of smart homes and smart cities. The Indian govt has also made some noise about building smart cities although anybody familiar with the chaos of Indian cities will find this laughable.

I am not sure if this concept of smart homes will take off in India. A lot of people seem to be working on smart phone controlled lights, fans, ACs etc. Not sure if there is a big market for this in India.

How about “smart communities”  where actual pain points are addressed by IOT and related technologies ? We have a lot of problems in Indian cities. Too many people chasing too few resources. We have too few livable cities for such a big population. Can we use IOT to mitigate these issues at the community level ? Smart communities will enable the smart city.

I live in a residential community of about 400 independent houses. Some of the major issues we face are water scarcity, load shedding (electricity), security etc. Suitable technology can help a community like ours tackle these issues and also make life more convenient.

Many of these issues are specific to countries such as India where good governance has never been a priority. Things are getting better but at a very slow pace.

We have realized that there are many use cases of a wireless mesh sensor/actuator network outside the home at the community level in India. We propose a community wide low power wireless mesh network which can be used to connect any device within the community. Let me give you some examples –

  1. Smart street lights which can be individually controlled and monitored for faults
  2. Monitoring of the water level in individual and common water tanks
  3. Monitoring of borewell production / water provided by tankers
  4. Continuous water quality monitoring of water (hardness etc) in the common water tanks.
  5. Smart watering of parks
  6. Connected water meters and electricity meters
  7. Back up generator health monitoring (diesel tank level monitoring)
  8. Air quality
  9. Tracking waste bins
  10. LPG cylinder usage monitoring
  11. Detecting speeding vehicles within the community
  12. Security using motion sensors
  13. Keeping an eye on the effectiveness of security personnel especially at night. Are they sleeping or making rounds ?
  14. Monitoring the health of solar powered street lights.
  15. Preventing unauthorized persons from entering the community
  16. Control of outdoor lighting for sports (tennis courts for instance). These lights are very power hungry.

Home owners associations want to save the effort and money required to run communities effectively. Communities bring economies of scale.

Can we build an ecosystem of companies which can build products and services for communities in India ?

Ram Krishnan

Jinen Jain

WiSense FFD power consumption

I have not paid much attention to the power consumption of a full function device (FFD) till now. A WiSense node configured to operate as an FFD keeps it’s radio on at all times since it has to participate in mesh routing. The CC1101 radio consumes around 19 mA (at 3 Volts) in receive mode. When transmitting, the CC1101 consumes around 30 mA. Further, the micro (MSP430) on an FFD node runs at 16 MHz consuming around 5.0 mA (Vcc at 3.0 V). As a result, FFDs cannot run on batteries for long.

In most scenarios, mains power is the only option. In applications where the mesh network is installed outdoors, it is possible to utilize solar cells to power FFDs. Assuming an FFD has to stay powered 24/7, let us calculate the daily energy consumption. Assume supply voltage is 3.0 Volts. Assuming maximum sizes PDUs (71 bytes on the air), a single transmission will take 15 milli-seconds (WiSense nodes transmit at 38.4 kbps). Let us also assume that this FFD does not have any sensors. Assume the FFD makes a maximum of Nt transmissions per day.

Let ‘Tn’ seconds be the total time taken by Nt transmissions.

  • Power consumed by micro and radio (in receive mode) will be Vcc * (5 mA+ 19 mA)  -> 3 * 24 -> 72 mW (milli-watts).
  • Power consumed by micro and radio (in receive mode) will be Vcc * (5 mA + 30 mA)  -> 3 * 35 -> 105 mW (milli-watts).
  • Energy consumption per day =  Tn * 105 + (86400 – Tn) * 72 milli-joules

Assume this FFD makes a maximum of ‘Nt =1000’ transmissions per day and each transmission takes 15 milli-seconds.

Tn is then (15 * 1000) / 1000  = 15 seconds.

Energy consumption per day = 15 * 105 + (86400 – 15) * 72 -> 6222 joules

Assuming 6 hours of good sunlight, we only need a (6222 / (6 * 3600)) =  .289 Watt panel to power this node 24/7.

The above calculation show that total energy consumption mainly depends on CC1101 power consumption in receive mode and to a lesser extent on the MSP430’s power consumption (if it is always active).

The FFD’s power consumption can be reduced by putting the MSP430 in LPM3 mode whenever it has nothing to do (this is now the default behavior of WiSense FFDs).  When the CC1101 receives a packet it interrupts the MSP430 and the latter wakes up within a couple of microseconds. So no packets will be lost if the MSP430 is put to sleep (LPM3 mode). LPM3 mode power consumption is less than 4 micro-watts. With the micro in LPM3 mode, the FFD’s energy consumption mainly depends on the radio’s power consumption while listening (receive mode).

The CC1101 and the MSP430G2955 can operate at voltages as low as 1.8 V. Let us give a safety margin of say 0.3 Volts and operate the CC1101 at 2.1 V.  Operating at a lower voltage has an added benefit of lower current consumption.

Energy consumed per day is ~ 86400 * (19 / 1000) * 2.1 -> 3448 Joules.

Assuming 6 hours of good sunlight, we only need a (34468 / (6 * 3600)) =  .16 Watt panel to power this node 24/7.

To tide over consecutive bad weather days, we can choose a 1 W solar panel.

We need to choose a rechargeable battery with enough capacity to get through a week of bad weather. A 2500 mAh NiMH battery (1.2 V nominal voltage) has a maximum capacity of 2.5 * 3600 * 1.2 -> 10800 joules. Usable capacity will be lesser. We can use two of these batteries with a maximum capacity of 21600 Joules. Assuming usable capacity is 80 %  (at an average discharge rate of 20 mA which is pretty low for these batteries),   we get 21600 * .8 -> 17280 Joules. This will power the system for 17280 / 3448 ->  5 days if there is no solar input due to bad weather.

Interfacing a MaxBotics ultrasonic range sensor to a WiSense node

MAXBOTIX makes highly reliable ultrasonic range sensors. I have used them in the past for vehicle detection in covered parking lots.

lv_max_sonar_ez_pic

This sensor can output ranging data serially. The serial parameters are –

  • 9600 bps
  • 1 stop bit
  • No parity bit
  • The serial output on the sensor’s TX pin needs to be inverted. I did this by using an opamp.

maxbotix_interface

In the block diagram (above), the +ve input is fixed at Vcc/2. The -ve input is connected to the MaxSonar’s TX pin. When the TX pin is low (0 Volts), the -ve input is lesser than the +ve input (Vcc/2), as a result the Op-Amp drives it’s output to Vcc volts. When the TX pin is high (Vcc volts), the -ve input is higher than the +ve input (Vcc/2), as a result the Op-Amp drives it’s output to 0 volts.

If the RX pin on the sensor is pulled high for at least 20 micro-seconds, it will trigger the sensor to perform a ranging operation. This will take around 49 milli-seconds.

I added an FFD app (ffd_app_wl.c) which periodically gets range data from this sensor and sends it to the external gateway app via the coordinator node. I used this app to measure the water level in the 1000 litre tank on the terrace.

The sensor driver is implemented in two files.

  • Pltfrm/src/max_sonar.c
  • Pltfrm/inc/max_sonar.h

Here is the code from ffd_app_wl.c.

max_code_2

.

.

.

.

.

.

.

.

.

.

.

.

max_code_1.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

You can take a look at the code on bitbucket.

Here is a snapshot of the gateway app running on the laptop connected to the coordinator node.

max_dist_gw_app_log

Some pics of  the test setup –

max_sonar_ffd_intf_pic

max_sonar_ffd_intf_pic_2

.

.

.

.

.

.

.

.

.

.

.

.

.

References:

Interfacing a soil moisture sensor to a WiSense node

This post is about interfacing a low cost soil moisture sensor (the CHIRP plant water level alarm) to a WiSense node. This can help you automate plant watering. Wireless moisture sensors can periodically monitor the moisture level in the soil near the roots of plants and send this data (over a WiSense mesh network) to a Raspberry-Pi. The Raspberry-Pi can then use this data to remotely operate valves in pipes supplying water to your garden. If you don’t want to invest in valves, the Raspberry-Pi can send you an SMS in case a plant gets too dry. You can make it more sophisticated by combining the soil humidity informaton, local weather reports and plant specific data to decide when to water each plant.

I bought a CHIRP soil moisture sensor from Adafruit. This sensor is “open source hardware available under CERN Hardware Licence v.1.1”. The sensor utilizes capacitive humidity sensing instead of the usual resistive sensing (monitoring resistance between two galvanized nails buried in the soil near the roots).

1965-01

(Pic courtesy: adafruit.com)

The “CHIRP” behaves as an I2C slave device (with 7 bit address 0x20). It is not that straight forward to use as compared to commercial sensor ICs from TI, ST, etc. It took me some effort to get it working. The sensor can work in two modes. One is the stand alone mode (default mode of operation) in which it will periodically monitor soil moisture and give out “chirps” when the moisture level indicates that the plant needs to be monitored. The other is the slave mode where it measures humidity/light only when requested by the I2C master node (a WiSense node in our case). The CHIRP can be put in the “slave” mode by resetting it (by toggling it’s reset pin) and sending any data to it (over I2C) right after resetting it. I had to read the description at “wemakethings.net/chirp/” and read the code in the repository to get it to work. Another problem was communicating with the “CHIRP” over I2C. WiSense platform has a “soft” I2C with support for 100 KHz bus speed. This driver (which has worked without issues with more than 30 different sensors) did not work as it is. I had to introduce extra delays in the driver to get it to work. The delay is introduced only when the macro “PLTFRM_CHIRP_PWLA_ENA” is enabled.

The “CHIRP” also measures ambient light using a diode and some analog jugglery.

After some hours of struggling with the I2C code, I was able to get the moisture level from the CHIRP (interfaced to a WiSense FFD node)  to my laptop connected to a WiSense coordinator. I tested the CHIRP’s output by watering the area near the sensor. The CHIRP responded immediately by sending an elevated value (indicating higher moisture content). I configured the WiSense FFD to send moisture data every couple of seconds to the gateway app running on the laptop.

All the code is in pltfrm/inc/chirp_pwla.h and pltfrm/src/chirp_pwla.c. The code has been checked in (to bitbucket.org). The app file “ffd_app_1.c” now supports this sensor.

Here is the code in ffd_app_1.c which calls the driver API to get the moisture level from the “CHIRP”.

chirp_code

You can see (below) the jump in moisture level reported by the the CHIRP is response to watering.

moisture_level_jump

Here are some pics of the setup.

chirp_in_pot_1

chirp_in_pot_2

References:

Interfacing a power relay to a WiSense node

I got a board with eight power relays from a friend. These relays (26-12-1CKE) are manufactured by O/E/N India in Bangalore.  The board has a relay driver IC (ULN2803A from TI). This IC can drive up to 8 relays. This IC  allows a low voltage GPIO pin to safely control an inductive load such as a power relay. The relays require 12 V supply.

uln2803

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

I added a command “dioc” to the gateway application. This command can be used to set the output (on any node in an WiSense mesh network) of any pin (configured as digital out) to 0 or 1. This command takes 4 parameters.

  • The short address of the remote node
  • The port id (1 – 4)
  • The pin number (0 – 7)
  • Value ( 0 or 1).

Examples:

  • To set P2.1 on node (with short address 0x5) to 1, run “./gw.exe  /dev/ttyS10   dioc   0x5   2   1   1”.
  • To set P4.3 on node (with short address 0x7) to 0, run “./gw.exe  /dev/ttyS10  dioc   0x7   4   3   0

The application payload format of the message sent to specified remote node is given below. This message requests the app layer on the intended recipient to set digital output P2.6 to 0. All messages exchanged between WiSense nodes and external entities such as the gateway app consist of a 1 byte DIS message type followed by one more TLV (type-length-value) structures. The type and length fields are single byte fields. All TLV related macros are defined in the file “dis/inc/dis.h”. In the message below, you can see one top level container TLV (DIS_TLV_TYPE_DIGITAL_IO) which in turn contains three simple TLVs (DIGITAL_IO_PORT, DIGITAL_IO_PIN and DIGITAL_IO_VAL).

  • Byte 0 (DIS message type): 0xb (DIS_MSG_TYPE_CTRL_DIGITAL_IO)
  • Byte 1 (TLV type field):  0x34  (DIS_TLV_TYPE_DIGITAL_IO)
  • Byte 2 (TLV length field): 0x9  
  • Byte 3 (TLV type field): 0x31   (DIS_TLV_TYPE_DIGITAL_IO_PORT)
  • Byte 4 (TLV length field): 0x1  
  • Byte 5 (TLV value field): 0x2  (Port P2)
  • Byte 6 (TLV type field): 0x32  (DIS_TLV_TYPE_DIGITAL_IO_PIN)
  • Byte 7 (TLV length field):  0x1
  • Byte 8 (TLV value field): 0x6  (Pin number 6)
  • Byte 9 (TLV type field): 0x33  (DIS_TLV_TYPE_DIGITAL_IO_VAL)
  • Byte 10 (TLV length field) : 0x1  
  • Byte 11 (TLV value field): 0x0  (Set digital output to 0x0)

The test setup had one coordinator node connected to a laptop running the small script shown below. The network had one more node (an FFD) with port p2.1 configured as digital output and hooked up to one of inputs of the ULN2803A  on the relay board. This script toggled the digital output p2.1 on the FFD (address 0x2) every second. The relay gated AC power to a CFL bulb.

  • while  [ 1 ]
  •      ./gw.exe /dev/ttyS2  dioc  0x2   2   1   0
  •      sleep 1
  •      ./gw.exe /dev/ttyS2  dioc  0x2   2   1   1
  •      sleep 1
  • done

The coordinator (and the laptop) were in one room and the FFD/relay/bulb were in another room.

Here’s a pic of the setup.

ffd_relay_cntrl.

References: