Last year the sensemake.rs community started their AirQuality Monitoring and Sensing  project on kickstarter. In september the Institute for GeoInformatics (IfGI) and 52°North held a workshop together with the designers of the platform to discuss further use and evolution of this project (see post). We had the great luck to receive 20 beta devices of the AirQuality Egg.

In the last months, we tried to convert the existing approach of “balcony-mounted” devices to a more autonomous solution. Instead of the nanode-rf we connected an RFBee Wireless device (based upon an ATMEGA 168) to the SensorShield. Like the nanode, the RFBee has an Arduino bootloader and can be programmed to fit your needs. The solution we propose is equipped with a GPS receiver to provide a location;  a LiPo battery and a solarpanel provide power to the sensor-platform. By adding these components, the AirQuality Egg turns into a sophisticated Wireless Sensor Platform. Data are sent to gateways which forward it into a Sensor Observation Service (SOS).

RFBees are equipped with a feature-rich TI CC1101 Sub 1 GHz transceiver. They are running on 3.3 Volts, this means we have to step up the voltage to power the sensor shield (which runs on 5V). In addition all data-signals have to be level converted. If you don’t do level conversion you may could destroy your RFBee.
The board below the RFBee is a Grove Xbee Carrier; it provides a socket for the RFBee. All pins are broken out to a 2.54mm raster. The carrier comes with a LiPo charging circuit and an FTDI chipset to attach the RFBee to USB. It should be noted, that in contradiction to the description of the carrier the button is NOT a reset button. Instead it is connected to one of the input Pins (PD4) of the RFBee and could be considered as a “User Input Button”.

The AirQuality SensorShields’ gas sensors are measuring the resistance of the sensor. From this resistance the concentration of gases in ppb can be deduced. The methods for this have been provided by the developers of the sensor shields. Our devices are using the AirQuality SensorShield in version 1.4 (which is the bleeding-edge version of the current AirQuality Shield), though they are still equipped with different microcontroller lack the capabilities of providing data which is needed for the conversion. Although the ATMEGA 168 on the RFBee is lacking of performance to convert to ppb (a more powerful alternative to the RFBee could be a panstamp (ATMEGA 328)). Due to that, conversion is done on the gateways, which are equipped with an ATMEGA 2560 mcu.

Each of the SensorShields has a MAC-Adress IC on it. To identify the platform, the RFBee broadcasts this MAC-Adress together with the raw readings of NO_2 and CO, temperature and relative humidity and the current latitude and longitude.

Data is received by Gateways, converted (raw -> ppb) and shall be uploaded into the SOS. As we are still working on the SOS insert, data is currently uploaded to cosm (See: https://cosm.com/users/xelo) and Thingspeak (See: https://www.thingspeak.com/users/xelo/channels). The correct feed/channel IDs and API-Keys for cosm and Thingspeak are stored in files on the SD card. They can be found in folders which are identified by a CRC32-Hash of the MAC-Address. Hashing is needed as the MAC address itself is to long to be a filename on the filesystem of the SD-Card.  The information stored on the SD-Card  makes it possible that every Wireless Sensor Platform is identified and receives an own channel/feeds.

To test the sensor platform in an outdoor environment, we build an enclosure from Lego bricks, which should make use of convection inside of the enclosure to create an airflow. Cold Air should be sucked in on an openeing on the lower side, heated up on the inside, and leave the enclosure as warm air on the top.

   

Still power consumption is a crucial thing. The RFBee can go to sleep regulary and only sends a message once per minute, but the sensors must stay switched on, so that they don’t cool down. It might be, that the 6Ah battery is not sufficient to power the device for longer than 24 hours, if insufficient light is available due to clouds or long nights. The consumptions are the following:

Configuration	Consumption
Complete	0.98 VA
Without Sensors	0.28 – 0.53 VA
GPS only	0.26 – 0.29 VA
RFBee only	0.08 VA

We are open for your ideas to improve this project.

Find more TechTalk on this topic’s Wiki-Page, and checkout our initiatives Website