Monthly Archives: January 2015

WiSense mesh networking demo using three nodes

In this post, I am going to go over a quick mesh networking demo using three WiSense nodes (one network coordinator, one full function device (FFD) and one reduced function device(RFD)).

Note that the mode of operation of a WiSense node depends on the firmware image flashed into the node. WiSense platform has four different image types. These are –

  • Network coordinator image
  • FFD image
  • RFD image
  • Sniffer image

Under CCS, you can build each of these images by selecting the corresponding build configuration.

WiSense nodes cannot change their mode of operation at run time. For example, a node flashed with the FFD image can only operate as an FFD. It cannot change it’s mode of operation to an RFD or network coordinator at run time.

WiSense network layer employs the AODV-L routing protocol to discover routes between nodes in the network.

In this setup, I wanted the RFD to select the FFD as it’s parent node so that frames sent by the RFD to the coordinator will go through the FFD.  One practical issue which arises is ensuring that the RFD does not choose the coordinator as it’s parent node.  We can do this by keeping the nodes apart such that the RFD is not able to hear the coordinator’s transmissions and vice-versa. Ideally, we want to create a multi hop setup in which all nodes are in the same room. I don’t want to walk around to reset nodes or change batteries etc. I want all the nodes on my desk. With three nodes, this can be done easily by removing the antenna on the network coordinator and the RFD. This ensures that the the coordinator and the RFD are not able to hear each other. Both the coordinator and the RFD can hear the FFD since we did not the latter’s antenna. This forces a 2 hop network with the FFD in the middle.

The coordinator node was connected to a laptop (over USB) running the gateway application. The application on the RFD was configured to send sensor data every 1 second. The application on the FFD was configured to send sensor data every 3 seconds.

I added a fourth node (configured as a sniffer) to the network. I have pasted a snapshot of the sniffed messages. Here 0x1 is the short address if the network coordinator, 0x2 is the address of the FFD and 0x3 is the address of the RFD.

#<22513> <Thu Jan 29 02:15:25 2015> rssi<-27 dBm> lqi<47> len<56> Type<DATA> Sec<n> FP<n> AR<y> PIC<y> Seq-Nr<1728> / Dest <0x1> / Src <0x2>

#<22514> <Thu Jan 29 02:15:25 2015> rssi<-71 dBm> lqi<45> len<16> Type<ACK> Sec<n> FP<n> AR<n> PIC<y> Seq-Nr<1728> / Dest <0x2> / Src <0x1> R<-82> L<42>

#<22515> <Thu Jan 29 02:15:26 2015> rssi<-59 dBm> lqi<42> len<56> Type<DATA> Sec<n> FP<n> AR<y> PIC<y> Seq-Nr<8056> / Dest <0x2> / Src <0x3>
#<22516> <Thu Jan 29 02:15:26 2015> rssi<-27 dBm> lqi<46> len<16> Type<ACK> Sec<n> FP<n> AR<n> PIC<y> Seq-Nr<8056> / Dest <0x3> / Src <0x2> R<-55> L<43>

Interfacing the HE055T01 hall effect current sensor to a WiSense node

I want to use a small network of WiSense nodes to measure the output the solar panels installed on the roof of my house. I have 8 panels producing 2 KW peak (8 * 250 Watts). The 8 panels are arranged in two strings of 4 panels each.  I needed a current sensor to measure the current output of each string. The HE055T01 is a high quality current sensor manufactured by Electrohms in Bangalore. It can be used to measure both AC and DC currents up 50 Amps. The HE055T01 has just three terminals.

  • Terminal #1 – Postive supply
  • Terminal #2 – Negative supply return.
  • Terminal #3 – This terminal outputs a current in proportion to the measure current (1 mA per Ampere of measured current).

This sensor requires two separate power supplies (one will be the positive supply and the other will be the negative supply). The negative supply allows the sensor to measure AC currents and the direction of DC currents. he055t01_bd

