Monthly Archives: November 2014

Interesting side effect of low power sleep

This is something I noticed recently. I was testing a WiSense sensor node operating as an RFD (reduced function device). It was sending sensor data to the coordinator/gateway every 5 seconds. The node was powered by the on board 3 V coin cell. I wanted to restart the RFD so I used the slide switch on the node to power cycle the node. It would have taken me less than 3 seconds to switch off and then switch on the power supply. I was expecting the node to restart  and reconnect to the coordinator node. Surprisingly the node did not restart. It just woke after a few seconds, sent sensor data to the coordinator, received an ack message and went back to sleep.  I realized that the bypass capacitor network on the node (used to filter out noise) was the source of the energy which kept the node powered while the power switch was in the off position.  When the switch was put into the off position,  the node was already in sleep mode and its power consumption was less than 5 micro-amps.  The bypass capacitor network was able to supply this current while the coin battery was disconnected. Next I kept the coin battery disconnected for more than 5 seconds.  This time the bypass capacitor network could not supply the active mode current required by the node when it woke up. The supply voltage (from the caps) collapsed and the node died (without power). When I reconnected the coin battery, the node restarted and reconnected to the coordinator.

WiSense nodes have one or more bypass capacitors near each IC (the microcontroller, the radio chip , the eeprom and each of the sensors). There are three capacitors at the entry point of each board (microcontroller board and the RF host / sensor board).  The MSP430 is bypassed by two 10 uF capacitors (one each for the digital and analog supply pins). There is a 4.7 uF cap at the point where the power supply enters the micro-controller board. . There is 4.7 uF capacitor on the RF host/sensor board and a 1 uF capacitor on the radio board. All these capacitors are in parallel so the total capacitance adds up. The total capacitance on the sensor node across all board comes to around 30.4 uF (ignoring the sub 1 uF capacitors).


The energy stored in a capacitor is given by the formula – (C * V * V)/2  where C is the capacitance and V is the voltage across the capacitor. A 30.4 uF cap nwk with 3 volts across it’s terminals stores (30.4 * (10 ^ -6) * 3 * 3)/2  ->   136.8 micro-joules. The usable energy of a capacitor is still less. The lowest allowed voltage for a WiSense node in sleep mode is 1.8 volts (required by the MSP430).  The usable energy is then  30.4 * (10 ^ -6)(3*3 – 1.8*1.8)/2  -> 87.6 micro-joules.

WiSense RFD power consumption in sleep mode is 3 V * 5 uA -> 15 uWatts.

The bypass capacitor network should be able to keep the node up for  87.552 / 15 -> around 6 seconds. It could be longer since the RFD’s current consumption will drop as the supply voltage (from the capacitor network) drops.

Interfacing (safely) with the MSP430

From the MSP430G2955 datasheet:

  1. The micro has an absolute maximum voltage range of (-0.3 V) to (+4.1 V).
  2. I/O pins have a maximum voltage range of (-0.3 V) to (Vcc + 0.3 V).
  3. The recommended operating voltage range is 1.8 V to 3.6 V.
  4. Diode current at any pin can be max +/- 2 mA.

I have already discussed points 1 and 3 in the last post. I will discuss the rest in this post.

Let us look at point 2. If the voltage at the supply pin is say 2.5 V, the voltage on any I/O pin should never get lower than -0.3 V or exceed 2.8 V. If the supply voltage is 1.8 V,  the voltage on any I/O pin should not exceed 2.1 V. You risk damage to the I/O pin otherwise.

The MSP430 family has a couple of protection diodes (also called clamp diodes) within each I/O pin. These diodes are inside the chip. It seems most micro-controllers on the market today have these protection diodes.














The absolute maximum current allowed through the protection diodes is 2 mA. When the pin voltage is within the allowed range (-0.3 V to Vcc + 0.3 V), both the diodes are reverse biased and therefore have no effect. Assume Vcc is 3.0 V and you apply 2.5 V to the I/O pin. Both diodes are reverse biased. Suppose you apply 3.4 V to the I/O pin. The lower diode is still reverse biased but the upper diode is now forward biased (3.4 V > (3 V + 0.3 V)) and this will cause current to flow through the diode. According to the datasheet, this current should be less than 2 mA otherwise the protection diode will get damaged.

Let us take another scenario which is easier to understand. Suppose you have a MSP430 micro powered by say a 3 V coin cell. Disconnect the coin cell’s +ve terminal from the MSP430’s Vcc and instead connect to it some I/O port. What is going to happen ? Look at the figure above. The I/O pin has a voltage of 3.0 V.  The upper diode will be forward biased and the lower diode will be reverse biased.  The upper diode will drop 0.3 V and Vcc will rise to 3.0 – 0.3 -> 2.7 V. The MSP430 will start running !!. This 2.7 V will power up any other component sharing the supply rail with the MSP430.  You have succeeded in powering your circuit through a I/O pin. Let us not forget the 2 mA current limit of the protection diode. If your circuit consumes more than 2 mA, this current (which is flowing through the upper protection diode) will damage the protection diode if the current is allowed to flow for a while. The diode could short or open up. In the former case, the I/O pin will get shorted to Vcc or Vss depending on whether it is the upper diode or the lower diode. In the latter case, the I/O pin will no longer be protected.

