Skip navigation

Previous posts:

In the Air Design Challenge - Pollen & Allergen Sensing

In the Air Design Challenge - Pollen & Allergen Sensing – Post 1 (Pollen Sensor)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 2

In the Air Design Challenge - Pollen & Allergen Sensing – Post 3 (AirVantage Intro)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 4 (Preparing the InTheAir Power Board)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 5 (InTheAir Power Board)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 6 (HDC1000 Sensor)

In the Air Design Challenge - Pollen & Allergen Sensing - Post 7 (WE Direkt PCB)

In the Air Design Challenge - Pollen & Allergen Sensing - Post 8 (InTheAir application)



Thanks to all the sponsors of this contest! Special thank you to doctorcdf who has been very helpful throughout this entire challenge.

I'm very happy that I got the chance to take part in this. I made contact to some great people who were always willing to help even though they compete too.

Now, as the title suggests, my intention with this post is to just take the current project snapshot, not to end it.

This project is not complete due to very bad estimation of the required time and some missing hardware components. Anyway, I plan to finish the project - I'll continue posting about the progress until I'm done. Next up will be the detailed post about InTheAir Qt application running on a BeagleBone Black without X server.


Components status


1. BeagleBone Black with BB_View43

BBB is used as a Control Panel with current sensor readings displayed in a full-screen C++ application. I spent way too much time on trying to make touchscreen work properly but I failed - pointer kept jumping to the right side of the screen by itself. It's probably some hardware fault so I decided that I will use the screen as a regular non-touch screen and make the kiosk mode application - this could still be nice.

I setup my BBB to run Debian Linux without window manager (or X server). Qt application writes directly into the framebuffer so X server is not required (The Virtual Framebuffer | Documentation | Qt Project). This is very convenient (no unnecessary resources are being used). The application itself is fully functional but I built Qt without OpenSSL so REST requests are failing so I need to rebuild Qt before I make the detailed post on this subject. Here's a short demo of my Qt application running on the BBB:

Video 1. BBB running my InTheAir application


2. CC3200 Launchpad with custom power supply board

This component of my project was looking very nice until I got to the part where I want to use solar panel for battery charging.

The board was designed using Eagle and made by Wurth Elektronik and I'm more than happy with how it turned out. Great job and thank you sleuz for your help!


Figure 1. Connected board with TI's HDC1000 and Sharp dust sensor


My board is using two TI boost converters with fixed output voltage for 3.3V (TPS61201 | Step-Up (Boost) Converter | Converter (Integrated Switch) | Description & parametrics) and 5V (TPS61202 | Step-Up (Boost) Converter | Converter (Integrated Switch) | Description & parametrics) rails on TI Launchpad. 5V supply is used for the Sharp dust sensor. This part of circuit works fine - if I drive this part of board with 3.8V input from a LiPo battery, I get proper voltages on TPS61201 and TPS61202 outputs.

This board also includes two headers one for TI HDC1000 and one for Sharp dust sensor. I followed shabaz's advice and included a OpAmp to put the dust sensor output in the MSP430 ADC input range. Since I wasn't thinking about this problem (input incompatibility) I designed the board without taking the OpAmp into account so I had to build a small board for that and place it in the middle of the dust sensor "cable". This isn't pretty but it works (especially that epoxy connector)!


Figure 2. Small board with OpAmp for level adjustment


One more thing that wasn't well considered was the choice of pin for the dust sensor output - I selected a pin that's being used for UART Rx and since I plan to use UART later I did a small PCB modification (using X-acto knife and a piece of wire) and changed the dust sensor reading pin.


Figure 3. PCB modification


BQ25504 is where the problem is. Everything looks nice, no shorted pads, everything soldered but this part doesn't give output when I connect a charged battery (charged to ~3.8V).

I decided to leave this for a while and work on other components until I get another sample from TI.


3. FRAM Launchpad

FRAM Launchpad will be used to operate the pollen sensor. My plan is to connect FRAM with CC3200 Launchpads via UART and feed the sensor readings to CC3200. Since I'm still waiting for some essential component for the pollen sensor I didn't spend much time on the Launchpad itself apart from testing it with Energia.

As for the pollen sensor, since I don't have means for pollen sensor calibration, I plan to provide readings of "low/medium/high" type.

I did some tests with detecting dust particles using a photodiode with built-in operational amplifier (OPT101P) but I think that the sensitivity is too low for my application so I ordered separate photodiodes and operational amplifiers and read some literature on photo-sensing. This will be in my focus until I complete the project.

I would like to express my gratitude to shabaz and michaelwylie for providing very useful information and resources.

Also, janisalnis's work on dust detection encouraged me to keep working on the pollen sensor.


4. Software

