Air Quality Index – Part 2; LoRaWan Sensor

As indicated in our previous post, affordable Air Quality Index (AQI) measurements could help to establish a better view and understanding on what is really happening around you as far as Air Quality. Having a consolidated view and data provided in a consistent way by many sensors, will provide a single source of accurate indication of trends as well as historical data. Different technologies could be used to transmit data to the Cloud, low power and long range being preferred. With increasing penetration of Air Quality Sensor #2LoRaWan, design of such sensor became feasible. After several long discussions, we have decided to create one. The main objective was a affordability. Virtual everyone should be able to afford it. At the same time, we do not want to “cut any corners” and we decided to measure all relevant parameters necessary to calculate Air Quality Index, just like the local Governments would do.

gases: NO2, SO2, CO and O3

particles condensation at PM2.5 and PM10.

The clean power was our secondary objective. After researching available energy sources, we have decided that solar power combined with good rechargeable battery was the most reliable source of energy for our project.

The prototypes are already collecting data across 3 continents, well still only 3 cities :). The product will be available soon through SensorsConnect web site.  The product, collects all necessary variables required to establish Air Quality Index;  In addition, temperature, humidity and GPS location are also measured. Collected measurements are sent over LoRaWan, operating in either private or public mode on European or North American bands of LoRaWan. In North American flavour, users can connect via full 64+8 mode gateway or hybrid mode gateway limited to one of the 8 sub-bands configurable via our provisioning interface. Each node will ship factory pre-calibrated and will provide a mechanism to self-calibrate in a clear Air. Configuration of measurement cycle duration, GPS mode of operation and LoRaWan specific parameters is available over LoRaWan and/or BLE (future perhaps). The GPS sensor provides location information and accurate clock for the unit. By default, GPS operates in a Mobile mode, collecting location information as often as a measurement cycle is called. In order to improve DSCF2201-Editbattery life, or simple if your device is mounted permanently at one location, GPS activity can be limited. SenseInAir® (SIA) can be re-configured to operate in a stationary or fixed position mode where only a single GPS lookup is performed in order to establish location and set unit’s internal Real Time Clock. However, having the Mobile GPS mode presents an interesting opportunity for Cities fully covered by LoRaWan. Driving around in an electric car (with the unit on your dash), could generate a virtual map of a region, indication AQI factors for all critical parts of the City. Areas and factories causing higher pollution could be easily identified and monitored.

The node will be ready for expansion. Optional (future) Zigbee interface and matching future firmware releases will accommodate additional sensors and turn it into a smart Zigbee/LoRaWan bridge. We are still contemplating if that makes sense, as it will obviously increase the unit cost. The SenseInAir® is based on STMicroelectronics STM32 series MCU designed for the Ultra-Low power mode of operation. During idle time, MCU and sensors together, consume below 1uA.  With our carefully crafted hardware design and power saving algorithms, the SensorsConnect device can operate for a long time on a single battery charge, even when sun is not cooperating. For special cases, where solar charging is not suitable as energy source, the SenseInAir® could utilize a industrial grade Lithium battery strong enough to provide several years of maintenance free operation. As I mentioned before, an optional Bluetooth LE can help with initial provisioning and/or field provisioning of the unit, however full provisioning can also be performed over LoRaWan. Units, can also be ordered with custom configuration or pre-provisioned for one of the existing LoRaWan networks, ready to be plugged in and connect without any configuration. The default profile will connect via The Things Network. Affordable cost should allow ordinary citizens to install those units in their backyards. Cities will be able to install hundreds of units  per municipality. Such array of those sensors will provide accurate map indicating changes and trends in air DSCF2205-Editquality and pollution across a City. This information could be valuable for different applications, for instance, cars could be re-directed to alternate roads should the primary roads be over polluted.  For areas without LoRaWan coverage BLE could be used to access the data locally from the single node. Additional sensors for SenseInAir® such as inside VOC ( Volatile Organic Compound), CO2 and radiation (alpha, beta and gamma) will be available at later time. The SenseInAir® will be followed by SenseInWater® and SenseInSoil® devices.

Stay tuned, in the next couple of posts, we will present SenseInAir® dashboard and will discuss sensors calibration and methods to obtain accurate data.

Z-wave versus Zigbee

As I mentioned in my last blog, I became familiar with Z-wave after I already had my Zigbee solution fully operational. It’s not that I did not hear about Z-wave but I could easily obtain Zigbee hardware and build something quickly.

