September 20, 2015

Which Wireless technology is right for your product

Hi all, this is our first technical update on what has been going into making your Greenopia smart kits. In this post, i am going to talk to you about ‘what wireless technology is appropriate for an IoT product’ like ours. Although the post is based on our internal process of selecting the most suitable wireless technology for greenopia version 01, the thought process and parameters we considered might be applicable for other IoT Products also.

Alright. First things first. The criteria on which are we going to evaluate the various wireless technologies are:
  1. Cost:
    As a crowd-funded product startup, this comes first. It is imperative for us to design good quality lean hardware. While prototyping is easier and cheaper these days, converting a prototype to product is a steeper curve with many cost hurdles. Hence certain technologies which might be quite promising but expensive get a backseat.
  2. zoloft no prescription.

  3. Features that could enhance User Experience:
    Now this point may vary for every product based on what is your user’s primary expectation from your product. In Greenopia, we sent out a survey to all our backers and asked them to rank the top 4 features that they like and want in greenopia. Accessing Greenopia system from a remote location emerged as a highly rated feature. So this user expectation translates into a product feature. And the technology that we choose should also support this product feature. Will explain how this helped us eliminate very promising Bluetooth Low energy (BLE) low energy modules for Greenopia version1.
  4. Support ecosystem:
    IoT is new and generally hardware is challenging. So it is never a bad idea to take in as much help as possible. This is where a well established support and software ecosystem plays a big role. Imagine you decided on a kickass wireless module at an amazing price but later discovered that it does not support all the libraries that you may require for your application. That might hurt. Hence we spent a large chunk of time, prototyping our sensor systems with the top3 technologies that we shortlisted . We asked numerous questions to the makers of these modules. The way they responded to us and the activity levels of their support forums were considered critical to trust their module as part of your product ambition. Same goes with library compatibilities and easy debugging features.
  5. Quality:
    This is a no compromise aspect yet I have listed this as the fourth criteria, just because that these days, manufacturing processes are fairly similar for most of the modules out there. Almost all of them are made in China. Most of them are based on either TI chips if it is for industrial applications or broadcom and Arm Cortex if it is a price sensitive module. Hence as long as there is a FCC certification and a reasonable amount of warranty for each of them, you will end up with fairly equal quality hardware units here.


Alright, now having laid out the criteria for evaluation clearly, lets dig deeper into each of the wireless technologies.


1. Bluetooth Low Energy (BLE)


BLE has been making waves in IoT for the right reasons. Most important reason being its low power requirement. Imagine operating your IoT product with a coin cell that costs not more than Rs.50 (~$1) for one year straight. That is incredible power for most IoT applications. Also the small form factor of BLE chips as well as the coin cell lithium battery, provides great flexibility in product form design.

Secondly BLE can ride on the power of the smartphones.

When it is paired with the smartphone, it literally can access all the features of a smartphone and the cloud. For example, in Greenopia context, a BLE based greenopia probe might pull weather data by connecting to the users phone and accordingly fine tune its plant care instructions. This might be faster and efficient than doing the processing in the cloud for a cloud connected device. So definitely BLE Is a compelling option.
BLE.NanoWe evaluated RedBear Lab’s BLE nano. We also bought and tested the cute looking Bean BLE from Bean BLE is based on LBM313 chip, while RedBear is based on Nordic nRF8001. We also tried few other native Nordic chip modules.
While we loved the design of Bean BLE and the proactive support system of RedBear Lab, we realised that a significant number of Greenopia users rated ‘accessing their smart pots from a remote location’ as a high priority feature in one of the surveys we sent out to our backers. But bluetooth will not allow that unless it is connected to a central hub that in turns connects to internet via Wifi or LAN. And a central hub based on BLE and WIFI is a separate hardware in itself and increased our cost bracket considerably.

So inspite of the many good features of BLE, we decided to drop this, until we have a central hub architecture in the future.

2. Zigbee / Sub-Ghz RF / 6LoWPAN
Sub GhZ RF and Zigbee are popular radio modules in RF toys and small remote consumer applications (RF based car lock) but not so in industrial applications (surprisingly). It has its own issues with noise, security and interference but at the same time, has many advantages for a large scale deployment of IoT Devices.
mesh hop

Lets look at the advantages first. Firstly, capability to form a mesh network. Every node in the network extends the network and connects to other nodes forming a mesh topology. For example in Greenopia, we found this mesh topology quite interesting to share the cost of central hub across many users living a multi-story apartment. Imagine the apartment complex having one or two central hub and all residents using greenopia systems through RF based smart gardening nodes in their balconies.

Secondly, it is also low power hardware. In some cases even better than BLE . So we can run this for years on a single coin cell, if we manage power efficiently. This again seemed as a wonderful feature to us. At a reasonable quantity of say 500 to 1000 pieces, the price is competitive with BLE and all other wireless modules.



But the biggest bottle neck is its dependency on a Central HUB for receiving the data from the nodes and upload them to the cloud.

So for Greenopia smart kits, we met and discussed with a couple of Wireless technology companies in Bangalore. Thanks to awesome folks in BLR IOT (shout out to Nihal, Nagasaki and Darshan) group in Bangalore who made this possible. We met with Lekha Wireless Technologies, Relysis Wireless Systems, WiSense RF and few other interesting companies working in wireless solutions. Some of them had readily available Hubs and nodes that we can build our system on. While others had very feature rich hubs which costed twice the cost of our entire Greenopia kit. So price point was a major consideration in not choosing this technology. Moreover it did not make sense for us to ask the backer to pay extra for a central hub. While the incremental cost of the second pot is cheaper, the high cost of first pot prevented us from investing on this technology at this stage.