Software part currently consists of Energia sketch running on CC3200 and a viewer application. This sketch currently reads the temperature, humidity and dust levels but I plan to include the pollen level as well. My initial plan was to use the collected data to operate the air purifier and automatically close window(s) depending on the sensor readings. For this I included the C MQTT library ( into my Qt application and made some test with subscribing to AirVantage's SERIAL/tasks/messages topic - this worked as advertised but I didn't connect any actuator until today.



Even though this challenge came to its end, I plan to continue working on this project since the crucial component (pollen sensor) is not produced.


Thanks Element14, Wurth Elektronik, Texas Instruments, CadSoft, Eclipse and Sierra Wireless! It's been fun!

Previous post: In-the-Air-Challenge: Air filter checking with a home-built laser+photodiode dust counter

Roadtest winners:…

Community vote: Community Choice Poll - In the Air Challenge

Although invisible, air is the most important in our lives. We can survive days without food and water, but only minutes without breathing. So we should consider air quality seriously.

It was a great pleasure to participate In-the-Air-Challenge organized by Element 14 and supporting companies.

Compared to the previous roadtests this was a difficult contest as three kinds of microcontroller development boards were supplied.

Challenge was intended towards programming of internet connectivity of microcontrollers, and Farnell shop does not contain large variety of sensors that could be bought.

Blogging appears to be the most efficent way to summarize results online. Element 14 blog is very nice as people can post questions and visitor count is also displayed.

In-the-Air Challenge:  Texas Instruments MSP 430 FR5969 launchpad

In-the-Air-Challenge:  Air Quality Sensor Box

In-the-Air-Challenge: Dust counting with Beagle Bone Black and a webcam

In-the-Air-Challenge: A sheet of laser light for 2D visualization of dust flow

In-the-Air-Challenge: Spending the 500 USD parts budget

In-the-Air-Challenge: Measuring CO2 levels during lectures with EXTECH CO2 monitor

In-the-Air-Challenge: Exploring internally NDIR CO2 monitor

In-the-Air-Challenge: NDIR CO2 meter connected to IoT via TI CC3200 Wi-Fi connectivity board

In-the-Air-Challenge: Laser-based dust counter using a photodiode, IoT connected

In-the-Air-Challenge: Air filter checking with a home-built laser+photodiode dust counter

In-the-Air-Challenge: AirSchool Project Summary

Multisensor box

I have built a box that included many cheap sensors: temperature, humidity, light, sound, air pressure, dust sensor from Sharp and electrochemical CO2 sensor. It was assembled for test of air quality in school during classes and showed that it is important to open the window  during breaks. Probably graphing data is not so essential and it would be enough to just indicate with LEDs if air is good, normal or poor. Two school students wrote their scientific report in physics about air quality sensing and presented it at school. They got promoted to a regional contest.


IMG_3988.JPG        dustCleaning room.png



CO2, infrared

Large part of roadtest budget was spent to acquire infrared CO2 detector. That is more precise than electrochemical. I interfaced it to the IoT and measured air quality at office and during meetings. As IoT provider I used Xively, the one that I had learned to use previously. AirVantage seems to be more complicated to get started with.


co2.png    co2.png

Dust detector, laser based

In one blog post  I demonstrated how to set-up Wi-Fi and webcamera on a Beagle Bone Black and it could be used to take pictures of dust flying through a laser beam. Such pictures could be sent to a server for image processing using for example LabVIEW. It appears that we swim in an ocean of dust of up to 50 particles/cm3 beig equivalent to 50 Million in a m3. For humans most dangerous are particles in the 1...10 um size that get stucked in the capillaries of lungs. Only HEPA rated filters can stop small dust. HEPA filter gets visually dark after a month. It is also nice to be able to measure particulate matter content outside the window in the city and not to depend on data from govermental agencies reporting in the newspaper just the average situation.


Laser-based dust counter that I constructed using recently available high-power blue diode laser makes it more sensitive for detection of smaller dust. This dust counter helps also my university carier as we got presentation about laser particle counter accepted in EuroNanoForum conference that wiill take place in Riga in June 2015. I was contacted by a nanosensor-on-a-chip company Applied Nanodetectors with offer to collaborate in interfacing their sensors to the IoT.


dust in the lab.png


My former Swedish boss Prof. Sune Svanberg, a great expert in optical atmospheridc pollution measurements, was complaining that the sad thing is that one could only measure pollution, but not actually improve the air. So I am happy that this time could improve the air using HEPA filters. I have now an Electrolux anti-alergy-bag on the air inlet of the lab and sliced plastic film sheets covering the door isle and preventing dusty air to come in. Result is 10-fold decrease of dust content in the room.






In summary, here are all the devices built.

musu sensori.JPG

We have presented work done at COST EuNetAir workshop in Riga March 26-27, 2015. Presentation is attached.

Students have written their science project about air quality. Their work is attached (in Latvian).

Previous Content:

In The Air: Epidose 1: Introduction

In The Air: Episode 2 - Preparing for Surface Mount Work

In The Air: Episode 3 - Surface Mount Beginnings

In The Air: Episode 4 - Inductors

In The Air: Episode 5 - PCB Design

In The Air: Episode 6 - Getting Ready For PCBs

In The Air: Episode 7 - Still Getting Ready for PCBs

In The Air: Episode 8 - SMT Population

In The Air: Episode 9: Pump Control




The original concept for this project was to develop a wireless node capable of determining PM10 and PM2.5 levels. The PM10 and PM2.5 quantities are globally recognized as the standard for measuring air quality, and as such the demand for robust embeddable modules is increasing. A CC3200 launchpad would be coupled with a particle counting sensor and a pump to create the node, and it could be embedded into any unit a user desired for monitoring air quality. I'll take you through the project progression chronologically (First blog post introduced my idea and disclosed my credentials). Below is a picture of the Air Quality Node created from a custom Booster Pack PCB and a CC3200 Launchpad. Note, the sensor and pump are not pictured.


CC3200 Launchpad showing the Particle Counting Booster Pack (click to zoom).


The Beginning

I have experience working with surface mount components, but usually I have access to expensive equipment to use such as microscopes and manual pick-and-place machines. In this case, the budget was $500 and I only had a fine tip soldering iron to solder with. I did my initial pricing research for instruments and tools and came up with a list of items to purchase (second blog post):



I ordered these parts and I revealed to the community this same list. I did this because not everyone would have experience working with surface mount and I thought it would be useful. The items were delivered promptly to me. At this point you might be wondering why the surface mount equipment was even necessary. Texas Instruments was a sponsor and had a list of suggested components to use in the challenge. All of the components were only available in surface mount packages, so it was obvious that some surface mount work was likely to occur.



I started working on the Particle Counter Booster Pack schematic and PCB, and in the meantime I did a primer on using the surface mount equipment I ordered. I made it video based, showing how to remove components and how to reflow using solder paste. WURTH ELEKTRONIK was another sponsor in this competition, and provided some really great design kits for their product line of inductors. In fact, there were so many choices it required a decent amount of investigation to select the appropriate inductor. As such, I did a blog post on the selection of inductors and which I had chosen for my design. I was doing a mixed-signal design (analog and digital) so inductive isolation/coupling was necessary. I created the graphic below to aid in my selection, and I also talked about the different benefits of each inductor type.


WÜRTH ELEKTRONIK Inductor Selection (click to zoom)


As part of the inductor post I also talked about using inductors on PCBs for such things as filtering, ground bridging, supply coupling, and buck regulators. At this point I completed my PCB design. and of course, I blogged about it. This post included text, pictures, and videos. I explained some basic PCB design guidelines and how to practically separate analog and digital portions of the circuit board. I've reproduced a 3D rendering of the board below:


3D Render of the Particle Counter Booster Pack PCB (click to zoom)


Having finished the hardware design, I completed my bill of materials and placed my orders:

  • I placed an order from Newark (Element14) for my components with my remaining budget. This included a lot of the passive devices and one function generator. I'll discuss the generator later. This order was placed on Dec 4, 2014.
  • I placed a sample order all of the ICs from Texas Instruments, but I did it through Element14. Basically, Element14 requests the samples on my behalf. Since Texas Instruments was a sponsor of this competition I used only their ICs in the design. There were a total of 8 different ICs, and I asked for 5 of each. This order was sent out around Nov 29, 2014.
  • I placed an order from Wurth Elektronik for some headers, terminal blocks, and two capacitor design kits. I can't get an exact date for the Wurth request because I did it through the E14 website and the message just says "3 months ago".


I ordered my PCBs from Seeed studio because I had already depleted my budget, and the boards were only going to be $15 USD. Wurth's capacitor design kits showed up very quickly, and the PCBs arrived in a timely manner.



It was at this point that I started waiting for things to be delivered, and while I waited I worked on what code I could for the CC3200 Launchpad. I waited until the new year (2015) before I started inquiring about my orders because there is always a holiday rush to deal with. Then one day a box from E14 showed up! I opened the box, and didn't recognize any of the parts. I e-mailed E14 about it, and it turned out they were parts for Peter Oakes' power supply project. So, my order was resubmitted. In the mean time I contacted Wurth and according to FedEx the headers and terminal blocks were delivered, but I never received them. So, they sent a new batch out, and a few days later I received them. By this time it's late in Janurary 2015, and I'm getting worried that my parts from Newark and the samples from TI won't show up in time. Other competitors were having logistics difficulties as well, and it became apparent, through another competitors digging, that there was a bigger issue at play. This other competitor called Newark directly and found out his order had been cancelled because an item was no longer in stock, but he was never notified. I was curious, so I checked the availability of my items on Newark's website and, sure enough, after I ordered my components an item had gone out of stock. It was a function generator that I needed to simulate a particle sensor. I chose a different generator and sent in my order. A short while later the generator showed up, without any of the passives I ordered.


The TI samples never showed up, so Christian (from E14) ordered them directly from Newark and had them delivered to me. Only ones available from the US distributor could be delivered in a timely manner, which meant I had to sample the others personally. That usually means a lower limit on the sample quantity. It turned out OK except for the DAC7574, which is a higher cost item (about $10 USD). I could only get one of that particular chip. The ICs showed up, but I still was waiting for capacitors and resistors from Newark. I managed to get components from work so that I could populate the board, but a lot of the components are not the correct values or right size footprint.


Populating the Board

By this time it's about February 12, 2015. (almost two and a half months from when placed my orders). I populated the board and made a video about it, which was the topic of my 8th blog post. Populating went well, and while troubleshooting some initial problems I had a few inductors blow up (see below). The board was finally powered without any shorts occurring. And, before you ask, no, I do not own a current controlled power supply, but I guarantee it's the next thing on my list!


Inductor Graveyard and Modified Particle Counter Board (click to zoom)


Getting the Hardware Working

To measure particle counts one needs to flow particles through a sensor. For flow control I opted for a PWM approach, and I blogged about that in my 9th blog post. I took a video of the PWM signal that drives the pump and showed an interrupt based approach to modifying the PWM duty cycle. I needed to make a board modification as well, so I made a video showing how to make a modification without ruining the board as part of that blog post. See above for a picture of the board mods.


I was moving at a decent pace once I had my board populated, but once I started programming the I²C devices on my board I found out my DAC7574 is dead. Well, it's outputs are dead. I'm not sure what happened to it, but it's definitely dead. The device acknowledges every command sequence I send it, but the outputs will just not turn on. The code comes from a known working library, and I've decoded the data on an oscilloscope. The next step will be to replace the chip, but I have to wait for those original samples to show up.



Hopefully you've made it through my wall of text and pictures to this section. I figure it will take about 4 weeks to finish my prototype once I receive my parts. I've got the code in place that creates the wireless node, which is easy since TI practically provides it, and I have also developed all the code to process the particle counting and determine the PM10 and PM2.5 levels. Mainly, I have to replace the DAC and get the hardware working. If you are a sponsor reading this for judging purposes, I apologize for not completing the project in the the specified amount of time, and I wish you the best of luck while reading about everyone's projects.


Until next time ...

Previous posts for this project:





This is it, the end of element14's In the Air Design Challenge. After 18 weeks of working on my project, I'm glad it's over And even though I didn't create a spectacular solution, the journey has been an interesting one.



What I Learned


This has been a challenge full of new things for me:

  • Launchpads
  • Surface mount components and soldering
  • Solar energy
  • LiPo batteries




Launchpads. I haven't fallen in love with them just yet. Problems were encountered at the beginning of the project starting with the software (week 1), and during the challenge as well (week 11).


I might be biased, as I've mainly been using Arduinos until now. But for the projects I'm working on and the requirements I have, there hasn't been something I couldn't do more easily with them. With the time constraints and the stress of getting the project to work being over soon, I'll try to take the time and explore the Launchpads in a more relaxed way, hoping to discover their potential.


Surface Mount Components and Soldering


The only previous experience I had with surface mount components and soldering, was when I removed a tiny resistor on the Gizmo 2. That is also the reason why I didn't go straight for the more complex parts like the BQ25504 and other extremely small and complex components. Once I have mastered the basics, I'll move on to the more advanced components.


I enjoyed my first hot air soldering experience very much (week 17). Seeing the solder reflow and having the components move into place was fun to see.


Solar Energy


This is my first project using solar energy. And even though I used off the shelf components like the FuelTank Boosterpack (week 3), I ordered the components required to build my own charging circuit. This will however require more research on the subject and (a lot of) practice with surface mount soldering.


LiPo Batteries


Finally, with the FuelTank Boosterpack I also used LiPo batteries in a project for the first time. I immediately made the mistake of letting the battery discharge too much (week 6), a mistake I won't repeat any time soon. It is an interesting solution to make projects portable.




I came in contact with a lot of new technologies, and even if I do not (fully) master them yet, I consider it a personal achievement. Putting all frustrations aside, I'm glad I participated and got to learn all of this!



What I Made


Over the course of the challenge, I created two things:

  • a central unit consolidating all collected sensor data
  • a solar powered, wifi enabled, remote sensor


Central Unit


The central unit is based on the Beaglebone Black with a 7" BB View LCD touchscreen (week 2) running openHAB (week 5). The Beaglebone Black is connected to the MSP430FR5969 (week 16b) using their UART interfaces. The MSP430 is in charge of the timing critical task of sending signals over RF (433MHz) to power sockets in order to turn individual filtering systems on or off. The data received by the control unit is categorised, interpreted and trended over time.

A custom enclosure was built to house the LCD touchscreen, Beaglebone Black and MSP430FR5969 with RF transmitter (week 16).

{gallery:autoplay=false} Control Unit

photo 5.JPG

Enclosure: the control units enclosure assembled and painted

Screen Shot 2015-02-22 at 13.53.16.png

Home: the landing page of the application, providing an overview of the monitored rooms

Screen Shot 2015-02-22 at 13.52.57.png

Data Collection: collected data available per room, with a debug menu providing more detailed information

Screen Shot 2014-11-27 at 14.29.55.png

Graphs: graphs are available for every measured value in hourly, daily or weekly view

photo 3.JPG

Enclosure: enclosure in the making

photo 5.JPG

Enclosure: screen fits, but enclosure needs additional layers to contain all electronics

photo 3.JPG

Testing: testing the control of a fan using the MSP430FR5969 and a 433MHz transmitter

photo 2.JPG

Enclosure: making additional layers to create depth in the enclosure


Remote Sensor


The remote sensor is built around the CC3200 Launchpad. Combined with a Fuel Tank and a custom dust sensor Boosterpack (week 13), it offers dust level monitoring, temperature measurements, battery information and solar charging. The CC3200 uses MQTT (week 4) to pass all the monitoring data to the control unit.


{gallery:autoplay=false} Remote Sensor

photo 1.JPG

Remote sensor: Attached to window for solar charging

Soldering: my adventures soldering surface mount components for the first time

Screen Shot 2015-01-25 at 19.55.14.png

Boosterpack: board design

photo (4).JPG

Boosterpack: fully populated dust sensor boosterpack

photo 1.JPG

Remote sensor: my printer giving me trouble days before the end of the challenge

photo (3).JPG

Remote sensor: solar panel and window suckers in place

photo 2.JPG

Remote sensor: the "guts" of the sensor, with a separate chamber for the dust sensor


Thank You


Finally, I'd like to thank element14 and the sponsors (Texas Instruments, Würth Elektronik, Cisco, the Eclipse Foundation, Sierra Wireless and Keysight Technologies) for the opportunity to participate in this challenge, Christian for taking care of the orders and the logistical nightmares involved, Simon Leuz for his help with kits and questions and my fellow competitors and e14 members for their valuable feedback and help over the course of this challenge. Thank you!




Before anything else, I would like to personally thank the organisers and sponsors of this challenge, and kudos to doctorcdf for the great support and ironing out issues around some duties on the kits.  This challenge has been really an exciting and productive experience.


Previous Posts

Setting up the development environment

MSP430 Development in VisualStudio

CC3200 Development in Visual Studio

BeagleBone + node.js + Visual Studio


Carbon Footprint Monitoring - Architecture

Carbon Footprint Monitoring - Sensor Nodes

Carbon Footprint Monitoring - Data Flow


Carbon Footprint Monitoring - Hardware Design

Carbon Footprint Monitoring - Printed Circuit Boards

Carbon Footprint Monitoring - Power Supplies

Carbon Footprint Monitoring - Hardware Mods

System Components

Central Hub

Carbon Footprint Monitoring - BeagleBoneBlack Quick Recipe

Carbon Footprint Monitoring - CC3200 Remote Debug Console

Emission Sensor

Carbon Footprint Monitoring - Emission Sensor

Carbon Footprint Monitoring - Emission Sensor Firmware

Carbon Footprint Monitoring - Calculating Car Emissions

Outdoor Sensor

Carbon Footprint Monitoring - Power Meter CT

Carbon Footprint Monitoring - Outdoor Sensor Enclosure

Carbon Footprint Monitoring - Interpreting Collected Data

Smart Plug / Smart Switch

Carbon Footprint Monitoring - Smart Switch/Plug

Carbon Footprint Monitoring - Smart Switch/Plug Test

Carbon Footprint Monitoring - Remote Switch/Plug Mobile Test

Cloud Platform

Carbon Footprint Monitoring - [kNow] more AirVantage

Carbon Footprint Monitoring - AirVantage REST Library

Mobile Application

Carbon Footprint Monitoring - Mobile Application

Carbon Footprint Monitoring - Mobile Application Auto Launch


Around four months ago, this design competition was kicked off with the objective of creating a solution using Internet of Things technology to sense the environment we live in and how IoT can help us build a cleaner and less polluted world. 

Reflecting on the question:

"How would you use the amazing products below to help create a cleaner, more breathable world?" -from link


And so I thought one possible way to achieve this goal is for everyone's little contribution in reducing greenhouse gas emissions. 

Currently , there are already a number of initiatives and regulations promoting the reduction of carbon footprint that mostly adopted by commercial/industrial companies around the globe.  However, it should not stop there.  With all the advancement in technology, it is now more economical to build devices that can be installed for residential applications, such as the one being proposed here: a real-time carbon footprint monitoring system, to provide awareness about the households carbon footprint and is the first step towards the reduction of CO2 emissions.  Then we can all contribute to this goal of transforming our world into a healthier place to live in.


As with anything that is to be built, the blueprint for the system was first laid out, followed by foundation laying, then building the design closely to the initial plan but allowing for modifications and slight detours along the way.  This approach has always been the practice I've used in creating a working minimum viable product.  This approach will be discussed into a bit more detail in the next sections.


During the first few weeks of the challenge and while waiting for the development kits to arrive, I started off thinking about the high level architecture which is simple and straightforward.  The image below depicts the high level architecture of the system.  Also, during this period, and since knowing the key components of the system, the software development environment were installed and configured.



From the high-level architecture, the features for each component were drafted and again another thought process about how to build a solution given the constraints of the challenge, i.e. must use provided kits and tools, limited time and budget, and the like.  For this process, pen and paper works best for me.  


Hardware Design

Pen and paper design yields to some hardware blocks and from each block the key components are identified and checked if they would meet the requirements for the system.  Datasheets, application notes and reference schematic diagrams are used to draw the schematic and design the PCB.  While the waiting for the PCBs to be manufactured and delivered, the task was shifted into some software development.



Software/Firmware Development

The key components for the system (firmware) are from Texas Instruments: CC3200 Launchpad XL, MSP430FR5969 Launchpad, and the Beagle Bone Black.  This is the first time I've worked on the CC3200 and MSP430 devices.  The very good documentation and lots of sample programs made firmware development a breeze.  It was more like building a Lego house and merely selecting which block components are necessary.  For the firmware, this was mostly the GPIO control, ADC sampling, I2C and SPI sample programs.  However for the CC3200, the TCP Socket was the most useful as it was the key for the sensor node talk to the central hub (Beagle Bone Black).


For the central hub application, this is not the first time I've used the BBB, but feeling a bit adventurous, I decided to use node.js as the coding language.  This was outside my comfort zone but thought that this is one of the unique features of BBB and was a good opportunity to brush up some node.js skills.


For the cloud platform, Sierra Wireless' AirVantage was also new to me.  The documentation is comprehensive and very much helpful.  Although, I was stuck at one point and almost gave up on AirVantage, thanks to the guys, they helped me out resolved the blocking issue.  This was a really great experience with this whole challenge, and I commend both amgalbu and tomaja for reaching out.  To give back to the community, I wrote two helper libraries to easily connect, send and receive data to AirVantage.  These libraries and other source code put as attachments hopefully will become useful to someone at some stage.


Lastly, the mobile application was written to close the loop (of a minimum viable product).  During a series of test and use of the mobile app (CO2 emission tracking), an issue was identified such that manually launching the app may be forgotten and the trip will not be monitored or will be monitored late in the trip.  This was resolved by automating the process.  That is, using a pre-programmed NFC sticker placed in the phone holder, the mobile app is automatically launched and started when the phone is placed in the holder.  This was never planned out in the beginning but imo was a great feature creep. 


Challenges and Limitations

There are a lot challenges along the way that some of them ended up into frustration and uninspiring.  Challenges such as delayed components, hardware failures, missing information, buggy software and drop date deadline are typically experienced even in larger companies.  To me though, time management is the greatest challenge.  I have to balance the time between family, work, Christmas holiday, and this project.



I am quite happy with the outcome of this challenge.  With the limited time, I was able to build a basic yet functional prototype that would monitor my daily carbon footprint.  Knowing how much is the start for me to identify areas where I could reduce this footprint.  As an example on how to reduce the footprint, idling is a big waste of energy and is usually caused by heavy traffic.  Thus, it becomes more economical and more environmentally friendly to travel when traffic is light (already a known fact).  However, using historical data, we can create algorithms to "learn" and forecast when traffic is lighter in a given week.  i.e. Mondays always have heavy traffic from 7-9 but on Tuesdays through Thursdays, traffic is only heavy from 6:45 to 8:30.  We can then adjust our daily routines and be able avoid traffic on most days of the week.

Also, with the current data set recorded in the span of one week, I have few other ideas to make this even work better, i.e. base from the power usage data, it is possible to identify the activities inside the house at any given time.

Sierra Wireless' AirVantage is a big platform and I feel like I only scratched the surface and have not gone deep into its key features.


Not all features were implemented with the given time frame and even if they were, the system has a lot of areas which it can be improved on that are detailed below:

Emission Sensor Node

    • It would be nice to make use the MSP430, BLE and CO2 sensor as initially planned to measure actual emission.  Further research is needed to accurately relate the ppm value of the sensor to CO2 emission.
    • Install a digital fuel meter or connect through the CAN bus to accurately measure fuel consumption.
    • As an additional feature, using the recorded distance traveled and CO2 emission level (via sensor), the system can send notifications to the user that the vehicle must be serviced.

Smart Plug and Smart Switch

    • The power monitoring feature (via ACS712) needs to be implemented
    • Implement ambient light sensing for the smart switch implementation
    • Report humidity and temperature sensing to AirVantage
    • Re-spin a smaller hardware that will fit inside standard wall socket flush box

Outdoor Sensor Node

    • Re-spin hardware to support additional CT sensor (i.e. for monitoring hot water power usage)
    • Report rechargeable battery state/condition
    • Report BQ25504 charging status

Indoor Sensor

    • To be fully implemented
    • Add microphone and implement some sort of voice detection to identify presence

Central Hub

    • Create additional capes for the Beagle Bone Black to support additional communication mediums, i.e. ZigBee or RF, to support additional off-the-shelf sensors

Cloud Platform

    • This improvement is more for Sierra Wireless, some of them might be implemented but I haven't had the time to dig deeper, regardless these are nice to haves
    • It would be nice to support more data series on monitoring charts, atm, it can only do 3 series max
    • It would be nice to support other charts aside from the line chart, i.e support for bar graph and pie charts
    • It would be nice for charts to support presentation of DateTime or Timespan in charts
    • Possibly the most important one, it would be ideal if there are downloadable libraries that can be used for ease of interfacing with AirVantage.

Texas Instruments

    • My personal experience with TI has always been great and the plethora of documentation and samples is just the best, and can only think of a couple improvements
    • (1) have an alternative package for the HDC1000 sensor.  It being a BGA is a real challenge to for prototyping and reworking (if even possible without destroying the chip).  Another note about this sensor, I think at its price and performance ratio, it is one of the best out there.  Well done on this one TI!
    • (2) possibly a light-featured and cheaper version of the CC3200 that can compete strongly with other WiFI SoC just wishful thinking...


For the short period of time, a working Carbon Footprint Monitoring System has been designed and developed for this challenge and to end this post (but NOT the project, as development will continue outside the scope of this challenge)  I would like to answer the posed question:


"How would you use the amazing products below (TI, Wurth Electronics, Sierra Wireless etc) to help create a cleaner, more breathable world?"

By using the amazing and awesome products and parts in this challenge and build a carbon footprint monitoring system within the realms of IoT technology, can indeed help create a cleaner and more breathable world.  With this sort of system placed in every house across the globe, we will all be aware and become cautious on our carbon footprint.  Being aware is the first step towards changing our daily routines and habits.  The smallest reduction in CO2 emission will have a great contribution in this goal.


As an example, given the 7 billion world population, and if each individual would save roughly 1kg of CO2 per day (which is roughly about 6km of travel on a 12.5l/km car efficiency) results to 7 trillion grams (7 million metric tons) of CO2 reduction per day.  To put this into perspective, using the data presented in earlier post, if each ton roughly costs $336.01 then that would be roughly $2.352 quadrillion saved per day!!! That's a lot of zeros...



Air pollution has taken a toll on everything around us and we seldom realize how our action effect the environment. This project was aimed to create a system of wireless, self-sustained sensors that can monitor air quality out doors and in doors. The initial plan was to create a solar harvesting system that would power the node and it could connect to a gateway device that would intern send data from multiple nodes to the Sierra Air Vantage Cloud. More nodes could be added as per requirement. A secondary standalone unit was also proposed that could be used as an indoor sensor node and could provide indoor air quality information via the Air Vantage Cloud service. The sponsors Element14, Texas Instruments, Wurth Electronics, Eclipse IoT and Sierra Wireless provided support along the way. A diagram of the proposed system is given below.




Work Plan

The entire project was done in phases since it had some hardware and software components. On the hardware side, TI had proposed some components such as BQ25504, HDC1000, TPS62740 and TPS61200 to name a few for use in the design. The entire system was divided into submodules as explained in the proceeding sections. Additionally, I created some tutorial like posts which I will index in one of the proceeding sub-sections.


A list of submodules is as follows


  1. Energy Harvester Module based on the TI BQ25504 and a SuperCap
  2. Energy Efficient Wireless Sensor Node based on the TI CC110L and FR5969
  3. Gateway device Based on the BeagleBone Black
  4. Standalone Sensor Node based on the TI CC3200
  5. Connectivity with the Sierra Air Vantage cloud Service.

Not all modules are finished but there are lessons learned which will influence future work.


Additionally it took me a lot of time to research sensors as many sensors in the market are NOT suitable for outdoor usage as per manufacturer recommendations.


Energy Harvester Module based on the TI BQ25504 and a SuperCap


One of the requirements of the Design Challenge was that the sensor nodes should require least bit of human intervention. Additionally, we were instructed to use certain parts such as the BQ25504 which is a energy Harvesting IC and hence a module was designed around it and TPS62740 and TPS61200 which are voltage regulators. The deviation from conventional design was to use a SuperCap instead of a battery and use the energy efficient MSP430FR5969. Hence I designed a circuit using Eagle CAD, got the passives from Wurth Electronics, Element14 and chips from TI as samples. Some parts arrived around two weeks from the dealline leaving very limited room for testing. Additionally the BQ25504 was so small that soldering it was a challenge but completed successfully. The result is shown in the image below.




It works to some extent but I had some minor issues as shown in the video below.


I want to assemble some more boards and experiment before I move on and that will take some time mainly because I have run out of chips and will request TI to supply some more. I am sure I can get it to work and will update once I do.


This module is hence parly complete due to lack of time and timely delivery of some passives.


Energy Efficient Wireless Sensor Node based on the TI CC110L and FR5969


This part is quite simple and is mainly a software segment. I used the FR5969 Launchpad along with Air Booster Packs to fabricate a wireless sensor node. With my unsuccessful attempt at making the Energy Harvester, I moved to use the TI Fuel Booster Pack and connected a solar panel to it. The code was written entirely in Energia which makes prototyping quick. There was a requirement that the system should "Sleep" when not transmitting. For this LPM3 was used along with a timer and interrupts to make sleepy delays possible making the node more energy efficient.



A potentiometer is used in place of a sensor. As a bonus, I used the TI HDC1000 and soldered on by hand. The result is as follows.




I got it to work using a buspirate but since I have to use softI2C on the FR5969 there is still a bit of debugging to be done. Just a matter of time.


This module is complete with the absence of sensors which have yet to arrive. I hope the sensor module comes through as I would like to finish this project in the future.


Gateway device Based on the BeagleBone Black


A BeagleBone Black gateway is used to send data to the AirVantage Cloud for logging. I was able to put together a custom setup with a NodeJS script to connect to the AirVantage Cloud and I wrote a tutorial in the process so that it may be useful to people in the future. Additionally, I made an Additional launchpad a wireless receiver based on the CC110L and it captures all the information from wireless node and funnels it to the BBB via USART. This data is conditioned and sent via Javascript(NodeJS) to the cloud service. The image of the setup is given below.





This module is also complete to the original intention.


Standalone Sensor Node based on the TI CC3200


One of the targets was to have a standalone Wireless Node which did not require a gateway. This is useful where only a single node is required or nodes spaced far apart are required. I used the CC3200 LP to accomplish this along with a Fuel Booster Pack. Again since the sensors are not yet available, a demo system was constructed. The code was written in Code Composer Studio and the system can talk to the cloud via MQTT. Since this node is designed to be an indoor unit, the charging can be done manually. In this case, it happens via Wireless Charging using the Wurth Electronics Wireless Power Design Kit(which I got in a previous Design Challenge. The result is shown in the following images





The basic system is working but I am using the onboard temperature sensor and logging the Fuel Tank values of Time to Empty and Time to full via MQTT. The base is ready and working.


Connectivity with the Sierra Air Vantage cloud Service


I managed to connect to the Air Vantage Cloud via MQTT and wrote a little bit about it. There is not much to it, but I hope my writing helps other in the future.


Conclusion and Future Work

Lots needs to be done at this point since I blew up some parts and got the circuit working a bit too later. Time was a crunch factor and I have learned a few lessons on project management. I will be continuing this project at my pace post challenge deadline since I want to have a project like this added to my porfolio. I am waiting for sensors to arrive and will be requesting TI for more samples. The harvester will also get an upgrade from it's current 0.1Farad SuperCap to something bigger. Every component needs a better enclosure and I hope to have some more PCBs in the future which have sensor circuits on them.


Additionally, I am studying Eclipse KURA as a gateway platform but I am not using it until I understand it a bit better. I am an EEE engineer and so my Java skills are a bit limited.


At the time of posting this Summary, I am working on more tutorials as I work.


Tutorials and Other Posts


My posts for the duration of the challenge are as follows:


Work progress and Design Posts

[Firecracker Analyser] [week 0] Project Description

[FireCracker Analyzer]: Index

[Firecracker Analyser] [week 0] Sensor Research

[Firecracker Analyzer] [week 1] System Design and ReDesign

[Firecracker Analyzer]Brief update

[Firecracker Analyzer] Another small update


Tutorial on LCD

[Firecracker Analyzer] Messing with an I2C LCD and using the BUS PIRATE


Posts on the Energy Harvester

[Firecracker Analyzer] Making the Power PCB with Eagle, TI BQ25504, TPS62740 and TPS61200

Bus pirate meets the HDC1000 Texas Instruments

Assembly intro to the Solar Harvesting Board

[Firecracker Analyzer] Hot air assembly of TI Solar Harvester

[Firecracker Analyzer] Successful QFN Assembly

[Firecracker Analyzer] Testing the Texas Instruments BQ25504 - Success?

Energy Harvester prototype Demo based on the TI BQ25504


Posts on the HDC 1000

[Firecracker Analyzer] Testing the HDC1000 on my Own board

Bus pirate meets the HDC1000 Texas Instruments


Tutorial on the CC3200

[Firecracker Analyzer] (Another) Guide to getting started with the CC3200


Tutorial on using the Air Vantage Cloud and NodeJS

[Firecracker Analyzer] Obligatory Guide - Using Sierra Air Vantage with your Device


Posts on the Launchpads and CC110L Based Wireless sensor System

Demo of working CC110L Modules with different Launchpads

[Firecracker Analyzer] Creating a Wireless Sensor Node using TI's stuff.




I would like to thank Element14, Wurth Electronics, Texas Instruments, EclipseIoT, Sierra Wireless and all the sponsors for their support and this opportunity. Special Thanks to Dr. Christian DeFeo Sir, Shabaz Sir(Cisco), Benjanine Cabe(Eclipse IoT), Crystal Lam(Sierra Wireless), Simon Leuz(TI), Peter Oakes for their support and amazing content on the forums. Very Special Thanks to all the community members for their support because without it, I would have dropped this project in a dark day.


Hope to produce more useful content in the future.




Previous posts for this project:





I needed to work on a few things before tomorrow's final summary post and challenge deadline. Here's a quick overview.




The little boosterpack I soldered last week works! I am able to make more stable measurements using the CC3200's ADC. The Energia sketch was updated to make the conversion back to the actual voltage and then convert it to dust concentration (mg/m3) based on the graph provided in the dust sensor's datasheet.


Screen Shot 2015-02-26 at 20.54.55.pngScreen+Shot+2014-12-11+at+22.14.26.png




I've also been working on the OpenHAB config to get all monitored parameters nicely categorized and organized. A debug menu has also been foreseen, providing additional values for troubleshooting purposes.


Here are some code snippets to better understand how I've created my openHAB configs.


The items file contains the monitored parameters of a remote sensor using MQTT. In the item definition below, you'll see how every item takes the value from a specific MQTT topic. The item file can easily be expanded with new items for extra parameters or extra remote sensors.


Group All

String livingroom "Living Room" <sofa>
String office "Office" <office>
String bedroom1 "Bedroom #1" <bedroom>
String bedroom2 "Bedroom #2" <bedroom>

Number FT_Voltage_Period "Chart Period"
Number FT_TimeToEmpty_Period "Chart Period"
Number FT_StateOfCharge_Period "Chart Period"
Number FT_Temperature_Period "Chart Period"
Number DS_Density_Period "Chart Period"
Number DS_Voltage_Period "Chart Period"

Number FT_Voltage "Battery Voltage [%d mV]" (All) {mqtt="<[eclipseIot:cc3200-fvan/voltage:state:default]"}
Number FT_TimeToEmpty "Battery Time to empty [%d min]" (All) {mqtt="<[eclipseIot:cc3200-fvan/tte:state:default]"}
Number FT_StateOfCharge "Battery [%d %%]" <battery> (All) {mqtt="<[eclipseIot:cc3200-fvan/soc:state:default]"}
Number FT_Temperature "Temperature [%d <C2><B0>C] "<temperature> (All) {mqtt="<[eclipseIot:cc3200-fvan/temp:state:default]"}
Number DS_Density "Dust [%.2f mg/m<C2><B3>]" <dust> (All) {mqtt="<[eclipseIot:cc3200-fvan/ddens:state:default]"}
Number DS_Voltage "Dust Voltage [%.2f V]" (All) {mqtt="<[eclipseIot:cc3200-fvan/dvolt:state:default]"}

String Launchpad "Launchpad [%s]" (All) {serial="/dev/ttyO0"}
Switch Socket "Filter" <socket>



The sitemap structures all the data in the web interface. I opted for a view per room, with every room containing all the monitored parameters. Just like the items file, the sitemap can easily be expanded to contain more rooms.


Frame {
        Text item=livingroom {
                Frame {
                        Text item=FT_Temperature valuecolor=[>35="red",>25="orange",>15="green",<15="blue"] {
                                Switch item=FT_Temperature_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
                                Chart item=FT_Temperature period=h refresh=6000 visibility=[FT_Temperature_Period==0, FT_Temperature_Period=="Uninitialized"]
                                Chart item=FT_Temperature period=D refresh=30000 visibility=[FT_Temperature_Period==1]
                                Chart item=FT_Temperature period=W refresh=30000 visibility=[FT_Temperature_Period==2]
                        Text item=DS_Density {
                                Switch item=DS_Density_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
                                Chart item=DS_Density period=h refresh=6000 visibility=[DS_Density_Period==0, DS_Density_Period=="Uninitialized"]
                                Chart item=DS_Density period=D refresh=30000 visibility=[DS_Density_Period==1]
                                Chart item=DS_Density period=W refresh=30000 visibility=[DS_Density_Period==2]
                        Text item=FT_StateOfCharge valuecolor=[>79="green",>29="orange",<30="red"] {
                                Switch item=FT_StateOfCharge_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
                                Chart item=FT_StateOfCharge period=h refresh=6000 visibility=[FT_StateOfCharge_Period==0, FT_StateOfCharge_Period=="Uninitialized"]
                                Chart item=FT_StateOfCharge period=D refresh=30000 visibility=[FT_StateOfCharge_Period==1]
                                Chart item=FT_StateOfCharge period=W refresh=30000 visibility=[FT_StateOfCharge_Period==2]
                        Switch item=Socket
                Frame {
                        Text label="Debug" icon="debug" {



The rules files contains some logic to trigger actions depending certain values. For example, when the socket's state is set to ON or OFF a specific value is sent to the MSP430FR5969 Launchpad in order to control the fan with filter. Turning the socket ON or OFF is based on the measured dust concentration.


rule "Fan Control"
     Item Socket changed
      if(Socket.state == ON) {
                sendCommand (Launchpad , "#A")
        } else {
        sendCommand (Launchpad , "#U")

rule "Dust Filtering"
        Item DS_Density changed
        if(DS_Density.state > 0.1) {
                sendCommand (Socket, ON)
        else if(DS_Density.state < 0.05) {
                sendCommand (Socket, OFF)



The events log shows that the fan is triggered to filter when the dust density reached a value higher than 0.1mg/m3.


2015-02-26 21:38:30 - DS_Voltage state updated to 3.534719
2015-02-26 21:38:30 - DS_Density state updated to 0.489120
2015-02-26 21:38:32 - Socket received command ON
2015-02-26 21:38:33 - Launchpad received command #A


The other way around works as well. When the dust density has reached a normal level again, the filtering system is stopped.


2015-02-26 21:40:10 - DS_Voltage state updated to 0.780146
2015-02-26 21:40:10 - DS_Density state updated to 0.030024
2015-02-26 21:40:10 - Socket received command OFF
2015-02-26 21:40:10 - Launchpad received command #U


Screen Shot 2015-02-22 at 13.53.16.pngScreen Shot 2015-02-22 at 13.52.57.png




Finally, I've been making progress on the enclosures for both the control unit and the remote sensor. I milled additional "layers" for the control unit, which when combined, result in an enclosure capable of holding all the electronics involved.

photo 2.JPGphoto 4.JPG


For the remote sensor, I've been running into some issues with my printer. Because the enclosure is too big for my current print platform, I split the part in two. Printing the first part went well and the result was as expected. Things started to go wrong when printing the second part. For some reason, the printer's X-axis is skipping frequently. Why this didn't happen with the first print is a mystery. I've been troubleshooting the issue, but with time running out, alternatives might need to be found. On the bright side, I now know my printer is capable of handling huge bridges without support material, which is rather nice


photo 1.JPGphoto 2.JPG

The final enclosures will be revealed in tomorrow's final summary post (because I'm still working on them).




We're about to enter the last day of the challenge! The solution works, but there are still a few details I'd like to take care of before the final submission. See you tomorrow!

Today I took down the outdoor sensor to work on the smart plug and smart switch modules.  I've ordered a few more CC3200 modules but may not arrive in time, especially that this challenge ends tomorrow, but that does not mean further development stops with it as well.


Anyways, back to this post.  My goal is to be able to remotely turn on/off an appliance from my mobile, or be able to set some triggers, i.e. power usage goes above a specific threshold, that it will turn off non-critical appliances.  Another use case, would be to schedule when certain appliances are completely turned off (no more vampire appliances at night time).



Test videos embedded below.



(Above) testing using DHC tool to validate REST command.  (Below) testing using mobile application.


AirVantage Data



The stuff presented here is just the ground framework for the smart switch and smart plug modules.  Current monitoring and reporting using the ACS712 module needs to be implemented.  The module also needs to be enclosed, for safety as it controls AC supply.  Hopefully, the demo presentation is enough to illustrate the capabilities of the Smart Plug module.



In my last post here ([Firecracker Analyzer] Creating a Wireless Sensor Node using TI's stuff.) I built up a wireless sensor node using the Anaren Air Booster Pack. They are cheap and I think I will be using these quite a lot in future projects. I wanted to use my solar harvester to power the FR5969 board but have run into issues with the boards I made and don't have any more BQ25504s to experiment with hence it has come to a halt. Instead I am now using the Fuel Booster Pack with some minor surgery to be charged by solar panels. In this post I have two things to explain.

1. To finish the code on the Wireless Node for the FR5969 and give it to you for further modification

2. Modifying the Fuel Booster Pack for Solar Power

Lets get started


Making the Wireless Node



15 - 1.jpg

I have the two launchpads setup as follows:

1. Wireless Node with the FR5969 Launchpad and Fuel Booster Pack and the Air Booster Pack

2. Station Node with the F5529LP with the Air Booster Pack

Lets start with some code.


Wireless Base Station Code


The base station code is the same as from the Energia Examples. For Demo purposes, the serial stream is connected to the USB emulated port and ot the PC. I will make one modification that will allow me to send this data to the Pins on the Board itself and then I will connect this to the Beagle Bone Black which is my gateway. The code is as follows:


*  ----------------------------------------------------------------------------
*  WirelessMonitorHub.ino - wireless monitor hub sketch using AIR430Boost ETSI driver.
*  Copyright (C) 2012-2013 Anaren Microwave, Inc.
*  This library is free software; you can redistribute it and/or
*  modify it under the terms of the GNU Lesser General Public
*  License as published by the Free Software Foundation; either
*  version 2.1 of the License, or (at your option) any later version.
*  This library is distributed in the hope that it will be useful,
*  but WITHOUT ANY WARRANTY; without even the implied warranty of
*  Lesser General Public License for more details.
*  You should have received a copy of the GNU Lesser General Public
*  License along with this library; if not, write to the Free Software
*  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*  This example demonstrates usage of the AIR430BoostETSI library which uses
*  the 430Boost-CC110L AIR Module BoosterPack created by Anaren Microwave, Inc.
*  and available through the TI eStore, for the European Union.
*  ----------------------------------------------------------------------------
*  Note: This file is part of AIR430Boost.
*  ----------------------------------------------------------------------------
*  Description
*  ===========
*  Acts as a simple receiver for a star network. The hub node can receive both
*  broadcast messages and messages directed to its assigned address. The hub
*  node should not be assigned to address 0 (broadcast address). To create an
*  additional network, simply change the hub address.
*  ----------------------------------------------------------------------------
*  This example assumes that two BoosterPacks will be used to showcase the
*  wireless radio communication functionality. This same code should be
*  programmed to both LaunchPad development kits.
*  This BoosterPack relies on the SPI hardware peripheral and two additional
*  GPIO lines for SPI chip-select and GDO0 for packet handling. They use pins 18
*  and 19 respectively.
*  In the default configuration, this BoosterPack is not compatible with an
*  external crystal oscillator. This can be changed, if necessary, and would
*  require reconfiguration of the BoosterPack hardware and changes to the
*  AIR430BoostETSI library. Refer to the BoosterPack User's Manual if necessary.
*  ETSI regulations must be followed when using this library. This example
*  limits the wireless duty cycle to 0.1% per ETSI.
*  For complete information, please refer to the BoosterPack User's Manual
*  available at:
*  To purchase the 430Boost-CC110L AIR module BoosterPack kit, please visit the
*  TI eStore at:

*  The AIR430BoostETSI library uses the SPI library internally. Energia does not
*  copy the library to the output folder unless it is referenced here. The order
*  of includes is also important due to this fact.
#include <SPI.h>
#include <AIR430BoostETSI.h>

// -----------------------------------------------------------------------------
*  Defines, enumerations, and structure definitions

#define ADDRESS_LOCAL    0x01

*  sPacket - packet format.
struct sPacket
  uint8_t from;          // Local node address that message originated from
  uint8_t message[59];    // Local node message [MAX. 59 bytes]

// -----------------------------------------------------------------------------
*  Global data

struct sPacket rxPacket;

// -----------------------------------------------------------------------------
// Main example

void setup()
  // The radio library uses the SPI library internally, this call initializes
  // SPI/CSn and GDO0 lines. Also setup initial address, channel, and TX power.

  rxPacket.from = 0;
  memset(rxPacket.message, 0, sizeof(rxPacket.message));

  // Setup serial for debug printing.

  *  Setup LED for example demonstration purposes.
  *  Note: Set radio first to ensure that GDO2 line isn't being driven by the
  *  MCU as it is an output from the radio.
  pinMode(RED_LED, OUTPUT);      // Use red LED to display message reception
  digitalWrite(RED_LED, LOW);

void loop()
  // Turn on the receiver and listen for incoming data. Timeout after 1 seconds.
  // The receiverOn() method returns the number of bytes copied to rxData.
  if (Radio.receiverOn((unsigned char*)&rxPacket, sizeof(rxPacket), 1000) > 0)
    digitalWrite(RED_LED, HIGH);
    Serial.print("FROM: ");
    Serial.print(" MSG: ");
  digitalWrite(RED_LED, LOW);

  // Note: This sketch never transmits so no additional delay required to meet ETSI
  // requirements.


In the above code, instead of Serial, we will use Serial1 which will cause the data to be sent over USART1 which is the Pins on the LP. Thats it! The LED will blink every-time data is received allowing us to debug.


Wireless Node


The code for the wireless node is also very simple, but is a bit tricky since the FR5969 shares PINs when it comes to the I2C and SPI. My problem is that I have the sensors and Fuel Booster Pack talking over the I2C and the CC110L talking over the SPI bus which causes a conflict. The solution is to have a soft I2C which I can just bit bang. I got a library from the 430oh forums but faced some issues with it. The second problem is that the Fuel Booster Pack has the I2C pins on the wrong side hence I need to do a little modificaion as follows.

Fuel Tank Modification


Below are some images of the modifications I made to the Fuel Tank.







As you can see, the I2C lines traces are cut on the PCB and then wires are used to reconnect them to the appropriate pins. Additionally I soldered some wires for the Solar Panel from the GND and Charge In test points. Simple.


Node Code


Before I give you the code, I will explain a few things about it. The base code is the same as the demo code from energia. I added a soft Serial Library but faced some problems while using it. I also added some code to add my data to the packet which will be sent across.

One major change here is that I have a sleep function that allows me to take the FR5969 into LPM3 which means the timer is active and everything else is shutdown. The function was taken from the forums as well and modified a bit to work with the FR5969

Here is the code.


* Description: This file is part of the Air Quality Sensor Project. Parts of the
* code have been forked from the Demo code for the ANaren Booster Packs.
* --
* Copyright (C) 2014 Inderpreet Singh(,
  Thought Process Designs
* Web      :
* This software may be distributed and modified under the terms of the GNU
* General Public License version 2 (GPL2) as published by the Free Software
* Foundation and appearing in the file LICENSE.TXT included in the packaging of
* this file. Please note that GPL2 Section 2[b] requires that all works based
* on this software must also be made publicly available under the terms of
* the GPL2 ("Copyleft").
* We put a lot of time and effort into our project and hence this copyright
* notice ensures that people contribute as well as each contribution is
* acknowledged. Please retain this original notice and if you make changes
* please document them below along with your details.
* The latest copy of this project/library can be found at:
// ----------------------------------------------------------------------------
#include <SPI.h>
#include <AIR430BoostETSI.h>
#include <I2C_SoftwareLibrary.h>
#define SCL_PIN P3_5
#define SDA_PIN P3_6

// -----------------------------------------------------------------------------
*  Defines, enumerations, and structure definitions

#define ADDRESS_LOCAL    0x02
#define ADDRESS_REMOTE  0x01

*  sPacket - packet format.
struct sPacket
  uint8_t from;          // Local node address that message originated from
  uint8_t message[59];    // Local node message [MAX. 59 bytes]

volatile unsigned long delaycounter;

void StartTimer()
    //To use the VLO, Use the following:

    //BCSCTL &= ~DIVA_3;      // ACLK without divider - nominally 12kHz
    //BCSCTL3 = (LFXT1S_2);    // Source ACLK from VLO
    TA1CCTL0 = CCIE;        //  CCR0 interupt activated
    TA1CCR0=11999;          // 12000 ticks is nominally 1 second
    TA1CTL = TASSEL_1 | ID_0 | MC_1; // Clock for TIMER = ACLK, No division, up mode

  //Alternatively to use the Crystal for more accuracy use the Following
    P2SEL |= (BIT6 | BIT7); // Reset P2_6 & P2_7
    BCSCTL1 &= ~DIVA_3;    // ACLK without divider - 32768kHz
    BCSCTL3 = (LFXT1S_0 | XCAP_3);// Source ACLK from XTal
    TA1CCTL0 = CCIE;            //  CCR0 interupt activated
    TA1CCR0=4096-1;      // we are dividing clock by 8, so 4096 ticks = 1 second
    TA1CTL = TASSEL_1 | ID_3 | MC_1; // Clock for TIMER = ACLK, By 8 division, up mode

void StopTimer()

//Set Up the Interrupt routine...
void timer_isr (void)
        ++delaycounter;        //increment our seconds counter
        __bic_status_register_on_exit(LPM3_bits); //exit at full power.

//And here is our delay function...
//this will create delays of up to approx 136 years
//with 1 second resolution.
void longdelay(unsigned long delayseconds)
  StartTimer();                    //start our timer up
  while (delaycounter<delayseconds)  //while we haven't reached our count...
    __bis_status_register(LPM3_bits+GIE); //switch back to LPM3.
  StopTimer();                      //times up, stop our timers.

// -----------------------------------------------------------------------------
*  Global data

struct sPacket txPacket;
SoftwareWire Wire(SDA_PIN, SCL_PIN);

void confHDC1000(void){

void readTemp(void){
  Wire.requestFrom(0x43, 4);
    Serial.print(c, HEX);

// -----------------------------------------------------------------------------
// Main App Code

void setup()
  // The radio library uses the SPI library internally, this call initializes
  // SPI/CSn and GDO0 lines. Also setup initial address, channel, and TX power.

  txPacket.from = ADDRESS_LOCAL;
  memset(txPacket.message, 0, sizeof(txPacket.message));

  // Setup serial for debug printing.

  *  Setup LED for example demonstration purposes.
  *  Note: Set radio first to ensure that GDO2 line isn't being driven by the
  *  MCU as it is an output from the radio.
  pinMode(RED_LED, OUTPUT);      // Use red LED to display message reception
  digitalWrite(RED_LED, LOW);

void loop()
  int i;
  int temperature, humidity, dust;
  digitalWrite(RED_LED, HIGH);
  // Carpet bom with zeros
  for (i = 0; i <= 0x2A; i++)
    txPacket.message[i] = 0x00;
  // Fill In packet Data Here
  /* TO-DO
  Need to get sensor data and fill it here
  sprintf((char*)txPacket.message, ":T%dCH%d\%D%d#", temperature, humidity, dust);
  // Transmit Data Here
  Radio.transmit(ADDRESS_REMOTE, (unsigned char*)&txPacket, sizeof(txPacket));
  digitalWrite(RED_LED, LOW);


The node will essentially read sensors, create a packet, send the data and go to sleep. The original author says we can make it sleep for a LONG time so feel free to experiment with it and let me know how that goes. The library is attached at the bottom.



Here is the screenshot of the console. Not very interesting but this is what is received by the base station...


It can be seen that temperature, humidity and dust values arrive in ascii format. This is useful for debugging and we can use javascript to extract what we want easily. Our gateway is running NodeJS as shown in my blog post

[Firecracker Analyzer] Obligatory Guide - Using Sierra Air Vantage with your Device

and we will use some JS to do the rest.


At this point, our Node and Base station is ready. I don't have the sensors but its a simple matter of either I2C reading or analog reading which can be done according to the sensor selected



I hope this helps anyone wanted to make a wireless sensor node in the future. In my next post, I will connect it the the BBB vs JS and then allow the data to be sent to Sierra wireless.




The outdoor sensor module has been collecting data for the past few days now and am quite happy with the results.



From the graph of mains power consumption, aside from knowing how much electricity is used and the carbon footprint is, I was able to observe the following.

  • The peak on the 23 Feb at about 7pm was actually around dinner time and that peak would be possibly caused by the preparing the food and having a few friends come over.  At around 8pm that night, the consumption began to drop as people started leaving.
  • From 10pm of 23 Feb to about 5am then next day, power consumption is lower and has somewhat flat, indicating not much activity, we were all sleeping at this point.
  • 6 am 24 Feb, there is this spike again, people are awake and are getting ready for work and school.  After that, its pretty much flat across the day,  No one is at home during this period.
  • Last two days (25 and 26 Feb) are possibly our typical consumption.  25 Feb, consumption starts to drop around midnight, that's when I usually hit the bed and sleep, the power consumption drops and stays for while until around 4am, time to wake up and do a bit more design challenge stuff. 



By monitoring and analyzing power usage, we can identify causes of peaks, helping us in our decision making on how to further reduce energy consumption and lowering carbon footprint.  At the same time, from this historical data, the household behavior can be mapped out.


Mapping the household behavior can be a double-edged sword. The best part is knowing and relating what could possibly be happening at home while at the office, i.e. seeing some spikes around 3-4pm could mean the kids have arrived home from school.  But at the same time, if this data has been tapped by malicious individuals, it can be used to determine patterns at which the house is usually quiet (i.e. no one is at home) and posts security threats.

All Previous Posts



I had initially planned to make an evergy harvester circuit around the BQ25504 which was one of the parts from Texas Instruments for this challenge. I managed to assemble one board partially since the size was so small that I managed to destroy three chips before getting one to work. Once I got it to work, I posted some information about my results. Related posts are

In this post I present a video demo of the circuit.


The Video

THe first thing is to present the working circuit with the issues I am facing.

The thing that I did not mentioned in this video is that the Cap charges to 3.8V or so which may be one reason for the output being disabled.


Next step


I have put this circuit on the back burner and wanna request for more samples of the BQ25504 to assemble more boards and compare them. Right now I am stumped! I will be copmpleting the rest of the build using TI's Fuel Tank booster packs but will come back to this once I have more boards built up.





This will probably be my last post  for this challenge as I will leave tomorrow morning for a business strip and returning next monday.

hen I experiment, when I test new components and ideas, and also every time I fail, I have fun. So this challenge was really funny to me!


This is my second challenge. The first one (ForgetMeNot) was bit disappointing to me because I have not been able to focus on the challenge requirements. On the contrary in this challenge, in my opinion, I met the requirements and I have been able to work out a working project (obviously with all the limitations due to both limited time frame available and limited personal skills). In more detail


Use of components and services from the sponsors


Texas Instruments


The MSP430FR5969 is the heart of the AirMobile sensor. It's really a good MCU, shipped with good development tools. "Thanks" to delays in the shipping of some components, I had the opportunity to dig into some interesting feature like FRAM retention, in-RAM execution and code protection


Wurth Elektronik


From Wurth, I got the transformer for interfacing the Peltier cell to the step-up converter. Also, they made the AirMobile sensors PCB. In this case, I appreciated the quality of the PCB and the timely delivery




All the data is stored to and retrieved from the Sierra AirVantage cloud infrastructure. Even if I initially was a bit perplexed because it was not possible to subscribe to data changes, I then realized the rationale behind that choice. Use of REST API make the AirVantage cloud easily accessible from any platform. Also the use of an XML document to describe data assets makes the tool easy to configure for your own application






Low maintenance


The requirements asked for "low maintenance (for example no need for battery)". I tried to push this requirement to the extreme by completing removing batteries and rely only on energy harvesting. Should I go back in time, I will add a backup battery. According to the experience I made, energy harvesting through a Peltier celle is not enough to provide reliable operations in all conditions. Even If I designed the board to use delta-T on Peltier cell's faces as low as 30 degrees, I think it would be very difficult to achieve this in a hot summer day. Also, operations are unreliable when you slow down and there is not enough airflow to cool down the cold face of the cell


Smartphone app


With some minor changes, I adapted an existing application to push data to AirVantage cloud. App lloks good and provides a lot of interesting features




Thanks to the OpenHAB platform, adding automation based on collected data was not a huge task. I developed two bindings: one to get data from the AirVantage cloud and one to drive a servo control

In this post, a complete overview of the implemented solution will be provided


Data collection

The first step is to collect data by simply driving around while the smartphone app records data



Pushing data to the cloud

When data is stored on smartphone, t can be analyzed on the msartphone itself and eventually pushed to the AirVantage cloud



Data visualization

Data store in the AriVantage cloud can be seen by means of a web application. Here only a quick overview is shown. For details about the data map, please check this post




Using data read out from the AirVantage cloud, it's possible to create automatic controls. In this example, I show how to drive a servo control to move a gauge. In a real application, an output could be driven to close an air intake or to adjust the speed of a fan


After recording this video, I closed down the bonnet with the intent to go around and collect some data. But as soon as I closed the bonnet, AirMobile sensor disconnected from the smartphone. I reopened the bonnet, and connection was back

The problem was clear, the reason less. I didn't expect the steel of the bodyshell to shield Bluetooth 2.4 GHz frequencies to that extent

In my opinion, the possible causes could be


Antenna / module position: the Bluetooth module was placed between the LaunchPad board and the AirMobile board. While the LaunchPad has a ground plane, the AirMobile hasn't. But the LaunchPad in on the "line of sight" between the Bluetooth module and the smartphone, so the ground plane could actually act as a shield

Bodyshell grounded: the steel the bodyshell is made of shields Bluetooth frequencies more than I expected because the bodyshell connected to the ground. I assumed that the simple equation "tyre = rubber = insulation" is not completely true. I found out that tyre's compound contains a certain amount f graphene (to reduce internal friction and hence fuel consumption) and graphene is a conductor...

High-frequency noise due to sparks: the last hypothesis is that high frequency noise are produced by the electrical system of the engine, in particular by the high voltages involved in generating sparks


Because I was not able to determine the root cause, I moved the Bluetooth module outside the case and placed it directly on the bonnet in a protective bag



Continuing from the last post, I created a (Windows Phone) mobile application that is largely based from this article and modified for use with the proposed system.  The UI will be very simple and will display the core metrics as defined in AirVantage application model.



The key metrics that I wanted to capture are :

  • Current Speed
  • Distance traveled
  • Travel Time
  • Idle Time
  • CO2 footprint


The code logic for the application is pretty straightforward as outlined below.

mobile app.png

And translated as code below:

private void UpdateMetrics(Geocoordinate geocoordinate)
    int thisTick = Environment.TickCount;
    /* Update travel time */
    int tickLapsed = thisTick - _timeLastPositionChanged;
    _travelTime = _travelTime.Add(TimeSpan.FromMilliseconds(tickLapsed));

    double speed = geocoordinate.Speed.HasValue ? geocoordinate.Speed.Value : 0;

    /* Speed is reported in meters/sec */
    if(geocoordinate.Speed.Value < MIN_SPEED || geocoordinate.Speed.HasValue == false)
        /* speed is below minimum speed or has not been reported, this could indicate we are at idle */
        _idleTime = _idleTime.Add(TimeSpan.FromMilliseconds(tickLapsed));

    double travel = Haversine.Distance(
                        new Position() { Latitude = geocoordinate.Point.Position.Latitude, Longitude = geocoordinate.Point.Position.Longitude },
                        new Position() { Latitude = _lastGeocoordinate.Point.Position.Latitude, Longitude = _lastGeocoordinate.Point.Position.Longitude },

    _distanceTravelled += travel;

    double co2 = ((_distanceTravelled / KM_PER_LITER) * CO2_KG_PER_LITER);
    _co2 = co2;
    /* Update UI components */
    Map.Center = geocoordinate.Point;
    Speed.Text = "Speed: " + (speed * 3.6).ToString("0.0") + " kph";

    TravelTime.Text = "Travel Time: " + _travelTime.ToString(@"hh\:mm\:ss");
    IdleTime.Text = "Idle Time: " + _idleTime.ToString(@"hh\:mm\:ss");
    Distance.Text = "Distance: " + _distanceTravelled.ToString("0.0") + " km";

    if (co2 < 1)
        Co2Level.Text = "CO2: " + (co2 * 1000).ToString("0") + " gms";
        Co2Level.Text = "CO2: " + (co2).ToString("0.000") + " kg";         

    double distanceSinceLastRender = Haversine.Distance(
                new Position() { Latitude = _lastGeoPoint.Latitude, Longitude = _lastGeoPoint.Longitude },
                new Position() { Latitude = geocoordinate.Point.Position.Latitude, Longitude = geocoordinate.Point.Position.Longitude },

    /* add data point to map line */
    if (distanceSinceLastRender > 0.010)
        _mapLine.Path = new Geopath(_geoPositions);   
        _lastGeoPoint = geocoordinate.Point.Position;             

    _timeLastPositionChanged = Environment.TickCount;
    _lastGeocoordinate = geocoordinate;


As you may have observed, idle time starts ticking when the speed is below the minimum value of 10kph.  The distance traveled is calculated at each geographical position changed using Haversine formula.  CO2 level is calculated as described in previous post where KM_PER_LITER and CO2_KG_PER_LITER are set as 12.5 and 2.22 respectively.


When the Stop button has been tapped, the monitoring flag is reset and the data is sent to AirVantage.  Immediately after writing the code, I tested it by driving around the block, and verified the data has been successfully saved in AirVantage.


road test.PNG










Fascinated by the data, I started using the app today and monitored how much my footprint is when dropping the kids to school.

school drop off.PNG

Looking at this data, I spent almost 44% travelling in idle (10kph or less) most of it is due to traffic.  My average speed is 16.85kph on a 50kph road, seems like its better to cycle (if possible) during this time than travelling on car.  Also, 1.35kg of CO2 was produced for that particular trip, given 5 days of school x 2 trips per day x 10 weeks (ave) per term x 4 terms a year ends up 540 kg of CO2 annually!



As I was not able to track a couple trips to work using this app, I thought of automating the process such that the app will auto-launch when the phone is placed in the cradle.  This ensures that the application starts immediately at the beginning of each trip.  This was done by programming an NFC sticker that will launch the app and pass an argument.  The app has to be slightly modified as well to handle the argument.  A short clip has been added in this post to see how it works.



The other major contributor to Carbon dioxide footprint is transportation accounting for the 13% of global emissions in 2004.


For a typical household, transportation would be the second main contributor for carbon footprint and part of this system is to quantify and monitor how carbon dioxide we are emitting from our daily routines.


Measuring Carbon Dioxide


There are a number of ways to determine the amount of CO2 emissions, from simple approximations to actual measurements.  The simplest I found is just a multiplier of the vehicles' CO2 emission rating, usually in gram/km.  For my specific case, I am driving a Toyota Blade, and has a rating of 191 gram/km.  However, I am not quite satisfied about this method since the car can be idling most of the time, resulting in a shorter distance travelled but would actually emit more CO2 than a car travelling long distance but with minimal idle time.


Alternatively, but still using the vehicle information, this time labelled as L/100km, or the amount of fuel used (in Litters) per 100kms.  My car has this rating specified to be approximately 3.8L/100km or 26.3157 km per Litter of petrol used.  These values are mostly likely measured in controlled conditions and does not reflect the car's actual efficiency.  In reality, the efficiency is just 12.5 km/l as shown in my dashboard.


WP_20150223_001 (Medium).jpg


This link has a scientific method to calculate the theoretical value of how much CO2 is emitted during combustion arriving at 2.22 kg of CO2 per liter of Petrol.  By using actual vehicle efficiency of 12.5km/l and 2.22 kg of CO2 per liter of Petrol, we can resolve how much CO2 per distance travelled (in km), and call this as the CO2 emission factor:


CO2 Emission Factor = 2.22 kg/l ÷ 12.5 km/l = 0.1776 kg of CO2 per kilomter or 177.6 gram/km.


Carbon Footprint and Idling



The infographic on the left illustrates the effects of idling into the carbon emission formula.  For the proposed system, we will measure how long we have been idling for each trip, and attempt to translate this into tangible savings.


CO2 Concentration to CO2 Emission

Using CO2 sensors, such as the MQ135, can measure the amount of CO2 in ppm.  I initially thought of using the collected data to determine carbon footprint.  However the relationship between the two metrics is inconclusive at this stage and further research is required.



Better estimation of CO2 emission is through measuring amount of Petrol consumed than distance traveled.  To determine actual fuel consumption per trip, one must install a digital fuel gauge (for older vehicles) or tap into CAN bus and listen for fuel gauge value as reported by the vehicle MCU.


The next post will be about the implementation of a mobile application using the information gathered in this research.



Global Emissions | Climate Change | US EPA

TOYOTA BLADE [IMPORT] (2005-2011) - Search Cars and Vehicles Ratings by RightCar NZ

CO2 Emission Ratings for your Car provided by RightCar NZ

Toyota Auris - Wikipedia, the free encyclopedia


Checkerspot Butterfly
For the Checkerspot Butterfly's sake, solutions will take wing.
Welcome to the last week of the In the Air Challenge. element14, Texas Instruments, Würth, Cisco, the Eclipse Foundation and Sierra Wireless all been intrigued and fascinated by the solutions that the challengers have been putting together since the challenge began.  We look forward to seeing the final summaries of the projects by the end of this week.
Please note: final submissions are due by end of Friday, February 27th - we will grant leeway of up to 24 hours should there be any technical difficulties.
As ever, if you have questions please let me know.

My Question to TI

Does the VSTOR Pin provide output voltage in the absence of the VIN BUT in the presence of a Storage element.? NOT!



I finally got around to testing the BQ25504 and it was not what I expected but I am stupid so its all good.. I assembled the required circuitry and connected my solar panel and super cap and expected the output to be reasonably 5V. Unfortunately it was not. I am going to do a flashback on what I designed and then a little on what I got.



I started with a schematic in Eagle that looks like this...


I did an entire post on the matter at [Firecracker Analyzer] Making the Power PCB with Eagle, TI BQ25504, TPS62740 and TPS61200 In this instance, I only mounted the BQ25504 part for testing and instead of connecting a battery, I connected a 0.1F(not uF) capacitor as my storage element.


The results

The solar panel can produce voltages around 2volts in low light and up to 5volts in direct sunlight. For test purposes, I connected it to my bench power supply and set it to 1.9Volts. The boost converter came alive and punched out 3.7Volts at the output and the capacitor began to charge. I connected a Tektronix Scope to the output and it was captured as follows.


It is seen that the capacitor charges to 3.96Volts and then the output steadies. Once I switch off the power, the output ramps down. Good right? Wrong. This waveform is for the output voltage and without any load other than the Scope. This means the output will be valid only until there is an input from the solar panel. The vstor output is used to drive things when there is solar panel input and if it goes down, it will NOT connect it to the storage element.


Furthermore, when I switch on the Vin, the output jumps up directly to 3.96Volts which means my Cap is already fully charged. The capacitor is rated at 5.5V and the voltage to the terminals is 4.08V and keeps steady even after I have switched off my supply or solar panel. Hence what I am SUPPOSED to do is to use the battery/capacitor directly. I can then use my buck and boost converters to create the voltages I like. Fancy that!. I have the buck converter already connected to the VBAT so my 3.3V should be painless.


The boost converter is however connected via the VSTOR which means it will provide stable 5V only when there is a solar pannel power generation. I may be doing something wrong here but this is what I have got!




Next steps.

I need to mount the buck converter to create the 3.3V for the launchpad and cut traces on the boost converter. I am going to assemble the boost converter on a seperate PCB and connect them together. Fingers crossed!

Previous posts:

In the Air Design Challenge - Pollen & Allergen Sensing

In the Air Design Challenge - Pollen & Allergen Sensing – Post 1 (Pollen Sensor)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 2

In the Air Design Challenge - Pollen & Allergen Sensing – Post 3 (AirVantage Intro)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 4 (Preparing the InTheAir Power Board)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 5 (InTheAir Power Board)

In the Air Design Challenge - Pollen & Allergen Sensing – Post 6 (HDC1000 Sensor)

In the Air Design Challenge - Pollen & Allergen Sensing - Post 7 (WE Direkt PCB)



I've been very busy at home (moving into my new home) so I didn't make too much progress but I have a multi-platform application to share. I have it running on Windows, Linux, OSX, Android and BlackBerry but should run just fine on iPhone/iPad too (haven't tried that - I don't have the iPhone).

My project will be missing the key feature (pollen sensor) but I will continue to work on it after this challenge is complete. Having the pollen sensor would be great for me, should help me fight the allergy.


Qt-based application

InTheAir client application currently just shows the sensor values (and history for dust and pollen). Since pollen sensor is on hold until I obtain the required parts this app only shows the dummy value for pollen. Other values seen on the screenshot are also manually submitted using the Paho MQTT client but I have other sensors working, so, in a couple of days, these will show the real values for other three parameters.



Figure 1. Android screenshot



Figure 2. Android screenshot with history charts shown


Source code

Source code is still dirty but I shared it anyway (attached

This is the video of the first run of the AirMobile sensor installed in a real car



Previous Posts:

In The Air: Epidose 1: Introduction

In The Air: Episode 2 - Preparing for Surface Mount Work

In The Air: Episode 3 - Surface Mount Beginnings

In The Air: Episode 4 - Inductors

In The Air: Episode 5 - PCB Design

In The Air: Episode 6 - Getting Ready For PCBs

In The Air: Episode 7 - Still Getting Ready for PCBs

In The Air: Episode 8



Board is complete, and not destroying components ... anymore. I went through 4 inductors troubleshooting this one. I really should get a current limited supply. Here's a picture of the inductor graveyard.


I also lost a buck regulator in the process. In fact, it was the buck regulator that originally caused the first inductor to be destroyed. There was a short from power to ground under the regulator, and that's how the first inductor got destroyed. Then, somehow, the power supply leads got reversed, and that took out another inductor. Finally, four inductors later, the board is working. These inductors are quite handy when prototyping; they act like a fuse of sorts.



Below is the Booster Pack Header pin out. I made a mistake in my original layout, because I used the I²C lines, P1 - Ref 9 & 10, and I used the PWM available from P4 - Ref 1. I'm using the PWM signal to drive a pump. If you examine the Dev Pin numbers, you'll notice that the I2C_SDA pin is the same as the PWM pin for Ref 1. The * indicates a hardware modification is required to connect the PWM, but you can't use both at the same time. So, I made a hardware change; that is, I cut the trace for the PWM from Dev Pin 2 and soldered in a jumper wire for Dev Pin 64 instead.


HeaderPinOut.pngFigure 1: CC3200 Header Pin Out


Figure 2 shows my modification. It's a yellow wire at the bottom of the figure. If you look closely you can also see where I cut the trace beside the resistor I jumpered to. There is a second modification as well, but that's just a voltage supply mod.



Figure 2: I²C & PWM Conflict Modification. The yellow wire at the bottom of the figure is the jumper.


Pump Control


Having fixed the hardware issue, the software to control PWM was next. The CC3200 offers example code from the SDK for PWM control. I started with that example and modified it to work for Pin 64 instead of the I²C pins. I started with the wlan example and started bringing in all the functions from the PWM example that I required:

  • void InitPWMModules()
  • void DeInitPWMModules()
  • void SetupTimerPWMMode(unsigned long ulBase, unsigned long ulTimer, unsigned long ulConfig, unsigned char ucInvert)
  • void UpdateDutyCycle(unsigned long ulBase, unsigned long ulTimer, unsigned char ucLevel)


You'll likely have to add a few includes and a few defines, but it's relatively simple.


pinmux.c should have these lines in it:

// Enable Peripheral Clocks

// Configure PIN_64 for GPIOOutput
MAP_PinTypeGPIO(PIN_64, PIN_MODE_0, false);


Your main program will have something like this implemented:

UpdateDutyCycle(TIMERA2_BASE, TIMER_B, pwmValue);


I wanted to be able to control the PWM duty cycle from one of the kit's switches, so I used the button_if example from the common directory in the SDK, and this is where all my problems started. I could read the button pin, but not get any interrupt from it. I searched for quite a while on this topic, and I happened upon a forum where a guy said that in order for his interrupts to work he had to use UniFlash to completely clear the ROM on his board. So, I did this and the interrupts now work. Apparently, there can be conflict between using the OSI examples and mixing them with the examples from common. I'm not sure what happens or why, but just be warned.




Here's a video of the interrupt driven PWM control working.



And a video of my modification explanation.



Until next time ...

Not a very complicated post just a few pics of the assembly.


I use some flux and copper wire strands and used it to sweep the extra solder out... The above is the result and I check with the DMM to see if any pins were bridged. They weren't .


I then moved on to solder the rest of the parts and...


Viola! All I need to do is mount the coil and connect the inputs and outputs. This should be fun...

Previous: In-the-Air Challenge:  Texas Instruments MSP 430 FR5969 launchpad

Next post: In-the-Air-Challenge: Dust counting with Beagle Bone Black and a webcam

I bought three CO2 sensors and Arduino-nanos and gave one to high school students and one to  my collegue Ilja Feschenko who designed a great-looking electrochemical CO2 sensor box using SolidWorks and printed it on a 3D printer. There is USB output to a PC and a line with color LEDs. Simple LED indication is particulary suitable for checking air at home during nights. It is powered from external 9V supply and contains a miniature fan. After initial try Ilja saw that readings are temperatuire dependent and he actively stabilized the CO2 sensor temperature by an external heater transistor and a thermistor in Arduino PID loop. This decreased the temperature dependence, but there is still humidity dependence and warm-up time of hours. Ilja callibrated CO2 sensor against a commercial infrared photoaccoustic CO2 monitor.  High school students managed to make a setup on a breadboard, learned programming and averaging ADC reradings, but did not have time to make a box.

1.png  2.png  3.png

After digging into more scintific articles we understood that not only the air temperature but also air pressure has to be taken into account requirng to put more sensors into the box. And that is the story of the multi-sensor box described below that I built for In-the-Air-Challenge.


Here is a presentation of air quality sensor  to measure air quality in school classes. There are up to 30 students in a classroom. In winter windows are kept closed and air quickly deteriorates  without forced-air heat-recovery ventilation. Carbon dioxide (CO2) in air is responsible for tiredness. Dust and smog is a problem in large cities.  In winter might be too cold and in summer too hot and moist to feel comfortable. Knowing air quality might help teacher to optimize window opening.  Besides that it will play a large educational role teaching young people about sensors,  programming microcontrollers and Internet of Things.



Idea was inspired by a sensor cube: where all possible sensors were mounted in a plastic cube.  Probably  not all the existing sensors are needed at the same time. Commercial sensors exist: Here are the sensors that I decided to use:

  • CO2 concentration
  • Dust concentration
  • Air temperature
  • Air humidity
  • Air pressure
  • Sound level
  • Light level


Arduino micro pro is used because of small occupied space and availability of libraries for sensors and LCD.  Arduino is the microcontroller that school students who attend robotics club are familiar with. So they can modify the program.  Two-line LCD display displays sequentially 8 values from sensors. Values  from Arduino serial port are read on a PC by Processing 2.2.1 that is plotting data saving to disk and and uploading to the Internet of Things. Code is attached. I used a ready made library for IoT server Xively. Feed will not be available all the time:

I tried bluetooth connection to a PC but it was unreliable and lost connection after several days. Idea was to run Processing scetch on an Android phone or tablet, but the sketch that run OK on a PC did not run on Android as Bluetooth serial port was named differently.


Dust  sensor

Dust sensor GP2Y1010AU0F made by Sharp is sensitive to average dust level not for counting individual particles. There is a significant output offset from photodiode amplifier noise and from light scattered from the black sidewalls. This background has to be subtracted. Dust sensor feels when the room is swept  and the broom brings dust to air. It is very sensitive to (cigarette) smoke.

Sensor output voltage depends on supply voltage. In the datasheet calibration curve was showed for 5V sensor supply. When supplied from 3.3V the output signal is smaller. Internal IR LED is driven in pulsed mode 100 short pulses per second. This allows to have more light in IR LED emission peak as scattering effect is relatively weak.

Fan glued behind the sensor box is sucking air through the sensor. It is a 25x25 mm low noise (18 dB) fan operated from 5V with 100 Ohm resistor in series to reduce speed.  Visible dust layer accumulated on the propeller blades in a week.

Arduino 5V voltage from USB is not stable. It changes with USB connection at different PCs and wire length.  So I had to use a 3.3V LDO regulator (LM1117  with two 1uF blocking capacitors) that powers Sharp dust sensor and Arduino reference voltage.


dustCleaning room.png

Dust in air can be cleaned using HEPA filters. Such HEPA filters are used in industrial and research cleanrooms, hospital surgery halls and airplanes. HEPA13 class  filters are used in Electrolux dust cleaners stopping 99.95% of dust. When using such dust cleaner the room air stays pleasant after cleaning and there is no fine dust smell in the air. Electrostatic filters pose an interesting alternative.

CO2 sensor

CO2 is a greenhouse gas and it's concentration has increased from 300 to 400 ppm in last 70 years. See graph at

Carbon dioxide (CO2) is responsible for tiredness. So we probably feel more tired than 70 years ago. Inside lungs CO2 concentration is up to 4%. If ambient air contains more CO2 we are breathing more frequently.

Among electrochemical sensors CO2 sensor is relatively expensive ca 30 USD because it contains gold and platin. Parallax CO2 sensor board with 7.67x preamplifier uses the CO2 gas sensor module  MG811. In electrochemical sensors the gas diffuses into the sensor, through the back of the porous membrane to the working electrode where it is oxidized or reduced. This electrochemical reaction results in an electric current that passes through the external circuit. There is no indication of sensor life-time in the data sheet. From comparison with a photoacoustic gas analyser got formula

ppm=346.3+581290*pow(2.718, -0.02387)*x

I have placed CO2 sensor board inside the air quality box after the dust sensor fan.

CO2 sensor needs 6V for the internal heater. It is more practical to to use a  step-up regulator to raise USB voltage than an external power supply. I wanted to  use some of the multitude of inductor coils donated by Wurth Elektronik for the Air Challenge, but found on Ebay cheap step-up modules. So I step up the USB voltage to 8V that is sent to CO2 sensor board. 8V is supplied also to the 3.3V LDO. CO2 sensor draws relatively much current and USB voltage drops to 4.2V not enough for 3.3V LDO.


Voltage from the CO2 sensor decreases with increasing CO2 concentration. CO2 sensor output voltage also strongle decreases with increasing temperature which is unfortunate artefact. CO2 sensor temperature is measured by 1-wire DS18B20 sensor taped with aluminum tape to the CO2 sensor. In principle, one would need to implement active temperature stabilization of the sensor. Electrochemical sensor output voltage is quite unreliable at small CO2 values. CO2 sensors need burn-in time 12-24 hours to dry the moisture accumulated inside the sensor.


Calibration could be done using 100% CO2 from sparkling water and further  diluting it with normal air. If a water tank is used to measure volume there should be oil layer on the water surface as CO2 dissolves in water.


Better would be to use near infrared CO2 sensors, for example, Telaire 6613 CO2 Module 400...2000 ppm, 50ppm or 5% . Or T7000 Series Handheld Indoor Air Quality (IAQ) Monitor sold by Farnell.



Measuring pollutant concentrations in ppm and ug/m3


Part per million (ppm) means parts per million. 1ppm is one pollutant molecule among 1 million air molecules.

ppm is a mixture ratio that does not change in mountains where the air pressure is low due to high altitude. ppm value does not change with gas temperature. When ppm is specified in sensor datasheet it is assumed that sensor is at normal conditions 25 deg.C and 1000 mbar.


Chemical sensors and living organisms sense number of molecules that enter the volume and ug/m3 concentration units are more practical to use. ug/m3 value is sensitive to ambient pressure. (Imagine that if the measurement volume was evacuated then there would be no signal at all). So ug/m3 value needs to be corrected for ambient pressure. ug/m2 needs to be corrected for temperature as well. Concentration n enters ideal gas law equation


where p is pressure, V is volume, n is concentration, k is Boltzman’s constant and T is temperature in degrees Kelvin.

At elevated temperature molecules move faster and push other molecules further apart. Intermolecular separation increases and there are less molecules in a volume unit.


Formulae how to convert ppm to ug/m3 are here.


In the sensor box C02 sensor generated voltage is measured together with the temperature of sensor’s enclosure and ambient pressure.





Temperature sensors. In summer it gets quite hot inside. And one would need air conditioning. But summers in Europe are short so most buildings do not have air conditioning.  Digital temperature sensors DS18B20 provide 0.125 deg. C resolution and can be connected in parallel at 1-wire data line. One sensor is taped to the CO2 sensor and the second sensor measuring room temperature is outside the sensor box.

Humidity sensor Honeywell HIH5031 produces linear output voltage proportional to humidity, minus some DC offset. According to a datasheet slope is quite linear, but has a 2% hysteresis at 25C. Air humidity is important to know not only in school class but also at home in bathrooms, kitchens, basements. High humidity values can cause appearance of mold.

Air pressure sensor BMP180 is extremely tiny and very sensitive pressure sensor with 0.1 mbar resolution. Output can be compared and coincides well with actual meteorological data. Besides pressure it includes also a temperature sensor.

Ambient sound level is measured by amplifying microphone signal and sending with a diode to a capacitor with 10s time constant. You can find circuit here:

Photodiode allows to monitor indoor light use in winter time and count sunny hours. It is reverse biased from 5V and loaded with 10 k resistor. In principle it would be better to use logarithmic digital light sensor from SiLabs as illumination changes by several orders of magnitude in sunny conditions.






Tight packaging of many sensors in one box caused some contradictions.

  • It gets warm inside because CO2 sensor heats up to +40…+50C. So the room temperature sensor is placed outside the box at the end of 10 cm cable.
  • Humidity value is influenced by elevated temperature inside the  box.  So the humidity sensor is placed directly after the fan where air has not heated up yet.
  • Pressure sensor BMP180 might feel increased pressure inside the box by the fan. To cope with that the fan rotates at slow speed.
  • Fan produces some noise that is felt by the microphone that measures sound level. Fan is mounted on the dust sensor and that is glued not directly to the wall but via a rubber pad to reduce vibration transfer.




It might be good to include bad-air sensor into the air quality box. However this sensor is more appropriate for restrooms and farms.

It might be good to use near-infrared CO2 sensor that would have much better long-term stability compared to electrochemical sensor.  NIR CO2 sensor is available at Element14 for ca 200 USD.

Could also add oxygen (O2) sensor for 200 $.

As a dust sensor it would be optimal to count dust particles illuminated by powerful1-10W LED or a laser. As it is visible by eye there are around 25 particles per cm3 or 25000000 per m3.  I will try to use Beaglebone with a webcam and image processing to count dust particles and size.

Could use a I2C controlled graphical  display, Nokia5110  84x64LCD or larger to graph the signals for the past hour(s).

Could add Wi-Fi connectivity and a rotary encoder to enter Wi-Fi credentials on the LCD display.



Window actuators


By measuring air quality we can not directly improve it, but only learn how often to ventilate the room.  Modern windows do not have gaps that were ventilating rooms in old times. Modern windows allow to save heat. For saving heat it is good that windows are completely closed when no one is at home. But when people are in the room it is necessary to open some gap in window for ventilation.

One thing would be to automate window opening that would for example ventilate a bedroom briefly during the night when  a person is too lazy to stand up and open the window.

Commercial window openers can be bought on Ebay for ca 100 EUR from Germany and 60 EUR from Italy. We plan to try to make our own window actuator using a stepper motor, gearbox and threaded stick similar as in home-made 3D printers.



Tests at school class


I gave the sensor box to a student who took it to Riga 1st Gimnasium  to measure air quality in the class. Test at school was tried for 3 days and only the last day was successfull. First day there was no Wi-Fi connectivity. Second day GSM-USB Internet adapter was used to bring notebook to the Internet, but Processing script stopped working as there COM port settings had changed. Below is the picture of the sensor readings at school. Live:

r1g measurement 18 dec thursday.png


Measurement was started on Dec. 18 at 8 am. CO2 sensor needed 1-hour warm up.

CO2 levels changed dramatically during the middle of the day when window was open. But this change was mainly due to decreased temperature.

Note that plotted is not the CO2 concentration, but voltage in ADC units. This voltage decreases with increasing CO2.

One could see slightly elevated dust level, but not too much.

Box was placed on the window aisle near heaters and room temperature reading was elevated.

After the school day around 2:30 pm the student took the sensor and notebook home. So there are no values for the time when noone was in the class.

After the Christmas and New Year holidays we need to install Wi-Fi or GSM module into the air sensor box. So that it can be left operatig at school 24/7 without a PC. Minimum would be to add a SD/card with RTC.




1) There were some interesting results analysing the sensor data, for example CO2 increase during every lesson and dust from floor sweeping after the classes.

2) A webcam would greatly simplify the analysis showing the number of people in the class and state of the windows,  but webcam is not legal to use without permission from authorities.

3) Wi-Fi at school was problematic to arrange as one needed to register MAC address by the webadmin. GSM module would be best to use.

4) At school students were not allowed to leave electronics running during the night. So background data could not be collected.

5) Electrochemical CO2 module needs too much warm-up time. NDIR CO2 sensor described in the following blogposts is more accurate and has only few minutes of warm up time.



In my previous posts here and here, I made a small circuit with the prescribed parts from Texas Instruments and made a PCB for it. I recently received the passives and went on the assemble the board. This is the story of how I failed!


Setting things up


I started very enthusiastically and the video below is me setting up for the assembly...




No I did not make a video. I tried assembly of three boards and failed when it came to the QFN BQ25504. One of my boards is shown in the image below.



There is obvious excessive solder paste on this one...




Board Assembled partly.


The basic problem I faced was the repeated bridging of pins on the QFN. I tried varying the quantity of solder paste but the pitch is so fine that it almost always failed. I tried it on three different boards and the problem is the same. My solder paste is a bit old but I use just enough flux to make it creamy but since my hot air station has no temperature indicator, I am flying blind. The air control is tweaked to a minimum but still the parts get blown here and there.


Lessons learned


Here is a list of lesson s learned for now so I don't forget.

1. Get extra samples! - I requested just enough samples and that means I will only be able experiment so much.

2. Just enough solder paste. If the paste is more then pins will bridge and paste should only be applied to the pads. Clean up the extra since it may bubble up and move the parts.

3. Have a temperature reading on the hot air station. Unless you are really practiced, you need to control the temperature of the hot air.

4. Practice practice practice. I am going to take apart every smd circuit I have in my scrap bin and practice before I jump back.

5. Build a Reflow Oven. Ben-Heck has some tutorials on making a reflow oven and I think that will make one in the near future.




I am short of silicons and with the deadline this coming week, I will tread carefully. Lucky for me I made jumpers so I can make the three sections separately and join them together. Finger crossed...


Update 1


I got some new solder paste from a friend and it has a lot less flux in it. Used that and the QFNs seem to get soldered pretty well. After a few tries, the bridging stopped happening. Just reduced the amount of solder and it worked. Unfortunately, I am out of BQ25507s so I am putting up another request to TI. It will take a while but I will get it working in the long run.

Previous posts for this project:





All parts needed to populate the PCB I designed in week 13 have arrived! So this evening, I cleaned my desk and installed the preheater and SMD rework station. This is my first time doing actual surface mount soldering and working with a hot air station. I enjoyed it a lot.




To prepare for the soldering, I first cleaned my desk and installed the preheater and rework station. Read the manual on how to use them and briefly turned them on for testing. After that, I picked the components needed to populate the board and put them on the workspace, together with a pair of tweezers. Took the solder paste out of the fridge and was ready to give it a try.


I've recorded the different steps taken to get the board populated and soldered. You can view the video montage below. Otherwise, you can just keep on reading for the written version



The first step was to clean the PCB. i used some rubbing alcohol to get rid of greasy finger prints on the pads.

Screen Shot 2015-02-21 at 00.50.45.png


Next, I applied the solder paster to the pads. I had some difficulty getting the syringe to dispense solder at first, as I wasn't sure how hard I needed to push. Once I figured that out, I started to apply a little bit of solder onto every pad. The solder wouldn't stick on the first one, but after some fiddling, I managed to get it on there. Applying solder to the other pads went a lot easier.

I used Chip Quick SMD291AX10Chip Quick SMD291AX10 solder paste.

Screen Shot 2015-02-21 at 00.52.02.pngScreen Shot 2015-02-21 at 00.55.07.png



With the solder applied to the pads, I started putting the components I had prepared where they belonged. I almost made a mistake with one of the capacitors, but realised it in time. Using a pair of tweezers I was able to easily put all components in place.


Screen Shot 2015-02-21 at 00.58.40.png




I mounted the PCB using some magnetic brackets on the pre-heater (Tenma 21-10135Tenma 21-10135), which I purchased from the budget, just above the hot air outlet.

Screen Shot 2015-02-21 at 01.03.43.png


Finally, using hot air (Tenma 21-10130Tenma 21-10130), I reflowed the solder and the components were soldered on. At first, the flow rate was too high and the components were being pushed away. After lowering the flow rate, things went better, but I still managed to get a resistor off the pads. I successfully managed to "push" it back on though I'm thinking that I should have used a bigger nozzle.

Screen Shot 2015-02-21 at 01.05.11.pngScreen Shot 2015-02-21 at 01.05.38.png

Once all components were soldered in place, I powered off the rework station and pre-heater and let the board cool down.


This was fun! And I didn't burn down the house!

Next step is to test the board and then hook it up to the Launchpad for final testing.



The objective of this post to completely describe the creation of a wireless sensor node which can be used for IoT Applications. Texas Instruments was kind enough to sponsor the parts for this build hence the entire demo is TI BOM. Additionally, the code used is also available free of cost via . Lately security has become a concern for IoT in addition to the cost of the components involved and their maintenance is also an issue. If you are planing a system with lots of nodes to be deployed in an existing system or environment or if you plan to have a temporary system with sensor nodes to be deployed, wireless self powered systems are the optimum solution. The issue in making these solutions is where to start. Such a requirement pops up frequently for me where I want to deploy a sensor in a location where I cannot establish a cable connection or if I am prototyping a system where I need to monitor a quantity in real-time and log it remotely(for comparison with other such nodes). My original solution was based on XBEE's which transmit to a central BeagleBoneBlack however this becomes less and less cost effective when the deployment quantity increases. Hence I have turned to experimenting with other solutions out of which one is using the CC110L radio Chip from TI. There are cheaper basic RF Tx Rx modules available out there but they are dumb modules and cannot provide any information about the connection state nor any intelligent control over the transmitter. For this exercise I work with Anaren Modules LR09A which are part of the TI Air Booster Pack and are available relatively cheap from Element14. I will go into the details of the steps I follow to design my little wireless network. Lets go!


Topology and CC110L Dissection


One of the things that XBEEs offer is the ability to form networks where a co-ordinator xbee can act like a hub and the nodes can be used to form a mesh network. This ability is great for deployments where the network will span large distances and the gateway or controller is at one end of the installation e.g. office/building lighting. THe diagram below show this capability.



Our test setup is simpler where we need a star topology as shown below and may even contain just a single node in addition to the coordinator.

This topology takes advantage of the smart features of the CC110L. A quick look at the block diagram of the CC110L shows a packet handeler which offloads a lot of the processor responsibilities to itself. This includes Preamble detection, Sync word detection CRC checking which form the basics of a reliable communication system. These features means that the controller does not have to keep scanning the module for valid signals nor does it have to compute CRCs which will save some Lookup table space as well as time & effort. Additionally if you plan to have a small network and you can have an addressing scheme with a single byte, you can have the CC110L do that on it's own. For larger addressing space you will have to write your own layer but for my application this fits in quite nicely.




If you have an RF analyzer, you can see the following packet transmitted over the air which the micro-controller will be oblivious to anything other than the data field. This is a good thing!


I am NOT an FAE with TI hence I will skip the marketing lingo on the other features. The bottom line is that its a simple RF chip with just enough capabilities to make a simple network. The CC110L also has power down capabilities for sensor nodes that run on battery. Choose when to power the PA and disable it when not needed. There is also the ability to select a channel which means I can isolate two sub networks in the same physical space. Neat!


The only bottleneck is that the FIFO buffer is 64-Bytes which means that if I want it to send a sonnet, I will have to break it down. We'll see about that later. Right now I just need to make two device talk over the Air!


The Air Booster Pack


As always I won't try to replicate existing content and there are plenty of good reviews on the CC110Ls as well as the Anaren Air BoosterPacks. The microcontroller talks to the CC110L via SPI and there are two configurable IOs on the Chip as well. One should be used to generate an Interrupt on successful transmission or reception. The datasheet talks of the GPIO being used for serial data input but I really do not want to get into that unless absolutely necessary. Simplify things and get the job done I say. Below is the image of the Air Booster on the MSP430fr5969 LP and one on the MSP430F5529 LP.


I am still experimenting with some permutations and combinations on a better way to prototype things but right now, for this exercise I will be using these two standard Launchpads. The FR5969 is a low power LP and the 5529 is a USB LP and will be used for this exercise. The Kit contains two MSP430s preprogrammed with demo code and the Booster pack has the basic circuit layout on it. You can mount a few components and it will function without the need to purchase a LP. Cool concept and I am temped to try it myself however if I want to have sensors then I have to add connections or make a separate board anyway so this arrangement is good for demo purposes and I would rather make my own addon board... and I will... eventually.


Right now I want to get up and running as soon as possible so its use it as is for now.


The rise of Energia


The reason why AVRs are so popular is simple. Arduino! Its a IDE and language and hardware prototyping made for hobbyists in mind. The code may not be optimized and the boards may be awkwardly sized but they are easy to use and have a LAAAARGE base of libraries, demo apps and communities built around it. Hence it makes everyone want to use one. TI saw this and came up with energia which is basically their clone of the Arduino Environment. Same language and similar looking IDE but for their MSP430 and now CC3200 line of controllers. I support the Energia Project Completely because it gives me the capability to use the Launchpads in applications where the arduino doesnt fit. 3V# GPIOs and higher frequency controllers with some made for low power is what I see MSP430s as. I was initially put off by the convoluted architecture of the MSP430 but with the advent of Energia, my MSP430s became useful again. Needless to say I just avoid Code Composer for MSP430s all together because of the bas experiences I have had in the past.


This instance is no different and using the CC110L is a breeeze with Energia and there are libraries and demo code that come with the IDE itself. The same code runs on both the launchpads without me having to change anything other than the target board name and port number. How cool is that? Bravo Energia! Below are some screenshots of the IDE and demo code at work.




The easy way to setup a link


I could go in and explain the SPI interface and then the code that goes along with it, but I won't... because its not necessary. This is the reason why this writeup exists in the first place. It requires NO coding experience to get started with these modules and that is the best part. I want to showcase how easy it is to setup these modules and I hope people will actually try out these modules because these are pretty good.


Step 1.

The first step is to put the Air Booster Packs together with a Launchpad. As stated before, I have the MSP430FR5969 and the other is the MSP430F5529 each with an Air Booster. The FR5969 is programmed to be the sensor node which can measure temperature and values from a dust sensor. These are transmitted to the 5529 LP which acts like a hub and sends the data via serial connectivity to the console. The image below show my setup.


Step 2.

Get Energia and from the examples menu, find the air430boost sub menu. First we want the hub to be setup hence select the appropriate example. Image below shows a screenshot of the Menu.


15 - 1.jpg


Next select the board which in my case is the F5529 and click compile. Once this is done, we upload the code to the board after connecting it via USB.


Step 3.

Next we setup the node(s) and to do so we select the wireless node example as shown below.


Change the target board selection which in my case is the FR5969 and hit compile. Next select the upload after connecting the board via USB.


Step 4.

There is no step 4! You are done. It's that simple. Just power up these boards and you should be able to press a button on the node and the hub should reflect the communication.


Video Clip


Here is a short video clip of the demo in working.




I don't have much to compare with. The XBEEs cost a little above INR 2300 which is quite expensive in my opinion but for applications where quick deployment is required, these are a slightly better option. I say slightly because the costing of so many XBEEs will accumulate and burden the project budget. Another option is the LPRC eRIC modules(Antenna Extra) cost INR1549 from element14 and even though I have not used these myself, I have heard good things about these. Lastly the Anaren CC110L modules are priced a little less than INR1650 which have the Antenna onboard are currently the modules under test here. Of the three, the Anaren modules are the only ones without a dedicated micro controller inbuilt but the cost of an additional MSP430 is not that much either.



To be continued...

I plan to continue this discussion but adding some custom code to transmit data to a console in the next part. My parts of the Power board just arrived and I wanna try and complete that part first... Stay tuned.

The crucial moment has come: it's time to install the board in a real car

Here is the sensor mounted in the car







The case is fixed to the bodyshell by means of plastic strips. The cell is kept in contact with the radiator using a spring bolt to an existing shell screw...

Installation does not look very professional, but I accumulated so may delays due to hardware problems I has not enough time to study a better way to install sensor on car

It's time to finalize the OpenHAB setup on the BeagleBoneBlack, which will collect and analyze data stored on the AirVantage cloud.

The steps required to complete the installation are

Install web server

A web server is required to serve the files for the web page that shows collected data. I chose lighttpd because it's lightweight and easy to configure.

To install lighttpd, simply type


sudo apt-get install lighttpd


First, let's check that your configuration is ok:

$ lighttpd -t -f lighttpd.conf


Now let's start the server for testing:

$ lighttpd -D -f lighttpd.conf


I edited the config file in /etc/lighttpd/lighttpd.conf

server.document-root = "/var/www/airmobile/pages/" 
server.port = 8082

mimetype.assign = (
  ".html" => "text/html", 
  ".js" => "application/javascript", 
  ".txt" => "text/plain",
  ".jpg" => "image/jpeg",
  ".png" => "image/png" 

index-file.names = ( "index.html" )


Then I started the webserver by typing

/etc/init.d/lighttpd start


Copy web page files

AirMobile web files (HTML and Javascript) have been copied to




Copy bindings

The binding bundles developed (namely gpio and iarvantage) needs to be copied to the openhab/addons folder. To create the bundle, right click on the project and select Export. In the Export wizard, select Deployable  plugins and fragments.



In the next step, enter the folder where you want the plugin to be generated and check the options as shown




During the deployment, I experienced a Java ClassNotFoundException. I was not able to completely understand the reason for that exception, and the only way to solve this issue was to create a bundle for each jar the AirVantage binding depends on (okhttp, Gson, scribe and org.json). I created bundle projects by selecting File -> New -> Project -> Bundle and following the wizard steps



Finally, I added the bundles to the Import-Package section of manifest file of the AirVantage binding.

Manifest-Version: 1.0
Bundle-Version: 1.6.0.qualifier
Bundle-Activator: org.openhab.binding.airvantage.internal.AirVantageActivator
Bundle-ManifestVersion: 2
Bundle-Description: This is the AirVantage binding of the open Home Automation Bus (openHAB)
Export-Package: org.openhab.binding.airvantage
Service-Component: OSGI-INF/binding.xml, OSGI-INF/genericbindingprovider.xml
Bundle-ClassPath: .,

Define the items and the sitemap

First, a set of items that show the last sensor readings are defined

Number Home_Temperature "Temperature [%.1f]" <temperature> {airvantage="system=AirMobile1,measure=temperature"}
Number Home_Humidity "Humidity [%.0f]" <humidity> {airvantage="system=AirMobile1,measure=humidity"}
Number Home_CO "CO [%.3f]" <co> {airvantage="system=AirMobile1,measure=co"}
Number Home_NO2 "NO2 [%.3f]" <no2> {airvantage="system=AirMobile1,measure=no2"}
Number Home_Dust "Dust [%.0f]" <dust> {airvantage="system=AirMobile1,measure=dust"}
Number Home_AQI "AQI [%.2f]" <gauge> 


Second, a set of items that show pollutant levels at a certain location (in this case the location of a public garden where I typically go for a run) are define


Number PB_Temperature "Temperature [%.1f]" <temperature> {airvantage="system=AirMobile1,measure=temperature"}
Number PB_Humidity "Humidity [%.0f]" <humidity> {airvantage="system=AirMobile1,measure=humidity"}
Number PB_CO "CO [%.3f]" <co> {airvantage="system=AirMobile1,measure=co"}
Number PB_NO2 "NO2 [%.3f]" <no2> {airvantage="system=AirMobile1,measure=no2"}
Number PB_Dust "Dust [%.0f]" <dust> {airvantage="system=AirMobile1,measure=dust"}
Number PB_AQI "AQI [%.2f]" <gauge>       


Finally, the item for controlling the servo for the Air Quality Index (see below) indicator is defined


Number Home_Servo "Servo [%.0f]" {gpio="pin:13 name:pwm_test_P8_13.11"}



Define the rule to compute AQI

In order to provide an easy to understand measure of the air quality, I defined a custom Air Quality Index. Unfortunately widely-used Air Quality indexes are based also on measure of the ozone concentration at ground level. Since the Air Mobile does not have a ozone sensor, I defined my own Air Quality index.

The index formula is


  homeAQI = 1 -
((((homeCO - 30.0)/(1000.0-30.0))* 0.4) +
(((homeNO2 - 200.0)/(2000.0-200.0))*0.4) +


The index is basically a weighted average of the percentage of the three pollutants detected by the AirMobile sensor

The value of the index range from 0 (worst air quality) to 1 (best air quality)

The index is calculate by an OpenHAB rule

rule "Home_AQI_Calculation"
      Item Home_CO changed or
      Item Home_NO2 changed or
      Item Home_Dust changed
  homeCO = Home_CO.state as DecimalType
  homeNO2 = Home_NO2.state as DecimalType
  homeDust = Home_Dust.state as DecimalType

  homeAQI = 1 - ((((homeCO - 30.0)/(1000.0-30.0))* 0.4) + (((homeNO2 - 200.0)/(2000.0-200.0))*0.4) + (((homeDust-0.0)/(500.0-0.0))*0.2))
      postUpdate(Home_AQI, homeAQI)
  homeServo = 1500 + (homeAQI * 1000)
  postUpdate(Home_Servo, homeServo)


This rule also updates the servo position by converting the index value (from 0 t 1) to a PWM duty cycle value (from 600 to 2400 microseconds). The PWM duty cycle is then posted to the Home_Servo item



For those of you who have been following this post, I had experienced some difficulty accessing data from Sierra Wireless' AirVantage Cloud platform.  Most of the topics posted in this challenge used MQTT protocol to send data to their AirVantage application.  However, it is not possible to use MQTT in retrieving data from AirVantage, and the only way to get retrieve data back is by using AirVantage's REST API. Some very good post from amgalbu and tomaja have covered on how to do this in their posts AirMobile - 12 - AirVantage REST API and In the Air Design Challenge - Pollen & Allergen Sensing – Post 3 (AirVantage Intro).  Again, thanks to you guys who helped me out during that time.  They did a great job and actually offered their helper classes (available in Java, JavaScript and C++).  I now feel its my time to share the love by sharing my versions.  A node.js implementation, that can be used on the BeagleBoneBlack and a C# .NET implementation that can be used in almost all applications using the C# .NET 4.5 Framework.  However though, this library is at its infancy stage and only the basic REST API to send and retrieve data has been implemented, but should make things a lot easier.




If you do not have an AirVantage REST application yet, follow the tutorial Using REST API for devices.


Using node.js


Add the attached airvantage.connection.js file in your workspace.  This particular implementation requires restler, so install it using the npm package manager.  This can be done by typing npm install restler in the bash window.  Once that is installed, modify the airvantage.connection.js file with your credentials.

/* set system credentials here */
var username = "username";      /* username used to log in AirVantage */
var password = "password";      /* password used to log in AirVantage */
var client_id = "use_api_client_id";
var client_secret = "use_api_client_secret";

var serialNo = "SERIAL_NO";     /* this is the SN set when creating a new Gateway */
var connPassword = "CONNECTION_PASSWORD";   /* credential set when creating new System */

/* systems uid */
var system_uid = "system_unique_id";    /* UID found in Systems Details */
var machine_name = "asset_id";          /* as defined in */


There are three main functions to use this library.  (1) connect, (2) send_data and (3) get_data.  These exported functions are self-explanatory, refer to snippet below on how to use these functions.


var airvantage = require('./airvantage.connection.js');
function airvantage_connected()
    /* comment/uncomment lines of code to test */   
    /* retrieve data from the AirVantage platform */
    /* upload data to the AirVantage platform */
    //airvantage.send_data("temperature", 22.4);
    //airvantage.send_data("threshold", 10);






Using C# .NET


This particular implementation is a bit more advance and magical than the node.js implementation.  I created this helper library for use with the planned mobile application. Nice features of this version includes:

  • support asynchronous calls
  • built-in serialization and deserialization
  • portable (just one file) although, it requires references to RestSharp.Portable and NewtonSoft.Json  which can be installed using NuGet package manager


To use this library, add it to your C# project then refer to Program.cs file (as attached) for usage. The key to serialization/deserialization lies within the representation of the AirVantage Application model into a C# class.  Given the sample below:


<?xml version="1.0" encoding="ISO-8859-1"?>
<app:application xmlns:app="" 
        name="DEMO Application"

   <protocol comm-id="SERIAL" type="REST" />
   <encoding type="REST">
    <asset default-label="Demo Machine" id="machine">
     <variable default-label="Temperature" path="temperature" type="double"/>
      <setting default-label="Threshold" path="threshold" type="int"/>



This has been translated into the following C# class:

public class DemoMachine : SierraWireless.AirVantage.IAppModel
    [DataMember(Name = "machine.temperature")]
    public List<AirVantage.DataPoint> Temperature { get; set; }
    [DataMember(Name = "machine.threshold")]
    public List<AirVantage.DataPoint> Threshold { get; set; }

    public DemoMachine()
        Temperature = new List<AirVantage.DataPoint>();
        Threshold = new List<AirVantage.DataPoint>();


The important things in this class are, and should be observed when using this library:

  1. Class must inherit from SierraWireless.AirVantage.IAppModel interface
  2. Add [DataContract] class attribute
  3. Add [DataMember] property attribute and ensure that the Name value matches the asset id and data path as defined in the model application.




Sierra Wireless AirVantage data can only be retrieved using REST API.  The two implementations presented in this post are bare minimum but provides a good starting point.



The code presented (attached) in this post has been shared as is, and is meant for educational purposes only.  I have not thoroughly tested the code and is not intended for any production use.

Recently, I updated the CT sensor post with the current test and power measurements done on bench.  In this post, I will run through the enclosure design process.  The enclosure design is intentionally made simple and really is used to conceal any hazardous voltages that the user might touch accidentally.


For the enclosure design, I used AutoDesk Inventor Fusion and using it is quite intuitive.  I started by measuring the dimensions of the CC3200 Launchpad with the outdoor sensor module connected.  From the measurements, I sketched the base in Fusion, adjust the base sketch with an offset to draw the wall.  Once the base was sketched, I applied the extrude on the drawn planes, this immediately resulted to be the shell of the enclosure.  Examining the CC3200 Launchpad board, the PCBoard is actually raised from the base because of the female 20-pin connector.  To prevent the Launchpad from tipping and have it more stable, the walls were extended to provide some sort of a rise.  Below is a screenshot of the modeled enclosure.


enc design.png


The next part of the enclosure is a frame for the solar panel.  Again the process was mostly the same, that is, measure the solar panel, use the dimensions to sketch the base and extrude.  To be able to mount the solar panel, I added a few screw holes.  See model below.


panel frame.png

The files were then saved and exported in STL format ready for printing.  WP_20150214_002.jpg

Solar panel frame being printed (above).  Printed enclosure (below).


Then assembly and installation.


Btw, I drilled a few holes for the CT sensor and solar panel wires, a couple more holes on each side for airflow to the humidity and temperature sensor (currently not fitted in these pictures).





Then installed inside the meter box.


The wiring inside the box is already in spaghetti state, and was hard to route the cable safely.


I will leave this box collect some data for a day or two while I will be working on the other parts of the project.


Lastly, how I wish I incorporated in the design a quick way to reset the system.  Taking the top assembly off tends to be quite challenging as the box is too tight.


Next post, I will share some Sierra Wireless AirVantage helper libraries that you might find useful.

Previous Posts:

In The Air: Epidose 1: Introduction

In The Air: Episode 2 - Preparing for Surface Mount Work

In The Air: Episode 3 - Surface Mount Beginnings

In The Air: Episode 4 - Inductors

In The Air: Episode 5 - PCB Design

In The Air: Episode 6 - Getting Ready For PCBs

In The Air: Episode 7 - Still Getting Ready for PCBs



I have received some more parts recently, but unfortunately, I am still missing critical components. I'll provide some history of the procurement here so that you can understand why I have not written a blog post in over a month.

  • I placed my first order very quickly after being selected as a competitor. My design was going to include many surface mount components, so I ordered the appropriate tools as part of the budget. Everything arrived very quickly.
  • My circuit board design was complete, and I was ready to order components.. I placed my second order on Dec 4, 2014. Christmas came and went and I hadn't received any parts, but I figured that was typical of the holiday season. I have been in contact with Christian Defoe doctorcdf27 throughout the process. I'd like to thank Christian for doing all that he could up to this point to ensure I get my parts in time.
  • I also ordered some passives from Wurth, and Fed Ex says the parts have arrived, but I did not get them. I ordered some design kits and received those, but the headers and terminal blocks never arrived. Simon at Wurth remedied the situation and the parts are on their way again.
  • I used all TI ICs in my design because they are a sponsor of the challenge. I sampled those parts through E14 from TI, but they never showed up. Christian fixed this by ordering what parts he could from Newark for me, and I sampled the rest from TI under my own name.


Latest Work


I made a video showing the population procedure. I've only placed the components I have thus far.



Here's a photo of the board BEFORE cleaning up the extra solder from the reflow process.



Here are two pictures showing the board after removing excess solder. I've plugged it into the launchpad to show how it will look in the end.




I have not powered my board yet because I was only able to sample a single piece for some components. If I destroy the component, it's game over for me! It's also possible I would damage the launchpad. I lack a current limiting power supply, so I'll have to come up with a solution.



As part of my last order I got an arbitrary function generator (AFG). I thought about it for quite a while, and decided that I indeed should get it. Hooking up a sensor up to an embedded system seems simple, but before anyone should consider doing so, the embedded system needs to be tested with a known signal. Sometimes this is as easy as using a DC voltage source, but for a particle counting system waveforms are required to test the electronics. So, I ordered the AFG because I need to verify that the system works.


I'll hopefully be testing the system soon.... Stay tuned!


AirMobile - Data map demo

Posted by amgalbu Top Member Feb 16, 2015



The challenge is to create a system for air quality sensing which can operate without human intervention. My idea is to create a system that can measure air quality indoors and outdoors and log this data to the Sierra Wireless System. For the indoor unit, I have a CC3200 power unit which can measure temperature and an MICS5524 sensor which can measure air pollutants and connects to the cloud over wifi. It is powered by the TI Fuel Booster Pack and charged wirelessly with the Wurth Electronics Wireless Charging System. All parts are TI and Wurth Electronics.


The second outdoor unit is made up of the FR5969 Launchpad and uses the Alphasense Sensor for SO2 measurements and a Dust Sensor to measure particulate matter. This data is transmitted via CC2500 modules wirelessly to the BeagleBone Black which also has a CC2500. The BBB acts like a gateway device and sends the data to the Sierra Wireless Cloud via Wifi. This can be expanded to include more nodes to connect to this gateway and will allow future work to be done.


In addition to this functionality, I created a small board that can harvest solar energy and store it in a Li-Po battery. BQ25504, TPS61200 and TPS62740 are used to create a power harvesting circuit and the details are explained.


In this post I present a tutorial on how you can get started with using Sierra's Air Vantage Cloud Storage system.



One of the sponsors is Sierra Wireless who provide cloud based services for embedded devices and gateways. In the world of IoT, devices connected to the Internet can be easily managed using platforms like Air Vantage where devices can send their status like health, signal strength and other diagnostic info and a bulk of devices can be monitored easily from a single online point. Alerts can be generated as well as action can be taken for IoT Gateways. As a thanks to our sponsors, I wanted to create a graphical tutorial which lets 'developers' and 'hackers' to create their own little system and I found out a little late that there is already a tutorial on the subject at

A lot of discussion has also happened on the topic as well so I offer my two cents worth here.


The objective is to setup Air Vantage Cloud services for MQTT and then connect to it via an embedded device. In this tutorial I use NodeJS BUT the script runs on my PC to demonstrate portability of the code. I have been able to run the same code on the BeagleBoneBlack and the snippets have been modified according to the instructions given at


Setting up Air Vantage

This tutorial is very graphic hence viewer discretion is advised What that means is that most of the tutorial is in screenshots and quite self explanatory.

Setup the App

When you login for the first time, you see...


The first thing we need to do is create something called an APP. This will basically define how data is communicated which in our case is via MQTT. Additionaly we define variables that will be used in the communications.

In my case, I am sending temperature, Dust and Hydrogen Sulphide Concentration in this instance. I have a different system which sends temperature and VOCs but that's a different tutorial since the code is in cpp. Here is how you do it.


Next we need an APP. I am attaching mine at the end of the tutorial but feel free to type up yours or modify the given file which looks like.


In the data section, remember to note the asset ID and variable paths. These will later on be used like...

BeagleBoneBlack.temperature etc where BeagleBoneBlack is my 'id' specified here. Put it in a zip file by any name. Next...


And then...


And then...


And then...


And then...


And then...


And then...


And then...


And then...


And then...


And then...


You are done with setting up the basic APP! Great



Setup the gateway

The next thing to do is set up the gateway. The app is released but not published hence we need to create credentials to allow login and post data. This is pretty simple.

In the inventory section we currently have no systems... so click click click


And then...


We need a name and in the gateway section enter your BBB serial Number. This is just a unique identified and since I am using a PC, I just used a random sequence. For the Applications, we already have one and when you select the drop down, you should see some familiar name(s).


If you did not add credentials then it will ask you for em. Enter a password to be used with MQTT.


You should be able to see the above.



Next we need to activate it...





Click click click and then...

You should end up with somthing like this...


Clicking on the app will take you to...



So we have no data. BUT we can see our variables. Excellent. Now to push some data onto it.


Meet NodeJS

For those who don't know what NodeJS is, it javascript that runs without a browser. You can run simple scripts and with the help of libraries you can access GPIOs and connect to the internet. With more libraries, we can even create a webserver entirely on NodeJS(See NodeJS and Express if interested). All we want here is to use MQTT with a little JS since the BeagleBoneBlack can run JS from the Cloud9 IDE. I want to do my development on my 100year old PC since it generates a lot of heat and its still winter here

I have installed NodeJS on my PC and have created a folder to work in.

In a NodeJS Command Prompt with NPM setup, I navigate to the folder where I want to develop the things.


Step 0.

This is not mandatory but I create a NodeJS package so that every time someone uses it, the dependencies are automatically installed as well. Type..

npm init

Enter the name and revision and author name. The entry point is by-default the name of the folder but make sure you name your .js script with the name entered here. Leave the rest blank and enter yes at the end.


Step 1.

Install mqtt if not already installed by typing..

npm install mqtt --save

the --save saves the version of mqtt library being used.


Step 2.

Create the script with the name used as entry point. Mine looks like this...


Save and in your node command prompt...


That worked... right?

On the airvantage site, we refresh and then...


Click on one of the buttons to see a graph like...







This is just the tip of the iceberg and I just took longer to do a simple thing. I hope this tutorial is helpful for those who wish to use the airvantage platform and they get a running start. If it was helpful, say hi and gimme a pingback. If there is something I missed, lemme know and I will do the needful.




EDIT1. Since I could not attach a .js, the script is given below.

var mqtt = require('mqtt');
var port = 1883;
var server = "";
var serialnumber = "3713BBBK7777"; //serialnumber
var password = "Make your own password";

var mqtt_options = {username: serialnumber, password: password};

// I know 'createClient' is depreciated but it has a lot of examples for it. 
var client = mqtt.createClient(port, server, mqtt_options);

console.log("Client started");

//Send values
console.log("Sending value");

//Publish a message on the right topic
var payload= {};
var timestamp = new Date().getTime();

payload[timestamp] = { "BeagleBoneBlack.temperature": 16.2, "BeagleBoneBlack.dust": 10.0, "BeagleBoneBlack.hydrogensulphide": 2.0 };
client.publish(serialnumber + '/messages/json', JSON.stringify(payload));



The is...

<?xml version="1.0" encoding="ISO-8859-1"?>
<app:application xmlns:app=""
        name="In The Air App for BBB"
      <protocol comm-id="SERIAL" type="MQTT" />
      <encoding type="MQTT">
        <asset default-label="BeagleBoneBlack" id="BeagleBoneBlack">
          <variable default-label="Temperature" path="temperature" type="double"/>
          <variable default-label="Dust" path="dust" type="double"/>
   <variable default-label="HydrogenSuplhide" path="hydrogensulphide" type="double"/>


After setting up the PWM outputs on BeagleBoneBlack, I created a binding for OpenHAB. In this way, I can create items and widgets that controls servos and are fully integrated into the OpenHAB UI.

What I basically did was to make some changes in the existing GPIO binding to accomodate some new configuration keywords.

The original GPIO binding accepts the following configuration settings

gpio="pin:PIN_NUMBER [debounce:DEBOUNCE_INTERVAL] [activelow:yes|no]"


After the changes, the binding accepts the following


gpio="pin:PIN_NUMBER [debounce:DEBOUNCE_INTERVAL] [activelow:yes|no] [name:PIN_NAME] pwm:[PWM period]"


The name is the name of the pin configured for PWM as I talked about in my previous post. When either a name is supplied, the output is assumed to be a PWM output

The pwm parameter allows user to set PWM period in microseconds. By default, this parameter is set to 20000 us, that is to say 20 ms which is the typical PWM period for controlling a servo

For example, on my BBB I set


gpio="pin:13 name:pwm_test_P8_13.11"


I also made some changes to the library


I added some new function overrides to accept an integer parameter that represent the duty cycle to set. Both the PWM and duty cycle are set by writing the values to the corresponding files. For example, to set the PWM the following code is executed

Files.write(runPath, "0".getBytes());
Files.write(periodPath, Long.valueOf(this.pwmPeriod).toString().getBytes());
Files.write(runPath, "1".getBytes());


In the same way, to set duty cycle the following code is executed


Files.write(runPath, "0".getBytes());
Files.write(dutyPath, value.toString().getBytes());
Files.write(runPath, "1".getBytes());


Note that both PWM and duty cycle values are passed to the class functions expressed in microseconds and hence they are multiplied by 1000 before being written.

runPath, dutyPath and periodPath are respectively set to

/sys/devices/ocp.3/<pin name>/run
/sys/devices/ocp.3/<pin name>/duty

/sys/devices/ocp.3/<pin name>/period


I finally created a test configuration with a single item


Number Home_Servo "Servo [%.0f]" {gpio="pin:13 name:pwm_test_P8_13.11"}


and a page with two controls: a setpoint to change the PWM duty cycle and a Text to provide feedback about the current PWM duty cycle


sitemap demo label="Main Menu"
                Frame label="Home"{
    Setpoint item=Home_Servo label="PWM" minValue=1500 maxValue=2500 step=100
    Text item=Home_Servo

After a week of hardware and mechanical issues with the AirMobile sensor, my self-esteem was at an alarming low level.

So I switched to tasks that could bring me some satisfaction.

I started wondering how to demonstrate some automation capabilities as required by the challenge.

So I decided to build a "Air Quality" gauge.

The gauge will have a moving needle that will notify about the current air quality. The handle will be moved by means of servo control.

To control the servo, I need two things:

  1. a PWM output on the BeagleBoardBlack Cape connectors
  2. a piece of software that make it possible to drive the servo from OpenHAB


In this post I will focus on how to configure an output of the BeagleBoneBlack for PWM


PWM Output

The BBB was specifically designed to be a dynamic piece of hardware, enabling third-party developers to create their own custom configurations and extensions known as capes. The board is so flexible, it can change its hardware configuration at runtime using an in-kernel mechanism known as the Cape Manager in conjunction with Device Tree Overlays.

The Device Tree consists of a set of human readable text files known as DTS files that end in the “.dts” extension.  DTS files can be edited using a simple text editor to set the configuration for a particular pin. These source files then get compiled into DTB files, a binary format ending in the “.dtbo” extension.  This process creates what are known as device tree fragments or overlays.  The kernels Cape Manager can then dynamically load and unload the DTB files post-boot as well as at runtime to set the hardware configuration.  For a more in-depth look on how to use device tree overlays, The following links have been very useful to understand how overlays work:


Beaglebone and the 3.8 Kernel

Derek Molloy, Beaglebone: Introduction to GPIOs – Using Device Tree Overlays under Linux 3.8+


Luckily for our purposes, creating a new overlay for configuring PWM is not necessary. Turns out a set of overlays are already present in the “/lib/firmware” directory:








root@beaglebone:/lib/firmware# ls *pwm*



All we need to do is load them using the Cape Manager, but first, lets get acquainted with a very useful command that will help us determine if our overlays were properly loaded:


root@beaglebone:~# more /sys/devices/bone_capemgr.9/slot
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI


Out of the box, the BBB shows the above slots.  Lets add two more slots to configure pin 13 on header P8 for PWM by executing the following commands:


root@beaglebone:~# echo am33xx_pwm > /sys/devices/bone_capemgr.9/slots
root@beaglebone:~# echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.9/slots


To confirm the overlays loaded properly we run the slots command again:


root@beaglebone:~#  more /sys/devices/bone_capemgr.9/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm
8: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P8_13

Our board is now configured for PWM on pin13 of the P8 header!  Before we move on, however, it’s worth noting these changes are not permanent. If you power off the board, the PWM slots we just added will disappear.  Thankfully, we don’t have to repeat the above steps each time we power up the board.  The Cape Manager supports a method to load the overlays at boot time by adding the following argument to the “uEnv.txt” file:


Make sure to append the argument in a single line like this:


root@beaglebone:~# more /media/BEAGLEBONE/uEnv.txt
optargs=quiet drm.debug=7 capemgr.enable_partno=am33xx_pwm,bone_pwm_P8_13


Once the pwm_test_P8_13 directory exists you'll want to move to it and set run to 0 to disable output while you configure the PWM. Below, I set the period to 20 ms and a starting duty of 1 ms, after enabling output again the servo will swing to left of its central position. After echoing 2 ms into the duty the servo should move to right of its center.


# cd /sys/devices/ocp.3/pwm_test_P8_13.*
# echo 0 >run
# cat period 
# cat duty 
# cat duty
# echo 0 > polarity
# echo 20000000 > period 
# echo 1000000 > duty 
# echo 1 >run

Previous posts for this project:





As I mentioned in my previous post, I've been trying to get the control of a dimmable power socket to work via the Launchpads. I moved on to plan B until I manage to spend more time to crack the code.

I then hooked up the Launchpad to the Beaglebone black over UART and configured openHAB in order to control the fan which will be in charge of filtering the air.


Plan A


Plan A sounded simple at first:

  • go to the hardware store
  • buy a remote controlled dimmable socket
  • analyze the signal
  • reproduce with Arduino/Launchpad


Going to the hardware store and finding a dimmable socket was the easy part.

photo 1.JPGphoto 2.JPG


I underestimated the signal analysis and reproduction though ...


When analyzing the signal, I noticed there were different sequences being sent out to the 433MHz transmitter, as opposed to a single sequence repeated multiple times with the regular ON/OFF sockets.

I did my best to reproduce the signal, but haven't succeeded so far. I also searched for alternatives such as using an Arduino with 433MHz receiver and a sniffer sketch, but that didn't help either.


A lot of time was lost trying to figure this out and trying different things. I want to be able to crack the code as being able to control such dimmable sockets will certainly be useful for future projects, but I had to park it for now.



Plan B


OK, with Plan A temporarily set aside, it was time to move to Plan B: regular ON/OFF sockets without dimmer.


I have worked with those before, in the FMN challenge and managed to reproduce the sequence of pulses using an Arduino. Knowing that, it shouldn't be too different using a LaunchPad, right ? Well, I was wrong (a little bit).


void writeOne() {

void writeZero() {


After loading the Arduino sketch from before onto the MSP430FR5969 Launchpad, nothing happened. The socket would not turn ON.

Booted the scope to have a look at the pulses and there they were. So why wasn't it working ?


Taking a closer look, the timing seemed completely off. A pulse that should have been HIGH for 0.940 ms only lasted about 0.140ms. What ?!



I searched the world wide web for answers and came to following post:

It is suggested that for timing critical application (which this one is), the Energia config needs to be adapted to have the MSP430FR5969 core run at 16MHz instead of 8MHz. This requires a small modification in the "boards.txt" file in the Energia installation folder.

Screen Shot 2015-02-11 at 22.01.10.pngScreen Shot 2015-02-12 at 15.20.00.png


You can either uncomment the 16MHz and comment out the 8MHz or, duplicate the board definition, give it a different name and have one at 8MHz and the other at 16MHz. After making the changes, I restarted Energia and had two MSP430FR5969 to choose from. After uploading the sketch using the 16MHz variant, the timing was correct and my socket could be turned ON and OFF.


Screen Shot 2015-02-12 at 15.24.32.pngtek00005.png



Screen Shot 2015-02-14 at 15.31.50.png

The control the fan, I have a 433MHz transmitter module attached to the MSP430FR5969 which in turn is controlled by OpenHAB on the Beaglebone Black over UART.


This is the connection diagram between the MSP430 and the BBB:

MSP430FR5969Beaglebone Black
Ext Power VCCP9-3 (3.3V)
P2.6 (UART1 RX)J1-5 (UART0 TX)
P2.5 (UART1 TX)J1-4 (UART0 RX)


Note: Don't forget to set the "Power Select" jumper to "External".


I then proceeded to configure openHAB with the serial binding, just like I did in the Forget Me Not Challenge: [CaTS] ForgetMeNot - Week 4: Arduino-OpenHAB communication


The only difference, is that instead of /dev/ttyACM0, it should be /dev/ttyO0.


With everything configured, it was now possible to turn the power socket ON and OFF from OpenHAB. This will later be triggered automatically by a rule, depending on the measured amount of dust.

I've used a small fan for testing, but will be using a bigger one with a filter attached to it, for the final setup.


photo 2.JPGphoto 3.JPGphoto 5.JPG


The pieces are finally coming together, and with only two weeks remaining in the challenge I'm glad things are starting to work.




Your vote counts! If you like my project or anyone else's, don't forget to vote for it! Community Choice Poll - In the Air Challenge

Previous post: In-the-Air-Challenge: Laser-based dust counter using a photodiode, IoT connected

Next post: In-the-Air-Challenge: AirSchool Project Summary

Air in a laminar flow box with 99.999% filter


I have attached a small speaker to the photodiode amplifier of the home-made laser dust counter described in the previous post. Speaker clicks after every dust particle and click loudness is proportional to the dust size. Dust content outside the window in the city is similar to what we have in the room and speaker clicks with similarity to a Geiger counter near a radioactive source. Video shows that inside a laminar-flow class-6 cleanroom box there are practically no clicks. So the air filter works. Sorry, the speaker is too small to be heard in video as the air fan is making noise. Can hear clicking around second 40.



HEPA anti-alergy filters of vacuum cleaners


HEPA - High Efficiency Particle Air filter.


With a dust home-made dust counter described in previous post, I checked air coming out from a vacuum cleaner with HEPA filter on the output. Filter was labeled as Class 13 and should stop 99.95% of dust. Filter has been in use for several months, nevertheless there was practically no dust leaking through it.


There are also dirt collection bags marked as Anti-alergy  S-bag by Electrolux. I put one of such bags on the output of air ventilation. Such bag filters air very good and, practically, stops all dust.

Air filter of the cars did not stop the dust. and could possibly be used as a pre-filter before a HEPA filter.


One of drawbacks is that HEPA filter needs high pressure air fan to get much air through.  In the vacuum cleaner power is >1000W. I use vacuum cleaner from Electrolux Ultrasilencer that is made to be very silent compared to regular models.  In home-built filters, probably, one should use large size HEPA filters to get more air through.


Probably vacuum cleaner with a HEPA filter could be used instead of expensive HEPA laminar flow module in the optics lab.

If I fill a 250 liter plastic bag from a vacuum cleaner then the air inside is clean. But just blowing the air in a whole lab is not making air much much cleaner. As there  is wind blowing dust into the room through wooden window isles and doors.

Since one year I have started a laser spectroscopy lab in Riga, Latvia and dust here is a major problem as it deposits on the optics and laser power drops within days. It would be nice to make overpressure in the whole lab, but it is easier to build a clean air cabin around the optical table using greenhouse plastic sheets.



I need to solve the problem how to callibrate click counts into ug/m3. I plan to get in touch with some people having a commercial particle counter.



Exercise: How much dust a person inhales in one year. If air contains 50ug/m3, I get ca 0.3 kg/year. This would become ca 15 kg over lifetime. Can lungs clean themselves or get congested after decades.




Fine dust regulations and situation in Europe


As a fine dust are called particles smaller than 10 microns in size PM10. Generally, the smaller are the particles, the deeper they can penetrate into lungs. WHO suggests limit of 20 ug/m3 averaged over year. EU limit is double as high 40 ug/m3 which many experts critisize already for longer time. Studies show that exposure to particulate matter  leads to increseased lung cancer risk rougly 1% for every 10 ug/m3: "Outdoor Particulate Matter Exposure and Lung Cancer: A Systematic Review and Meta-Analysis"


Particulate Matter (PM10): annual mean concentrations in Europe  —  European Environment Agency (EEA)             

SPIEGEL article describes that values are above threshold, for example in German cities Berlin, Munich, Stutgart.

Feinstaub-Prognose: Die schmutzigsten Städte Europas - SPIEGEL ONLINE



This is a continuation of the last post and highlights a quick guide on how to have a quick remote debug console for the CC3200.  One can use UART connection for debugging or can use a socket to send debug messages to a remote console server.


Starting from the TCP Socket CC3200 sample project, I have decoupled the WLAN and TCP Client parts inside main.c and encapsulated them into a more portable and reusable code fragments.  The main.c has now been transformed as:


void main()


    /* WLAN Connect */

    /* We are connected to the network, setup a TCP Client
    * and connect to the server
    ConnectToTcpServer(IP_ENDPOINT, IP_PORT);

    while (true)
        /* Send some data to remote server */
        TcpClient_Write("Can be debug message...", 23, 0, 0);
        /* stall for a second */



The remote console is really a TCP server running on a Desktop machine or Beagle Bone.  For the TCP server running on the Desktop, a quick Google search will result in a few TCP tools for Windows, MAC or Linux, or you can roll your own using C# .NET with this sample program ready to go.  Using the Beagle Bone is quite easy as well by writing a simple nodeJS script in Cloud9 IDE of the Beagle Bone.

Remote Debug.PNG

Using the files is quite straightforward and hope the API are self-explanatory.  One thing to note though, when connecting to a TCP server, the IP address argument is of an array of 4 bytes representing the endpoint IP address.  i.e. to connect to a TCP server with address on port 40000, you can do the following:


uint8_t endPoint[4] = {192, 168, 1, 60};
uint16_t port = 40000;
TcpClient_Connect(endPoint, port);



The attached code in this blog post is shared to the community as is.

This post is more about updates on the hardware state than anything else.  Since my last post, I have spent the time to completely populate the custom boards and test them.  As most of my requirements rely on the ADC peripheral, I first tried out CC3200 ADC sample application found in the SDK library toolkit.  I must say that the sample programs packed in the SDK are all well documented and relatively easy to follow.  The sample setup suggests to use a signal generator which I do not have, instead I used a rudimentary voltage divider circuit with a maximum output voltage of 1.4Vdc and connected it as below.




Doing this exercise revealed a stumbling block.  I could not get any reading from ADC Channel 0 on the CC3200. This channel is quite important for this system, as this is used for current sensing.  The main CT sensor of the outdoor module block is on this channel as well as the ACS712 output of the smart plug and smart switch modules.




I did further investigation around this issue and learned that I was not the only one who had similar issue. janisalnis also experience the same issue during his IoT Backyard of Things. This led me to re-route the CT sensor to use ADC Channel 2 instead and re-route the ACS712 output as well.


Re-routing was quite simple, thanks to the R0's in the schematic, I did not have to cut any tracks.  This ended up with the following mod (see red wire).




Finally, the boards with connected to the CC3200.



Outdoor sensor + CC3200 Launchpad



Smart plug / Smart switch + CC3200 Launchpad



I only have one CC3200 Launchpad atm, and in the process of acquiring a few more, hopefully they will arrive within the next two weeks or so.  However, this should not stop me from completing the software.


The challenge is to create a system for air quality sensing which can operate without human intervention. My idea is to create a system that can measure air quality indoors and outdoors and log this data to the Sierra Wireless System. For the indoor unit, I have a CC3200 power unit which can measure temperature and an MICS5524 sensor which can measure air pollutants and connects to the cloud over wifi. It is powered by the TI Fuel Booster Pack and charged wirelessly with the Wurth Electronics Wireless Charging System. All parts are TI and Wurth Electronics.


The second outdoor unit is made up of the FR5969 Launchpad and uses the Alphasense Sensor for SO2 measurements and a Dust Sensor to measure particulate matter. This data is transmitted via CC2500 modules wirelessly to the BeagleBone Black which also has a CC2500. The BBB acts like a gateway device and sends the data to the Sierra Wireless Cloud via Wifi. This can be expanded to include more nodes to connect to this gateway and will allow future work to be done.


In addition to this functionality, I created a small board that can harvest solar energy and store it in a Li-Po battery. BQ25504, TPS61200 and TPS62740 are used to create a power harvesting circuit and the details are explained.



I await some passive components as well as the sensors to arrive. I have been able to mount the HDC1000 using a hotair station and test out it's functionality. In this post I go through my experience with the CC3200 and connecting with the Sierra Wireless Cloud.



The CC3200

TI calls this the 'Internet of A Chip' and rightly so since it has a wifi stack as well as a microprocessor on the same die. The first thing we need to do is get this baby up and running. TI did something brilliant with this chip- they supplied demo code for a broad spectrum of applications from Basic Timer and peripheral stuff to the extensive access point mode. The Out Of The Box demo starts as an AP and you can configure it to connect to the Internet. I will go step by step here rather than write a journal about it since that has been done so many times.

(Disclaimer: Some Images have been taken from the TI Website because of their awesomeness)


Step 1: UnBox it and Get started

Yea that simple enough but the fact is the device come with little more than a USB Cable and the board itself.

The getting started instructions can be found here

The idea is to connect to the CC3200


This will give you a basic idea of the AP mode of the CC3200. Now we need to connect it to our router.


Step 2: Connect to our router.

In order to do some real work, we need to connect to our wireless router. For that, go to the settings page once connected to the CC3200


Enter the SSID of your router and also the password and type of Security. Do an ADD and power off the board. Next, pluck out the jumper shown in the image below


Power it back on and you should be able to see the board in your network. Just connect to your wirless router and go to

Congrats you are now on the network. Lets complicate things...


Step 3: Install the Dev IDE

We need to configure the CC3200 to do our bidding hence we need to install the tools necessary. ( This document can help you get started but I recommend visiting...

CC3200 "Internet-on-a-Chip" Getting Started Guide – Part 1

shabaz sir wrote this so beautifully that I just cannot do it better.


There are updates for the CC3200 available on the website which TI Recommends you download and upgrade. The post above helps you do that and steps 1 through 8 are what I used. It involves setting up the IDE and updating the firmware.

Great we now have the tools and board updated at this point. Next we need MQTT



Step 4: Start Coding

Like I said, TI did a brilliant job with the demo code and it would be wrong not to use it. I encourage you to import the examples and try em out. It's as simple as connecting your board and clicking the little bug icon on the top. DOn't worry you cannot brick your device since your program will only be in RAM and when you reboot the board, it will again start the OutOfBox Example application.


Steps 9, 10 and 11 of the above mentioned link from shabaz sir's post do exactly that.



Step 5: Understanding MQTT

MQTT has been called the language of IoT. It's basically a small protocol that allows communication using a broker/server. The basic mechanism is a publich/subscribe type where you subscribe to a 'topic' and then when someone 'publishes' data, you get it at your end. The problem is that the message or data is typically not stored by the server/broker in the basic form. We are interested in getting basic communications up and since we have the CC3200 connected to the router, why not the internet? Instead of setting up our own broker/server, we will use the MQTT broker which works for free! Yay! To test this out, you should first install a utility for MQTT like Google Chrome as an extension called MQTT Lens. You can get apps for android as well or iOS. Fire up the app and enter and port 1883. No username or passwords are needed at this point but some apps may want one anyways. In the topic, use any string. I preffer strings like /Inderpreet/myProject/CC3200. This is not a folder structure but just a way to uniquely identify the Topic. Click Subscribe and now you are listening. Next we need to publish something type in the same topic name and enter some text. When you press publish, you should be able to see the message in the window below. Here is a screenshot.




In my IoT Holiday Lights Challenge, I used MQTT to send strings like :TM255255255 which meant

: = start of frame

T = command for the tree

M = Manual Mode

255 =Red

255 =Green

255 =Blue


The crafting of such a message is done in software and we will see how. First lets see if our CC3200 can talk to the broker.


Step 6: MQTT on CC3200

Since our CC3200 already connects to the router, we should be able to connect to anything. My starting point for new projects is the demo code for the OOB which is provided by TI. It is the simplest way to get up and running in a jiffy. There is a wonderful video tutorial by kartben sir on the subject of running MQTT on the CC3200 and here are the blog posts.

Connect the CC3200 to the Internet of Things with MQTT and Paho embedded C client - Part 1

Connect the CC3200 to the Internet of Things with MQTT and Paho embedded C client - Part 2

Once you are done, you should have an MQTT enabled CC3200 transmitting the temperature. Cool now what? For the Forget Me Not Challenge, I used the CC3200 to read an ADC and then send that data to another topic. Lets see how to do that...


Step 7: Reading a Frequency and sending it via MQTT

By now you have figured out that the CC3200 is running an RTOS and everything happens in Tasks. So we will start by writing our own task and extend the capability of the system. I am going to setup the CC3200 so that it will measure a frequency of a signal and send that data over MQTT. I used this technique in the forget me not challenge to measure rainfall in a tipping bucket sensor. We will be using timers hence this should be fun. (


The first thing to do is to find out which pin I can use. The infographic by shabaz sir is very helpful.


A quick look at the datasheet and...


Its clear I can use TimerA0. Using the PinMux Utility, I can easily generate the desired code. Here is what I did...


a> Adding to main

In the main.c, in the void main() function, I added the following lines...

    // Configure the pinmux settings for the peripherals exercised


    // Configure TimerA0

    // Register timer interrupt hander

    // Configure the timer in edge count mode

    // Set the prescaller

    // Set the detection edge

    // Set the reload value
    MAP_TimerLoadSet(TIMERA2_BASE, TIMER_A, 0xffffff);

    // Enable capture event interrupt

    // Enable Timer
    MAP_TimerEnable(TIMERA2_BASE, TIMER_A);

That configures the timer a and connects the Capture mode input to Pin P04 which is on J1(left side).



b> Add the handellers

Add the following functions to the main.c file


//! TimerA0 interrupt handler
void TimerA0IntHandler( void )
  if(g_change == 1)
    GPIOPinWrite(SIG_PORT, SIG_PIN, 0x00);

  g_change ^= 1;

//! TimerA0 and pin_61 Initialization
void TimerA0Init()

  // Configure PIN_61 for GPIOOutput
  MAP_PinTypeGPIO(PIN_61, PIN_MODE_0, false);

  // Configure TimerA0
  Timer_IF_IntSetup(TIMERA0_BASE, TIMER_A, TimerA0IntHandler);



The handler function takes care of measuring frequency in the Background. Nice!



c> Add our task


Next I need to add my own little task... create a copy of the MQTTTask Function OR simply use the code below.

static void MQTTTaskRain(void *pvParameters){
    // Now connected

        MQTTPacket_connectData data = MQTTPacket_connectData_initializer;

        unsigned char buf[200];
        MQTTString topicString = MQTTString_initializer;

        char cTemp = (char) g_ulFreq;
        char payload[20];
        memset(payload, '\0', sizeof(payload));
        short sTempLen = itoa(cTemp, payload);
        int payloadlen = strlen(payload);
        int buflen = sizeof(buf);

        data.clientID.cstring = "me";
        data.keepAliveInterval = 20;
        data.cleansession = 1;
        int len = MQTTSerialize_connect(buf, buflen, &data); /* 1 */

        topicString.cstring = "/forgetwhat/cc3200/rain";
        len += MQTTSerialize_publish(buf + len, buflen - len, 0, 0, 0, 0, topicString, (unsigned char*)payload, payloadlen); /* 2 */

        len += MQTTSerialize_disconnect(buf + len, buflen - len); /* 3 */

        int mysock = sl_Socket(SL_AF_INET, SL_SOCK_STREAM, 0 );
        SlSockAddrIn_t addr;
        addr.sin_family= SL_AF_INET;
        addr.sin_port = sl_Htons(1883);
        addr.sin_addr.s_addr= sl_Htonl(0xC6291EF1);
        sl_Connect(mysock, (SlSockAddr_t*)&addr, sizeof(addr));

        // rc = Socket_new("", 1883, &mysock);
        sl_Send(mysock, buf, len, NULL);

        // rc = write(mysock, buf, len);
        // rc = close(mysock);



d> Add the task to the OS



The last thing to do is add the newly made task to the OS's list of things to do. Simply add the following line to the main function.



osi_TaskCreate (MQTTTaskRain, ( signed char *)"OOBTask" ,OSI_STACK_SIZE, NULL, OOB_TASK_PRIORITY, NULL );



Done! Debug and let her rip! My box looked like this...





Step 8: Making things permanent

In order to retain this code, we need to program the flash. Step 8 of this tutorial by @shabaz sir has the correct instructions.



Step 9: Experiment!


You have the basics, so now its time to move to more advanced stuff. The above link has info on how to configure I2C with the CC3200 and control an LCD which I have experimented with in a previous post.



I tried to curate the information of the best and put my little something into it as well. In the next post, I will be displaying the temperature data on the LCD as well as sending it to the Sierra Wireless Cloud and configuring the service to work with the CC3200.


Till then, happy CC3200



Previous posts for this project:





I missed last week's post, and I'm sorry. I was trying to get the wireless control of the fan using dimmable sockets to work, but just didn't manage crack the coder. You can expect a post about it this week.


For this post, I have something completely different in mind! It's been a while since I used my ShapeOko2 CNC milling machine and since my wife's not home, I can make all the noise and dust I want (I'll have to clean up before she gets home though ...)! The goal was to make a simple panel/enclosure to which I could mount the BB View touchscreen to give it a more finished look.


Waste board


Before getting to the actual milling, I completed a modification to the stock waste board of the ShapeOko2.


I drilled a whole bunch of holes (totally overdid it!) in the waste board and screwed in threaded insert. This will help me clamp down the work piece when milling, instead of using tape like I did until now ... There were about 200 inserts to screw in, so I ended up with a few blisters on my fingers. I'll survive, and I'll spare you the pictures


photo 2.JPGphoto 3.JPG


Inkscape & Makercam


The first thing to do was making the measurements of the screen. The BB View is not symmetrical, a bit annoying but not a problem. Once I had the measurements done and verified, I ported them to inkscape.


The flow is as such:

  • a line drawing is made in Inkscape and exported as *.svg
  • the *.svg is imported in Makercam
  • a milling operation is associated to a line or area
  • gcode of the milling operations is exported from Makercam
  • the gcode file is interpreted by the GcodeSender application
  • GcodeSender passes the commands to an Arduino UNO which controls the stepper motors


Everything went well in Inkscape, but once I imported it in Makercam, the rounded edges caused a glitch:

Screen Shot 2015-02-11 at 09.29.54.pngScreen Shot 2015-02-11 at 09.29.10.png


Errr, right. I tried various things to get that fixed but nothing helped. So instead, I used rounded corners. I wanted to try something different, but as it didn't work, I had to move on and not waste too much time.

That's when I realized I forgot to mirror my design, as the milling will happen on the back side of the panel. And of course, there had to be another glitch ...

Screen Shot 2015-02-11 at 10.22.48.pngScreen Shot 2015-02-11 at 10.23.20.png


What is it today with things going wrong ?? I removed the outer shape and redrew it unmirrored. That did the trick.




With the drawing finally properly imported in Makercam, I started associating milling operations to the lines.


The inner rectangle needs to be cut out completely. To do this, I used the "follow path" operation which will mill the rectangle for the entire thickness of the piece of MDF.

The second rectangle needs to clear an area for the screen to slide in. This calls for the "pocket" operation.

Finally, the outer edge uses the "follow path" operation to cut out the piece completely.


Makercam visualizes the operations by means of arrows, taking into account the width of the drill bit to determine how many passes are required. With the operations calculated, the gcode was exported and imported in GcodeSender. A simulation can be run to confirm everything is as intended.


Screen Shot 2015-02-11 at 14.25.51.pngScreen Shot 2015-02-11 at 13.06.34.png


All ready to go, I clamped down a piece of MDF to cut out the shape from, set the Dremel in position and hit the "send" button.


By the way: when working with a CNC or any other power tool for that matter, wear protection and be careful! Safety first!


Now, back to milling. Here are some "action" shots of the milling in progress. I regularly took the vacuum cleaner to get rid of the material being milled off.


photo 1.JPGphoto 2.JPG




The result is not bad at all (if I may say so myself). The piece came out clean and only required a tiny bit of sanding.


photo 3.JPGphoto 4.JPG

photo 5.JPG


I'll be milling more pieces to make it a "PiBow" style enclosure in which I can fit all the electronics.




Your vote counts! If you like my project or anyone else's, don't forget to vote for it! Community Choice Poll - In the Air Challenge

Previous post: In-the-Air-Challenge: NDIR CO2 meter connected to IoT via TI CC3200 Wi-Fi connectivity board

Next post:  In-the-Air-Challenge: Air filter checking with a home-built laser+photodiode dust counter

After trying to count dust using image processing I turned to a classical dust counter approach with a laser and a photodiode.

Background materials to read: Measuring dust with a commercial "Dylos" air quality monitor.

My device is based on article by a A. Morpurgo "A low-cost instrument for environmental particulate analysis based on optical scattering".



I made a 445 nm 1W laser pointer salvaged from Casio beamer and tried first to use a commercial amplified photodiode Thorlabs PDA36A and see the video below how the signal looks on Iphone:

Summary of  observations

  • Light pulses are having length of 0.1...1 ms depending on air flow speed.
  • Number of particles detected depends on air flow speed.
  • Need ADC sampling frequency in >10 kHz range (10 samples/pulse).
  • Need a fast algorythm for finding maximum of the peak.
  • Need to solder Opamp amplifier. Gain ca 70 dB.
  • Prefered a large area photodiode or a lens to collect more light. 10 mm diameter PD from Thorlabs was great. But also 1 mm diameter photodiode is OK.
  • Photodiode signal can be  AC coupled to suppress light scattered from walls.
  • Need large area photodiode or large lense to collect light.
  • Can place a mirror on the other side of laser beam to double signal.
  • To generate clicks we need a thin sheet of light. That is why laser beam is focussed. With broad beam particles are so many in volume that they overlap and are impossible to count.
  • In a small focussed beam scattering intensity is high and disturbing background is less.
  • If air speed is increased there are more particles coming in a time unit. Pulses get shorter.
  • There is a huge number of small particles in air. They are not molecules. Something bigger. Smoke for example.


Some particles leave multiple peaks. This is due to interference-diffraction if particle size is close to wavelength of light. By pfotographing such diffraction patern one could calculate the size of particles as it was done on pollen:







Photodiode can be 1...2 mm active area size. I ordered from Farnell BPX65. I had in drawer older FND100 photodiode and it worked too.

First OP is a transimpedance amplifier. It keeps photodiode input at 0V using the 1M feedback resistor. The output voltage is very linearly proportional to the photocurrent. Photodiode generates negative current on OP inverting input that is compensated to 0V by feedback resistor. So OPamp output becomes positive.

I use Texas Instruments OPA350 that was recommended in the italian paper about dust detection. It is single-supply rail-to-rail OP. Dust produces weak scattered light, so amplifier has to be low noise.

Input noise of OPA350 is 5 nA. One of often used photodiode amplifiers in physics laboratories is OP27 that has twice smaller input noise but requires bipolar power supply.

Note that the OPA350 schematic in the original paper has some mistakes: OP legs are incorrectly numbered and photodiode leg connected to the + input is also grounded.

dust schema.png

Circuit has to be fast because the light burst is short. I dimension circuit to some 50 kHz bandwidth that is suitable for taking several consecuitive samples with ADC. It is not practical to use larger feedback resistor than 1 Meg as circuit becomes slow. Better is to add one more OP stage. As a rule of thumb OP DC gain should be below 100 and resistors used below few hundred kOhm.

The circuit self oscilates without the capacitors across feedback resistors. So I added a 10 pF capacitor across 1 Meg and a 100pF capacitor across 100k. Low pass filter is dimentioned for 1M+10pF=100k+100pF=100kHz.


At output is a high-pass filter to eliminate continuously scattered light and 50 Hz. 10k+100nF=1ms=1kHz.


Circuit diagram is drawn using  Eagle. Both opamps are assembled on a small SSOP chip breakout board. See the photo. The amplifier board is covered with insulating tape and aluminum tape for electric pickup shielding. Photodiode is fixed 3...5 mm from the beam. Position is not very sensitive.



A thing to try: photodiode in a plastic chip with built-in preamplifierTexas Instruments OPT101P-J. But need to check noise specs first





First diode lasers available were near infrared around 800 nm as used in CD players. Then red lasers appeared and now blue diode lasers are used in blueray disks. Light scattering increases quadratically for shorter light wavelength. So I think it is advantageous to use blue laser. Si photodiodes have sensitivity peak around 900 nm, but around 400 nm signal is only 10%. This might be why

red lasers are  still used. I use a blue laser because I have many 1W laser diodes from an old Casio projector. To extend  the lifetime I run laser diode at a half of maximum power. I made current controller for laser diode from a  LM317 regulator and a 2 ohm resistor that stabilizes maximum current at 0.6A. Resistor is rated for 1W gets dissipation. Similar circuits can be found elsewhere, for example, here:


Laser diode I soldered to a hole on a copper heat sink. I glued a glass lens with f=5 mm at some distance to make the beam focus at couple centimeters. There are 2 foil diafragms to reduce scattered light.

If you decide to build your own device, be extremely carefull with class 4 laser laser. You can permanently damage vision. (For comparison electricity is more dangerous as you can loose your life!) During alignment try to run laser at low power. Fix everything steadily on the table. Keep other people away from the room. According to safety measures you should wear color protective goggles.  Laser beam should be directed at  steady dark painted metal surface. Focused beam can start  fire and smoke.

When device will be ready  the beam will be enclosed inside the metal enclosure and that is considered safe. But the box needs a warning sticker about laser inside.



Enclosure and Signal

dust setup.png

Beam dump is a 90 degree copper plumbing piece sprayed with furnace black paint. Photodiode is looking at 90 degrees to the laser beam into another 90 degree black piece.

Air is sucked into the box through a tube. About 10 cm long tube is practical for checking air coming out from air ducts and filters. A small fan is placed not on the input but on the exit of the box because some dust sticks on the turning blades. Number of particles counted in a time interval depends on air flow speed. As there is relatively much heat from the laser diode and LM317 I had to use a cast aluminum enclosure by Hammond that I got  from Farnell as a gift for this challenge. As a 9V power supply I use Ansmann APS600 rated at 0.6A that I got from Element 14 for this challenge.  Here is a video showing assembly and dust signal on oscilloscope.



Particle counting

laser based dust counter.JPG


Texas instruments Launchpad supplied for this challenge does not fit inside the compact size metal enclosure. Microcontroller runs in a loop to find out when ADC voltage has reached some threshold. Then it samples and looks for maximum value. ADc peak value I think is proportional to the particle size. Microcontroller bins particles into small medium and large bins. And once in 10 seconds reports to display and serial. Previously I have experienced pickup  from Wi-Fi when measuring weak light levels and decided  not to use Wi-Ffi in this project.


void loop() {
  Value = analogRead(A0);
  if (Value>2)
    Value1 = analogRead(A0);
    if (Value1>Value){Value=Value1;}
    else { if (Value1<20) {small=small+1;}
          if(Value1>19 && Value1<500){medium=medium+1;};
          if (Value1>501) {large=large+1;}
    Value=0; }


  Serial.print(small);  Serial.print(" ");
  Serial.print(medium); Serial.print(" ");



In ambient air there are 30...100 clicks per second. To my surprise outside the window the air was not cleaner than in the room. If I sweep the room there is a giant burst of large size dust. Only inside a cleanroom box there were no clicks.

50 dust particles in 1cm3 means 50 million in 1m3. That is a large number.

I attached the Processing 2.2.1 code for Windows PC that receives USB-serial data from the particle counter averaged for one minute, saves in file and posts  on Xively. Link to live Xively plot is here:



I left my dust counter on for a weekend in a 20 m2 lab with HEPA13 filter bag on the air duct. After a couple of weeks of running the filter bag color starts to darken from inside.

dust in the lab.png

Air gets cleaner in about 5 hours - counts dropped from 4000 to 200  per minute. Dust quickly enters into the lab from adjacent rooms when the doors are left open. So I installed a curtain in the doorway. Curtain helps but is not as good as closed doors. During the weekend levels change when there is wind outside. I will continue logging  and prepare a new picture during the week when the people will work in the lab.


Below is a graph of two weeks of counting dust in the room.

dust 2 weeks.png


How many Element 14 carbon atoms contains 1 micron size soot particle? C molar mass 12 g/mol, density 2.26g/cm3.

The crucial moment is coming: installing the sensor in a real car

Before of that, all the components have been mounted in a case, as shown in pictures below.






Particular care has been taken to thermally insulate the electronics components from the heat. I placed some foam on the side that faces the car radiators. This, and the air that flows from the holes in the front-facing side of the case, should prevent electronics from overheating




Care has been taken in order to make the airflow slowdown inside the case, so that measure are not affected by air speed (especially for temperature and humidity) and particles concentration increases. The idea is that air enters through the tow holes (see picture below), passes through the hole in the dust sensor and then between the two boards, where sensors are mounted. Air have to bend by 90 degrees because of the back case and this should slow it down. This is just my thought, that needs to be proven by a test on field. It could worth the while to spend some time studying how to implement a simple model in one of free CFD software, just to have an idea of air speed and pressure...

The case will be installed at a certain distance from the radiator, whereas the Peltier cell needs to be placed in contact with the radiator itself.

To increase cell efficiency, I glued a PC heatsink to the clod face of the cell itself.



ita.jpgThe In The Air Challenge is running from September 22nd to final submission date of February 27th (at midnight).

Previous Activity:

Blog Summary #000 : In The Air Challenge 2014

Blog Summary #001 : In The Air Challenge 2014

Blog Summary #002 : In The Air Challenge 2014

Blog Summary #003 : In The Air Challenge 2014

Blog Summary #004 : In The Air Challenge 2014

Blog Summary #005 : In The Air Challenge 2014

Current Activity:

Blog Summary #007 : In The Air Challenge 2014

Blog Summary #008 : In The Air Challenge 2014 - Final


NameSuper Awesome Blog Time

In-the-Air-Challenge: A sheet of laser light for 2D visualization of dust flow

In-the-Air-Challenge: Spending the 500 USD parts budget

In-the-Air-Challenge: Measuring CO2 levels during lectures with EXTECH CO2 monitor

In-the-Air-Challenge: Exploring internally NDIR CO2 monitor

In-the-Air-Challenge: NDIR CO2 meter connected to IoT via TI CC3200 Wi-Fi connectivity board

dimonicNo Updates

No Updates


BeagleBone + node.js + Visual Studio

Carbon Footprint Monitoring - [kNow] more AirVantage

Carbon Footprint Monitoring - Power Supplies

Carbon Footprint Monitoring - Power Meter CT


AirMobile - 19 - Memory retention

AirMobile - 20 - Bluetooth protocol

Protocol for IoT

AirMobile - 21 - The board

AirMobile - 22 - Heating up the board

AirMobile - 23 - LaunchPad mating

AirMobile - 24 - Bluetooth connection

tomajaIn the Air Design Challenge - Pollen & Allergen Sensing - Post 7 (WE Direkt PCB)

No Updates


No Updates


[Air ex Machina] #06 Passive components - prototyping

ipv1[Firecracker Analyzer] Testing the HDC1000 on my Own board

Dust, Temperature and Humidity Monitor Chapter 8

Dust, Temperature and Humidity Monitor Chapter 9

Dust, Temperature and Humidity Monitor Chapter 10

Dust, Temperature and Humidity Monitor Chapter 11

happy1No Updates

[AirCare] InTheAir - Week 11: CC3200, Energia and analogRead()

[AirCare] InTheAir - Week 12: Automatically starting some things

[AirCare] InTheAir - Week 13: GP2Y10 BoosterPack

[AirCare] InTheAir - Week 14: Ordering Parts and PCBs


IOT - In the Air Challenge - Portable Field Tester (Note)


In The Air Update

The last step before installing the AirMobile board on a real car is to test the Bluetooth connection


What you see in the video is the AirMobile board mated with the TI LaunchPad board and powered by a Peltier cell. The gray box you see in the video is a PC power supply unit that cools down the cold side of the Peltier cell.

In this condition, there is enough energy to power up the Bluetooth module (you see the module's LED blinking)


On the smartphone, I installed an open-source application that I modified to meet my requirements. The application continuously tries to connect to the AirMobile board. When connection succeeds, sensors data is shown (you see 5 new rectangles appearing on the smartphone's screen). The smartphone's app is also already capable of pushing data to the AirVantage cloud infrastructure (see here for details about how AirMobile handles data)


Here is the video of the test



Hopefully I will be able to install the sensor in the car by the end of the week and see how it behaves!

As a software engineer, I do not normally work with custom hardware/electronics, so I was missing all basic components required for prototyping and was feeling kind of stuck. I did not want to spend the farnell budget on “consumable” general purpose electronic components, so decided to buy from ebay some cheap passive components in bulk, and use the competition budget on things that make more sense to buy from farnell.

I ordered “kits” of resistors, capacitors, dimmers, cables, breadboards, etc…mainly sourced from shenzhen, very cheap, but took more than a month to arrive in Greece (vs ~next day delivery when ordering from farnell), so lost quite some time in the hardware department, but atleast I finally now have a nice collection of passive components to use in this and future prototyping.

210Pcs 25 Value 0.1uF-220uF Electrolytic Capacitors Assortment Kit Set

1000 Pcs 50 Values Ceramic Disc Capacitors Kits

15 Values 3296 Trimmer Potentiometer Variable Resistors Kit

560pcs 56 Values (1Ω–10M Ω) 1/4W 0.25W 1% Metal Film Resistors

Breadboard, cables..


MQ7 CO Carbon Monoxide Coal Gas Sensor

MQ135 Air Quality Sensor Hazardous Gas Detection

LM2577S LM2596S DC-DC Step Up Down Boost Buck Voltage Power Converter ( will try to use it for the CO2 NDIR Infrared sensor which needs 18v)

Cheapy seansors: Rain sensor, temp-humidity, LM35 (these are for arduino so I need to check 3.3v operation)

SOT23 MSOP10 SMD to DIP10 Adapter for testing the TI temperature sensor

and two NRF24L01+ 2.4GHz Wireless Transceiver Module (in case I decide to separate CC3200 from EXP430)


Btw, Wurth was kind enough to provide me with a total of five kits of SMD inductors and capacitors, so here is a photo of my son sampling them :-)


More Hardware and software update:


For hardware, PCB have been send for manufacture. Most of the component is ready for assembly.

Now just waiting for PCB and some accessories.

Picture show the final PCB send for manufacture.



Picture bellow show the pin map for the CC3200. Please edit the given example before upload to MCU.

Do remember if you are using the 430 shapr96 LCD with CC3200, connector at the P1 and P2 is using by the LCD.

Please avoid using pin function at this connector if possible. If you still need to use the pin at P1 and P2 then you need to check in detail at the LCD side which pin is available.


This one show LCD pin map. Please bare in mind that some of the pin is not use for LCD but they been use or connected touch slide.

For more information please go to the given link. Guide_SharpMemoryDisplayBoosterPack | Energia


This picture show the pin map for the LCD:


Wire crimping:

Sound and look simple for wire crimping but without proper tool it will give you bad day. For this I will show the wire cramping for the JPT connector use with dust sensor.

Proper tooling for the wire crimping and some tip to make wire crimping more easy.

But for me, I will solder the wire directly to the connector for better connection .






Please chose suitable cable size for the crimping job if not you will end up with difficulty to place the cable assembly in the holder.

I know some of you thinking of cut down the cable to smaller size but with this end up having a lose wire crimping.

You also need some steady hand for this jobs where very bad for me he..he..


Picture show my dust sensor using direct wire soldering



PCB is coming and it look good to use.


Assembly and Connection:

Now in the process of assembly the hardware. Most of the hardware is ready for assembly and now just use temporary fix using magic tape .

Like I mansion the wiring will be a bit headache due to multipurpose PCB. my self also get confuse about the pin he..he..

Picture show the working progress for the assembly work.






I plan to use the aluminum spacer from WÜRTH Electronic. They look very nice but unfortunately they only have limited stock.

So I end up using some PVC spacer




Dust, Temperature and Humidity Monitor Chapter 10



Coming soon

Previous posts for this project:





This post is more of a small update, as I didn't find enough time to dive deep into this project this week.




I have ordered various parts for the project over the weeks. I'm still missing some key components to populate the PCB from last week, I hope they show up before the PCB does.


The capacitor kits from Würth, which I ordered before Christmas have arrived this week. They look great! Big thanks to sleuz for arranging that.

photo 2.JPG




We were given a 50EUR budget to get our PCBs made via Würth. Quoting my little board for the sensor, the total cost would've been around 75-80EUR for one board. Taking into account the 50EUR reduction, that would still have been 25-30EUR.


I don't have a problem paying things for the challenge myself, as we already get so much. But I do think that the quality Würth would've delivered for that price would have been overkill. The PCB will mainly be used to practice surface mount soldering and create a first prototype.


So instead, I opted for SeeedStudio. For 12EUR, I'll be getting 10 pieces of my PCB design. This will give me the chance to practice and possibly mess up a few boards without much consequence. If the design proves to be correct and functional, and after becoming a bit more skilled at surface mount soldering, I still might order a "final" board via Würth.


Screen Shot 2015-02-01 at 20.38.05.png

After testing most of the hardware to detect short-circuits that could burn the MSP430 pins, I mated the AirMobile board to the TI LaunchPad board


Before proceeding, I had to set the TI LaunchPad's jumpers properly.

The configuration is as follow

  1. all the jumpers in the isolation jumpers block (J13) have been removed
  2. all the jumpers on J10 have been removed
  3. jumper on J11 has been removed
  4. jumper on J12 has been removed and the header pin "In use" has been connected to the AirMobile board
  5. jumper on J9 has been removed


Power supply 2.png


I finally connected the Capacitor with the header pin on the AirMobile sensor board so that the capacitor is charged through the LTC3108 circuit


The MSP430 runs a simple application that switches on the  Launchpad's red LED when the application itself  is running and blinks the Launchpad's green LED when the PGOOD output from LTC3108 is detected high. PGOOD is high when enough power is harvested to provide a stable 5V output


In the video the green LED can not be seen clearly. It starts blinking after 5 to 10 seconds since the Peltier cell is put in contact with the radiator. Please note that in the video the capacitor is not connected, so the MCU is switched off as soon as the Peltier cell is removed from the radiator