The HE055T01 outputs a current (through the burden resistor) directly proportional to the current being measured (let us call it primary current).  The sensor’s conversion ratio (as specified in the datasheet) is 1000:1. This means if the primary current is 1 Amp, the HE055T01 will output 1 mA through the burden resistance. If the primary current is 50 Amps, the HE055T01 will output 50 mA through the burden resistance. The HE055T01’s output current (Is) can be determined by measuring the voltage drop across the burden resistance. The primary current is then simply (Is * 1000) Amps. The MSP430G2955 microcontroller on a WiSense node has a channel 10 bit ADC module. I used channel #0 (Pin A0 / P2.0) to measure the voltage across the burden resistance. I used a burden resistance of 70 ohms. When output current is 50 milli-amps (corresponding to primary current of 50 Amps), the voltage across the burden resistance will be 3.5 Volts. I decided to use the ADC10 internal 2.5V reference voltage. To support measurement of high currents, I decided to use an op-amp to divide the ADC input voltage by 2. I wired up a circuit and was able to successfully transmit primary current values to a laptop via an LPWMN coordinator. In this setup I was measuring the current value every second.

he0 55t01_bd_wisense.

.

.

.

.

.

.

.

.

.

.

.

The figure above shows how the sensor is interfaced to  WiSense node.

20150127_143655

This pic (above) shows the HE055T01 sensor with two turns of the wire (caarrying the primary current) going through the sensor’s center.

20150127_143701

.

.

.

.

.

.

.

.

.

.

This pic (above) shows the rig used to test the sensor (interfaced to a WiSense node).

The node is configured as a full functioned device (FFD). The instrument in the background is a DC current generator. The white proto board next to the WiSense node has a 12 V -> 3.3 V regulator and the op-amp div by 2 circuit. Two 12V wall adapters are used to provide the two supplies needed by the HE055T01. The test rig was able to accurately measure the current output of the DC current generator and transmit the measurements once per second to a laptop to which a WiSense coordinator was connected. Now I need to put all the electronics in a weather proof enclosure and measure the output of the panels on my roof. Stay tuned for more updates. References:

Interfacing the SHT10 (humidity/temperature) sensor to a WiSense node

The “SHT10” is a humidity and temperature sensor from Sensirion.

  • Voltage supply range : 2.4 V to 5.5 V (Typical 3.3 V)
  • Interface: 2 wire (CLK and DATA)
  • Humidity range: 0 to 100 %
  • Temperature range: -40 deg C to 123.8 deg C
  • Humidity accuracy:  +/- 4.5 %
  • Temperature accuracy:  +/- 0.5 deg C
  • Sleep mode power consumption @ 3.3V: Max 5 micro-watts (Typical 2 micro-watts)
  • Active mode power consumption @ 3.3V: Typical 3 milli-watts

I wasted an hour trying to communicate with it using the WiSense software I2C driver. Then I decided to take a harder look at the data sheet and found (to my relief) that this sensor is not compatible with the I2C protocol but it can be connected to an I2C bus without disrupting connectivity to any other I2C devices on the same bus. Looks like Sensirion wanted to avoid paying royalty (for the I2C protocol) to Phillips/NXP. I just wish they had this information in bold right at the beginning of the data sheet. This sensor is not cheap. I had purchased a soil temperature/moisture sensor from adafruit.com (see the pic below). This product uses the SHT10 sensor and it costed me around $50. Naturally, I got really nervous when the sensor did not respond to I2C commands.

1298-00

.

.

.

.

.

.

.

.

.

.

sht10_exp

.

.

.

.

.

.

.

.

.

.

sht10_wisense_node

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Luckily, I did not have to write too much code to support this sensor’s 2 wire (non I2C) communication protocol.  I won’t go into the details on the differences here. The driver code for this sensor (in sht10.c) is self explanatory.

The SHT10 has low active and standby power consumption which makes it suitable for energy constrained sensor networks.

The sensor offers two measurement resolutions. In the high resolution measurement mode, the sensor outputs a 14 bit temperature value and a 12 bit humidity value. This mode is the default mode. In the low resolution measurement mode, the sensor outputs a 12 bit temperature value and a 8 bit humidity value.

The time taken by the sensor to perform a single conversion depends on the resolution of the parameter being measured (see below).

  • 8 bit value – 20 milli-secs
  • 12 bit value – 80 milli-secs
  • 14 bit value – 320 milli-secs

This means temperature conversion will take 320 milli-secs in high resolution (14 bits) mode and 80 milli-secs in low resolution (12 bits) mode. Humidity conversion will take 80 milli-secs in high resolution (12 bits) mode and 20 milli-secs in low resolution (8 bits) mode. On a reduced function device (RFD) (wth limited energy source), the MSP430 should be put to sleep while the sensor is performing the specified conversion.