Why is the current limit just 2 mA ? Why have these protection diodes in the first place ? I have not found any official documentation from TI on these diodes. I have come across some posts on TI E2E and other sites. I have copied one post ( ) below.

The diode is called an intrinsic diode as it is formed as a natural part of the mechanical architecture of the IC. It is possible to make pins that do NOT have this intrinsic diode but they require an additional processing step so take room and cost money and the pin is then unprotected so pins are liable to have this diode unless there is a special need to not have it.

The diodes are there to protect the pin in scenarios like the one described above. If the diodes are not there,  the I/O port will see 3 Volts (with respect to ground). This could damage the port circuitry.

Now, how do we keep the current below the limit (2 mA) if (by accident), the voltage on any I/O pin goes below -0.3 V or above Vcc + 0.3 V? This is easy. Use a resistor.  The value of the resistor will depend on the current consumption of the circuit (which uses the MSP430).


Suppose you accidentally apply 4.0 V to the I/O pin shown in the figure above. For the sake of simplicity, assume Vcc is disconnected from the power supply (a 3 V coin cell). We want to calculate the minimum value of R which will prevent damage to the MSP430.

Vio is 4.0 V. The upper diode will be forward biased since Vcc is not connected to the power supply. If R is missing, Vcc will rise to 4 – 0.3 -> 3.7 V which is above the max recommended voltage (3.6 V). We want to choose a value for R so that Vcc does not go beyond 3.6 V. Iio is the current through the upper protection diode.

  • Vio – (Iio * R) – 0.3V < 3.6V
  • Iio * R > Vio – 3.9V
  • R > (4.0V – 3.9V) / Iio
  • R > 0.1V / Iio

Assume the circuit (containing the MSP430) has a constant current consumption of 5 mA.

  • R > 0.1V / (5 * 10^-3) 
  • R > 20 ohms

The minimum value of R is 20 ohms.

In practice, you may not know the current consumption of the circuit or it may vary with time. So it is a good idea to use a large value for R to make sure that the Vcc does not go above 3.6 V. A value between 10K and 20K should be ok. This resistance will not effect the normal operation of the I/O pin (assuming you are not using the pin to drive say an LED).

One last point. What happens if say Vcc is 3.0 V (not disconnected) and you apply 4.0 V to an I/O pin ? Now things get complicated depending on the how the Vcc is being generated. How will Vcc change ?  I hope to cover this scenario in another post.


Notes on absolute maximum ratings of ICs (such as the MSP430)

The major components on a WiSense node include the MSP430G2955 micro, the radio (CC1101 or  CC2520), serial EEPROM (AT24MAC602), the LM75B temperature sensor and the TSL45315 ambient light sensor. You are of course free to interface any compatible sensor to a WiSense node.

Each of the components listed above has an absolute maximum supply voltage rating and a recommended operating voltage range. I have listed them below.

      Component                  Absolute max supply voltage             Recommended range

  • MSP430G2955                      -0.3 to 4.1 V                                           1.8   to 3.6 V
  • CC1101                                 -0.3 to 3.9 V                                           1.8   to 3.6 V
  • AT24MAC602                        -0.1 to 7.0 V                                           1.7  to 5.5 V
  • LM75B                                   -0.3 to 6.0 V                                           2.8  to 5.5 V
  • TSL45315                               0.0 to 4.5 V                                           2.3  to 3.3 V

The datasheet for the MSP430G2955 has this note in relation to the absolute max supply voltage which can be applied to this IC (-0.3 to 4.1 V).

Stresses beyond those listed under ‘absolute maximum ratings’ may cause permanent damage to the device. These are stress ratings only, and functional operation of the device at these or any other conditions beyond those indicated under “recommended operating conditions” is not implied. Exposure to absolute-maximum-rated conditions for extended periods may affect device reliability.”