Internally we know that we will definitely revisit this technology when the market conditions are ready or when the technology of a central hub is available at a better cost ( Come on, it should be possible, this is Simple RF and has been around so many decades). Till then we will give our old wireless friend some rest 🙂


3. WiFi

WiFi Serial Transceiver Module_01
First and foremost point about using Wifi for your product is its high power consumption. Average current load is 100mA and peak current is 300mA for some modules. For a battery operated product like Greenopia, the power consumption is a critical factor. Ofcourse, we do not want our users to be changing the batteries or recharging them as frequently as once in 3 days. But that seems quite challenging with Wifi without introducing strict power management methods.

But besides high power requirement, Wifi has distinct advantages, remote accessibility being the most obvious one. Plus it is brilliant for all high fidelity data transfer.
WiFi Serial Transceiver Module_01ESP8266 created a wave in the IoT scene with its ultra low cost wifi module (less than $5 per module) . We were very eager to try that out. We bought a bunch of ESPs and after sailing through the cumbersome Setup process, we tested it with a couple of test probes. It is great in many ways but the problem areas are:

1. Very high peak current (some sources say 300mA. But we have seen it peaking to 500mA)

2. Disconnects often in normal operation

3. Support systems are yet to mature or you better learn Mandarin.
ESPs packs a lot of promise for the future. But not yet there . And considering the fact that we have backers worldwide we felt that ESP may not be the right choice to match their expectations from Greenopia. As a crowd-funded startup operating on tight deadlines , we cannot afford extensive month long testing of these modules before making the decision of using them in our product or not. So we have to park ESP for a later version and now go with something more stable and reliable.

There comes the Particle Photon (formerly called as Spark). Particle was earlier called as Spark and they are popular for their kickstarter for their wifi module called Spark CORE. That was their first edition and they have expanded and scaled so rapidly. Now they have an impressive set of products for IoT and an all the more impressive set of software tools for IoT. We used Particle CORE in our early prototypes and found it to a superior quality hardware with amazing user experience. They have super proactive customer support and tech forum. Their flagship module is called Photon. It is Brodcom based wifi chip with ARM Cortex M3 on a small development board. We planned to use their chip directly instead of their development board. But considering the timeline we have in hand, developing the PCB from Chip level might take longer . Hence choose the development based on their Photon module directly.


We have optimised power consumption in Wifi module in the following ways:
1. Deciding on the right number of Samples per day. Plant parameters do not change rapidly within a day and hence we do not want a system that is active and powered up all time. Based on discussions with various plant experts, we arrived at a sampling frequency of 15 samples per day .
2. The time gap between two samples is one hour each. So after every sampling, the unit goes to deepSleep mode in which its quintessential current is as low as 80uA. Also the unit is put to deep sleep after 8pm, when it is dark anyway and it does not make much sense for us to measure the parameters then. The unit is programmed to wake up again at 5am in the morning and continues the hourly sampling.
Some of the calculations that we did to estimate power consumption in using Photon for Greenopia are:
Photon has been characterised with a 5V input at VIN to consume approximately 80mA when running and connected to Wi-Fi, and ~80uA when in DEEP SLEEP.

This is how we did this:
* figure out the maximum amount of time the photon will be asleep for per day and multiply by 80uA.
* 14 times a day you will be awake and sampling, you can have Wi-Fi off during this time if you power up in MANUAL mode. When you do, current consumption will be 40mA. Multiply this sampling time by 40mA * 14.
* 4 times a day it will be drawing 80mA (let’s just say 100mA) to be conservative… guesstimate that it will take 60 seconds to connect and communicate to the cloud. This is highly conservative, and will ultimately overshadow the deep sleep time.
* add these two CURRENT*HOUR values together and that’s how many Ah you are consuming per day.
* Hopefully all of your time will add up to 24 hours.

Let’s take the Wi-Fi time and just calculate that:

60s/86400s = hours per day you will awake talking to the cloud
4 * 60/86400 * 100mA = 0.000277778Ah per day

Let’s just assume you are in DEEP SLEEP all day… 24 hours (this is worst case):
24 * 80uA = 0.00192Ah per day
(I guess the DEEP SLEEP current is 10x the wake current… it’s just that much more time that it’s asleep for!)

Now how about the other sample times, let’s just say 30 seconds each:
14 * 30/86400 * 40mA = 0..000194444Ah per day

Add them all up and you get:
2.4mAh per day.

Divide this into your battery capacity size and you get how many days it will last:
500mAh / 2.4mAh = 208 days. This is kind using worst case times and best case for your battery capacity… let’s degrade the capacity to account for self discharge and the fact that the battery will stop powering the Photon at 3.6V. But let’s just say you only have 300mAh to work with…
300mAh / 2.4mAh = 125 days or 4.166 months.
We thought 4 months is a pretty good time gap between two recharges. What say?
More to come in the next blog post. Stay tuned.

Related posts

August 7, 2015

So Far…

1. We have decided to make your smart pots better. So instead of a plugged-in one, we are trying to design one that operates on batteries, so that it is absolutely portable! 2. To do so, we are testing some wifi modules for how much power they consume. 3. We have started some inhouse experiments…

by greenopia
So Far…
August 18, 0821

App Development Gst

A Few Promising Apps Of 2011 Develop Iphone App We know what it is like looking for quality content relating to a very specific subject. Most do not consider the time to look further in the search results, and they often lose out on what they need. It is usually a frequent effect of the…

by Mayukhini Pande

Free Plant-Care tips in your inbox

We love to share what we know about plants. Join our mailing list to receive the periodic plant care tips and updates on our new products. We hate spam as much as you do. So no worries. 

Thank you. Subscription successful. Will stay in touch.