The driver files for this sensor are:

  • pltfrm/src/sht10.c
  • pltfrm/inc.sht1o.h

References:

Home automation applications

I was thinking of the various applications of low power wireless mesh networks in home automation particularly in the Indian context.  Here’s the list.

  • LPG leak detection
  • Track usage of LPG cylinder by monitoring it’s weight
  • Kitchen hob monitoring
  • Door monitoring (open or closed)
  • Smoke alarm
  • Control of all lights, fans, a/c etc through a smart phone (This is the most common application)
  • Connected electricity meter (Separate from the utilty/govt meter)
  • Monitor water taps (send alarm if tap open for too long)
  • Monitor water storage tanks (usually on the terrace)
  • Sub metering of heavy duty appliances (a/c, geyser, washing machine, clothes iron etc)
  • Automatic control of porch/terrace lights
  • Automatic and/or remote controlled watering of plants inside and outside the house.
  • Outside weather monitoring (Temperature, humidity, pressure etc).
  • Emergency call button for seniors
  • Intruder detection (porch, backside, terrace)
  • Wireless tags to locate objects such as wallets, keys etc.
  • Indoor air quality
  • Monitor the temperature of medicines (insulin etc)
  • Smart MCB which can report that it has tripped
  • Smart clothesline – Informs when clothes have dried (by monitoring the tension in the line. As clothes dry, the tension will go down).

I thought of the last two applications just now.

Here is what we need to support these use case scenarios –

  • Wireless mesh network (865 – 867 MHz)
  • Wi-Fi network
  • A gateway box which interfaces the wireless mesh network with the Wi-Fi network and optionally to the internet.
  • Smart phones (IOS / Android) as the user interface
  • Optional wall mounted console

I have seen some made in India home automation products which look good from the outside but the electronics is really bad quality. The software is even worse. There is no support for security (encryption/authentication), fault tolerance, over the air upgrade, mesh connectivity and so on. Surprisingly, builders are installing them. God help the end user.

Govt of India’s IOT policy

I recently came across an IOT policy document authored by the dept of electronics and information technology (DeiTY).  The highlights of this policy document are –

  1. The Indian Government’s plan of developing 100 smart cities in the country, for which Rs. 7,060 crores has been allocated in the current budget could lead to a massive and quick expansion of IoT in the country.
  2.  Some of the key aspects of a smart city will be:
    • Smart parking.
    • Intelligent transport system.
    • Tele-care.
    • Women’s Safety.
    • Smart grids.
    • Smart urban lighting.
    • Waste management.
    • Smart city maintenance.
    • Digital-signage.
    • Water management.
    • Agriculture.
    • Pollution monitoring.
  3. Acknowledges that “Several countries like US, South Korea, China among others, have taken lead in
    their preparedness for taking advantage of IoT”.
  4. Proposal’s objective is “to create an IoT industry in India of USD 15 billion by 2020″  so that “India would have a share of
    5-6% of global IoT industry”.
  5. To develop IoT products specific to Indian needs in the domains of agriculture, health, water quality, natural disasters, transportation, security, automobile, supply chain management, smart cities, Automated metering and monitoring of utilities, waste management, Oil & Gas) etc.”
  6. Develop 1 nodal agency (3 crores funding over 5 yeards) and 15 institutional/academic partners (1 crore each over 5 years).
  7. Set up a center of excellence (COE) with NASSCOM under PPP mode.  These COEs will serve as incubation centers to support start-ups, SMEs, students and other innovators based on membership and supp from  design to prototype in productizing their ideas. Expected cost is Rs 35 crores over 5 years for up to 5 centers in major cities.
  8. There is the usual blurb about introducing IOT specific courses in educational institutions, support for exhibiting products abroad etc.

All this looks good on paper but will it translate into any real action ?

What is in it for Indian start-ups in this field (including our modest efforts at WiSense) ? I don’t see any direct support for Start-ups other than through the centers of excellence (COE) proposed to be setup under PPP mode with NASSCOM. The proposal mentions incubation centers which will assist from design to prototype in productising ideas. Where is NASSCOM going to get people with this kind of expertise ? At most they can provide some office space.

Educational/research institutions do not have the urgency to show results unlike start-ups. Further, the former would be more interested in research than product development. The dept of electronics (in association with NASSCOM) can select start-ups to fund and take it from there. I may be wrong but VCs / angel investors in India are not interested in IOT startups (especially those involved in hardware development). I cannot blame them since the risk is clearly higher. The govt has to step in. It is going to be the biggest buyer (directly / indirectly) of IOT enabled products so it makes more sense for the govt to fund IOT startups.