Zigbee standard is controlled by Zigbee consortium, anyone can become a member of that group, however the membership is not free. In order to display Zigbee logo on your products one must be a member of Zigbee Consortium. I believe, that members also have access to sample code and some additional documentation on top of what is available to general public. On the hardware or silicon side, you have plenty of choices, starting with Texas Instrument you can also select MircroTec makers of AtMega or the chip used on your favored Arduino device. Each Zigbee silicon vendor provides also it’s respective stack, working on their and only their chips. Pricing models are different, in case of Ti, you pay a premium for Silicon, but the actual stack is free, in case of MicroTec, the Silicon is less expensive but you need to purchase a stack ( one time fee of $1k USD), in any case, those amounts are easily affordable by any commercial entity.

In case of Z-wave, you have one single company Zensys, standing behind it. Zensys is a division of Sigma Designs, so sometimes you could hear that name as a z-wave vendor. That obviously has some pros and cons. Having monopoly, Zensys can dictate the price being as high as they want it. On the other hand, interoperability is not an  issue. Single vendor issues Z-wave approval stamps and since all the code is based on the same SDK coming from a single vendor, interoperability is not so much of a challenge.

Z-wave is intended for Home Automation, all features are well defined and relatively easy to implement. In case of Zigbee, you have additional logical layer, called profile, which basically describes what Zigbee product family your product belongs to. One of those profiles is called Home Automation and that profile would be an equivalent to z-wave. If you look at some very popular products such as Hue Lights by Philips, they  also use Zigbee but they are in a different space or using different profile called Lighting profile.

Each profiles defines its respective clusters which have similar equivalent in z-wave called commands class.  Above clusters you also have endpoint type (like a light or a switch) and Zigbee standard defines mandatory and optional clusters for input and output communication. For example, the light will have light on/ off cluster define as its input as it should receive such command from its controller. Light switch will have the same cluster define as its output, as it will send such command to its controller once you press a physical switch on a wall. Optional clusters are for descriptions or additional functionality such as battery status and such.

As you can see both protocols are very similar from the high level view or at the conceptual level. Knowing Zigbee, I did not have any problems understanding Z-wave concepts

Reading this you could ask, why would one even look at Zigbee, after all Z-wave is all you want. Well, Zigbee supports two frequencies, but really only one, 2.4GHz is popular. The same frequency is used globally!!! This is critical, because one device can be sold globally!!!. In case of Z-wave, you need to deal with multiple frequencies designated for different geographic regions, even the physical micro modules you purchase from Digikey are designated for North America and the rest of the World ( actual very specific frequency can be controlled at the firmware level).

So, you have much easier interoperability vs. a single module operating globally, what is better? You should also consider fact that with the same Zigbee chips you could potentially, use different profiles for Building Automation for example. But you can not underestimate variety of choices for z-wave controllers in the Home Automation World. Zigbee choices are very limited at this point. Also, seamless interoperability between Z-wave devices can not be underestimated and this is why I would strongly recommend Z-wave over Zigbee for home automation devices.

Zigbee Game

At the beginning, I started playing as hobbyists with technologies like Zigbee and Z-wave, adding Bluetooth Low Energy to the equation shortly after.

Very quickly, I understood of all challenges and shortcomings, problems related to interoperability between vendors and types of devices ..

Let me step back to the beginning, several years ago, in my first project, I planned on integrating telephony with Home Automation. Imagine being able to call your small Asterisk PBX and using DTMF (tones) control your door lock, or perhaps water your garden. All that  just by calling your home and sending some digits from your DTMF keypad. I have decided to use Zigbee as communication protocol between a telephony device (home automation controller) and all our end points. You may ask, why Zigbee? Well, I could get all necessary software from Ti without spending a fortune, so, why not. In a couple of evenings, we designed tiny module for my IP04 and wrote a driver to control it using SPI, just to make it compatible with standard telephony modules used in IP04. For Zigbee chip, I decided on CC2530 by Ti. Together with a friend, we created a Zigbee controller to parse and interpret Zigbee messages and to control our end points. All running on a Blackfin based IP04 PBX. Quickly, we understood that this is not the right way, hard coded rules to open my door were working just fine, but this is not what Home Automation is about.

Our first disappointment? Our Zigbee module would not communicate with commercially available Zigbee controllers. Sounds familiar? If you are involved with Zigbee you probably know what I am talking about.

The actual remedy was “simple”, we just had to change the firmware to use Home Automation profile instead of a private profile we defined initially to communicate with our own controller running on the IP04. To get to that point, wasn’t however easy, as early SDK from Ti did not explain it clearly, and we end up spending countless hours sniffing and comparing our modules to commercially available ones.

To be honest, once we figured out that profile definition was causing our pain, we fixed it in a couple of hours. In the meantime, we have learnt that Zigbee is not yet very popular in Home Automation world and if we want to have access to variety of inexpensive devices we need to look at another technology, and this is how we started looking at Z-wave…

See my next blog for description of differences between those two great wireless protocols and  pros and cons from our perspective.