Monthly Archives: March 2015
Today I was able to get one “Lite” node assembled and tested. This variant is intended for FFDs and RFDs. It does not have any sensors on board. Other components which are missing include the coin cell retainer and the USB interface. It has two boards instead of the three in the WSN1101N and WSN1101C.
The radio board has a U.FL connector. We will also offer a radio board with an SMA connector.
Here are some pics of the “Lite” node (WSN1101L).
Quick update on what we are up to these days.
We are working towards rolling out a WiSense low power wireless sensing/control network in Pruksa Silvana (east Bangalore) where I live. This is a new community of around 400 houses out of which around 150 are currently occupied. The idea is to use this network to provide wireless sensing and/or control throughout the community. The network will initially have a single WiSense coordinator/gateway node, multiple FFDs (full function devices which will be involved in routing) and multiple RFDs (energy constrained nodes). We are currently testing solar powered FFDs since these nodes will be installed outdoors. These nodes will have a small solar panel (max 3 Watts) charging an NiMH battery pack. This will provide enough energy to keep an FFD powered up 25/7. These FFDs will not have any sensors. Assuming an average current consumption of 25 mA, the energy usage per day comes out to 25/1000 * 3 * 86400 = 6480 joules. A 3 Watt solar panel will produce around 3 * 3600 * 3 = 32400 joules per day assuming just 3 hours of good sunlight. This is ok since we want the node to tide through a week of bad weather. The battery pack currently has three 2500 mAH NiMH cells with best case capacity of 2.5 * 1.2 * 3600 = 10800 joules.
We are going to introduce a “lite” version of our eval module suitable for routing only nodes (FFDs without sensors). Just got the bare PCBs today so I will share some pics in another day or two. This version does not have any sensors. It also does not have a USB interface. It has two boards. One is the radio board and the other is the micro-controller board. The latter has a 128 kilo-byte eeprom to support over the air firmware upgrade.
Coming back to the solar powered node, the battery pack voltage is being monitored by a voltage monitor IC. When the battery pack voltage drops below 2.7 volts, the monitor IC shuts off a load switch which is gating power to the node. When battery pack voltage climbs above 2.8 volts, the load switch is turned on. The MSP430 on the node powers on and it monitors the battery pack voltage until it climbs above 3.9 volts at which point the radio is switched on and the FFD starts operating normally. These thresholds will likely change before we are done with testing this (solar + batt) power source. We are streaming the battery pack voltage (being reported by the solar powered FFD every 10 seconds) to Xively (channel id is V_sony_batt).
This week we hooked up the LPG cylinder (used for cooking) at my house to the internet. High time these cylinders smarten up and communicate with the consumer and the utility company by themselves.
Continuous tracking of LPG consumption has some real benefits.
– Inform the consumer and if possible the utility company when a cylinder is running low on LPG. I know most ladies and elderly people do not want to change cylinders since they are heavy (around 30 Kgs when full). If they know that a cylinder is about to go low on gas, they can have it replaced when someone (who can replace the cylinder) is around.
– Leakage detection (especially when the cylinder is kept outside the house)
– Theft detection
– Automatic switch over from one cylinder to another using electronic/pneumatic valves.
LPG consumption can be easily tracked by monitoring the weight of the cyclinder. We did this by putting a load cell below the cylinder. In our demo, the load cell is connected to a WiSense node. This node is sending the weight information every minute to a coordinator node (connected to a Raspberry Pi) inside the house. The Raspberry Pi is connected to a DSL modem (my internet connection). The setup has been running for around 3 days now. The Raspberry Pi is sending the weight data to Xively. You can take a look at the weight info here – https://xively.com/feeds/379406804.
We got the load cell from Epoch instruments (Bangalore). This load cell has a resolution of a few grams and has been able to accurately track LPG consumption over 3.5 days. There is no drift (see flat lines in between).
I want to plug our smart community concept here. These “smart” cylinders can be hooked up to our community wide WiSense mesh network so that we can avoid having a gateway in each house within the community This community wide mesh network will have one or two gateways to send data to a local server within the community and/or the internet.
Here are some pics of the setup.
Pic below shows the cylinder kept outside the house. It is actually kept in an enclosure but I took it out for the demo.
In the pic below, you can see the load cell below the cylinder (two wood planks screwed to the load cell provide a stable platform for the cylinder).
Pic below shows a WiSense node (with antenna) and the amplifer/ADC board connected to the load cell. The node and the associated electronics is running on two AAA batteries (2×1.5v).
Finally (below), the coordinator node connected to a Raspberry Pi (over USB). The Pi is connected to a DSL router.
One of our customers requires an outdoor wireless mesh network which will include routing (FFD) nodes. Some nodes will be out of range of the sink node (network coordinator connected to a GSM modem) requiring the installation of FFDs in the middle. One problem is providing power these FFDs. Our customer wants these nodes to be battery powered (9 volt battery) and the battery is required to last at least 6 months. FFDs have their radio on at all times which will consume around 14 – 20 mA depending on the supply voltage, baud rate etc. Assuming the 9 volt battery has a capacity of around 300 mAH. This translates to a capacity of 9 * 300 * 3600 / 1000 = 9720 Joules. Assuming the wireless node is running at 2.2 V and has a receive mode current consumption of 16 mA. The battery will last 9720 / (2.2 * .016) = 276137 seconds which is just 3.2 day !!.
The customer’s application will generate sporadic traffic. Nodes will communicate mostly in response to external stimuli and max latency allowed is at most a minute.
Networks with this kind of traffic can benefit from the CC1101’s WOR functionality. When the CC1101 is put into WOR mode, it will go to sleep and periodically wake up (time period T0) to sniff the channel. If the channel is clear, it will quickly go back to sleep. In sleep mode, the power consumption is less than 1 microamp. If the channel is not clear (some neighbor is transmitting), the CC1101 will stay in receive mode until it detects the start of a frame within a configurable time (let us call it T1).
So, in the absence of traffic, the CC1101 will wake up but quickly go back to sleep. This allows the average current consumption to go very low (< 100 microamps) compared to the receive mode power consumption (15 mA). As usual the devil is in the details. The channel baud rate has to be low (eg- 1200 bps) and each frame will have a long preamble (24 bytes). This makes transmissions really long and energy intensive. A 61 byte MAC + APP frame along with 24 bytes of preamble, 4 bytes of SYNC and 2 bytes of CRC will take around ((24 + 4 + 61 + 2 ) * 8) / 1200 = 600 milliseconds. This implies that WOR will only work for applications in which there are as few transmissions as possible. With this data rate and long preamble, the CC1101 on any intended recipient needs to wake up only once every 133 milliseconds and still successfully receive every transmission (with 24 byte preamble).
I have started adding the WOR functionality to the WiSense stack. You can see some snapshots of the current consumption of a node whose CC1101 has been put into WOR mode. The node’s radio wakes up every 130 milliseconds to sniff the channel. Baud rate is 1200 bps.
Stay tuned for more updates on WOR. There is lot more effort involved before WOR can be deployed.