Coming to WiSense, I do not see any other start-up in India which has actually built a working wireless mesh platform from scratch (both hardware and software) and selling it. In my opinion, hardware is not easy but software seems to be a bigger issue. Lot of start-ups (in India) struggle with developing stable bug free software. Distributed systems such as mesh networks are not easy to develop. Most people with this kind of expertise are employed in large organisations. WiSense is at a stage where it is ready to scale up. We need support to manufacture 1000 or more nodes in one shot instead of just 10 – 50 right now. One of our aims is to make WiSense the number vendor for low power wireless mesh network development kits for educational/research institutions in India. We can bring our per node cost down only if we can build in 1000 – 10000 range.  Beyond development kits, we are already helping a couple of established companies in adding low power wireless interface to their products.

Indian start-ups should also realize that there is more to IOT than wearables and home automation. The government’s IOT proposal lists lot of areas in which longer range low power wireless sensor networks can be used. The Indian reality is that only the govt has the ability to encourage the growth of the IOT sector by buying IOT enabled devices. If we are able to build for local consumption, only then we can think of exporting to other countries.

Enough of my ramblings. I hope IOT is not one more bus India misses.

References:

Solar + super cap power source testing

In my last post, I described our solar cell + super-capacitor power module. I did some more testing and graphed the voltage and light intensity recorded periodically over time. WiSense nodes have an on board light sensor (the TSL45315) which outputs the light intensity in “Lux”. The super-capacitor voltage (which is the voltage provided to the WiSense node) is measured using an ADC10 channel on the MSP430. The MSP430 has one ADC10 channel dedicated to measuring the supply voltage without using an extra pin.

The test setup had these components

  • One WiSense coordinator node
  • One WiSense node configured to operate as a reduced functionality device (RFD).
  • One Solar + Super-capacitor power supply (powering the RFD above).
  • One multi-meter to monitor the RFD voltage

The super-capacitor voltage was around 0.3 V at the beginning of the test.

The test started when the Solar + Super-cap power supply was connected to the RFD and placed in direct sun light. A multi-meter was setup to monitor the super-cap voltage.

The multi-meter showed the super-cap charging towards 2.6 Volts at which point the voltage monitor IC switched on the load cell, thus powering up the RFD.

The RFD monitored the supply voltage (every 5 seconds) till it rose above 2.8 Volts.  The RFD blinked an on board LED to indicate that it was up and running and monitoring the supply voltage.

When the supply voltage rose above 2.8 V, the RFD started the association procedure and eventually registered with the coordinator.

After association, the RFD periodically (every 5 seconds) sensed the power supply voltage and ambient light intensity and reported both to the coordinator which pushed the data to the WiSense gateway software running on a laptop. In between the RFD entered and remained in deep sleep.

The test ended when the RFD lost power because the super-cap voltage fell to 2.5 V and the load switch got turned off by the voltage monitoring IC.

The test lasted around 6.5 hours.  You can see two graphs below depicting change in voltage / light intensity with time.

jan_9_solar_sc_test_graphs

The bottom graph indicates that starting from 9:46 am, the solar cells stopped receiving any sunlight till the end of the test. The RFD remained powered by the energy stored in the super-capacitor for the next 4.5 hours till the super capacitor voltage dropped to 2.5 Volts.

The top graph shows that the first voltage value reported by the RFD to the coordinator is around 2.67 V even though the RFD waited for the super-cap voltage to climb above 2.8 V before it started the association procedure. This is because the association procedure requires the radio to be switched on for a considerable time since a joining node has to send beacon requests in all the channels (9 in the 865-867 MHz band) and wait for beacons in each channel. All this microcontroller and radio activity drained the super-cap from 2.8 V to 2.67 V even though the cells were producing power at the same time. The energy consumed by the node was more than the energy provided by the cells leaving the super-cap to pick up the slack. If the RFD firmware did not wait for the voltage to rise above 2.8 V and instead started the network association procedure as soon as the node was powered on, the node would never have been able to associate since the super cap voltage would drop below 2.5 V, thus switching power off to the node. This process will repeat endlessly as long as the solar cells are able to generate power.