I found a post by a TI employee on TI E2E (  (copied below).

“If you’re just playing around with the part and not planning to go to production with the design, 3.7V is probably OK.  However, officially we won’t guarantee anything over 3.6V, as it can degrade the part’s performance.  So for production, you want to use a regulator and keep Vcc under 3.6V.”

This matches the note in the datasheet. Even though 4.1 V is the absolute max voltage the IC can handle without permanent damage, this does not imply that you should operate the part outside the recommended operating supply voltage (1.8 V to 3.6 V).

The important takeaway is to operate any component only within the recommended operating voltage range as specified in the component’s data sheet. This should be true for most components available on the market today.

Surprisingly, the 3.6 V limit for the MSP430G2955 does not mean that the part will always get damaged if the applied voltage exceeds 3.6 V.  I have reversed power and ground connections to WiSense nodes many times. The nodes always worked after I corrected my mistake. According to TI, I was just lucky. It is possible that the MSP430 did get damaged but I do not know it yet. We are going to add a reverse protection mechanism asap to WiSense nodes.

When you have multiple components with different operating voltage requirements and a single supply rail for all the components (which is true for WiSense nodes) you need to make sure that your operating voltage satisfies the recommended operating voltage range of each component. According to the table (above), the TSL45315 ambient light sensor has a max recommended operating voltage of 3.3 V.  The LM75B’s recommended lowest operating voltage is 2.8 V. This provides the recommended operating voltage range for WiSense nodes (2.8 V to 3.3 V).  If you interface any other component to a WiSense node (sensors for example),  you may have to adjust the operating voltage range (2.8 to 3.3 V) further depending on the component’s operating voltage range.

Measuring current consumption of WiSense nodes

When a WiSense node is operating as an RFD (reduced function device) and its energy source is very limited (usually a non rechargeable 3 V lithium coin cell), it is supposed to keep its current consumption as low as possible. RFDs are usually in sleep mode most of the time and only wake up now and then to sense and communicate. In sleep mode all the components on the node are put in their lowest power consumption modes. This includes the microcontroller, the radio, the eeprom and all the different sensors on the node.

The sleep mode current consumption can be as low as a few microamps. In an earlier post, I mentioned that when the duty cycle is low, the life time of the battery powering the RFD depends entirely on the sleep mode current consumption. Duty cycle is the fraction of time spent sleeping.

It is therefore very important to measure the sleep mode current consumption of an RFD before deploying it.  Suppose you add a sensor to an RFD but forget to put the sensor in its low power mode before the RFD is put to sleep. Your coin cell will be useless in no time (depending on the sensor’s current consumption). Good lithium coin cells are not cheap. One small bug in the code can burn a big hole in your pocket.

I am not getting good Lithium coin cells in Bangalore.  I have tried many shops for Sony coin cells but I only get bad quality Maxell coin cells. These burn out pretty fast.

Time to get to the point. How do we measure DC microamps ? The easiest way is to get a top brand multimeter which has a DC “microamp” range.

I have a Agilent U1242B which has a “microamp” measurement function. It has two ranges within this function.

Range 1 : 0 to 1000.0 uA with a resolution of 0.1 uA

Range 2: 0 to 10000 uA with a resolution of 1 uA

The U1242B also has a “milliamp” measurement function. It has two ranges within this function.

Range 1: 0 to 100 mA with a resolution of 0.01 mA.

Range 2: 0 to 440 mA with a resolution of 0.1 mA

You can select the required range by pressing the “Range” button on the multimeter and stepping through the available ranges within the selected measurement function. The selected range appears on the LCD screen.

You need to hook up the multimeter leads such that the positive multimeter lead is connected to the positive terminal of the coin cell or any other battery you may be using. The COM/ground lead of the multimeter needs to be connected to the positive supply input of the WiSense node. The ground pin of the WiSense node should be connected to the negative terminal of the battery. Make sure that the multimeter leads are plugged in to the proper ports on the multimeter before connecting to the coin cell and the sensor node. These will be the uA/mA port and the COM (ground) port. The relevant measurement function must also be selected before connecting to the coin cell and the sensor node.

There is one important aspect to be aware of when making the current measurement. When the WiSense node is active (sensing or communicating), its current consumption can be as high as 30 mA.  When the node is sleeping, the current consumption can be as as low as a few microamps.  As mentioned above, the U1242B has a 0 to 1000 uA range with a resolution of 0.1 uA. Obviously, we want to use this range to measure the node’s current consumption.  The problem is that measurement will be proper only when the node is sleeping. When the node wakes up, its current consumption will go up and you will see that the node is not working properly. To get the node to work properly, you would be forced to change the measurement function to “mA”. What is happening here ? How can the multimeter interfere with the proper functioning of the sensor node !!!.


The problem is because of the mechanism used by these multimeters to measure currents. Multilmeters measure current by measuring the voltage drop across a shunt resistance through which the current (which needs to be measured) flows. The voltage drop across this shunt resistance is referred to as the burden voltage.

Voltage_supplied_to_node = Supply_Voltage – Burden_Voltage

The U1242B has a shunt resistance value of around 60 ohms in the 0 to 1000 uA range. If the sensor node consumes 5 uA in sleep mode, the burden voltage will be 60 * 5 * (10^-6) -> .30 milliVolts. This is hardly anything compared to the supply voltage from the coin battery (3.0 Volts).  When the node wakes up and starts consuming current in milliAmps, the burden voltage will increase. Let us assume that the node consumes say 2 mA while it is sampling the sensors. The burden voltage will be 60 * 2 * (10 ^ -3) -> .12 Volts. The voltage seen by the node will drop from 3.0 V to (3.0 – 0.12 -> 2.88 V). This is still ok since the MSP430 and the radio (CC1101 / CC2520) can work at a voltage as low as 1.8 V.  When the node switches on it’s radio to transmit/receive, the current consumption will increase to around 30 mA. Now the burden voltage will increase to 60 * 30 * (10 ^ -3) -> 1.8 V !!!. The voltage supplied to the node will drop to (3.0 – 1.8 -> 1.2 V). This is too low. The MSP430, the radio and the sensors will abruptly stop working. The node will not work properly until you change the measurement function to mA or A.

One way out is to configure the RFD’s sleep interval to a large value (say above 30 seconds). Start off with the multimeter in mA measurement function. This function (on the U1242B) has a 0 to 440 mA range in which the shunt resistance value is 1.8 ohms. Assuming worst case current of 40 mA, the burden voltage will be only 1.8 * 40 * (10 ^ -3) -> 72 mV. Power up the RFD and wait for it to join and finally go to sleep. Now, change the measurement function to uA and monitor the sleep mode current consumption (which should be a few microamps). Wait until at least 5 seconds are left in the sleep interval and then change the measurement function to mA. This will ensure that the node keeps working after waking up and goes back to sleep subsequently after sensing/communication.

WSN application – public transport

I recently talked to a person who is familiar with BMTC’s bus location system. The system uses GPS+GPRS to provide real time updates on the location of each bus operated by BMTC in Bangalore. Looks like the system is not working because of problems with cellular coverage, GPS accuracy, maintenance and the recurring cost of all the data traffic. He suggested a simpler alternative. Install a low power radio in each bus and at each bus stop. When a bus stops at a bus stop, the radio node on the bus sends a message conveying the unique id of the bus. The low power radio at each bus stop will be connected to a GSM modem. The information about each bus which stops at a bus stop will be sent to BMTC over the cellular network. BMTC customers can get the data about each bus on their cell phones. Each bus stop can also display information about every bus which stops there. The cost of equipping each bus with a low power radio is not much compared to a GPS/GPRS module. Over 6500 BMTC buses run everyday. The number of bus stops is far less which means the number of GSM modules required is also less. The data traffic will also be less. Data will be sent over the cellular network only when a bus arrives or leaves a bus stop instead of say every 5 to 10 minutes in the earlier system.

WiSense radios operating in the 865-867 MHz are well suited for this application. The nodes can run on couple of AAA batteries for more than a year. This radio can be installed inside the bus in a location where it is not tampered with. A GPRS modem can be easily integrated with a WiSense node.

WiSense nodes at bus stops can also be equipped to collect environmental data such as temperature, humidity, ambient light and common pollutants.

Many bus stops have a power connection for lights. The low power radio + GPRS node at these bus stops can be AC powered with battery backup.

The radio nodes on each bus can be solar powered if the node is attached to the roof of the bus. This will increase the cost since these nodes require a robust weather proof enclosure.

Communicating with a reduced function device (RFD) in a WiSense LPWMN

A reduced function device spends most of its time in deep sleep, waking up now and then to sense and communicate. RFDs have limited energy supply so they need to conserve energy at all times. Since RFDs are sleeping most of the time, communicating with such nodes is not as simple as talking to full function devices (FFDs) which are awake all the time.


Every RFD selects a parent node through which it joins the network. When an RFD wants to send a frame to the external world via the network coordinator, it will sends the frame to its parent. The parent then takes care of sending it to the coordinator through one or more hops. The parent node is a full function device and has the capability to discover routes to any other node in the network. The RFD can go back to sleep after receiving the link level acknowledgment from the parent node. If a node (say the network coordinator) wants to send a frame to an RFD, it will send the frame to the RFD’s parent. The parent node will buffer the frame until the RFD wakes up and asks for it. When the RFD wants to check if it’s parent has any frames for it, it will send a DATA_REQ command frame to the parent. If the parent has one or more frames pending transmission to this RFD, the parent will set the “PENDING” bit in the frame control field of the acknowledgment (ack) frame sent in response to the “DATA_REQ” command frame. The RFD will then check this bit in the received  ack frame. If this bit is not set, the RFD can go back to deep sleep immediately. If the bit is set, the RFD needs to wait for some time (say 200 milli-secs) for the parent to send the pending frame. The parent node has to send the pending frame immediately after sending the ack with the “PEND” bit set so as to minimize the time the RFD has to keep it’s radio on. As you can see, this mechanism is energy intensive which means RFDs need to poll as infrequently as possible.

A common application scenario involves RFDs periodically sending sensor data to the external world via the network coordinator. When an RFD sends a frame (containing sensor data) to it’s parent, the parent will acknowledge this frame since this frame will have the ACK_REQUIRED bit set in the FC field within the MAC header. The parent will set the “FRAME_PENDING” bit in the ack frame if it has any buffered frames pending transmission to the source RFD. When the RFD gets this ack frame, it will check the FRAME_PENDING bit in the FC field. If this bit is not set, the RFD can go back to sleep right away, If this bit is set, the RFD can opt to send a “DATA_REQUEST” command to the parent. The parent will ack this command. After receiving this ack, the RFD needs to stay awake (radio in listening mode) for some fixed time waiting for a frame from the parent.  Note that the “DATA_REQUEST” command is still needed since the RFD may not be interested in receiving buffered data every time it sends out some data to the parent. This allows RFDs to determine if any frames are buffered on the parent without any additional cost. This is very useful since in many application scenarios, most of the communication is from a sensing node towards the network coordinator. There is not as much traffic from the external world towards sensor nodes (RFDs).

The WiSense coordinator/gateway CLI has a command “cfg-dpi” which can be used to configure the frequency at which an RFD will push sensor data to the external world (through the network coordinator). When this command is executed, a frame containing the new interval (in seconds) will be sent to the parent node of the specified RFD. This parent will buffer this frame until the next time the child RFD wakes up and sends a frame to it. When the RFD sees the “FRAME_PENDING” bit set in the ack, it will send a “DATA_REQUEST” command to the parent. The parent will ack this command. This ack will also have the “FRAME_PENDING” bit set.When the RFD gets this ack, it will keep it’s radio on for a fixed time waiting for the buffered frame from the parent. When the RFD gets this frame, it will update it’s sensor data transmission frequency.

WiSense coordinator/gateway CLI (command line interface)

The coordinator CLI is a small Linux app which talks to the coordinator node. It can be used to get info from the coordinator as well as configure the coordinator / network. This app comprises a few “.c” and “.h” files. This app can be run on any Linux system including the Raspberry Pi. It can also be run on Cygwin. You can compile the app by running the included script “comp”.

Step #1 – Compile the app by running “comp”.

Step #2 – Connect the coordinator to the laptop/PC using the USB cable

Step #3 – Get the serial port device created when you plugged in the USB cable (other end connected to the coordinator)

Step #4 – Execute the app

$>  ./gw.exe  /dev/ttyUSB0  cea

Coordinator’s 64 bit (extended) address – 0xfc:0xc2:0x3d:0x0:0x0:0x0:0xe8:0xa9


List of supported command strings :-

$> ./gw.exe ?
* sc – start the coordinator

* nc – get number of nodes in the network

* nid – get the 16 bit network id

* rfb – get the radio frequency band

* grch – get the radio channel number

* srch – set the radio channel number

* rcf – get the radio carrier frequency

* grbr – get the radio baud rate

* grm – get the radio modulation format

* rtp – get the transmit power of the radio on the coordinator

* cea – get the coordinator’s 64 bit address

* nl – list all nodes in the network

* rpn – get the part number of the radio on the coordinator

* nj-ena – allow nodes to join the coordinator

* nj-dis – do not allow nodes to join the coordinator

* nj-sts – are nodes currently allowed to join the coordinator ?

* wl-get – Get white list (list of all nodes allowed to join this nwk)

* wl-add – Add node to white list
example: wl-add fc:c2:3d:0:0:0:e9:54

* wl-del – Remove node from white list
example: wl-del fc:c2:3d:0:0:0:e9:54

* wl-clr – Delete the white list

* cfg-dpi – Confgure node’s data push interval
format: cfg-r-dpi <short-address> <interval in seconds>
example: cfg-r-dpi 0x5 3


Let us look at each command in detail.


[sc]: This command is used to request the coordinator node to start normal operations. After reset (power cycle or push button reset), this command has to be given so that the coordinator will start network formation.

$ ./gw.exe  /dev/ttyUSB0  sc




[nc]: Use this command to get the number of nodes which are currently part of the LPWMN (low power wireless mesh network) managed by this coordinator.

$ ./gw.exe  /dev/ttyUSB0  nc

Number of nodes in the network – 2



[nl]: Use this command to get a list of nodes which are currently part of the LPWMN (low power wireless mesh network) managed by this coordinator.

$ ./gw.exe  /dev/ttyUSB0  nl

Node Index <0> / short addr <0x2> / ext addr <0xfc:0xc2:0x3d:0x0:0x0:0x0:0xdc:0xef> / node cap <0x80>

Node Index <1> / short addr <0x3> / ext addr <0xfc:0xc2:0x3d:0x0:0x0:0x0:0xdc:0xfd> / node cap <0x80>



[nid]: Use this command to get the 16 bit network id of the LPWMN manages by this coordinator

$ ./gw.exe  /dev/ttyUSB0  nid




[rfb]: Use this command to get the radio band in which the network is operating

$ ./gw.exe  /dev/ttyUSB0  rfb

865-867 MHz



[grch]: Use this command to get the specific channel number in which the network is operating

$ ./gw.exe  /dev/ttyUSB0  grch

Radio channel – 5



[srch]: Use this command to change the specific channel number in which the network will operate. This command can only be given before the coordinator is started (using the sc command).

$ ./gw.exe  /dev/ttyUSB0  srch  3




[rcf]: Use this command to get the frequency of the channel in which the network is operating.

$ ./gw.exe  /dev/ttyUSB0  rcf

865.199829 MHz



[grbr]: Use this command to get the network’s radio baud rate.

$ ./gw.exe  /dev/ttyUSB0  grbr

38383 baud



[grm]: Use this command to get the network’s radio modulation scheme.

$ ./gw.exe  /dev/ttyUSB0  grm




[rtp]: Use this command to get the radio transmit power (same for all radios in the network).

$ ./gw.exe  /dev/ttyUSB0  rtp

+10.80 dBm



[cea]: Use this command to get the coordinator’s fixed 64 bit extended address.

$ ./gw.exe  /dev/ttyUSB0  cea

Coordinator’s 64 bit (extended) address – 0xfc:0xc2:0x3d:0x0:0x0:0x0:0xe8:0xa9



[rpn]: Use this command to get the part number of the radio on the coordinator

$ ./gw.exe  /dev/ttyUSB0  rpn




[nj-dis]: Use this command to request the coordinator to stop accepting join requests from nodes.

$ ./gw.exe  /dev/ttyUSB0  nj-dis




[nj-ena]: Use this command to request the coordinator to start accepting join requests from nodes.

$ ./gw.exe  /dev/ttyUSB0  nj-ena




[nj-ena]: Use this command to find out if the coordinator is currently accepting join requests from nodes.

$ ./gw.exe  /dev/ttyUSB0  nj-sts

network join enabled/disabled



[wl-get]: Use this command to get all nodes in the “allowed-to-join” white list. If this list is not empty, the coordinator will only accept join requests from node’s on this list. On the other hand, if this list is empty, the coordinator will not disallow any node from joining.

$ ./gw.exe  /dev/ttyUSB0  wl-get

Tbl Index <0> / ext addr <0xfc:0xc2:0x3d:0x00:0x00:0x00:0xdc:0xef>
Tbl Index <1> / ext addr <0xfc:0xc2:0x3d:0x00:0x00:0x00:0xdc:0xfd>
Tbl Index <2> / ext addr <0xfc:0xc2:0x3d:0x00:0x00:0x00:0x12:0x34>



[wl-add]: Use this command to add a node to the “allowed-to-join” white list.

$ ./gw.exe  /dev/ttyUSB0  wl-add  0xfc:0xc2:0x3d:0x00:0x00:0x00:0xdc:0xef

request sent …



[wl-del]: Use this command to delete a node from the “allowed-to-join” white list.

$ ./gw.exe  /dev/ttyUSB0  wl-del  0xfc:0xc2:0x3d:0x00:0x00:0x00:0xdc:0xfd

request sent …



[wl-clr]: Use this command to empty the “allowed-to-join” white list.

$ ./gw.exe  /dev/ttyUSB0  wl-clr  

request sent …



[cfg-dpi]: Use this command to configure the frequency at which the specified node send’s sensor data to the external world (through the coordinator node). The third argument is the short address of a node and the fourth argument is the interval between consecutive sensor data messages. In the example below, the interval on node “0x2” is being set to 1 second.

$ ./gw.exe  /dev/ttyUSB0  cfg-dpi   0x2   1 

request sent …




Solar power module .. continued

We will be using the KXOB22-04X3L solar cell from IXYS.

  • Voltage (at max power output) – 1.5 V
  • Current (at max power output) – 13.38 mA
  • Max power output – 1.5 * 13.38 -> 20 mW

Let us calculate the upper limit on the amount of energy which can be produced per day by this cell assuming that the cell operates at the maximum power point for 8 hours.

20 mW * 8 -> .16 Watt-hours -> 576 joules

The V80H battery has a usable capacity of 80 mAh which translates to 80 * 1.2  -> .096 watt-hours -> 345 joules

Let us calculate the node’s power consumption. The CC1101 based node has a data rate of 38.4 kbps. Assuming packet size of 64, a packet and it’s ack will consume 20 milli-secs at max. Assuming average power consumption of (35 mA * 3 V) -> .105 W, energy consumed every time the RFD wakes up comes to .105 * 20 / 1000 -> .0021 Joules. Assuming the DC-DC converter operates at 70% efficiency, the RFD energy consumption comes out to .0021/.7 -> .003 Joules.  Let us assume that we are able to use just 1 % of the max possible solar output. This comes to 576/100 -> 5.76 Joules.  Number of times RFD can send data/receive ack comes to 5.76 / 0.003 -> 1920 which translates to a sleep duration of 86400/1920-> 45 seconds. Note that we are ignoring the energy consumed when the node is sleeping.

One thing to note is that if the node’s peak current consumption is say 35 mA, the battery’s peak discharge current will be (3 / 1.2) * 35 -> 87.5 mA, This is assuming the DC-DC converter operates at 100 % efficiency. Assuming efficiency of say 70%,  max discharge current (Ib) can be calculated as follows –

1.2 V * Ib * .7 = 35 mA* 3 V

Ib = 35 * 3 / (1.2 * 0.7)

Ib = 125 mA.

The V80H can sustain a continuous discharge of 140 mA whereas our requirement is  a burst discharge  (125 mA for 20 milli-seconds). We are covered.

Varta mentions sensor networks power supply as one of the applications for the V80H.

Let us look at the charge and discharge curves of the V80H. The curves (shown below) are given here –












As shown in the figure above, if the battery is continuously charged at 0.2 CA (which corresponds to 0.2 x 80 -> 16 mA), it will take between 7 to 8 hours for the battery to get fully charged.  If the battery is continuously charged at 0.1 CA (which corresponds to 0.1 x 80 -> 8 mA), it will take between 16 to 16 hours for the battery to get fully charged.In our design, the solar cell will be operating at 1 Schottky diode’s drop voltage above the battery voltage. The Schottky diode is used to prevent the battery from discharging through the solar cell. This Schottky diode (DB2J20900L) has a forward voltage drop between 0.3 V and 0.5 V (for currents between 10 mA and 500 mA). The solar panel will be operating roughly between (1.1 + 0.3 -> 1.4 V) to (1.4 + 0.3 -> 1.7 V).  The solar panel current should be around 11-13 mA on average (assuming good illumination). The figure also shows how the cell voltage changes when charged. It can go up to 1.5 V if charged at 15-16 mA.

Let us look at the discharge curves next.












The figure above shows the available capacity at different discharge rates. If the battery is continuously discharged at 14 mA, it’s effective capacity is above 80 Ah (battery voltage drops below 1 volt after releasing 80 mAh of it’s energy to the load). On the other hand if the battery is discharged at a high rate of 140 mA, it’s effective capacity is only 16 mAh (battery voltage drops below 1 volt after releasing  just 16 mAh of it’s energy to the load).  These graphs are for continuous loads but a sensor node operating as an RFD  will mostly consume high current (> 100 mA) in very short bursts (compared to the time the RFD spends sleeping).  I need a setup to  monitor the V80H’s output voltage with a WiSense RFD as it’s load. I will configure the sensor node to send out data at different frequency (once every second, once every 10 seconds etc) until the battery voltage drops below say 0.9 volts. This setup won’t have the solar cell.  This data will help us decide the threshold level below which node should stop using the radio or perform any other high energy activity.

Solar power module for WiSense sensor nodes

We intend to build a solar power module to power WiSense nodes operating as RFDs (reduced function devices). I am going to document this process in a series of posts. Hopefully there won’t be too many.

Let us start off with the requirements.

  1. Low cost
  2. As small as possible
  3. Low quiescent current
  4. Single Rechargeable NiMH cell (1.2 V)
  5. Should output a voltage between 3.0 V  and 3.6 V  (MSP430 and CC1101/CC2520 can operate at 1.8 V but the on board LM75B sensor requires 2.8 V)
  6. Should be able to supply at least 50 mA continuously for say 100 milli-seconds.
  7. If possible the output voltage should be configurable in steps of 0.1 V.
  8. Should allow the node’s MSP430 to monitor the battery voltage.
  9. Should shut down cleanly when the battery is depleted
  10. Should be able to come up even if battery is depleted (wait for battery to charge before powering the load).

Solar cell –  KXOB22-04X3L-ND from IXYS (Datasheet –

  • 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

Battery – V80H from Varta (Datasheet –

  • Nominal output voltage – 1.2 V
  • Usable capacity – 80 mAh
  • Max continuous discharge current – 140 mA
  • 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’s nominal voltage is 1.2 V which means we have to use a DC-DC converter to boost the voltage to 3.0 V. We are going to use the TPS61200 from TI. This IC has a configurable under voltage lock out function (UVLO) which can be used to disable the output (3.0 V) if the battery voltage falls below some level (battery is depleted). It also has a power save mode for improved efficiency at low output power. This is important since the sensor node will spend most of the time sleeping. You can look up the datasheet here –  In case the battery is completely depleted, UVLO will allow the battery to charged by the solar cell until the battery voltage climbs above the configured threshold (indicating battery has enough charge to power the load through the TPS61200). In the absence of this UVLO functionality, the system may never power up since the DC-DC will suck up all the energy provided by the solar cell while trying to boost the input voltage to 3.0 V. The battery will never get charged in this case.

The software also needs to be enhanced to take care of conditions where the battery is not completely charged. The start-up code on the MSP430 should try to keep the micro’s power consumption as low as possible until the battery voltage is determined. If the voltage level indicates that the battery is charged, only then the node should enter normal RFD mode (waking up and reading from sensors and using the radio). If the voltage level is low, the node should sleep until the battery has enough charge to support normal operations. This can be done by waking up periodically and checking the battery voltage.

When the RFD is operating normally (sleep -> wake up -> sense and communicate -> sleep), it should still monitor the battery voltage to make sure it is not near the UVLO threshold. If so, it should reduce avoid or reduce the frequency of activities which consume lot of energy such as radio transmit/receive. The RFD code should measure the battery voltage first after waking up and the battery voltage level should dictate what it should be doing next (sleep or do the usual sensing/transmission).

Stay tuned for more posts.

Internet enabled load cell

Early this year, I built a prototype of an internet enabled load cell. The idea was to have a network of load cells connected to an internet gateway through low power radios. I bought a cheap kitchen weighing machine from a local store . It had a single load cell with four strain gauges arranged in a wheatstone bridge configuration. You can learn more about these kind of load cells here “;.


The voltage signal produced by this load cell is very small (in the milli-volt range). It needs to be amplified. I used the AD7797 from analog. Since this was only a prototype, I bought an AD7797 eval module and wired it to the load  cell.  The AD7797 contains an amplifier and a 24 bit ADC. The amplifier has a fixed gain of 128.

The AD7797 is a complete analog front end for high precision bridge sensor applications such as weighing scales. The AD7797 contains a ∑-∆ ADC capable of 24-bit resolution. The on-chip instrumentation amplifier has a fixed gain of 128 so signals of small amplitude such as those from bridge sensors can be interfaced directly to the ADC.”

I connected the AD7797 to a WiSense node (over the SPI bus). I had to write a driver for the AD7797 and an app to use the driver to get the weight and report it to the external world through the WiSense coordinator.


When a load cell is not loaded, the differential output of the wheat stone bridge should ideally be 0.  The excitation voltage (Ve) is the voltage supplied to the Wheatstone bridge circuit.

V+ = Ve/2 ,     V- = Ve/2

dV = V+ – V- = 0

When the load cell is loaded with weight ‘W’ N,

V+ = (Ve*(R + dR))/(2R),    V- = (Ve*(R – dR))/2R

dV = (Ve*dR)/R 
dR is proportional to the applied load ‘W’ which means the load cell’s output “dV”  is also proportional to the applied load ‘W’

dV = K*W

Load cells have a parameter called sensitivity (S) which specifies the  output voltage of the sensor in mV per volt of excitation with full scale (Wfs) input.

If we put Wfs kgs on the load cell, then the output of the load cell will be S*Ve. That is,  S*Ve  is proportional to the applied weight (Wfs Kgs).

Ve * S  = K * Wfs

Suppose you put a weight “Wo” on the load cell and the output voltage is measured as Vo.

Vo = K * Wo

Wo can be calculated as follows –

Wo = (Vo * Wfs) / (Ve * S)

I got my load cell from a cheap weighing machine. I did not know it’s  Wfs and S values. The obvious thing to do was to see if I could output (of the load cell) proportional to different known weights. For this I used some VIM dishwash bars (200 grams each). I was pleasantly surprised to see the values consistent with the weight of the bars (from 1 bar to all 7 bars together). The load cell was unexpectedly accurate.

Assume Vo is the output of the load cell in response to applied weight Wo.  The AD7797 amplifies Vo 128 times and then converts it into a digital value.

Let Nadc be the ADC output at the end of a conversion.

    Nadc = (Vref x Nadc) / 2^23 

When input signal is bipolar, the resolution is 23 bits. The output of the load cell can be negative if the Wheatstone bridge is not perfectly balanced. The zero load output is zero volts in the ideal case.

Vo can be calculated as follows –

   Vadc = (Vref x Nadc) / 2^23

   Vo = Vadc/128

   Vo = (Vref x Nadc) / (128 * (2^23))

Here Vref is nothing but Ve (the voltage supplied to the load cell).

Vo = Ve * Nadc / (128 * (2^23))