Once the node started sending periodic sensor data (every 5 seconds), the super-cap voltage started rising up to a max of 3.481 V since the RFD spent the 5 second interval in deep sleep.

I used plot.ly to get the two graphs shown above. I just uploaded a text file containing time, voltage and light intensity data. “plot.ly” took the comma separated data in each line of the uploaded file and plotted a line graph. It is a really nice and extremely useful website and it just took me 5 minutes to get my graphs with no prior experience.

Solar and super-capacitor power source for WiSense nodes

We are testing a battery less solar power module for WiSense nodes operating as reduced function devices (RFDs).  An RFD spends most of it’s time in deep sleep (all components on the node are put into their lowest power modes). It wakes up now and then periodically or in response to an external stimulus. On waking up it senses and/or communicates if required. RFDs do not take part in routing. They communicate with the rest of the network through a parent node (an FFD) chosen at the time of joining. This mode of operation allows an RFD to keep it’s energy consumption to a minimum. RFDs can therefore be powered by a constrained power source such as a coin cell or a low capacity rechargeable NiMH cell assuming the application requirements can be satisfied. If an RFD is deployed outdoors, it can utilize solar power to power itself. An energy storage device is still required to get through periods of low or zero solar insolation.  The energy storage device can be a rechargeable battery or even a super capacitor.

A super capacitor is essentially a capacitor with an extremely large capacitance (usually in Farads). We are using a 2.5 F super-cap in our tests. The energy stored by a capacitor is given by  0.5*C*V*V where C is the capacitance and V is the voltage applied across the terminals of the capacitor. WiSense nodes can tolerate a maximum voltage of 3.6 V. At 3.6 V, the energy stored in a 2.5 F super-capacitor is 0.5 * 2.5 * 3.6 * 3.6 -> 16.2 Joules. Of course, not all of this energy is usable. Let us assume 1.8 V as the lowest usable voltage. The amount of usable energy is then 16.2 – (0.5 * 2.5 * 1.8 * 1.8) ->  12.15 J. How much is 12.5 J ? Let us calculate how long 12.5 J of energy can keep a node powered assuming it’s radio remains active. Let us assume that the node’s average power consumption is 30 mA and the super capacitor’s voltage drops from 3.6 V to 1.8 V.

  • Average_Voltage = (3.6 + 1.8) / 2 = 2.7 V
  • Average_Power = Average_Current * Average_Voltage = .03 * 2.7 =  0.081 W
  • Time = Energy / Average_Power = 12.15 / 0.081 = 150 seconds

So, in the absence of any energy from the solar cells, the super capacitor can keep the node powered on for only 150 seconds !!.  The super-capacitor is therefore only useful for very low duty cycle applications where the RFD spends most of it’s time sleeping. As long as solar power is available, it will keep the super-cap charged. The RFD can afford to have a higher duty cycle (wake up more frequently) when solar energy is available. When there is low or no solar insolation, the RFD has to reduce it’s energy consumption. Power management decisions (at any time) will depend on the following variables –

  • Super capacitor voltage
  • Energy required to transmit a packet
  • Energy required to perform a sensing cycle
  • Time of the day

Super capacitors have some advantages over rechargeable batteries –

  • Available energy estimation is accurate (E = 0.5 * C * V * V). NiMH rechargeable batteries (on the other hand) maintain a constant voltage for most of the discharge cycle so it is difficult to estimate the amount of energy left based on the battery voltage.
  • Number of charge/discharge cycles is very high (> 500,000 for the particular super capacitor we are using). Batteries have between 500 and 2000 cycles and need to be replaced eventually.
  • Some batteries cannot sustain the burst loads (when the node wakes up and switches on the radio). Super caps have no such limitation.

One disadvantage of super capacitors is the high cost. We are using the “EMHSR-0002C5-005R0” from “Nesscap”. This is a 2.5 F capacitor with max voltage of 5.0 V.

Coming to our test setup, we are using two solar cells (KXOB22-04X3L from IXYS) to power a WiSense node configured to operate as an RFD.  The specs are:

  • 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

super_cap_ls_node

We are using two of them connected in series. The maximum voltage across the super cap will be  2*1.89 V minus the voltage drop across a schottky diode. This comes to 3.78 V – .18 V -> 3.60 V. This is well under the max voltage (5 V) which the super cap can tolerate. This is also the maximum voltage a WiSense node can safely tolerate.

One of the requirements for this design was to avoid the use of a dc-dc converter.

We are using a load switch (from TI) which is gated by a voltage monitor (from ST). The latter monitors the voltage across the super cap. The monitor’s output controls the load switch. As long as the super cap voltage is below 2.5 V, the monitor’s output will remain low which keeps the load switch off. When the super cap voltage climbs above 2.625 V, the monitor’s output will go high which will turn on the load switch.  When the load switch is off, the load (which is the WiSense RFD) will not be powered. When the load switch turns on, the load will get power from the super cap. This circuit allows the super cap to get charged by the solar cell up to 2.625 V while the load is disconnected. Note that the MSP430 can start running at 1.8 V. We could have chosen a monitor IC with a lower threshold voltage of say 2.0 V. The voltage monitor IC has a hysteresis of just 0.125 V.  We chose 2.625 V to make sure that the MSP430 powers up and is able to run properly without any danger of discharging the super cap below the selected threshold (note the small hysteresis voltage). When the super cap voltage climbs above 2.625 V, the MSP430 powers up and starts running. The default clock on power up is 1.1 MHz (DCOCLK). The first thing the RFD firmware does is to check the super cap voltage using the on chip ADC10 channel dedicated to measuring the MSP430’s power supply voltage. If this voltage is below 2.8 V, the RFD goes to sleep, waking up every 5 seconds to monitor the supply voltage. When the supply voltage exceeds 2.8 V, the RFD starts normal operations which involves initializing the system and attempting to join the network. This was our first attempt at testing the circuit so we were very conservative wrt to the voltage levels. We might choose a lower threshold in further tests. Testing was successful. A completely discharged super cap was used and it charged up to 2.625 V before the MSP430 powered on. The RFD firmware then monitored the supply voltage till it climbed above 2.8 V at which point the RFD started the network association procedure. The RFD then associated with the network coordinator and started sending sensor data every 5 seconds. The super cap voltage increased up to 3.476 V and stayed there. The RFD sent out around 374 packets (in around half an hour) before I terminated the test.

WiSense is going to offer this solar power module as an add on to WiSense nodes.  Stay tuned for more updates.

See the test setup in the pic below (I am not good at soldering).

solar_super_cap_test_setup

Over the air firmware upgrade of deployed sensor nodes

The WiSense stack does not currently support over the air firmware upgrade. I intend to add this feature soon. I am going to go over the design and implementation of this feature in a series of posts.

One very important requirement for wireless sensor networks is the ability to upgrade the firmware on the sensor nodes which are already deployed in the field. If the network does not have this capability, it is going to be very painful to upgrade the firmware on each node in the network. Firmware upgrade may be required for the reasons listed below:

  • Bug fixing
  • Some feature may need modification
  • A new feature needs to be added
  • The application running on the node needs to be enhanced / modified

WiSense nodes are controlled by the MSP430G2955 16 bit microcontroller from TI.  The size of the on chip (MSP430G2955) flash memory is 56 KB. So, the maximum size of the firmware (including code, read only data and initialized data) can be max 56 KB. This includes the application layer.

We can divide the upgrade into two categories:

  • Update the whole firmware
  • Upgrade only the application running on the node.

The first category involves upgrading the complete firmware on a node (including the application).

The second category involves upgrading just the application. Typically WiSense nodes run a single application. This upgrade is more complicated since the new application object file has to be linked with the rest of the firmware already present in the node’s flash.

Let us list the challenges involved in implementing firmware upgrade:

  1. Get the image (the whole firmware or just the app layer) from the external world to the node to be upgraded.
  2. Support application upgrade only.
  3. The network should be able to support unicast, multicast (multiple nodes) and broadcast upgrade (all nodes).
  4. Need some external memory (i2c or SPI eeprom) to store the new image.
  5. The micro-controller should be able to support self reprogramming of the on-board flash memory using the image stored in the external EEPROM.

Let me address each of the challenges above.

  • The image can be transferred in chunks (chunk size limited by the maximum allowed MAC PDU length). There are many ways to reduce the amount of traffic required to upgrade a set of nodes.
  • Application only upgrade is more complicated. One can create a separate “app-only” section in the on-board FLASH for application code and read only data. When the node (being upgraded) receives the new application only image, it can erase this “app-only” section and write the new application image to this section. The rest of the firmware can remain undisturbed in a separate section on the flash. Rest of the firmware needs to call app layer functions indirectly (through a table of function pointers).  The application layer will have some restrictions on defining writable global variables. I am not sure at this point but looks like the application will not be able to define global writable variables. It has to define all such variables in a single structure and allocate memory for the structure during run time (app initialization).
  • Multicast upgrade can be supported by using the MAC layer multicast addressing mechanism and adding the ability to invite specific nodes to join a multicast group.
  • Broadcast upgrade can be supported by using the MAC layer broadcast address.
  • We plan to add a 128 KB I2C EEPROM to the micro-controller board. Received image chunks will be written to the EEPROM.
  • The MSP430 family allows self programming of the on board flash memory.

What if the new image contains changes in the routing protocol or the MAC layer ? We need to be really careful in this case. We want the specified node or set of nodes to rejoin the network after the upgrade otherwise what is the point. One strategy is to make sure that the new image is sent out to all the involved nodes. Then the nodes which are farthest are requested to perform the upgrade and restart followed by nodes which are closer to the coordinator and finally upgrade the coordinator itelf (if required). This way all nodes receive the new image followed by the request to upgrade.

So it looks like this is doable but as usual the devil is in the details.

WiSense network stack

WiSense_nwk_stack

Relationship between data rate, bandwidth, sensitivity etc

WiSense CC1101 radio based sensor nodes operate at 38400 bps in the 865 – 867 Mhz band (which is license free in India).

Channel bandwidth is the region of the RF spectrum occupied by a channel. The channel bandwidth required by WiSense CC1101 radio based nodes is around 113 KHz. Channel bandwidth depends on the data rate and the modulation used (2-GFSK in our case).  You can configure a WiSense CC1101 based radio network to operate at any one of 9 different channels in the 865-867 MHz band (from 865.199829 MHz to 866.799437 MHz). You can see that the  channel separation (we have chosen to use) is around 200 KHz.

The receiver bandwidth is a major factor in determining the noise floor of a channel.

Noise floor (in dBm) = –174 + 10 log10 (receiver-bandwidth)

 At 113 kHz, the noise floor will be -174 + 10 log10(113000) -> -123.5 dBm.  A radio can demodulate a received signal only if the received signal’s strength (RSSI) is above the noise floor of the channel.

Receiver sensitivity of an RF receiver is the lowest power signal which it can successfully receive. It is specified in dBm. Here’s the definition from Wikipedia – “The dBm is an abbreviation for the power ratio in decibels (dB) of the measured power referenced to one milliwatt (mW)”.

Power in dBm = 10 * (log10((Power in milli-watts) / (1 milli-watt)))

If received signal power is 1 milli-watt, the corresponding power level in dBms is (10 * (log10 (1 / 1))) -> 0 dBm. If received signal power is say 1 micro-watt, the corresponding power level in dBms is (10 * (log10 ((10^-3) / 1))) -> – 30 dBm.

A sensitivity of -112 dBm means that the CC1101 can successfully receive a signal whose power is as low as 6.309 * 10^-12 milli-watts !!!!.

Receiver sensitivity is specified at some data rate (in kilo-bits per /sec) and packet error rate (1 % in our case). 1% packet error rate implies that the receiver cannot loose more than 1 packet for every 100 packets sent by the transmitter.

Note the relationships listed below.

  1. Network throughput depends on the raw data rate (among other things).
  2. Channel bandwidth depends on the raw data rate.
  3. Receiver sensitivity depends on the channel bandwidth.
  4. Channel bandwidth determines the noise floor and thereby the receiver sensitivity.
  5. Radio range depends on radio receiver sensitivity (and also on radio transmit power).

According to the CC1101 spec, the CC1101’s sensitivity at 38.4 Kbps (at 868 MHz) is -104 dBm.

            Data Rate                       Receiver Sensitivity (at 25 deg C, 3 V supply)

  • 1.2 kBaud                               -112 dBm
  • 38.4 kBaud                            -104 dBm
  • 250 kBaud                               -95 dBm
  • 500 kBaud                              -90 dBm

The table above shows the drop in receiver sensitivity with increasing baud rate.

For a given radio output power, the radio range can be increased by increasing the receiver sensitivity of the receiver. This can be done by reducing the data rate but that increases the time for which the radio is on (thus increasing the energy consumption per message). It also increases the probability of packet corruption and collision. It all depends on the application.