Skip navigation

Its been a hectic couple of weeks and progress has been slow. I will be posting a series of smaller posts to cover work done and my "evil plans". One of the factors that contributed to my slow progress was sensor selection and I am still a bit stuck on that- the reasons I will explain. I also received the basic kits from E14 so thanks for the support. Lets jump in to the progress part direcly.



The Sensor Problem

I had planned on building a sensor system for open air and in order to do so I started contacting vendors like I usually do. I asked about the sensors they provide as well as their suitability for my application. Turns out that sensors such as the ones provided by SGX Sensortech (IS) Ltd like the MICS series is really not suitable for outdoor use. At least that what their sales manager says. Most of these sensors are made for indoor use and not sensitive enough for ambient air measurements. So what next?



Moving On

The objective here is to monitor air quality and that is why I had divided the system into two segments. There is an indoor as well as outdoor unit but there are many ready made solutions in the market so what can I do different? Well most of these work on measuring air quality and alerting when a level is exceeded so we can add a display as well as connecting it to the Internet. I already experimented with connecting the CC3200 with OpenHAB using MQTT for the Forget Me Not Challenge. That works! One change will be that we will be posting to the Sierrra Wireless Cloud instead of OpenHAB.



Since we have a 50USD budget for the PCBs I started work on the circuits. Not having selected the sensors still meant that I can work with power circuit. For the charger, I am using the BQ25504 so I used eagle to make the schematic.





Had to jump through a few hoops to make the footprint and that thing is smaller than small. Next was the boost converter for the 5V. This is getting to be very similar to the Fuel Booster Pack but it has its differences. The boost converter selected is  the TPS61200. Again a few hoops and I made the footprints to match the devices.





Next is the buck converter which is the tps62740. The footprint of this one is still a bit fuzzy and if anyone has it please send it across.



As of this writing, that part is under construction and I will blog about it in the next post.



I was thinking about doing a post on using eagle but there seems to be too many already and to be honest everyone has a systemm of doing things. I typically make the schematic in parts and keep committing to git. Once I am done with a part of the circuit, I jump into layout and just place the parts in a suitable arrangement. This makes sure that the part groups don't get mixed up and there is less confusion while doing the final placement and routing.

Anyway I will do a video when I route the board which I think I will have to dedicate some time for since there are layout considerations for the used devices and fitting them all on the PCB will be a challenge on its own.


Thanks to Micheal W for inputs on the post on inductors. It was useful.


Baby Steps:

I am going to finish the schematic this weekend and move onto the software part. More progress will be updated in separate posts.

Setting up Beaglebone Black

This is my post for setting beaglebone for connecting to airvantage. For this beaglebone needs to be setup. For windows machine follow the following steps :

  1. Connect beaglebone to USB port of pc using usb cable.
  2. Install drivers for beaglebone from It may take a while to install the drivers.
  3. Launch : to log into the board.

Next connect the beaglebone black to internet using Ethernet or Wifi.

Open Cloud9 IDE by going to the address .

Then i noticed an article on the element14 site to update the image of debian. The factory installed version has many problems. I tried to login from the user debian to root but it asks for a password which is not there. You will always notice a authorization failure in this case.

So to avoid these problem update your image. This can be done in two ways :

  1. By Flashing the image to emmc:
  2. Download the latest image from
  3. The downloaded image is a .img.xz file. Then download 7zip to decompress the archive.
  4. Use 7-zip to decompress the SD card .img file. In my case 7zip was not able to open the archive.I had the following error saying “cannot open file as archive.”
  5. So i used my ubuntu pc to flash the sd card with the image.
  6. In ubuntu just click on the link and restore the image on the sd card.
  7. Now power down the beaglebone insert the sd card and press down the BOOT button and power up the board.
  8. If using BeagleBone Black and the image is meant to program your on-board eMMC, you'll need to wait while the programming occurs. When the flashing is complete, all 4 USRx LEDs will be steady on or off. The latest Debian flasher images automatically power down the board upon completion. This can take up to 45 minutes. Power-down your board, remove the SD card and apply power again to be complete.
  9. In my case i had errors in this case, the board started with the emmc flashing and the user leds started blinking in a sequence. But after 5 minutes this stopped and all of them started to glow. I powered the board down to see if the process is over but i noticed that the board wasn’t booting. I was not able to ssh into the board. So i used the other method of using an sd card to boot the board.
  10. By using sd card :
  11. Download the latest image from (bootable sd card image)
  12. Decompress the image using 7zip and flash it to the sd card using win32disk imager on windows or restore it in ubuntu.
  13. Now power down the beaglebone insert the sd card and press down the BOOT button and power up the board.
  14. For booting with sd card this is all you have to do. The board will boot from the card.


In my last post, I wrote about the system components and gone through the proposed electronic components.  This post is dedicated to firmware architecture of the emission sensor.  As a reference to the diagram in that post, this node consists of:


  • TPS767D301 Dual Channel LDO to provide 5V and 3.3V rails
  • MSP430FR5969 as the micro controller unit
  • nRF8001 Bluetooth Low Energy module for communications with a smartphone
  • ADXL362 accelerometer for detecting vehicle vibration
  • MQ-135 sensor for measuring air quality, particularly CO2 emissions


By checking the pinouts for each component, I have decided to initially wire the different modules to the MSP430FR launchpad in the following configuration:


Firmware Architecture

Before writing any code, the structure for the firmware must have a level of abstraction such that any code can be re-used on a different platform.  A simple architecture will be used as a framework for the firmware code base as shown below.


This architecture is very generic and provides a level of separation between each module which should make the code portable and should still work on a different platform, i.e. using the CC3200 module instead of the MSP430FR.  All platform specific code will reside in the low level block which is then abstracted by the (Hardware Abstraction) layer above.  This approach with the software design will enable me to code and test one module at a time in isolation.  Each layer of the codebase will follow a set of API's and guidelines.  This will be covered in my next post along with some sample code.


For now enjoy some of the pics for this setup.


(Clockwise) MSP-EXP430FR5969 Launchpad, Click booster pack adapter, MQ-135 Air Quality Click board, nRF8001 Module, ADXL362


Texas Instruments MSP-EXP430FR5969 Launchpad


MQ-135 Air Quality Click board and click Booster Pack


Nordic nRF8001 Bluetooth Low Energy module




Btw, I accidentally bricked my MSP430FR launchpad whilst mocking around with the different compilers, testing out different Ti tools for the platform and upgrading the FET firmware.  Not exactly sure which from the above caused the corruption, but basically, the MSP430FR5969 chipset could no longer be identified by emulation tool.  I tried looking for the cause and the solution online but never found a real answer.  So with a bit of courage and determination, I ended up replacing the chip with another one.


<< Previous

Table of contents

I am still finding Wind Shield wiper motor from near by scrap yard for automatic window opening and closing.

I have managed for exhaust fan from local scrapyard (230V 60Watt) and I will simply use relay switch for control this fan.


Still I am waiting for basic kits for this challenge, I have compiled and sent spreadsheet of components for my design to Element14.


Here is this spread sheet...

Line No.Order CodeQtyDescriptionMftr. & Part No.
312967771TIP, D00663, 0.5MMDURATOOL - D00666
412967792TIP, D00661, D00662, 3MM, CHISELDURATOOL - D00668
718914282SENSOR, HUMIDITY, 20-90%RH, +/-5%MULTICOMP - HCZ-D5-A



This is all about this week... And I know that my the progress is too slow... and needs to be boosted.....


AirMobile - 9 - CO sensor

Posted by amgalbu Top Member Nov 27, 2014

CO sensor Figaro TGS2442

As CO sensor, I'm going to use the Figaro TGS2442.


Hardware considerations

Connecting the Figaro TGS2442 is relatively simple (the difficult part is drive its inputs properly!)


TGS2442 Wiring.png  


The sensor requires application of a 1 second heating cycle which is used in connection with a circuit. voltage cycle of 1 second. Each VH cycle is comprised by 4.8V being applied to the heater for the first 14ms, followed by 0V pulse for the remaining 986ms. The Vc cycle consists of 0V applied for 995ms, followed by 5.0V for 5ms. For achieving optimal sensing characteristics, the sensor's signal should be measured after the midpoint of the 5ms Vc pulse of 5.0V.

The only component to dimension is the load resistance RL. Datasheet states that RL needs to be greater than 10k. I think a 39k resistor is a good trade-off

As usual, I added a buffer and a voltage divider to get a voltage between 0 and 2.0 V

  TGS2442 Signal conditioning.png


Software implementation

Using the same functions I already talked about in my previous post, I can write a the function to read out the output value provided by the TGS2442 sensor





#define SENSORS_NO2_OUTPUT_PIN     1


void SENSORS_ReadCO()





      // generate pulse on heather pin











      // generate output to measure NO2 level






      float val = SENSORS_AnalogRead(ADC12_B_MEMORY_3);

      SENSORS_Data.CO = SENSORS_Map(val, 0 , 1023, 0, 100);



Currently the delay function is implemented as a simple loop. I'm trying to devise a more energy-efficient implementation

Hi everyone,


I wanted to get a quick update of where we are at. As most my know, my daughter is working with me on this project (See last blog post). We have received most everything from Element14 (Thank you so much). We have downloaded and registered Cadsoft Eagle Pro and are working hard to design the PCB's for our sensors (Thank you Cadsoft for this incredable software).


I am currently working on the PCB design for the sensors as well programming the Beaglebone Black. I will update our progress this weekend with pictures and experimental script to operate the GPIO's and TI boards. I also have a TI EZ-430 watch I want to integrate in all this as well. Chrystal, my daughter, is beside me learning as much as possible as giving great ideas as we move forward (I am learning as much as she is). We still need to activate our Sierra Wireless account which will be this weekend and give details about our plans for the cloud.


Thank you to everyone for your generous support and to the Element14 community,

Dale and Chrystal Winhold

Interesting photos of London from 1952. This is Nelson's Column:


The photo above is from wikipedia. The smog was caused as a result of burning coal. Read the full article here. This article from the met office has further information.



This photo is from an encyclopaedia (I can't recognise the area, but the sign on one of the buildings to the right says Sheraton I think).

Apparently smog killed between 4000-12,000 people that year, when smog was particularly bad for five days in December.

Afterwards, the Clean Air Act of 1956 resulted in dramatic improvements within just years. Smokeless fuel was mandated in certain areas. This resulted in far lower industrial coal burning, and railway output was eventually diminished to nil.

Previous posts for this project:





Other competitors in this challenge have already described how they installed openHAB. I did notice however that they used different methods to go the job done.


In this post, I describe the method that I've used to deploy the latest version of openHAB (v1.6.0) and how I created a basic configuration to receive MQTT messages.

By the end of the post, I have openHAB subscribing to a broker, receiving MQTT messages sent by the CC3200 containing some statistics on the FuelTank's battery.




First, I updated my system and ensured the "unzip" tool was installed, as I'll be requiring it to install openHAB.


debian@beaglebone:~$ sudo apt-get update
debian@beaglebone:~$ sudo apt-get upgrade


debian@beaglebone:~$ sudo apt-get install unzip


I also configured the proper timezone.


debian@beaglebone:~$ sudo dpkg-reconfigure tzdata

Current default time zone: 'Europe/Brussels'
Local time is now:      Wed Nov 26 12:23:46 CET 2014.
Universal Time is now:  Wed Nov 26 11:23:46 UTC 2014.




To install Java on the BBB, I followed the steps defined by nikil511 in the following post: [Air ex Machina] #04 Beaglebone for dummies - JAVA,OpenHab

I did add "sudo" here and there, as I was running the commands as user "debian" and not "root".

debian@beaglebone:~$ echo "deb precise main" | sudo tee /etc/apt/sources.list.d/webupd8team-java.list
debian@beaglebone:~$ echo "deb-src precise main" | sudo tee -a /etc/apt/sources.list.d/webupd8team-java.list
debian@beaglebone:~$ sudo apt-key adv --keyserver --recv-keys EEA14886
debian@beaglebone:~$ sudo apt-get update
debian@beaglebone:~$ sudo apt-get install oracle-java8-installer


Easy enough, and Java was installed!




I installed openHAB a bit more manually than the other competitors here, but it works just as well.


First thing I did, was to download the openHAB runtime and addons for version 1.6.0 directly on the Beaglebone Black.


debian@beaglebone:~$ wget
debian@beaglebone:~$ wget


Next, I prepared the location I would deploy the application to.


debian@beaglebone:~$ sudo mkdir /opt/openhab
debian@beaglebone:~$ cd /opt/openhab/ 
debian@beaglebone:/opt/openhab$ sudo unzip /home/debian/


Then, I deployed the addons (bindings, actions, persistence, ...), but I did it in a subfolder called "unused".

That way, openHAB will not load all the addons, but I can easily deploy/activate them by moving the files from the "unused" folder back to the "addons" folder.


debian@beaglebone:/opt/openhab$ cd addons/
debian@beaglebone:/opt/openhab/addons$ sudo mkdir unused
debian@beaglebone:/opt/openhab/addons$ cd unused/
debian@beaglebone:/opt/openhab/addons/unused$ sudo unzip /home/debian/


openHAB requires a configuration file to be able to work properly, so I created one, based on the default.


debian@beaglebone:/opt/openhab/addons/unused$ cd ../../configurations/
debian@beaglebone:/opt/openhab/configurations$ sudo cp openhab_default.cfg openhab.cfg


I also created some placeholders for my items, sitemap and rules.


debian@beaglebone:/opt/openhab/configurations$ sudo touch items/intheair.items
debian@beaglebone:/opt/openhab/configurations$ sudo touch sitemaps/intheair.sitemap
debian@beaglebone:/opt/openhab/configurations$ sudo touch rules/intheair.rules


Finally, I made the startup script executable, edited the HTTP port in it to use port "9090" instead of the default "8080".


debian@beaglebone:/opt/openhab$ sudo nano

# set ports for HTTP(S) server


debian@beaglebone:/opt/openhab$ sudo chmod +x
debian@beaglebone:/opt/openhab$ sudo ./


openHAB was installed successfully!




Last week, I already explained how I got the CC3200 to publish data to a broker. The next step, was to have openHAB subscribe to that same data and visualise it.


Using MQTT with openHAB is made easy by means of a ready-to-use MQTT binding.


The first step, is to prepare the MQTT binding addon and define the broker to be used.

To activate the addon, I moved it from the "unused" folder created earlier, to the "addons" folder so that openHAB would be able to use it.


debian@beaglebone:/opt/openhab/addons$ sudo mv unused/org.openhab.binding.mqtt-1.6.0.jar .


Because I also intend to use persistence, I deployed the required addon for that as well.

I've used MySQL persistence before and thought I'd use RRD4J this time around.


debian@beaglebone:/opt/openhab/addons$ sudo mv unused/org.openhab.persistence.rrd4j-1.6.0.jar .


Next, I specified the broker information in the general openHAB configuration file "openhab.cfg".

There is a MQTT binding section in the file, which I edited as follows:


################################# MQTT Transport ######################################
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with a id you choose.

# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883

# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a default one is generated.

# Optional. User id to authenticate with the broker.
# mqtt:<broker>.user=<user>

# Optional. Password to authenticate with the broker.

# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.

# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.

# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.

# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>
#mqtt:<broker>.lwt=<last will definition>


For the parameters you intend to use, it is important to uncomment them and to replace "<broker>" by an alias you can refer to in the items configuration. In this case, I used "eclipseIot" as an alias for testing.<broker>

Then, I started defining my items in the "intheair.items" file.


Group All

Number FT_Voltage_Period "Chart Period"
Number FT_TimeToEmpty_Period "Chart Period"
Number FT_StateOfCharge_Period "Chart Period"

Number FT_Voltage "Voltage [%d mV]" (All) {mqtt="<[eclipseIot:cc3200-fvan/voltage:state:default]"}
Number FT_TimeToEmpty "Time to empty [%d min]" (All) {mqtt="<[eclipseIot:cc3200-fvan/tte:state:default]"}
Number FT_StateOfCharge "State of charge [%d %%]" (All) {mqtt="<[eclipseIot:cc3200-fvan/soc:state:default]"}


After the items, I defined the sitemap in the "intheair.sitemap" file. Pretty simple so far: three clickable items, leading to a chart visualising the history of that specific item.


sitemap intheair label="In The Air" {
     Frame label="Fuel Tank" {
          Text item=FT_Voltage {
               Switch item=FT_Voltage_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
               Chart item=FT_Voltage period=h refresh=6000 visibility=[FT_Voltage_Period==0, FT_Voltage_Period=="Uninitialized"]
               Chart item=FT_Voltage period=D refresh=30000 visibility=[FT_Voltage_Period==1]
               Chart item=FT_Voltage period=W refresh=30000 visibility=[FT_Voltage_Period==2]
          Text item=FT_StateOfCharge {
               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]
          Text item=FT_TimeToEmpty {
               Switch item=FT_TimeToEmpty_Period label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
               Chart item=FT_TimeToEmpty period=h refresh=6000 visibility=[FT_TimeToEmpty_Period==0, FT_TimeToEmpty_Period=="Uninitialized"]
               Chart item=FT_TimeToEmpty period=D refresh=30000 visibility=[FT_TimeToEmpty_Period==1]
               Chart item=FT_TimeToEmpty period=W refresh=30000 visibility=[FT_TimeToEmpty_Period==2]


Finally, I set up the persistence by creating a configuration file for it.

The file should be located in "/opt/openhab/configurations/persistence" and have the name of the persistence service to be used with ".persist" extension. In my case "rrd4j.persist".


This is what I put inside the configuration file:


Strategies {
  everyMinute : "0 * * * * ?"
  everyHour : "0 0 * * * ?"
  everyDay : "0 0 0 * * ?"

  default = everyChange

Items {
  * : strategy = everyChange, everyMinute, restoreOnStartup


After all the modifications, I restarted openHAB for everything to take effect.


To close this week's post, I have some screenshots of openHAB with some Fuel Tank BoosterPack data received from the CC3200 via MQTT:

Screen Shot 2014-11-26 at 10.40.21.pngScreen Shot 2014-11-26 at 10.39.27.pngScreen Shot 2014-11-26 at 10.39.48.pngScreen Shot 2014-11-26 at 12.38.11.png


In my next post, I'll be describing in detail how I got the Fuel Tank to work with the CC3200 in order to retrieve battery information, along with longer duration measurements.

NO2 sensor MiCS 2710


Today I connected the NO2 sensor MiCS 2710 to the MSP430 Launchpad.

This sensor features low heather current (26 mA), fast response, miniature dimensions and high resistance to shocks and vibrations


Hardware considerations

MiCS 2710 has four connections:


Mics2710 pinout.png 



A heather power of 43 mW is applied between pins 3 and 1. This the temperature of the sensing resistor to reach up to 220 °C. Detection of pollution gases is achieved by measuring the voltage drop on the sensing resistor Rs.

The wiring diagram is shown below


Mics2710 wiring.png

The sensor is powered with 5 V.

Datasheet states that the maximum power the sensor can dissipate is 1 mW.


Mics2710 datasheet1.png

Because in the worst case Rs is 0.8 kΩ, the maximum allowed current is


Formula 08_01.png



To limit the current that goes through Rs, another resistor is required. The value of this resistor can be determined by imposing



Formula 08_02.png


Let's take some safety margin and let's use a 4.7 kΩ resistor.

To determine the resistor to connect to the heather terminal, we have to impose that the current through the heather is 26 mA. So


Formula 08_03.png



With a 100 Ω resistor and a 33 Ω resistor in series, we also meet the maximum power dissipation requirement, because



Formula 08_04.png



I have now to limit the maximum voltage not to exceed to analog Vref (2.0 V). The voltage limits are


Formula 08_05.png

Formula 08_06.png


The Vmax exceeds the ADC limit, so a voltage divider is required. The ratio of the voltage divider is


Formula 08_07.png 


I can choose R1 = 10 kΩ and R2 = 0,73 R1 = 7,3 kΩ. The voltage divider are going to be connected in parallel with the Rs, so it would affect the Equivalent Resistance. An operation amplifier in buffer configuration is required.


MiC2 Signal conditioning.png 


Software implementation

Using the same functions I already talked about in my previous post, I can write a the function to read out the output value provided by the MiCS 2710 sensor


float val = SENSORS_AnalogRead(ADC12_B_MEMORY_2);


According to calculation, the minimum ADC value corresponds to the maximum N02 concentration. I have taken a general approach and I created a function that linearly maps a given range of input values to a given range of output values

float SENSORS_Map(float x,

    float in_min, float in_max,

    float out_min, float out_max)


  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;



The input and output ranges for the MiCS 2710 are as follow


ADC Value

NO2 ppm






Now I'm ready to write the final function to read N02 concentration


void SENSORS_ReadNO2()


  float val = SENSORS_AnalogRead(ADC12_B_MEMORY_2);

  SENSORS_Data.NO2 = SENSORS_Map(val, 1023, 0, 0.01, 5);


Humidity sensor HIH4000

Today I connected the temperature sensor Honeywell HIH 4000 to the MSP430 Launchpad.

With a typical current draw of only 200 µA, this sensor is ideally suited for low-drain battery-powered devices.

Hardware considerations

HIH4000 has only three connections:

  • Vcc
  • GND
  • Output


The output voltage varies linearly with the Relative Humidity. Output voltage depends on Relative Humidity as shown in picture


HIH4000 Output voltage.png


According to datasheet, output voltage ranges from 0.8 V to 4 V. Because ADCs are configured to have a Vref of 2.0 V, a voltage divider is required.

Just to prevent any possible impedance mismatch between the HIH4000 output and the ADC input, I added a 741 operational amplifier in buffer configuration

The Vcc is provided through the ULN2003LV integrated circuit


HIH4000 Signal conditioning.png


To determine the R1-to-R2 ratio, the following equalities can be written


Formula 07_01.png


and substituting


Formula 07_02.png


Vmax is the maximum sensor output voltage (4 V) and Vadc is the ADC maximum input voltage (2.0 V). This leads to


Formula 07_03.png

Formula 07_04.png

Assuming R1 and R2 equals to 10 kΩ, the Equivalent Series Resistor seen by the sensor output (ignoring the input impedance of the operational amplifier, which is in theory infinite) is

Formula 07_05.png

So the sensor current load is

Formula 07_06.png

which seems to be ok


Software implementation

Using the same functions I already talked about in my previous post, I can write a the function to read out the output value provided by the HIH4000 sensor


float val = SENSORS_AnalogRead(ADC12_B_MEMORY_1);


According to the datasheet, relative humidity read by the sensor must be compensated in temperature according to the formula


Formula 07_07.png

T being expressed in degrees Celsius

The formula to convert ADC reading into RH is

Formula 07_08.png


  • "RH"  is the relative humidity (%)
  • "ADC reading" is value returned by the AD converter
  • "ADC precision"  is the ADC reference voltage (2.0 V) divided by the maximum value returned by the AD converter (1024). This resulting value is 2.0 V / 1024 = 0.00195
  • "Vout @ 0 RH"  is the output voltage when the sensor measures a Relative Humidity of 0. According to datasheet, this is 0.8 V. This value must be divided by the voltage divider ratio (2)
  • "Voltage step per RH"  is the variation in the voltage output when Relative Humidity changes of 1%. This can be calculated as

Formula 07_09.png

Note that the voltage divider ration must be taken into account when defining Vout@100RH and Vout@0RH


#define SENSORS_HIH4000_V_RATIO    2.0f

#define SENSORS_HIH4000_V_0RH      (0.8f / SENSORS_HIH4000_V_RATIO)

#define SENSORS_HIH4000_V_100RH    (4.0f / SENSORS_HIH4000_V_RATIO)

#define SENSORS_HIH4000_RH_MAX      100

#define SENSORS_HIH4000_V_PER_RH    \



void SENSORS_ReadRH()


  // read sensor value

  float val = SENSORS_AnalogRead(ADC12_B_MEMORY_1);


  // compensate with temperature

  val = val / (1.0305 +

            (0.000044 * SENSORS_Data.temperature) +

            (0.0000011 * SENSORS_Data.temperature * SENSORS_Data.temperature));


  // scale value to get RH


  val = (val - SENSORS_HIH4000_V_0RH) / SENSORS_HIH4000_V_PER_RH;


  SENSORS_Data.humidity = val;


Temperature sensor TMP36

Today I connected the temperature sensor Analog Devices TMP36 to the MSP430 Launchpad.

I chose his sensor for my project because it is widely used, cheap and very easy to use


Hardware considerations

TMP36 has only three connections:

  • Vcc
  • GND
  • Output

The TMP36 sensor can measure temperatures between -40 °C and +125 °C and provides an linear output voltage between 0.1 V and 1.7 V. At 0 °C, the sensor outputs 0.5 V. The output changes of 10 mV for each degree of temperature. So the maximum output voltage is


Formula 06_01.png 


This means that output of the sensor can be connected directly to the input of the MSP430's ADCs. Just to prevent any possible impedance mismatch between the TMP36 output and the ADC input, I added a 741 operational amplifier in buffer configuration


HIH4000 Signal conditioning.png 


The supply voltage of the sensor comes from the LTC3108 VOUT2. VOUT2 can be configured to output several voltage ranges by properly connecting input pins VS1 and VS2. In this case, LTC3108 is configured to output 5V.

To save energy, all the logic driven by the 5V supply voltage is switched on request. The MSP430 drives the LTC3108's VOUT2_EN pin to switch on and off the 5V output.

The temperature sensor (as well all other sensors on the board) are switched on when required by a ULN2003LV integrated circuit

In the next picture, the 5V supply voltage path is highlighted in red color. The 5V is output by the LTC3108 and is connected to the COM+ pin of the ULN2003LV. When a sensor needs to be switched on, the MSP430 drives high the corresponding output pin (see yellow path). When a ULN2003LV's input pin is high, the corresponding relay closes and this let current flow from 5V to ground thus powering up the sensor. ULN2003LV minimum input voltage is 1.8V, so no extra circuitry is required


TMP36 Power supply.png 


It's very easy to connect the sensor to the MSP430 demo board. I placed on a breadboard the TMP36 sensor and the 0.1 µF capacitor. This capacitor must be placed between Vcc and ground and is required in order to improve the precision of readings



To read output from TMP36, I first configured the MSP430's ADC by means of Grace


TMP36 Grace.png


I'm going to perform a single acquisition of the ADC value, so the clock source and the sample&hold time is not important. I will use a resolution of 10 bits, because this resolution gives me steps of

Formula 06_02.png

which is sufficient for this type of application


To read the ADC value, I use the Texas Instruments driverlib library, which provides a convenient way of accessing the MSP430 peripheral. This library basically wraps the access to peripheral registers in human-readable C functions.

For example, to start an ADC acquisition, instead of

    ADC10CTL0 |= ADC10ENC + ADC10SC;        // Sampling and conversion start


I will write





which, in my opinion, is much more clear

To save energy, I will not loop waiting for the conversion being completed, but I will instead put the MCU in sleep


    __bis_SR_register(LPM0_bits + GIE);    // LPM0, ADC12_ISR will force exit


and will read the ADC value in the ADC12_ISR function

extern void SENSORS_SetADCReading(uint16_t memory, uint16_t value);


#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)

#pragma vector=ADC12_VECTOR


#elif defined(__GNUC__)



void ADC12_ISR(void)


    uint16_t value;




    case  0: break;                        // Vector 0:  No interrupt

    case  2: break;                        // Vector 2:  ADC12BMEMx Overflow

    case  4: break;                        // Vector 4:  Conversion time overflow

    case  6: break;                        // Vector 6:  ADC12BHI

    case  8: break;                        // Vector 8:  ADC12BLO

    case 10: break;                        // Vector 10: ADC12BIN

    case 12:                                // Vector 12: ADC12BMEM0 Interrupt

        value = ADC12_B_getResults(ADC12_B_BASE, ADC12_B_MEMORY_0);

        SENSORS_SENSORS_SetADCReading(ADC12_B_MEMORY_0, value);

__bic_SR_register_on_exit(LPM0_bits); // Exit active CPU

        break;                              // Clear CPUOFF bit from 0(SR)





The SENSORS_SetADCReading function simply set a global variable


uint16_t SENSORS_Adc;


void SENSORS_SetADCReading(uint16_t memory, uint16_t value)


      SENSORS_Adc = value;



This said, the function that reads the ADC value can be written as follow


uint16_t SENSORS_AnalogRead(uint16_t memory)


    // Base address of ADC12B Module. Start the conversion into memory buffer 0

    // Use the single-channel, single-conversion mode




    __bis_SR_register(LPM0_bits + GIE);    // LPM0, ADC12_B_ISR will force exit


    return SENSORS_Adc;



The sensor output voltage has linear relationship with the temperature

TMP36 Output voltage.png 

The formula to convert ADC reading into degrees Celsius is

Formula 06_03.png


  • "°C" is the temperature value in degrees Celsius
  • "ADC reading" is value returned by the AD converter
  • "ADC precision" is the ADC reference voltage (2.0 V) divided by the maximum value returned by the AD converter (1024). This resulting value is 2,0 V / 1024 = 0.00195
  • "output @ 0 °C" is the output voltage when the sensor is at 0°C
  • "voltage step per °C" is the variation in the voltage output when temperature changes of 1 degree °C. According to TMP36 datasheet, this value is 10 mV / °C

The final function for reading temperature value can be written as

#define SENSORS_ADC_V_MAX        2.0f

#define SENSORS_ADC_STEPS_MAX    1024


#define SENSORS_TMP36_V_0DEG    0.5f

#define SENSORS_TMP36_V_PER_DEG  0.010f


void SENSORS_ReadTemp()


  float val = SENSORS_AnalogRead(ADC12_B_MEMORY_0);


  val = (val - SENSORS_TMP36_V_0DEG) / SENSORS_TMP36_V_PER_DEG;


SENSORS_Data.temperature = val;


This is a continuation of Post#4 , data received through UART in Beaglebone board is displayed in terminal. My problem the last time is that I can't send data to AirVantage using MQTT since my Beaglebone is behind university proxy. MQTT is using default port 1883 as reserved with IANA. To avoid this problem, I will be using REST API instead.

In this post, data will be sent to AirVantage using Python with REST API.


About AirVantage:



Sierra Wireless AirVantage M2M Cloud provides a seamless connection between devices, M2M cloud and the enterprise. Devices include Sierra wireless' modules and gateways but third party hardware like Beaglebone may be used instead which may communicate to AirVantage Cloud using standard protocols like MQTT and HTTP. AirVantage platform offers secure big data storage and management with good features like data and communication monitoring. Stored data may be retrieved and integrated with multiple backend systems, web and mobile application. All of this can be tried for six months with up to 5 connected devices through this link Sierra Wireless - AirVantage Enterprise Platform (AVEP)


Connecting Beaglebone to AirVantage Cloud with Python using REST:

Here are some guides on how to setup system on AirVantage:

1. Video Link: Building IoT Projects on the AirVantage M2M Cloud

2. To interface with AirVantage: Using REST API for devices


Command to access Beaglebone serial number:

# hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -s 16 -n 12 2>&1


After AirVantage setup is to write a code in Beaglebone for publishing data. You will need to install "requests" to use example code below:

# pip install requests


Edited version of post#4 Python code ( added sending data to AirVantage )

import serial
import time
from xbee import XBee
import json
import requests

serial_port = serial.Serial('/dev/ttyO2', 9600) #UART2 of Beaglebone
host = ""
url = "{}/device/messages".format( host )

def print_data(data):
  if 'source_addr' in data:
  hex_data = data['rf_data']
  sensor_data = map(ord, hex_data)
  doxy = sensor_data[1]
  data = [
    "algal.doxy": [
      { "value" : doxy }
    "algal.threshold": [
      { "value" : "30" }
  ] url,
  auth=("XXXXXXXX", "1234"), #replace XXXXXXXX with Beaglebone serial number
  headers={'Content-type': 'application/json'}
  print 'D.O. = %d'%sensor_data[1]

xbee = XBee(serial_port, callback = print_data)

while True:
  except KeyboardInterrupt:



Run the python code in Beaglebone and monitor updates in AirVantage cloud.

reading nov24.png


Data History: D.O. chart for last 3 hours


Next post: Since I have already tested Beaglebone and AirVantage, I might shift my work on CC3200 and post my experience with it next week.

(Best view still 1900 x 1200)

In this chapter I will introduce some detail for the hardware (humidity and temperature sensor) and a little bit on software.


Hardware is one of the important part for a device so I will try my best to go detail for this section.

I have list down most of the hardware use for this project (please refer to previous blog for detail).

BBB and BB view:



Testing the BBB out of the box. It just working like charm

Using the cable HDMI D to HDMI A from element 14 (

Plug to TV, power it up and it working with no issue. It also working with the DC-DC converter supply from power bank with no issue.

Will going for WIFI connection or Ethernet connection and try for programing in future after finish with the hardware.


BB View 4.3"

It toke me few hour to found the correct link for the image file support the BB view and few more hour to download it

I think better share it here so other have another alternative getting the file.

Tips: Google drive share file here ( This share link is not permanent maybe broken without notice.

TI-SDK image and source code toke about 2hour each to download in Singapore.

The share file from Google drive with hope it will be faster then the given link.


Image NameImage (patched for BB View)Source Codes (patched for BB View)
DebianDebian ImageDebian Source Code
TI-SDKTI-SDK ImageTI-SDK Source Code
AngstromAngstrom ImageAngstrom Source Code
Utility Tools Download Tools


element14: BB View LCD Cape Software Download Centre[1]





To the summary for this testing Sensirion EK-H5 + SHT75

Sensirion EK-H5 and SHT75 humidity sensor and temperature sensor is a complete set for testing.

This system only work in window OS. The application call Sensirion AG/USB RS485 Sensor Viewer.

It can be download from Sensirion webpage or by the given link ( )



STH75 sensor and SHT2 sensor that come together with the evaluation kit.

Tips: please handle the SHT75 sensor with care because the PCB is small



This picture show the complete set of the Sensirion EK H5 and Sensor. It easy to setup.

There is no polarity for the sensor connection but it do not damage if install wrongly. So don't worry.

Software will show error when the sensor install wrongly. Just flip the sensor and problem solve.



This is the inside look of the USB converter. They using Cypress MCU for this and look like EZ USB Cypress chipset to me.

Almost remove the label to see the chip model he..he.. Maybe will do it if have request




I will show some of the software related to the using hardware. This will not cover the detail of the software for this project.

There are few option for BBB, CC3200 and MSP430FR5969. It come with IAR, Energia and CCS

I like the IAR but this one come with size limitation .

Energia is arduino similar platform. For those who using arduino it will be easy to get use of it.



USB Sensor Viewer

This is the software for the Sensirion sensor. I have tested with SHT2 sensor and SHT75 sensor.

Data also can be log using this software and the format is in excel sheet .csv file.


Picture show the USB Sensor Viewer work with SHT2x sensor.



This picture show the USB Sensor Viewer hock up with SHT75 sensor.

Face some issue at the beginning due to wrong polarity sensor install but problem solve when flip the sensor and reload the program (Tips: reload is place at the bottom right)



Taking some data with SHT75 sensor. Sampling rate at 1Hz

Maybe will make a more detail in future for this.


usb sensor viewer data.jpg

This is the example of data logging taking form the sensor using USB sensor viewer from Sensirion.



MSP 430 Software Platform




This is the IAR software for the MSP430 platfrom. This software can only use in Window OS.





Energia is arduino similar platform. This support OS platfrom and look like the only choice for MAC user.





CCS (code composer studio) from TI. Come with a lot of example and it just run in Linux and window.

This software is design to support a lot of MSP430 family. It will be long story if want to do a step by step for this, I think.


Some information related with the CCS but I think it not support the MSP430 family. I need to go a bit detail to tell about this GUI Composer from TI.

Category:GUI Composer - Texas Instruments Wiki


That all for software introduction more detail about software will be posted in the future chapter depend on which software is using for this project.



Interesting Information:

While doing search for example and getting reference form online. I just come across this spark io, they look interesting and using cc3000 TI WIFI module.


Plan to get one of this to try it out. But now can just pre order only


The spark is available in cpc Farnell. Have anyone know what the different cpc farnell and just farnell or element14??



For simple data capture service.

Internet of Things application development platform

Another data capture service for easy and simple use.




Doraemon movie



Dust, Temperature and Humidity Monitor Chapter 4



Dust, Temperature and Humidity Monitor Chapter 6

Previous: In the Air Design Challenge

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


Thanks to Element14 and all the sponsors for selecting me as a rodtester for In the Air Challenge.  I have received Texas Instruments Beaglebone Black, MSP430 and CC3200 launchpads and inductors from Wurth Electronik. I registered at AirVantage and received a kind email with their offer to help me during the roadtester.  Cadsoft sent a licence for Eagle that will allow me to draw schematics and PCBs. Now I am preparing an order list for 500$ to spend. One wish would be that Element 14 as a distributor could get in their webshop sensors from SeedStudio or Adafruit.


I have proposed to study air quality during school classes. Most schools in Latvia are built in times when motorised ventilation was not used. Proposal is to measure carbon dioxide CO2 that is responsible for getting tired. This could teach the lecturer when is time to open the window. Other sensors will be dust, temperature, humidity, air pressure, light, sound level, oxygen O2.


As a dust sensor I have started to use Sharp sensor, but it is sensitive only to average dust level. I plan to detect scattered light from a 10W LED, using a webcam, Beaglebone and image recognition to count dust particles. That would allow to size dust particles. It is known that soot particles less than 10 um can cause lung cancer.


Data will be sent to the Internet of Things for plotting and later evaluation. One would be to look for correlation if air gets worse quicker during mental activities like a math test.



Customs problems

For 3 weeks I could not start the project as experienced problems in the customs with parcels from the USA. Import tax had to be payed but I could not do it as the packages were addressed for the University of Latvia, but in the university administration just kept sending me from one bureaucrat to another.  Best solution was found that Element14 payed the import tax and the packages were delivered to the university where I could pick them up.




MSP-EXP430FR5969 launchpad

  • 16MHz,1.8-3.6v power
  • Ultra-low power consumption mode, Deepsleep LPM 3.5 when only RTC active.
  • It has relatively new type of memory 64 kB of FRAM  that retains data after switching off and can be rewritten practically indefinitely (10E15 times) compared to EEPROM.
  • Analog to digital converter ADC has 12 bits resolution that is 4 times better compared to 10 bits of Arduino.
  • This MSP chip has a built-in temperature sensor. (2 deg.C precision).
  • Most impressive application for me is to run a temperature logger from a 0.1 F supercapacitor.
  • Launchpad  price  is 16 USD.



Out of the Box Demo

Getting started: MSP430FR5969 LaunchPad Development Kit - MSP-EXP430FR5969 - TI Tool Folder

Connected launchpad to PC  USB. Windows installed automatically MSP Tools Driver because I had CCstudio installed from the previous roadtest.

Downloaded software examples "MSP-EXP430FR5969 Software Examples" and read the pdf guides.

User's guide p.27 describes Out Of the Box example.

Programmed OutOfBox_FR5969.

Run /GUI/OutOfBox_FR5969_GUI on Windows. Connected to COM5 and looked at the live temperature data.



Activated "FRAM log mode". Green LED flashes briefly every 5s.

One could store in FRAM ca 8 hours of temperature and voltage as long as supercap lasts.

Set jumpers "use supercap" and "charge" the supercap. Should remove V+ jumper from J13.

Supplied from a from supercap LED stops blinking after a few minutes but the logging continues.

Exit from logger by pressing button 2 or reset button.



TI Energia


Would like to give a try with Energia that is very similar to Arduino IDE.

Downloaded Energia 13. Opened blink example. Tried to upload. Message came that need to run update /programmer

"A firmware update is required for the MSP430 Debug Interface (MSP-FET430UIF / MSP-FET / eZ-FET). "

"device inicialization failed"


It is a bug that several other roadtesters already encountered. Solution will be to wait until Energia 13+ appears.


I think Energia would not allow to use chip-internal temperature sensor and power down modes that are the major advantage of the MSP-EXP430FR5969

chip. Also in Energia is probably not implemented writing to FRAM.






I had CCStudio installed during previous CC3200 roadtest.

Pressed New project/Energia .  A project template came up and it could be compiled and  debuged (press the green bug icon)

Needs to update driver too. Update successful.

"MSP430: Loading complete. There were 506 (code) and 0 (data) bytes written to FLASH. The expected RAM usage is 20 (uninitialized data + stack) bytes."


Pasted Blink example from Energia, pressed "Debug" and after compilation MSP430 launchpad LED started blinking. So far OK.

Next I tried to make LED shine all the time and checked how long it shines from a supercap: 2 minutes and the MSP430 chip was in normal speed mode.


advanced tools/energy_trace  - I could not find where to select

project/properties/build/msp40 compiler/ulp advisor  was already checked active


CCStudio is described in MSP430 user guide from p.26.

I opened and compiled OutOfBox example.

tools/import ccs projects/outOfBox_FR5969

It worked by blinking red/green LEDs and the green LED blinks shorty every 5s  when activated FRAM storage from GUI demo o a PC.


So far OK.  CCStudio works More example code ADC_12, timer is at TI resource explorer.



Left the board runing OOB demo overnight powered from the supercap to see how long time it lasts. In the morning saw that data saving continued for 1/2 hour.

Possible time extension would be by disabling thermometer and LED flashing.


Portable Field Tester part 3, making a solar power supply:


This part will be written by my daughter Chrystal, she is looking after making the power supply for our field tester (With my guidance).


Hi everyone, my name is Chrystal and I am 14 years old. My dad has helped me with this part by explaining diodes, resistors and how electricity works. I will explain each picture in detail as they are posted.



They allow electricity to pass only one way. So the power coming from our solar panel to the chargeable batteries have a diode soldered in (Silver ring end of diode towards the batteries). This stops the charged batteries from forcing electricity back up the wire to the solar panels.




The power supply I made is only for testing as my solar panel I have is not strong enough to power the project. As shown below we are only getting 2V from our small panel. We added a volt meter (I, with Dad's help, built it from a kit) with a push button to display the voltage. The volt meter is powered by a 9 volt battery (This is a waste of energy and won't be battery run in the final project), the push button only displays the volts for the length of time pressed (Saves some energy from being wasted).






The 150 Ohm resistor is to being the 9 volt battery down to the 5 volts required to run the volt meter. The resistor isn't exactly what we should have used as it drops us down to 4.6 volts but still works good (I should have used a 130 OHM resistor).


Recharger Wires:

So the picture above (Mess of wires) I will explain how this works. The green panel behind the battery is the backside of the solar panel. There are 2 red wires and 2 black wires attached, 1 red and black to the battery charger and the other 2 go to the volt meter. The positive red wire that goes to the charger has the diode. It is attached to the positive side of the charger. The negative wire is attached to the negative on the charger.


Volt Meter Wires:

The other red and black wires go to the volt meter test end. I wired it wrong the first 3 times, I hooked it up to the power side which didn't work, then reverse to the test side (Dad finally explained what I did wrong... I learned a lot from this mistake). The positive rom the battery with the resistor attached went to the positive on the volt meter and negative to negative. Oh, I almost forgot to say I put a push button on/off switch in the positive wire of the volt meter.




Working solar energy:

After it was all together I tested it. The panel was put in the light and I pressed the button...... It worked, 2 volts shown!!! I did it, except..... I require around 9 volts to run everything (Beaglebone, TI's, sensors.... ) My solar panel is to small for the energy I require to collect.





The power supply worked great but I require a bigger or more panels to reach the required volts. Dad just informed me he had ordered the panels we required so when they arrive I will make this run our Field Tester.


More to come,


Chrystal W.

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


Since I spent a lot of time on trying to get notifications from AirVantage when new values are published from BBB (in my case just a Paho MQTT client) I decided to dedicate a short post to AirVantage topic.


Wrong approach

At first, I was trying to subscribe to a topic on AirVantage MQTT and receive messages whenever BBB publishes new sensor values. I tried with a couple of different test clients and a couple of topics but no success. I tried using MQTT wildcards (# and +) but still - nothing arrived from AirVantage.

I read some AirVantage docs and find out that I could use REST API to read published data but I was under impression that I should only use MQTT (for some strange reason )

After a few hours of failed attempts I posted a question (Subscription to AirVantage MQTT topic) and soon I got a couple of replies. Some of them were from dlahay who was kind enough to answer all my questions and soon I got my app working…


Correct approach

The correct way to use AirVantage is the following:

  • Use MQTT to publish new data messages like sensor readings (to topic<SERIAL>/messages/json) and subscribe to a topic (<SERIAL>/tasks/json) to receive commands and settings updates. Code sample written in C for publishing data is provided in my previous post. Check API documentation to see how commands can be sent to subscribed clients.
  • On the remote clients (like mobile phones and computers) use REST API to get published data. For example, you can get historical data for the last 3 months.


REST API is well documented and can be found here:


The first thing you have to do to start using REST API is to obtain a valid Access Token. There are three ways to get this token and they are described in documentation too.

  1. Resource owner for really trusted application
  2. Authorization code for server-side application
  3. Implicit for client-side application


I chose the first one because it’s the easy to implement and fits my needs.


It’s as simple as making a HTTPS request to:$$WORD&client_id=CLIENT_ID&client_secret=CLIENT_SECRET



  • YOUR@EMAIL.COM is the email you use to login to AirVantage
  • YOURPA$$WORD is your AirVantage password
  • CLIENT_ID is your API Client ID
  • CLIENT_SECRET is the API Client Secret

You obviously need to have an API Client in order to fill in these parameters. If you don’t have one, you need to create it: go to AirVantage management console and there navigate to Develop -> API Clients and then click Create (Name is the only mandatory parameter). After you create a client you will have your Client ID and corresponding Secret Key.


In response to the above HTTPS request you will receive a JSON string which, among other values like access rights and token type, contains your Access Token that you can use to perform REST API calls. This token is valid for 1 day (86399s to be exact).


One more thing! Many REST API calls take system UID as a parameter, at least those that I require for my application. You can get your system's UID by clicking on System name in the Systems table under Inventory. Make sure not to click the system's serial in that table like I did the first time I tried to get the UID - this will take you to the linked Gateway instead.


I hope this will save time to others who are new to AirVantage or MQTT like I am.




Now that the development environment has been set for the two targeted platforms that will be used for the sensor nodes, in this post I will run through the initial thoughts about the components to be used and how the IO's are utilised.  From the architecture diagram described in this post, there are five sensor nodes outlined in the following sections.


[Vehicle] Emission Sensor




The vehicle emission sensor's role in the system is to monitor the time the vehicle is running (or idling) and samples the carbon emission and sends the collected information to a smartphone.  This sensor node will be powered from the vehicle's 12V battery and then to a dual-channel LDO to provide the voltage rails of 5 and 3.3 Vdc.  The 5V line drives the MQ-135 CO2 sensor which is sampled by the MSP430 via analog input.  The accelerometer (LIS3DH) will be used to measure the vibration of the vehicle as the detection mechanism to determine whether the engine is running.  Data that has been collected will be transmitted to a Bluetooth-enabled smartphone running a background application.  The nRF8001 (from Nordic Semiconductor) is selected to be the BTLE module for this sensor node.  Since the Bluetooth module and the accelerometer are SPI-based peripherals, they will have to share the SPI peripheral of MSP430 and so the CS pin should be managed through software.

Details about the smartphone application will be presented in future posts.

(Outdoor) Environment Sensor


This outdoor environment sensor will be using the CC3200 for sampling, managing peripherals, and the wireless transport of data to the central hub.  Being an outdoor sensor, it is ideal to have the design a maintenance-free device.  So the design of the power module uses both solar harvesting energy and a rechargeable battery which are inputs to TI's BQ25504 LDO and battery management IC.  Aside from the high efficiency DC/DC boost converter and battery management feature, what make the BQ25504 perfect for this solution is its battery status feature which can be used to trigger an event on the CC3200 application and manage the peripherals effectively.


Battery output voltage will be boosted up to 5V using TPS6123x powering the MQ-7 sensor.  Additionally, this node will have a few more sensors, including the HDC1000 temperature and humidity sensor and to be connected to the CC3200 via I2C bus.  An ambient light sensor and a non-invasive current sensor, both of which are sampled via analog inputs.


(Indoor) Environment Sensor


As described in earlier post, this sensor is really for monitoring the air quality and environmental conditions inside the house and relays the sensor information to the central hub.  The hardware configuration resembles much like the outdoor sensor but is solely powered by a battery then to a dual channel LDO to generate the voltage rails for the sensor and the remaining circuit.  The other notable difference in this configuration is the use of a buzzer.  The buzzer will be used as an audible alert notification should there be 'health risk' conditions detected, i.e. high CO levels, house too hot or too cold, smoke/fire, etc.


Smart Plug and Smart Switch


The switch and plug sensor nodes are very much quite similar in hardware.  Both are using the CC3200 as the core and has the capability to control the load via relay switch at the same time measure and monitor power consumption using a Hall-effect based sensor (ACS712).  The sole difference between these two sensor nodes is that the smart switch will be fitted with a light sensor.


One interesting and challenging part of this design is around the power supply block.  The challenge is to have a small-sized DC power supply from AC and so I have looked at different options to achieve this.  Initially, the design follows a transformer-less approach as briefly described in this link.  This approach is very cost effective but is not safe as it does not provide any isolation from the high AC voltage.  The second approach is to used a very small AC-DC step down transformer as used on USB chargers.  This method will be ideal as it provides AC isolation.  However, I have difficulty sourcing the most economical transformer.  If you know of a solution, please share it in the comments below.  Perhaps there is a solution from Wurth Electronics that I could not find in their catalogue.  Further searching, I found two components which fit the requirements and have a very small footprint: VTX-214-001-105 and VSK-1U-5S.


That's it for now.  My next post will be about the firmware development for the emission sensor.

Did a little bit of project planning along with some schematic work last night. Put together a gantt chart to keep myself on track with the competition deadline.

In my last post, I have walked you through on how to write firmware for the MSP430 using Visual Studio and VisualGDB.  This post however is now focused on developing for the CC3200 using Visual Studio.


TI's CC3200 was not officially supported by VisualGDB, and so will have to follow their legacy tutorial on how to setup the development environment.  This tutorial however is a bit cumbersome and you will have to extract the GCC flags from the example make files.  Below are the VisualGDB (GCC) settings used for this approach.  Ensure that the CC3200 SDK has been installed in the default directory.




Include Directories




PreProcessor macros


Entry Point Argument


Linker Script


Additional Libraries

"add path as required."


CPU type flag


There is one big hurdle with this approach, and that is debugging.  Setting up the environment to debug the firmware was a bit tricky such that it requires changes to OpenOCD, one needs to configure the connection interface with LaunchpadXL, etc. which I had serious struggle getting that up and running.  So I contacted SysProgs support team and ask them to lend me a hand on how to get debugging work on the CC3200.  Kudos to the support team, that not only they helped me out on how to configure the debugger, they actually made updates and patches to OpenOCD and officially support the CC3200.  My contribution to them was really about testing the update and providing feedback.  The tutorial can be found here.

I have tried the TI's sample applications by following the tutorials and they do work as expected.  Then I tried creating another project based on the tcpSocket example from which I will build my firmware for the sensor nodes.  My current VS solution now looks like the image below.


Some important stuff:

  • If you have setup VisualGDB before and have OpenOCD already installed, you will have to manually delete the folder C:\Users\<CurrentUser>\AppData\Local\VisualGDB\EmbeddedDebugPackage\com.sysprogs.arm.openocd.  If this folder has not been deleted, VisualGDB will throw an error in Step 5 of the tutorial.
  • When selecting the CC3200 MCU variant, if your CC3200 LaunchpadXL board is rev 3.2, choose XCC3200HZ (170Kb RAM variant).  Better yet, check the chip marking.
  • Possibly the most important part.  Microsoft has released Visual Studio Community Edition which has all the capabilities of the VS Professional variant but FREE.  You can download Visual Studio Community Edition here.


Now that the development environment has been setup for my sensor nodes, my next posts will be more design-focused and will go through the guts of the CFMS (Carbon Footprint Monitoring System).



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


I'm designing my circuit board as a booster pack for the CC3200 Launchpad. It's taking a long time because I'm trying to use TI parts for every component, and the plague (read flu) just passed through my household. I'll be finishing the board and ordering it and my parts soon. While waiting for the parts, I will work on the software.




Hope on over to Newark or Digikey and do a parametric search for inductors. Ever notice voltage isn't usually a parameter to be refined? It’s always seems to be current for an inductor, voltage for a capacitor, and power for a resistor. This isn't always true, but it is in most instances. Why, do you suppose, are inductors usually current rated and not voltage? I’m going to leave this question unanswered so as to spark a conversation about it.


We were sent four kits as part of the design challenge:


  1. WE-SPC SMD Shielded Power Inductor
  2. WE-MAPI – Metal Alloy Power Inductor
  3. WE-MAPI - Metal Allow Power Inductor
  4. WE-LMHI – SMD Low Profile High Current Molded Inductor


I hope you didn’t throw the boxes away, because there is a pair of plastic tweezers embedded into the wall of each cardboard box, just in case you didn’t have a pair. Note, they’re anti-static plastic tweezers:


I’m not sure how much heat they can take, so I may have to sacrifice a pair to find out. Kudos to WÜRTH ELEKTRONIK. These kits are great. I’m really impressed with the presentation. Wurth definitely met their motto of “more than you expect”.


The Inductors We Have

Let’s have a look at the packages of the inductors we’ve been provided:


WE Inductor Selection.png

Figure 1: WÜRTH ELEKTRONIK Inductor Selection


This image is my attempt at showing the relative size of each inductor package with respect to each other. The packages are associated with a metric number like 4818. The first two digits refer to the square dimensions of the package (width and length) and the second two digits are the height. For example the 4818 refers to a 4.8 mm square package with a height of 1.8 mm. In Fig 1, notice the first three types (left to right) have the term Power Inductor directly in their names. In fact, all the inductors we have been supplied are power inductors. This is because they are typically used in applications involving power supply design. They have other applications, but by far the most common is likely the design of switching DC to DC voltage converters (think Buck or Boost regulators). The WE-SPC is a coiled power inductor (as far as I can tell) and is shielded. Depending upon your efficiency requirement the presence of a shield can be quite important. It essentially isolates the magnetic field of the inductor from the rest of your circuit. Having said that, it also stops EMI from affecting the rated inductance value. The WE-MAPI inductors are shielded as well and made from a metal alloy, likely proprietary and patented.


If you consider all the MAPI packages they cover the same inductance span as the SPC, but their package is significantly smaller. Let's take a 47 uH SPC and a 47 uH MAPI for comparison.


Parameteter74408941470 (SPC 47 uH)74438335470 (MAPI 47 uH)
Rated Current (A)0.40.4
Saturation Current (A)0.751.2
RDC typical (mΩ)9602090
RDC [max?] (A)11332300
Resonant Frequency (MHz)148


The first thing that I noticed was, for 47 uH, the MAPI inductor has over twice the DC resistance of the SPC inductors. That's perfectly fine if your application can withstand the I²R losses. I'd go with the MAPI if possible because it is so much smaller and it's 75% the cost of the SPC inductor. Note, in this instance the MAPI is 3.0 mm x 3.0 mm x 1.5 mm and SPC is 4.8 mm x 4.8 mm x 1.8 mm. Personally, I lean more towards price than anything else, so that is what makes the MAPI more attractive to me. The final inductor in our list, the LHMI, is a low profile, high current inductor. It can handle the same or more current than the SPC package, and it's very low profile.The LHMI and SPC cost about the same, so if you need the space you might choose the LHMI. The specifications of the LHMI claim "no acoustic noise and no leakage field", so maybe they are targeted at quiet power supplies for audio equipment? I've heard it mentioned to steer clear of switching regulators for audio applications, but that was back when the switching frequencies were in the tens of kilohertz. I think I will be using the MAPI inductors, because they offer the best performance for the price.


Using the Inductors


Let's assume, like me, you are designing a PCB for your project. This PCB is going to supply power to all your sensors and allow the sensor outputs to be digitized by one of your launch pads. I need to drive a pump in my design, so I used TI's WEBENCH software (on their website) to design a 12 Volt to 3.3 Volt regulator using the TPS62175. If you've never tried the WEBENCH Designer, it's pretty neat. On TI's website if you are looking at the "main page" for a part on the right side will be a link to open the WEBENCH designer for that part. Figure 2 shows the resulting regulator design.


TPS62175 Circuit.png

Figure 2: TPS62175 12V to 3.3 Volt Regulator Design from Web Bench.


You'll likely notice the inductor L3, which I chose as a 10 uH MAPI inducutor (P/N: 74438336100). You might also be wondering why there is a pin 11. That's the thermal pad on the underside of the chip. There are other ways to include that pin in the design, I just prefer to add an extra pin. That covers the regulator. Next we'll talk about an extremely important concept with regard to mixed-signal design, that is designs including both an analog and digital ground. Supply and ground decoupling. To emphasize why, let's look at Figure 3.


Supply Decoupling.png

Figure 3: Supply Decoupling (SGND is signal or analog ground)


Figure 3 shows the launch pad designators on the left (GND and LP_+5V) and my decoupled versions on the right (SGND and VCCS). I've decoupled the 5 Volts and ground from the launch pad header connector. Digital circuits are noisy; that's just the way things are. Digital by nature has higher noise immunity, so it stands to reason that the circuitry is likely noisier than its analog counterpart. I don't want any of that noise created by the digital circuitry to show up in my analog circuits (sensors). The easiest way for this noise to get to the analog parts is via the power supply or the ground connection. Given that, we separate them using inductors because our DC signal can pass unaltered and the AC signals (noise) will be presented with a high impedance. Remember the reactance of an inductor is proportional to frequency (X = jωL). This is where the term choke comes from, since AC signals will be attenuated. There are caveats here, especially with the ground decoupling, but unless you are dealing with high return currents it's a pretty safe practice. The issue that could arise is ground lifting. If the return current from the signal or analog ground is high enough the I²R loss of the inductor will lift the analog ground above digital ground. This will likely cause an offset error in your digitized sensor reading.


That's it for now, hope it helps. If you find a mistake, let me know in the comments so I can correct it.

<< Previous

Table of contents

Next >>

In my previous post In The Air [IoT_Healthy] #Post 3: BBB/Pi to Airvantage via MQTT using Paho python client ,I have discussed my work for Sending Temperature and Humidity data to Airvantage cloud using MQTT Paho python client running on RPi.


Currently I am working on Receiving data/task from Airvantage cloud and do some control at RPi.


This week I am on trip for training... So not able to post current status of my work... Also I am still waiting for my components mainly BBB and CC3200.


Our Indian competitor friends starts receiving their kits so I am hoping that my kits will be on my doorstep soon..


So In next week I am hoping for some fruitful results...

Previous posts:

In the Air Design Challenge - Pollen & Allergen Sensing

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



Since I had problem with customs and still waiting for my kits (Christian is very helpful and hopefully we will sort it out soon) I decided to spend some time in preparing software part of my project, both BeagleBone Black and remote clients.


Development platform

In order to make one code base that will run on multiple platforms (desktop and mobile) I decided to use Qt | Cross-platform application & UI development framework. Qt framework is packed with features that make life easier for developers. I have some experience with Qt but not too much so this will also be a fun way to get more into the Qt framework and development tools.

As we got free AirVantage MQTT access, I decided to use the C version of open source Paho MQTT library (Paho - Open Source messaging for M2M). This library provides versions for use in many popular programming languages (Java, C/C++, Python, Go, JavaScript and C#). There’s also a version called C(Embedded) suitable for microcontrollers if you plan to publish data from a LaunchPad or if you plan to send some commands directly to it (via subscription).

Additionally, I chose to use the AnalogWidgets library for Qt (nice gauges design in my opinion).


This library provides some nice gauges that can easily be customized for my project. I will use it for both apps (clients and BBB dashboard).


BeagleBone Black

BeagleBone Black will serve as a central house unit that’s responsible for communication with AirVantage cloud service and on the other side for communication with CC3200 LaunchPad. It will also serve as a system dashboard – I ordered a 4.3” resistive touchscreen for BeagleBone Black to be used for that role. There are tutorials and even YouTube videos on Qt development for BeagleBone black so I will just provide some links:

Project specific code is the part that’s in charge of MQTT publishing and here’s how it looks like. It’s pretty much out-of-the-box example with a small addition to connection options – username and password must be provided for AirVantage. Additionaly QoS parameter had to be set to 0 for data to be published successfully.



#define ADDRESS  "tcp://"
#define CLIENTID  "BBB_Client"
#define TOPIC  "123456789/messages/json"
#define TOPICSUB  "123456789/tasks/json"
#define PAYLOAD  "{\"machine.temperature\":39.2, \"machine.humidity\":86, \"machine.pollen\":3 }"
#define QOS  0#define TIMEOUT  10000L

QTTClient client;
MQTTClient_connectOptions conn_opts = MQTTClient_connectOptions_initializer;
MQTTClient_message pubmsg = MQTTClient_message_initializer;
MQTTClient_deliveryToken token;
int rc;


conn_opts.keepAliveInterval = 20;
conn_opts.cleansession = 1;
conn_opts.username = "123456789";
conn_opts.password = "supersecret";
if ((rc = MQTTClient_connect(client, &conn_opts)) != MQTTCLIENT_SUCCESS)
      printf("Failed to connect, return code %d\n", rc);

pubmsg.payload = (void*)PAYLOAD;
pubmsg.payloadlen = strlen(PAYLOAD);
pubmsg.qos = QOS;
pubmsg.retained = 0;

MQTTClient_publishMessage(client, TOPIC, &pubmsg, &token);
printf("Waiting for up to %d seconds for publication of %s\n on topic %s for client with ClientID: %s\n", (int)(TIMEOUT/1000), PAYLOAD, TOPIC, CLIENTID);

rc = MQTTClient_waitForCompletion(client, token, TIMEOUT);
printf("Message with delivery token %d delivered\n", token);

MQTTClient_disconnect(client, 10000);

I plan to add the history charts to the dashboard but I still didn’t manage to get the historical data back from AirVantage. There seems to be a REST API for getting raw historical data ( but I didn’t find anything like it in AirVantage MQTT Docs.

I’m not sure if this is even possible with MQTT.

UPDATE: No, it's not. We have to use the REST API to get historical data. Please read the following post for more details: In the Air Design Challenge - Pollen & Allergen Sensing – Post 3 (AirVantage Intro)


Optionally, depending on sensor inputs or AirVantage commands, BeagleBone Black should also control actuators (if I get enough time for it). I’m not sure I will fit this task into given timeframe, might be done later.


Remote clients (desktop and mobile)

As I said, Qt will also be used for remote clients, both mobile and desktop. It will also be able to show readings history when I sort out how to get it from AirVantage using MQTT.

Additionally, I will support direct actuators control once I get to the point that I can add them - not necessary in the given timeframe.

I’ve come up with an initial application design that runs on Desktop(Windows, Linux and Mac), and mobile (Android, iPhone and BlackBerry) but still not good enough to be presented here so give me a week or two for screenshots.

Previous posts for this project:





I'm not feeling the Launchpad love ... yet. The biggest struggle so far has been the software:

  • CCS only available on Windows
  • Latest MSP430 with EnergyTrace not supported on Mac
  • Can't get the CC3200 to work with Energia on Mac either


I'm not giving up yet though! I got some news from the TI people at electronica last week, stating the following:

  • A new version of Energia should be coming out any time now, supporting the MSP430 with EnergyTrace on Mac
  • A CCS(-like) version for Mac is expected to be released by the end of the year


So until then, I'm stuck with my Windows machine in order to make some progress.


I've been playing around with the CC3200 with both CCS and Energia. These were my tests ...


Getting Started Guide


What better place to start than the "Getting Started" guide ? Well, There is this extremely nice post by shabaz : CC3200 "Internet-on-a-Chip" Getting Started Guide – Part 1


Following the instructions from both sources, I set up Code Composer Studio, flashed the CC3200 with the latest software version and got my first sample program running: "wlan_station".

The wlan_station example has the CC3200 connect to the network, ping the gateway and ping an external host ( I believe), lighting up an LED for every successful test.



I won't repeat all the steps performed here, as they are already very clearly documented, and this would only result in duplication of information.


Out Of Box


Using CCS, I then loaded the OOB (Out Of Box) program back on the CC3200 and experimented with that for a little bit.


Connecting to the CC3200's access point, some demos are accessible:

  • sprinkler simulator
  • washing machine/dryer monitor
  • door alarm
  • thermostat simulator


That was nice and working well, but I wanted to have the CC3200 connect to my home network instead of having to go through the CC3200 access point.


I came across a tutorial video, where a smartphone app is used to connect the CC3200 to a wireless network. There is an app available for Android and iOS.


photo 3.PNGphoto 1.PNGphoto 4.PNGphoto 2.PNG


The first step is to enter the data of your wireless home network, after pressing start, the application discovers the CC3200 and has it connect to the home network.

The CC3200 can then be selected from the list of discovered devices and the OOB example can be accessed over the home network instead. Finally something that was rather straightforward.





I was feeling adventurous and thought I'd take it a step further: get the CC3200 to talk MQTT.


A while back, kartben posted some videos on getting MQTT with Paho on the CC3200 by modifying the OOB example. The videos are very clear and guide you step by step through the setup of CCS and Paho, and which modifications to make to the code. But ... for some reason, that doesn't seem to work for me. Either I did something wrong, or ... I don't know, I probably did do something wrong. There are no compilation errors, and the code seems to run fine, but I'm not getting the MQTT messages.


I wanted to get MQTT working! Searching the web for answers, I came across a MQTT sketch on the Energia website. As I mentioned before, the CC3200 is not detected on my Mac, so I used it on my Windows machine.


After installing the library and tweaking the example sketch, MQTT was working! At last! Not the way I originally intended for it to work, but at this stage and with my current level of frustration, this is more than good enough.


energia.PNGScreen Shot 2014-11-19 at 21.22.37.png


With this finally working on the CC3200, my stress and frustration levels should decrease, enabling me to try and understand what went wrong. *deep breath*

Post 3 :

I have received the boards now. I will be showing initial experience wuth the boards in the coming days. For now i am trying to interface sound in the system.

For this sound detection i will be using adafruit microphone amplifier breakout.

Adafruit Electret Microphone Amplifier : It is used to measure sound levels. The specification of the amplifier is :

Supply Voltage: 2.4v-5v

Output: Rail-to-Rail - up to to 5vp-p

Frequency Response: 20Hz - 20 KHz

Adjustable Gain 25x-125x

Connection :

The amplifier has only 3 connections:


VCC -> 3.3V

OUT -> Analog input

VCC can be anywhere from 2.4-5VDC. For the best performance, we use the 3.3v pin.

The amplifier gain is adjustable from 25x to 125x.

The output will have a DC bias of VCC/2 so when its perfectly quiet, the voltage will be a steady VCC/2 (1.65v).

Measuring Sound Levels : The Audio signal from the output of the amplifier is a varying voltage.  To measure the sound level, we need to take multiple measurements to find the minimum and maximum extents or "peak to peak amplitude" of the signal.After finding the minimum and maximum samples, we compute the difference and convert it to volts.

Although the amplifier is capable of a rail-to-rail signal (3.3v in this case), we map it to a 1v peak-to-peak signal. This output is compared to a reference to know if sound is low, normal or high.


The overall design for sensor is :


Board schematics

After many days, I finally made up my mind about the basic circuitry on the sensor board.


I tried to optimize power consumptions, but some sensors require a power supply of 5V and that's very difficult to accommodate in a low-power design.

Attached to this post is the first draft of the board. There are still some component values to define, but the main idea is there


The power is managed by the LTC3108. This circuit provides a 2.2V power supply, that powers up the MSP430. When the MCU senses (through the LTC3108's PGOOD output) that the 5V power supply is good, it switches on sensors (one at a time) by means of a ULN2003LV.


Because the MSP430 is powered with 2.2V, ADCs accept voltages from 0 to 1.5V, so I scaled all sensor output to that range by means of voltage dividers. I also added a 741 op amp connected as buffer to each ADC input in order not to load the ADC input.

I'm evaluating whether a resitor + capacitor is required at the output of the 741 op amp, but I don't think so mainly because of the very low sampling frequency

(Best view 1900 x 1200)

This chapter I just sharing with all about component and sensor that plan to get.


I will develop hardware in parallel for BBB and CC3200. Both system have pros and cons for example the CC3200 have an build in WIFI which BBB don't have.

But the main reason is because I not really strong in programing especially high level programing and Linux OS.

So this will prepare me with two ready for programing hardware because at this stage I don't know which platform will provide the best outcome in programing and management.

But base on experience CC3200 look more similar with my daily platform micro controller and BBB look more like a small computer.


Given Component:


Long story at 126 page huh...



This also have some story at 66 page another huh...


This one better with 38 page.


This all not included the link given which will increase more page...

Next is must have Design Kit from Würth Elektronik. They come in nicely heavy duty box and nicely organize container.

With the plus is they also come with anti static tweezers.

I will recommended to all R&D engineer or anyone in circuit design.


Nice and solid box. No affect at all with my 2 year old daughter step on it.



Very good container with information and picture about the component inside.This help a lot when searching for component.

There also prepare a place for tweezers where perfect touch here.



Well design and labeling for all component inside.

Will make use of this when design the DC-DC in future.

Really more than you expect. Nice product recommended to all.



Part list from Element 14:

Part can added to parts list using given link below. Part webpage also can be access by click the Element 14 order code below.



BB VIEW_43   BB VIEW_43   or  BB VIEW_70BB VIEW_70






SUNON - EB40200S2-0000-999 - FAN, 40X40X20MM, 5VDCSUNON - EB40200S2-0000-999 - FAN, 40X40X20MM, 5VDC








Line Note:   
  Accessories Available RoHS Compliant





Line Note:   
Accessories Available RoHS Compliant


DUST SENSOR Yes  SG  0 UK 366    S$17.53   



Line Note:   
Accessories Available RoHS Compliant


CONTACT, CRIMP, RECEPTACLE, 32-28AWG Yes  SG 4904 UK 25130    S$0.033   



Line Note:   
  Alternative Products Available RoHS Compliant Accessories Available RoHS Compliant


CONNECTOR HOUSING, 6WAY Yes SG 19947 UK 9254    S$0.041   



Line Note:   
  Accessories Available RoHS Compliant


SENSOR, HUMIDITY & TEMP, 3.3V Yes  US 0 SG  71 UK 32    S$40.56   



Line Note:   


FAN, 40X40X20MM, 5VDC Yes  SG  15 UK 382    S$4.47   



Line Note:   
Accessories Available RoHS Compliant





Line Note:   
Accessories Available RoHS Compliant


MICRO HDMI CABLE ASSEMBLY Yes  US 376 SG 0 UK 0    S$24.45   



Line Note:   
Alternative Products Available RoHS Compliant Accessories Available RoHS Compliant


USB DONGLE, WLAN, 150MBPS Yes  SG 91 UK 936    S$19.40   



Line Note:   
Accessories Available RoHS Compliant

Going to get component:

430Boost-sharp96 - 20 page

Plan to use this with CC3200 and MSP-EXP430FR5969 for showing data information and work as front end GUI.

BB view 43 - 48 page

Plan to use this with BBB for GUI.

SHT 75 - 12 page

This is temperature sensor and humidity sensor (2in1). I choose this sensor because they are the best that I found that come with reasonable price tag.

(please let me now if anyone have better suggestion)

This sensor also come I²C digital output where user can get data with less issue with noise and ADC.…


Dust sensor - 12 page

The only dust sensor available to get on hand. Maybe need to consider the measurement laser system in the laboratory to replace this one.

Hm..m.. I don't think so. Look at the price, no way can use that system.

Other will be the support component like connector, fan, EK-H5, power bank and more.

I will not go into detail for support item unless it useful from my point of view.


We do it with cubic

Design version 1.0.0 with placing all the part in the drawing.

Using multistage concept with each level dedicated for certain part or component. This will make installation, modification, debugging, assembly and other work easy in future.

Plan to use PCB as the base for each stage which can work as support and able to make connection header between them if needed.

Now having some placement issue to bring internal connection out of the box. Maybe the end design in not cube anymore .

Right now just think of using acrylic or 3D printed nylon for this housing. Please let me know if anyone have suggestion . Now just plan for local 3D printing service.


Picture show with transference housing to show the inside part. Current dimension is 120mmx120mmx120mm due to 4.3" LCD. But may change in future.

Other information:


More information on IoT. This is presentation slide show more information about their product.

Building the Internet of Things with Eclipse IoT - JavaLand 2014


Kura-Kura mean turtle in Malay language

Example for BBB with kura Eclipse

BeagleBone Quick Start




Thinking of making cube design for my sensor and look around internet I found this

Cube sensor product on market come with app and base station. More information:


Seat back for a while and rest.....

Nature Wallpaper Beautiful Sunset


OK enough go back to work. he..he..


Dust, Temperature and Humidity Monitor Chapter 3



Dust, Temperature and Humidity Monitor Chapter 5

Ambrogio did a very nice post on how to install java & openhab on BBB:…

Follows an alternative approach for installing JAVA and OpenHab on BBB which is hopefully more newbie-friendly.

1) Where is my Beaglebone ?


I have never played with Beaglebone before, so I assumed it was more or less an RPi and did not bother to look at the details.

Some differences that might delay an excited user are: HDMI plug is not the typical size (Type A), it is micro (type D)

So you need a micro hdmi cable or adapter to connect BBB directly on a monitor.


However, since Debian Linux is already installed in the internal eMMC 4GB, of the latest version of BBB, you can do stuff headless (without monitor) straight away.

So, hook an ethernet cable, power up BBB over USB. Note: use a dedicated PC USB (not a hub, where power is shared across).

(had to press reset for it to boot) ...and blue leds are flashing, Debian is up and running.... but what's the IP address ?


You can find out it’s IP with a number of ways, the easiest one is to try this:


this should by default work on linux/mac but for windows only if you have an mDNS/bonjour service installed.

(if you can’t be bother with bonjour, try FING or see your access point / modem DHCP list)

and you will see this web site running on BBB



of course SSH will work too, username root , with blank password.

(can use putty.exe on windows)



2) Installing JAVA

You can easily install java in BBB via the repository like this:


echo "deb precise main" | tee /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src precise main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer


The above installs the Java8 hard float after accepting the License Agreement ASCII screen, and configures the environment.

Hardfloat can have dramatic performance boost on some applications. More details here: - Oracle JDK


... Alternatively if you want to install JAVA manually:

First step is to download the JAVA8 "ARMv7 Linux - VFP, HardFP ABI, Little Endian1" from oracle. However this is not possible command line from BBB with "wget" because, oracle want's you to accept licences and login. So you need to do it from you desktop and then transfer the file to BBB. One way to transfer the file is via SFTP , so in windows you need to use something like filezilla or

you then sftp://beaglebone.lan

using root and blank password, and transfer the file across. Then...

tar xfvz ejdk-8-fcs-b132-linux-arm-vfp-hflt-03_mar_2014.gz

export JAVA_HOME=/usr/java/ejdk1.8.0/linux_arm_vfp_hflt/jre/

export PATH=$PATH:/usr/java/ejdk1.8.0/linux_arm_vfp_hflt/jre/bin/

...and add last two lines at  ~/.profile set upon boot


Eitherway, you should get something like this in the end:

java -version

java version "1.8.0"

Java(TM) SE Embedded Runtime Environment (build 1.8.0-b132)

Java HotSpot(TM) Embedded Client VM (build 25.0-b70, mixed mode)

Build 1.8.0-b132 is the lates manual one, and build 1.8.0_06-b23 the repository one.

3) Install Openhab

Openhab is very well organized as a community & java opensource project. They have debian builds/repo, and they use cloudbees for continuous integration.


That means it should be very easy to install OpenHab it in BBB/Debian, without having to do any manual stuff.


echo "deb /" > /etc/apt/sources.list.d/openhab.list
sudo apt-get update
apt-get install openhab-runtime


Thats all :-)

Reading package lists... Done

Building dependency tree

Reading state information... Done

The following NEW packages will be installed:


0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.

10 not fully installed or removed.

Need to get 37.5 MB of archives.

After this operation, 42.0 MB of additional disk space will be used.

WARNING: The following packages cannot be authenticated!


Install these packages without verification [y/N]? y

Get:1  openhab-runtime 1.5.0 [37.5 MB]


Of course, you need to select some bindings, e.g:


apt-get install openhab-addon-binding-http

apt-get install openhab-addon-binding-ntp

apt-get install openhab-addon-persistence-exec

apt-get install openhab-addon-persistence-logging

apt-get install openhab-addon-persistence-rrd4j


You will wanna change the OpenHAB's jetty webserver port in /etc/default/openhab since by default its HTTP_PORT=8080, and Debian has already a proxy service there. (e.g. change to 9090)

nano /etc/default/openhab

You may start now the openhab service

/etc/init.d/openhab start

[ ok ] Starting openhab (via systemctl): openhab.service.

service openhab status

find / -name openhab








Unfortunately openhab spreads on the above directories, (vs installing it manually from a zip, which keeps everything in one place)

If you want to replicate the demo you can download/extract the demo zip in /usr/share/openhab

If something is wrong you will need to see the log: /var/log/openhab/openhab.log

I will post more details on OpenHab on a future post, once I have some incoming sensor data.

4) Problems encountered

A) Upgrading

I always have the urge to upgrade stuff to their latest version, but maybe this is not such a good idea. Here is why:

sudo apt-get update

Fetched 20.1 MB in 48s (419 kB/s)


sudo apt-get upgrade

90 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Need to get 63.7 MB of archives.

After this operation, 264 kB of additional disk space will be used.


and got a couple of upgrade errors like:

dpkg: error processing apache2 (--configure):

dependency problems - leaving unconfigured

Setting up libdpkg-perl (1.16.15) ...

Setting up dpkg-dev (1.16.15) ...

Processing triggers for ca-certificates ...

Updating certificates in /etc/ssl/certs... 18 added, 5 removed; done.

Running hooks in /etc/ca-certificates/update.d....done.

Errors were encountered while processing:









E: Sub-process /usr/bin/dpkg returned an error code (1)


Restoring OS

So I guess, its better if you avoid upgrading, unless you want to dig deeper into what's happening.

btw, here are the images in case something goes wrong, or if you wanna try via an microSD card

To restore BBB to original state, download the emmc debian image, sector-write it on an microSD, and boot BBB with S2 button pressed.

Note:If all 4 leds flash together, try again, it should not be like that. (Its a emmc write error)

I flashed SD card again, tried everything from start, and copy finished in ~10min)


B) Debian default approach will not install java:

I could not install java the straightforward Debian way.


sudo apt-get install python-software-properties

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java8-installer


W: Failed to fetch  Unable to find expected entry 'main/binary-armel/Packages' in Release file (Wrong sources.list entry or malformed file)

W: Failed to fetch  404  Not Found

W: Failed to fetch  404  Not Found

W: Failed to fetch  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

root@beaglebone:~# apt-get install oracle-java8-installer

Reading package lists... Done

Building dependency tree

Reading state information... Done

E: Unable to locate package oracle-java8-installer

C) Openhab ver 1.5.1 via deb repository does not seem to work on BBB

Latest stable release of openhab is ver 1.5.1. Unfortunately I could not start the service on BBB neither could I find out what was wrong.

More details here:

They will release version 1.6 in the next few days, so I will upgrade to that version one way or another (via deb repository or manual "zip")


Next post:[Air ex Machina] #05 Lost in the sensors

In this week's post, I will be using a transceiver connected to a UART of BBB to collect data.

  • Cool features of Beaglebone Black rev C
  • Hardware setup
  • Using UART of BBB


Cool features of Beaglebone Black:

     This is the first time I use BBB and below are some of the cool features I love during the first few days of use. This board is amazing and I'm sure there will be more features to enjoy.

  1. Processor. 1GHz chip with 512 of DDR3 RAM
  2. OnBoard Flash Memory. Referred to as eMMC with pre-installed Debian OS. With this, I was able to use BBB out of the box even without MicroSD card and the change from Angstrom to Debian makes my transition from RaspPi easier.
  3. Mini USB Port. This allows you to access BBB through your computer aside from the ethernet port. Since I frequently change IP address of eth0 of the board, the mini usb port gives me a fix way to access BBB (BTW through
  4. Expansion headers. There are two headers labeled P9 and P8 for GPIO, I2C, SPI, UART, CAN, PWM, ADC


Hardware setup:

xbee_analog.jpg xbee_bbb.jpg

The materials used in this post including Arduino board, shields and XBee radios are just to test the UART of BBB and will not be used in the design challenge instead they will be replaced by MSP4305969 and CC110L. The left figure above is the source of data. I am using Arduino Mega with Wireless shield. The transceiver is XBee series 1. The potentiometer is to simulate analog sensor and connected to A5 of the Arduino board.

The right figure is a Beaglebone Black conncted to my computer. The XBee s1 is attached to an XBee shield for Arduino but this shield is just used as breakout board in this setup.

  • XBee pin 1 is Vcc connected to P9_3 of BBB (3.3V source) Caution: XBee operates at 3.3V and check the BBB pin mapping below
  • XBee pin 10 is GND connected to P9_1 of BBB (GND)
  • XBee pin 2 is Dout connected to P9_22 of BBB (UART2_RXD)
  • XBee pin 3 is Din connected to P9_21 of BBB (UART2_TXD)


Using UART of Beaglebone Black:

Pin mapping of BBB with UART pins highlight






1. To use a particular UART, it has to be enabled first:

# echo BB-UART2 >> /sys/devices/bone_capemgr.9/slots


2. Before the code, you have to install xbee library for python:

#tar -xvf XBee-2.1.0.tar.gz
#cd XBee-2.1.0
#python ./ install

3. Create a python file and give it a name:

# nano

4. Code:

import serial
import time
from xbee import XBee

serial_port = serial.Serial('dev/ttyO2', 9600)

def print_data(data):
     if 'source_addr' in data:
          hex_data = data['rf_data']
          sensor_data = map(ord, hex_data)
          print 'D.O. = %d'%sensor_data[0]
          print sensor_data[1]
          print sensor_data[2]
          print sensro_data[3]

xbee = XBee(serial_port, callback = print_data)
while True:
     except KeyboardInterrupt:


Note: Check the table above for device name if you want to use other UART


5. Run the code:



Here is the output:


6. Turn the potentiometer connected to A5 of Arduino to see change of value for  D.O. The other 3 values below D.O. are analog readings from A4,A3 and A2 of Arduino and these will be just random values since nothing is connected to these ports.


I am supposed to publish the received data by the BBB to AirVantage cloud but I am having trouble with proxy configuration since my device is behind university proxy.

I will update this post or have it another post with data in the cloud as soon as I'm able to figure out my proxy configuration.

I am able to update and install in my BBB but sending data to cloud fails. Any help on this is much appreciated. Thanks.

Installing OpenHAB on a Beaglebone Black


This post is about installing the OpenHAB home automation software onto the BeagleBone Black. The idea is to collect data from the AirVantage cloud and make automation decisions based on that data

For BeagleBone Black development, i found the homepage of Derek Molloy ( to be extremely helpful, most of the below setup-steps can be found there. However, that page refers to Angstrom distribution, whereas I installed Debian (see @fvan post in this challenge for more info about installation). So this post details the procedure for installing OpenHAB on Debian

1. Installing the Java JRE

Since the Oracle JRE is reported to perform much better than the OpenJVM implementation, I decided to use the first option. JRE can be downloaded here:


I copied this to /home/debian and extracted the file:

# mkdir /usr/java
# cd /usr/java
# tar xfvz /home/debian/


The bin-folder can be added to the search-path by adding it to the PATH environment variable and I also exported the JAVA_PATH variable:

# export PATH=$PATH:/usr/java/ejdk1.8.0/linux_arm_sflt/jre/bin
# export JAVA_HOME=/usr/java/ejdk1.8.0/linux_arm_sflt/jre


These two lines can be added to ~/.profile (the users shell profile file) to have it set automatically upon next login.


2. Installing OpenHAB

The next step was to install OpenHAB. Just copy the OpenHAB folder into /home/debian/openhab.

I made some changes to, in particular I created an environment variable



and replaced "java" with this variable in the invocation of the runtime

$JAVA -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true -Djetty.port=$HTTP_PORT -Djetty.port.ssl=$HTTPS_PORT -Djetty.home=. -Dlogback.configurationFile=configurations/logback.xml -Dfelix.fileinstall.dir=addons -Djava.library.path=lib -Dequinox.ds.block_timeout=240000 -Dequinox.scr.waitTimeOnBlock=60000 -Djava.awt.headless=true -jar $cp $* -console


OpenHAB will now run (when configured properly) when the script is invoked. As I want OpenHAB to start automatically after a reboot, some additional work have to be done:


3. NTP Support

Next thing was installing the NTP support for the beaglebone. As the systems RTC is not battery buffered,  he date and time information will be lost upon each power cycle. I worked around this by syncing the time via NTP upon each startup

NOTE: I experienced some problems with the led_aging script, so I temporarily removed it

# mv /etc/init.d/ /etc/init.d/

First the NTP package has to be installed:

# sudo apt-get update
# sudo apt-get install ntp


Then /etc/ntp config file needs to be changed, basically to use the local NTP servers from the timeserver pool.

# This is the most basic ntp configuration file
# The driftfile must remain in a place specific to this
# machine - it records the machine specific clock error driftfile /etc/ntp.drift

After that, the local timezone needed to be adapted by letting the symlink /etc/localtime point to the right zone-file:

# rm /etc/localtime
# ln -s /usr/share/zoneinfo/Europe/Rome /etc/localtime

Upon next reboot, the date and time should be correct.

4. Autostart OpenHAB

To automatically start OpenHAB when BeagleBone boots, let's create a file openhab in /etc/init.d

#sudo nano /etc/init.d/openhab

Add the following content



# Provides: openhab

# Required-Start: $remote_fs $syslog

# Required-Stop: $remote_fs $syslog

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Start OpenHAB at boot time

# Description: Start OpenHAB at boot time





export USER HOME


case "$1" in


    echo "Starting OpenHAB"




    echo "Stopping OpenHAB"

    killall java



    echo "Usage: openhab {start|stop}"

    exit 1




exit 0


and save the file.

Now grant execution permissions to the file

# cd /etc/init.d
# chmod 755 openhab

Now let's create a link to the script file in rc5.d (this directory includes all the scripts that are executed when system enters run level 5, which is the default runlevel)

# ln -s /etc/init.d/openhab /etc/init.d/rc5.d/S18openhab

Finally, let's update the service entries

# updaterc.d /etc/init.d/openhab defaults

If you get an error, try

# updaterc.d openhab defaults


5. Setting up a Samba

To make the copy of configuration files easier, Samba can be a valuable approach. Install the SMB server via apt-get:

# sudo apt-get install samba
# smbpasswd

Edit the Samba config file:

# sudo nano /etc/samba/smb.conf


I stepped through the config and configured samba to the local needs, most defaults already fitted. I installed a new share:


comment = OpenHAB
path = /home/debian/openhab
public = yes
writable = yes
printable = no
write list = root


That's all... I am now ready to get data out from the cloud by means of MQTT

ita.jpgThe In The Air Challenge is running from September 22nd to February 27th.

Current Activity:

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

Blog Summary #006 : In The Air Challenge 2014

Blog Summary #007 : In The Air Challenge 2014

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


NameSuper Awesome Blog Time
janisalnisNo Updates

In the Air - Automated Greenhouse First Post

In the Air - Automated Greenhouse Post #2

In the Air challenge - Auto Greenhouse Post #3


In The Air [IoT_Healthy] #Post 1: Introduction

In The Air [IoT_Healthy] #Post 2: Initial thoughts on CC3200,BBB and Airvantage

Arduino+GPRS or Raspberry-Pi to Airvantage

In The Air [IoT_Healthy] #Post 3: BBB/Pi to Airvantage via MQTT using Paho python client

In_The_Air [iot_healthy] : Table of contents


Carbon Footprint Monitoring System - Introduction

Carbon Footprint Monitoring - Architecture

MSP430 Development in VisualStudio


AirMobile - Description

AirMobile - 1 - Experimenting with Peltier cell

AirMobile - 2- Power management

AirMobile - 3 - Power circuit design


In the Air Design Challenge - Pollen & Allergen Sensing

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


Anit-Smog Blog #1

AirWise #2 - Bits and Pieces

AirWise #3 - CC3200 Launch


Low Cost Harmful Algal Bloom Monitoring

HAB monitoring Post #2 (Wireless Sensor Node)

HAB monitoring Post#3 (The Base Station)


[Air ex Machina] #01 Introduction

[Air ex Machina] #02 LaunchPad cc3200 first play

[Air ex Machina] #03 CC3200 with CCStudio


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


Dust, Temperature and Humidity Monitor Chapter 1

Dust, Temperature and Humidity Monitor Chapter 2

Dust, Temperature and Humidity Monitor Chapter 3


Pollution Effect Minimiser(Post 1)

Pollution Effect Minimiser(Post 2)


[AirCare] InTheAir - Project Description

[AirCare] InTheAir - Week 1: Getting a Launchpad to Blink

[AirCare] InTheAir - Week 2: Preparing the Beaglebone Black

[AirCare] InTheAir - Week 3: Fuel Tank Testing


iot_field_tester (Introduction)

IOT - Portable Field Tester


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 this chapter I am going to write about dust sensor. If you follow my project then you will know I plan to use Sharp GP2Y1010AU0F dust sensor.

Again I will provide the information here in case someone is not read my previous chapter.



Link to Element 14


Link for datasheet


Related connector



This is a simple dust sensor, it shine an LED light and measure light power or density to determine the dust or particle in the air.

Given picture below show the internal design of the sensor.




















To anyone who want to use this sensor please noted that this sensor is not accurate calibrated and user need to calibrated them to get correct and good data (base on my experience).

They never mention to use different supply for LED and the amplifier circuit. In my case I using same supply 5V for LED and amplifier circuit.

For this testing I using workbench power supply unit but in the real application I going to use DC-DC converter or Power Bank to run the circuit.

I hope those dc-dc not affected the stability of the output data. My selection power bank is Xiaomi power bank due to price and battery given (Mi Power Bank - Mi Singapore).

Will DIY the power management part if possible but for now just keep with power bank.


Warning: Please remember to install the 150Ω resistor before power up the LED to prevent damage to the LED.


LED is driving using pulse wave, LED is activated when the input is low. Mean LED ON when the drive pulse at 0v or lower then 2.5V.

You need a digital output or PWM output for this LED drive pulse.



For data it look straight forward. Output of amplifier is analog signal form about 0.9v to 3.5V.

The important is the data taking need to be taken 0.28ms after the on stage for LED to get the accurate data.


Dust sensor detail:


This is front view of dust sensor(I think). They have 6 pin 1.5mm pitch header and some test point with opening hole from the metal housing.

The variable resistor to set the sensitivity of the sensor also can be access from this side.

Higher resolution picture:



This is back view of dust sensor(also I think). The hole in the middle is to allow air pass and where the air dust will be measure.

Here you also can identifier the sensor brand and model. They are indicated on the housing (this angle of picture normally see for Element 14 order) .

Higher resolution picture:



This view is after metal cover been remove.

Here you can see the transistor, amplifier and PCB where all the component been put together.

The metal cover hold by two screw that screw to the plastic housing.

Higher resolution picture:




The last view is LED, photo detector and lenses in black plastic housing. They been arrange nicely to detect the light reflection

Look like this sensor is not design for servicing. Everything is keep hidden inside and lenses also unable to access from outside.

Higher resolution picture:



Dust sensor testing:


Higher resolution picture:



Higher resolution picture:



For testing I'm using function generator to drive LED and oscilloscope for output reading and measurement.

Look like a particle counter is needed to calibrate this sensor. The output is just difficult to see from oscilloscope and it come in random unless you put something in the hole

Vibration will affected the output of this sensor, mean that this sensor is not suitable to use in a vibrating or very hash environment.

The output signal will keep jumping although the LED pulse is not given.

Lighting also will affected the output signal, this mean when there are strong light shine to sensor it will provide some reading.

This will affected data and provide an error data when in the event of data reading.

Some advice:

Try to make the connection as short as possible to get nice and more accurate data. This also will help to reduce the noise and prevent delay that will affect data taking.

Solder directly to the PCB on this sensor will be better way of connection. Having some issue with the connection using DIY clamp header.





Some example form other work on same sensor.


Please check the code I not sure it working

Arduino code for this sensor

Another similar sensor found just for sharing.

Buy Grove - Dust Sensor [SEN12291P] | Seeedstudio


Dust, Temperature and Humidity Monitor Chapter 2



Dust, Temperature and Humidity Monitor Chapter 4

Design power circuit

Bacause the AirMobile sensor is going to harvest energy from waste heat by means of a Peltier cell, a proper power circuit is required to provide a reliable power supply to the electronic board.

My choice was the Linear Technology LCT3108. This is a highly integrated DC/DC converter ideal for harvesting and managing surplus energy from extremely low input voltage sources such as TEGs (thermoelectric generators), thermopiles and small solar cells. The step-up topology operates from input voltages as low as 20mV.

Using a small step-up transformer, the LTC3108 provides a complete power management solution for wireless sensing and data acquisition. The 2.2V LDO powers an external microprocessor, while the main output is programmed to one of four fixed voltages to power a wireless transmitter or sensors. The power good indicator signals that the main output voltage is within regulation. A second output can be enabled by the host. A storage capacitor provides power when the input voltage source is unavailable. Extremely low quiescent current and high efficiency design ensure the fastest possible charge times of the output reservoir capacitor.


Circuit simulation

Using the power requirements defined in my previous post, I tried to define a power circuit that could meet my requirements. In particular I was interested in determining how much time would be required to charge the super-capacitor that will provide energy to heat up the CO sensor.

LTSpice has been of great help. It can be freely downloaded from Linear Technology web site. Starting from one of the proposed circuits based on LTC3108, I changed the components to meet my scenario.

In particular I assumed that

  • the input voltage from Peltier cell is 300 mV (which is typical for a Δt of 20 °C
  • the Cstore (i.e. the capacity of the super.capacitor) is 0.1 F


The first thing that I found out was that a 0.1 F super-capacitor would never be charged. So I tried again with a 0.01 F super-capacitor, which is, in any case, 10 times the capacitance required by the sensors


            I ran the simulation with this parameters and I got the graph below




           I limited to simulation to 10 seconds due to hardware constraints.

It takes about then second to charge the super-capacitor up to 1.4 V. To simplify, let's assume that the charging curve is (almost) linear. I expect the super-capacitor to be fully charged in 50 seconds. However this is the initial condition. During normal operation the super-capacitor is never going to be fully discharged. The voltage drop should be



  • Vo is the capacitor initial voltage (5V)
  • C is 0.01 F
  • R is the resistance of the circuit. Because current is 200 mA, the resistance R is 25 Ohms
  • Sensor 200 mA for 1 ms to heat up the capsule, to t = 0.001 s

With this values, the above formula tells me that the voltage drops to 4.80 V


Starting from this residual voltage, the super-capacitor is going to be charged at full power in a few seconds

Previous posts for this project:





I am away from home this week, attending Electronica. That doesn't mean I haven't prepared any content for this week's post though


One of the goals for this project is to have the sensors combined with some kind of energy harvesting solution, much like the EnOcean sensors. To do this, I looked at combining the sensors and the CC3200 Launchpad with a battery pack and solar charging circuit. To test the idea, I started with some off the shelf components.


The parts used are:



Solar Charging


There are some interesting posts and discussions regarding the Fuel Tank and solar charging:


According to the datasheet, the bq24210 "... is suitable for charging from alternative power sources such as solar panel ...".


I took a small solar panel for testing, cut the micro USB cable and soldered it directly to the panel.

Alternatively, I could've used the "charge in" and "gnd" points foreseen on the board.

photo 1.JPGphoto 2.JPG

I put the whole thing in the sun, and the "charging" LED was lighting up!

photo 4.JPGphoto 5.JPG

There will obviously be need for actual measurements, but for now, this is sufficient to demonstrate the idea.


Power Save Mode


Thanks to peteroakes' great videos on the Fuel Tank and how he repaired a suicidal boost regulator, I discovered his easy modification to enable low power mode.

I thought I'd give it a try myself, because like he says in the video, it's "something anybody who's got mediocre skills with a soldering iron could do"


First I measured the current without the modification to confirm I had similar readings as he did. I had a reading of about 12.8mA, compared to his 13.4mA, so that was close enough.

photo 4.JPG


Then, I took some female headers and bent the pins, so I could easily solder them onto the pads. The soldering went well, and the result is rather clean.

photo 1.JPGphoto 2.JPG


Finally, I made some jumpers, connected them and measured the current draw again.

photo 3.JPGphoto 5.JPG


Wow, what a difference: from 12.8mA down to 0.93mA! And this modification only took a couple of minutes to apply.


Next week, I hope to hook this up to the CC3200 and visualise the battery's charge over time.

This should help me see the effect of the solar panel charging during the day and the battery discharging over night.


AirWise #3 - CC3200 Launch

Posted by clk Nov 11, 2014

I've decided to use Code Composer for my development environment. So far I have all the software installed, the LaunchPad connected, and the example project from the Getting Started Guide built. Was able to establish a LAN connection and ping the host.


For my next steps I'd like to hook up one of my sensors and have it post ADC readings online. Still working on the preliminary schematic as well.

I received my kit last week and have looked at the different IDE options available for the MSP430 and CC3200.  The choices vary from (1) Energia which has the same feel as coding for an Arduino, (2) Code Composer Studio, an Eclipse-based IDE that is full-featured and has a number of plugins that can extend its functionality especially around code optimisations and debugging features.  CCS costs nothing if compiling with GCC or US$495 when using the optimised TI compiler.  I think its a reasonable price for a good product.  (3) Another option would be to use IAR Embedded Workbench for TI MSP430.  The Kickstart license is free but has an 8K code size limitation which I think is quite small, or shell out anywhere between $4000-5000 for a full license which I think is too dear especially for a hobbyist work whose code space exceeds the code size limit.  (4) The last option, which is hardly mentioned around the web is using Visual Studio.  If you have a license of Visual Studio Professional or above, you can write embedded applications by installing a plugin called VisualGDB.


With VisualGDB, one can write application for embedded devices including and not limited to TI's MSP430.  It has support for STM32 MCUs, Atmels, etc.  Also, depending on the license type, it is also possible to write Linux applications (including the BeagleBone) within Visual Studio.  A 30-day trial period can be downloaded here.


Btw, I am in no way connected with VisualGDB nor am I gaining any profit in any form from them about this write up.  I am merely sharing my experience with this tool.


Again, if you have Visual Studio Professional (or better) installed in your machine and would like to try out this plugin, then continue reading this post.


Getting Started


1. Ensure that the necessary drivers for the MSP430xx launchpad are installed.  Check in Device Manager that you do NOT see a bang icon on the MSP devices as shown below.  If you do, unplug your launchpad and install the appropriate drivers here.

msp driver.PNG

2. Download and install VisualGDB from this link.

3. Download and install MSP430 toolchain

4. Get a more recent version of GCC Toolchain and replace the files at C:\SysGCC\msp430

5. Get a copy of the latest MSP430.dll and paste it to GCC folder C:\SysGCC\msp430\bin

Updating MSP430 DLL.PNG

6. Extract the linker scripts (attached in this post) and copy them over to C:\SysGCC\msp430\msp430\lib\ldscripts\msp430fr5969.

7. Launch Visual Studio

8. Create a new embedded application by following this tutorial.


However, we will be doing some things a bit different, that is when selecting the MCU type, select MSP430FR5969 instead.


9. Continue clicking on the Next button until prompted to select the Debug method.  Use JTAG (gdbproxy++) and set the name to USB.


10. Click Finish and VisualGDB will generate a simple LED blink app.  Unfortunately, this does not work as expected so replace the code in LEDBlink.c with the following, which is the same as the msp430fr5969_1.c sample in the MSP430Ware.


#include <msp430.h>

int main()
     WDTCTL = WDTPW | WDTHOLD;     /* Stop WDT */
     // Configure GPIO
     P1OUT &= ~0x01;
     P1DIR |= 0x01;
     PM5CTL0 &= ~LOCKLPM5;

          P1OUT ^= BIT0;

11. Connect the MSP430FR5969 Launchpad.

12. Click on the 'Run' button and watch the green LED blink.



From here, you can debug the code as you would debug a desktop application.


The immediate benefits from using Visual Studio is that I can have a single Solution that will include multiple projects of various targets, from firmware running on MSP430 MCU, Linux app running on the BeagleBoneBlack, a test application/simulator running on the Desktop, a cloud application that can be deployed to cloud service (i.e. Microsoft Azure), and a mobile app running on a smartphone (Windows Phone, Android, or iOS).  Also, with this approach, we can leverage Microsoft's Unit testing framework even for firmware development.

iOS and Android application development using VisualStudio requires Xamarin plugin and will be covered in future posts.

Power management

Low power mode is a feature for which the MSP430 is designed for. It is useful because it shuts down certain areas of the CPU in order to save power. Since most embedded systems need to be energy efficient, low power modes of operation are employed.

Some microcontrollers may provide a sleep mode that shuts down the CPU clock. The MCU comes out of sleep mode when an interrupt is detected. The program resumes execution following the SLEEP instruction and returns to sleep mode after executing another SLEEP instruction.

TI MSP430 does things a bit differently. The bit settings which select the requested sleep mode are part of the status register (SR). When an interrupt occurs, the mcu stores away the SR and goes into full operational mode, Active Mode (AM). At the end of the interrupt service routine (ISR) the MCU retrieves the saved SR and returns to the previous low power mode.

I want my sensor to be as energy efficient as possible. So my purpose is to put the MCU in sleep for 30 seconds, wake up for the time required to make measurements(about 2 seconds) and then put it back to sleep. During the 30 seconds of sleep the energy generated by the Peltier cell is stored in the super-capacitor to provided extra energy to feed the dust sensor heating cycle

The first step is to get familiar with clocks, timers and low power modes


Clocks and timers

In the MSP430FR5969 MCU, the two main clock generation mechanisms are internal RC type oscillators and internal oscillators using external crystals.

The MSP430FR5969 can contain several internal oscillators. Of particular note are the Digital Controlled Oscillator (DCO) and the low frequency oscillator (VLO). Both of these are based on an RC network. RC networks can be rather inaccurate in generating precise clocks, so TI has trimmed and calibrated them to reach close to 1% accuracy. These type of oscillators are heavily affected by temperature and cannot be always be used for interfaces requiring accurate timing such as UART without causing errors. The DCO is digitally controlled because its frequency can be selected from a given set of frequencies that are calibrated at the factory.

The MSP430FR5969 can also use external crystals with internal oscillator circuitry to generate both low frequency (32kHz) and high frequency (Up to 16MHz) clocks that are as accurate as the crystal used.

The clocks available are the following:

  • DCOCLK - Internal Digitally Controlled Oscillator capable of generating a factory-calibrated set of frequencies.
  • VLOCLK - Internal low frequency and low accuracy oscillator for low power
  • LFXTCLK - Low frequency mode of the XT1 oscillator, typically used with watch crystals or clocks of 32.768kHz.
  • HFXTCLK - High frequency mode of the XT1 oscillator, used with High Frequency crystals. Not available in all MSP430 (not present in G2553 device)

The clock tree in the MSP430FR5969 is actually composed of several signals whose source is selectable. This flexibility helps power CPU and peripherals using different clocks to achieve either speed or low power. The main signals in the MSP430FR5969 include:

  • Master clock (MCLK). MCLK is software selectable as a sub-frequency of LFXTCLK, VLOCLK, HFXTCLK or DCOCLK. MCLK. MCLK is used by the CPU and system.
  • Sub-main clock (SMCLK). SMCLK is software selectable as a sub-frequency of LFXT1CLK, VLOCLK or DCOCLK. SMCLK. SMCLK is software selectable for individual peripheral modules.
  • Auxiliary clock (ACLK). ACLK is software selectable as a sub-frequency of LFXT1CLK or VLOCLK. ACLK is software selectable for individual peripheral modules.


The CPU of the MSP430FR5969 runs only from MCLK, while other peripheral modules can be sourced by any of the clock signals or in some cases from other clock sources brought in on specific pins.


Power modes

The MSP430 features five modes of operation, yet the most popular 3 are the following (the others can be found in the datasheet):

1. Active mode (AM), I ≈ 300 uA
      a. All clocks are active

2. Low-power mode 0 (LPM0), I ≈ 85uA
      a. CPU is disabled
      b. ACLK and SMCLK remain active, MCLK is disabled

3. Low-power mode 3 (LPM3), I ≈ 1uA
      a. CPU is disabled
      b. MCLK and SMCLK disabled
      c. ACLK remains active
      d. DCO’s dc-generator is disabled


Let's code

After this overview, let's write a simple test application.

Texas Instruments provides a great graphical tool integrated into its Code Composer Studio IDE for configuring MCU peripherals: Grace.

Using Grace is very easy: just click on the sub system you want to configure..


.. and this will lead you to a form where peripheral settings can be easily changed


In the same way we can configure Timer 0 to generate an interrupt every second


and GPIOs

The main function is very easy

int main(void)


    Grace_init();                  // Activate Grace-generated configuration


     /* Entering low power mode 3 */





I simply invoke the initialization code generated by Grace, then I enable the interrupt and finally I enter the power mode 3. Because in power mode 3 the CPU is not running (only peripherals are active) a infinte loop is not required. The only code that is going to be executed is the code in the Timer 0 interrupt routine

#pragma vector=TIMER0_A0_VECTOR

__interrupt void TIMER0_A0_ISR_HOOK(void)


    /* USER CODE START (section: TIMER0_A0_ISR_HOOK) */

      P1OUT ^= BIT5;

    /* USER CODE END (section: TIMER0_A0_ISR_HOOK) */


Title: Low Cost Harmful Algal Bloom Monitoring

In post#2, I have identified the sensors, microcontroller and transceiver to be used for the sensor node. For this week to complete the whole system, detailed on the 2nd subsystem(the receiving end) will be illustrated.


A. Aggregator node:

This node collects data from one or more sensor nodes through CC110L transceiver, but this node has more functions than just receiving data. Using CC3200 wifi Launchpad, the node will act as MQTT client, directly publishing received sensor data to AirVantage cloud. With air and water temperature, humidity, color, dissolved oxygen and CO2 data available in the cloud, coastal managers and other authorities can easily assess the possibility of harmful algal bloom through smartphone apps.

Additional function of this node is being a messaging client connected to a messaging server. I am thinking of using this so authorities after receiving data through the cloud may in return send messages that will control sensor nodes in the field.

B. Beaglebone as messaging server:

Sensor data are only particularly useful to authorities who can analyze these parameter but fishing operators, fishermen and ordinary consumers don’t care about these data, all they need is advisory/notification whether it’s safe to harvest/consume marine products. With this in mind, Beaglebone will be setup as XMPP server to send alert messages. This will allow coastal managers to directly communicate to consumers, fishermen and as well as our aggregator node since it was configured to be an XMPP client as well.

C. AirVantage cloud:

All data will be published and stored in this cloud service.

D. Data clients/messaging clients

These refer to consumers, fishermen and other interested parties. I will be creating apps (through the help of my colleagues) that able to graphically display data coming from Airvantage cloud through REST api. The app should have a messaging (similar to Viber) feature, user registered to any XMPP public server will be able to receive messages from Beaglebone XMPP server as long as it’s federated.

In this post, I will share a very high level architecture of the system and a brief description of its subsystems in the section below.




The subsystems can be classified into five: (1) Indoor sensors, (2) Outdoor sensor, (3) Central Hub, (4) [Vehicle] Emission Sensor and (5) Cloud Platform.


1 Indoor Sensors

The indoor sensors include:

(a) Smart plug - this particular unit would be similar to a conventional wall socket unit, but with a built-in power consumption monitoring module.  An ACS712 current sensor will be used to monitor current consumption.  The smart plug will be connected to the home network wirelessly and can be remotely controlled and managed.  Being wirelessly connected, the CC3200 will be the suitable component in the management and control of this sensor.

(b) Smart Switch - similar to the Smart plug, this is pretty much the same as a conventional light switch, but (again) with a built-in consumption monitoring module and an ambient light.

(c) Environment Sensor (Indoor) - having the looks of a smoke alarm system, this module is equipped with additional sensors such as: an air quality sensor, a temperature and humidity sensor.  This sensor will be battery powered, thus an ultra-low power MCU is required to be the brain for this device, at the same time will require to have a wireless interface for it to connect to the home network.  Battery should last at least year before replacement and should inform the user of battery status and notification on low battery state.


Each sensor unit will wirelessly transmit their status to a central hub.  The power consumption reported by these sensors will be used towards the "carbon budget".


2 Outdoor Sensor

This sensor is to be mounted outside the house that will monitor outside temperature, humidity, external light, and an air quality sensor as well, which will be used as differential air quality monitoring.  The outdoor sensor, as with internal equivalent, will be connected to the home network wirelessly.  This will be self-powered for maintenance-free operation.


3 Central Hub

The focal point of the system where all "static" sensor nodes report their status.  The data is collated here then packaged before being sent to the cloud for storage.  The central hub will also dispatch any remote control commands to a connected sensor node.


4 [Vehicle] Emission Sensor

This sensor will be fitted to a car's exhaust system and then be connected to the smartphone device via Bluetooth LE.    The main component for this node will be a CO sensor which will measure the relative CO emission of the vehicle.   An accelerometer will also be fitted and will be used to detect the engine's vibration to determine whether it is running or not.  The duration for which the vehicle's engine is running multiplied by the CO emission factor will be counted towards the carbon budget.  The CO emission data can also be used to notify the user about the relative condition of the car, ie. the higher the emission as compared to a known standard, will suggest to the user that the vehicle will require some servicing.


5 Cloud Platform

This part of the system will include two sub-components: data storage and data viewer.  The central hub and the smartphone will send sensor node data to the cloud storage part.  The data viewer will basically be a web application that will retrieve information from the cloud storage and will graphically present the information on a web browser.  Given the separation of the data [model] with the view, this architecture would make it possible to have a separate view running on a smartphone.


The system has a lot of connected sensors and I have explicitly not went into the details of the components to be used since all these are still up in the air atm, although the initial thoughts would be to use:

  - CC3200 as the main processor for both the indoor and outdoor sensor nodes.

- MSP430 as the main processor for the Vehicle Emission sensor

- Beagle Bone Black (AM335x) for the central hub

- ACS712 for current sensor

- MQ-135 + MQ-7 air quality sensor

- HTU-21D digital temperature and humidity sensor



The flow chart below is my overall idea of how this will work. (Just the start)




Here is the list of Items I have ordered from Element14 with the budget generously provided:







Learning curve


The idea of the device was given to me by my 14 year old daughter Chrystal. She will be greatly involved in the project and learning as much about electronics and programming as possible. Her love for the environment started when she was quite young, her desire is to become a wildlife or environmental biologist. Chrystal has invented an alarm clock that never needs to be set and automates the bedroom.

We will be working together to make this a reality.



First Step:


We have received the parcel the other day, seemed like an early Christmas. We opened it together and were very surprised. We received a Beaglebone Black, MSP 430, CC3200 (Thanks to Texas Instruments) and 4 boxes of Power Inductors (Thanks to Würth Elektronik). We can't thank enough to all those involved in making this challenge possible.

Now with our order placed with Element14, we are starting with experimenting on the Beaglebone Black and solar energy for the power supply. Chrystal will be working on the solar supply while I work on the programming. This is only the start of a long journey of learning and bonding. The next blog will also have a part from my daughter in her words for what she is learning.

Chrystal has also mentioned about having a hydrogen energy cell for power as well. This will be decided later on as I feel we have our hands full already, but I won't say no if she feels it can be incorporated in the design.


To be continued,

Dale and Chrystal

Previous Posts


In The Air: Epidose 1: Introduction

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



I've been combining some "Working With Surface" mount material for this weeks post. The target audience will be anyone who has soldered previously, but has not done surface mount and anyone who could use a few more tricks to add to their repertoire. We'll be covering surface mount soldering using an iron and using paste. If you're not a fan of watching videos, you won't like this post, as I have used videos to show the soldering process.


The Demonstration


This video demonstrates:

  • The setup for surface mount work
  • Removing components with hot air
  • Soldering surface mount components onto a board without using hot air
  • Soldering surface mount components onto a board using hot air
  • Using a solder sucker



The Magnifier Shows


My lamp magnifier showed up after I created the video above, so I made another short video demonstrating the use of the unit.




That's it for now. I hope it's useful when it comes time to solder your project. Good Luck!

Downloaded CCStudio, after creating an account on TI

I am familiar with eclipse based IDEs (for java though), so I thought how hard can this be ?

well... took me an couple of hours to find my way, and understand just the basics.


I started doing random stuff (like always) but this time nothing worked :-) so had to follow carefully this excelent guide (thank you for that shabaz):

which also includes this guide:

Everything went smoothly, and CCStudio works as it should.

I really like the debugger  + serial console, and I guess that's one of the differences with Energia.

In Energia you can not "freeze" running code, so the only way to debug stuff is to use the Serial.println()

In CCStudio you freeze execution at breakpoints and check all variable state, etc..


Furthermore I noticed that http related examples use the TI-RTOS (right?)

I hope an embedded RTOS will not make software development more complicated (than a super loop approach), then again I guess that's unavoidable when program becomes more complex. Will report back on that.


I have encounter a problem. I can not make to "out of the box demo" work 100% correct again. I can see the web site with the demo apps, but temperature value is NaN. It was working when I first received the board, and I want to make it work again, to understand the example, so I will look deeper into that and edit this post.



found more details on the sample programs:

so the problem I had with the out of the box application is solved.

I was flashing "httpserver" and not "oob". Once I had flashed "httpserver", with the android simplelink app, I could see an (offline) website same as oob, and demo apps were not working. When I flashed oob, everything worked correct.


Next post:[Air ex Machina] #04 Beaglebone for dummies - JAVA,OpenHab

Table of contents

<< Previous

Next >>

Introduction :


In this post I will provide Step by step guide for communicating your BBB/Pi with Airvantage over MQTT.

I have used Paho - Open Source messaging for M2M , this guide to install Paho Python MQTT Client on My Raspberry Pi B+. As have not received my BBB so far. I am very much sure that the same steps will also work with BBB.


DIY Guide :


Step1 : Setup System with MQTT Support on Airvantage M2M cloud..


I have used this guide to setup System with MQTT Support on Airvantage Cloud.


Step2 : Test the system using MQTT Client..

I have used MQTTLens Google Chrome extension as easy to use MQTT Client for Test my system on Airvantage cloud from


here is screenshot of connection setup to Airvantage system on MQTTLens... Here username is system serial no and Password is system password...



First subscribe to <username>/messages/json topic then send json string with data....



here is screen shot of my System working on Airvantage cloud..


once airvabtage start responding to your MQTT pulish message then move to next step...


Step3 : install paho MQTT Python client on your Pi... from this guide

once installed creat new python file with your system credential...


import paho.mqtt.client as paho


def on_connect(pahoClient, obj, rc):
# Once connected, publish message
        print "Connected Code = %d"%(rc)
        client.publish("<username>/messages/json", "{\"machine.temperature\": 23.2, \"machine.humidity\": 70}", 0)

def on_log(pahoClient, obj, level, string):
        print string

def on_publish(pahoClient, packet, mid):
# Once published, disconnect
        print "Published"

def on_disconnect(pahoClient, obj, rc):
        print "Disconnected"

# Create a client instance

# Register callbacks
client.on_connect = on_connect
client.on_log = on_log
client.on_publish = on_publish
client.on_disconnnect = on_disconnect

#Set userid and password
client.username_pw_set(<userID>, <password>)

x = client.connect(host, port, 60)



name this file say or any thing of ur this file by command



U will see update on Airvantage cloud with your latest data....


In next post I will explore Airvantage API and creat real time python appilication on RaspberryPi with external inputs ... and will show this data on Airvantage cloud...

Another day, another delivery. This time, a shiny Tenma pH probe has arrived - a delicate looking affair, with the tip sealed into a tiny bottle containing some liquid. This weekend I will hook up the parts to do some initial testing of the sensor.


Plan of action:


  1. Setup OS on Beaglebone, connect it to my network (and Internet).
  2. Get MSP430FR5969 started - connect the pH probe to it, and try out some initial code.
  3. Get Beaglebone talking to the MSP430FR5969, and have some logging going on.


I notice that a humidity/temperature sensor has also arrived, so I will also hook that up and test it.


I am going to get a cheap shelf unit from Ikea which is 2 feet deep, over 2 feet long, and 4 shelves tall. I can sling fluorescent lights under the higher shelves, and plastic growing trays beneath them. Later I will get some heavy duty transparent PVC and fabricate a cover, to complete my cheap greenhouse prototype.


My first actual planting time will be next weekend - for spring season Tomatos, so enough must be ready before then.

R & D:

Sensor, sensor, sensor and more sensor.

Other already start with some sensor and testing but I still in progress looking for sensor . Maybe I should stop looking at other and just doing my own one he..he..

Looking for good and affordable sensor is not that easy and fun. First issue price, 2nd quality, 3rd interface and lease not last program. This all haven't included the accuracy, stability, lifespan and other.


After few research, I have choose this Sharp GP2Y1010AU0F dust sensor and SHT75. Below is more information about this two sensor.



Look like this is the only dust sensor available in element 14 up to my knowledge. Please let me know if someone have any information for dust sensor from element 14.


Now preparing of testing for this sensor. I’m currently using old sensor for testing.


The output for this sensor is analog voltage (please refer datasheet for more information

It should not have any issue for use with BBB or CC3200 unless the build in ADC is not enough resolution for the requirement.


Dust sensor:

GP2Y1010AU0F - SHARP - DUST SENSOR | element14 Singapore

Sensors | Sharp Devices Europe


SENSIRIONSHT75This sensor look good enough for the requirement needed. SHT75 have an accuracy of 1.8% and SHT71 have an accuracy of 3%.

They both using I²C digital output and able to operate at 3.3V or 5.0V.

Another good news is they come with pin package. Wo..ho.. don't need to make PCB for connection.


Planning to get the evaluation kit to help in the testing and more understand about the sensor.

This also will help in development of this sensor in the circuit.



Humidity and temperature sensor(combine):


SHT75 - SENSIRION - SENSOR, HUMIDITY & TEMP, 3.3V | element14 Singapore


For individual temperature and humidity sensor I will look into them if there any issue with the plan sensor.




  • USB
  • DC jack



Memory cards





Using BBB + dust sensor + humidity & temperature sensor + 7" or 4.3" display for BBB + power bank (4cell 18650 battery) + WIFI dongle

Plan 2:

Using cc3200 + dust sensor + humidity & temperature sensor + 430BOOST-SHARP96 + power bank (4cell 18650 battery)



Screen shot 2014-11-04 at AM 10.23.32.png

Experience with some error with blog save draft. I suggest you have another backup although here already have build in back up.

I just lost some of my information here with some unknown error.














Edit and delete is close to each other be careful when aim your target.

So far no issue with this, using a 5200dpi mouse he..he..

One more thing, when the blog is post there is no option for you to bring them back to draft.

But don't worry, you able to edit them from time to time




Dust, Temperature and Humidity Monitor Chapter 1



Dust, Temperature and Humidity Monitor Chapter 3

I had already proposed a design but it was a bit rough and after talking to some sensor vendors, I found that not only are gas sensors expensive but most of them might not be suitable for outdoor use at all. Hence I have cut down on the sensors and added expansion connectors in my design for later use. The current design is shown in the figure below.


It has been a slow week due to personal reasons but I have come up with the above diagram and there are a few pieces still missing which I will add once information comes together.




The system has three main parts. The first is the Field Sensor Node which is where a lot of the work is focused. It uses the 'compulsory parts' and I have received samples via Dr. Defeo. They are SMALL! The objective here is to create a booster pack for power management and an expansion board for the sensors. I will spend the next week working on board layout and will try and send that to manufacturing ASAP. This node talks to my second module which is the Beagle Bone Black over the CC110L which is a 433MHz based module and I am hoping to test out its range and performance. The BBB will have the CC1101 module which is a bit more feature rich and will itself talk to the Sierra Wireless Cloud. I have successfully tested the Sierra Air Vantage platform and will try to do a writeup next week.


The third module is the CC3200 based Table Top Sensor. I have used a Fuel Booster Pack from a previous roadtest and it seems with a little modification I can charge it up using a solar panel directly! More details will come soon. A small addon board here again for the sensors and the data is directly logged to Sierra Wireless. I have tested connectivity from the CC3200 to the Sierra Wireless platform and works like a breeze. The documentation is a bit slow on my part because I was unclear as to the usefulness of some things.


I am running some experiments on the CC3200 boards and will start writing more detailed posts when I am done.


More later.




Experimenting with the power source: Peltier cell

In 1821, Seebeck found by using two different metals that are connected by two separate junctions, they will develop very small voltage if the two junctions at maintained at different temperatures.

In 1834, Peltier discovered the opposite of this, he found that if you apply a voltage to the same setup that it caused a different temperature at each junction, allowing you to generate both heat and cold from the voltage. Although what’s actually happening is heat transfer, the heat is transferred from one side to the other, making this a solid state heat pump.

You may also find they are referred to as TEC’s – ThermoElectric Coolers or in some cases TEG’s – ThermoElectric Generators. Essentially the Peltier Element is a combination of lots of very small thermocouples, junctions between 2 different metals or semi conductors and these are sandwiched between 2 ceramic plates and then encased in silicon.


Energy Scavenging with Peltier cells

OK, so you can’t get a lot out of these, but the point is by combining them in systems that produce a lot of wasted heat, we could minimize the waste and reclaim this. Granted, this is not going to amount to much, but scale it up and you can see why car manufacturers such as BMW are beginning to combine them around the exhaust – some of that wasted heat from the engine can be converted to electricity. So if you’re going to waste heat, why not get the most out of it?

Imagine an oven lined with these, or a device that could cook your food and chill something at the same time. Of course, it’s much harder than that, unfortunately Peltiers aren’t able to transfer much heat and because they work by creating a temperature differential, you need a way extract the heat and keep the other side cool at the same time. So just sticking them out in the sun or on the side of your oven isn’t going to generate electricity, it works on a car exhaust because of the air flow when the car moves cools one side.

Cell design

Before proceed, I need a rough estimation of the power requirements of the sensor.




<< 1 mA

Bluetooth module

27 mA

Temperature sensor TMP36

0.5 µA

Humidity sensor HIH4000

0.5 mA

NO2 sensor MiCS 2710

26 mA

CO sensor Figaro TGS 2442

203 mA

Dust sensor

20 mA

The problem comes with the Figaro TGS 2442 CO sensor, that has a very high consumption (203 mA) during the heating cycle. The heating cycle last 14 ms according to the datasheet, so it's better to keep the Peltier cell as small as possible and use a super capacitor to store enough energy to drive the heating cycle.

The power required during the heating cycle is

            P = V * I = 5V * 203 mA = 1.015 W

The energy consumption during the heating cycle is

            E = P * t = 1.015 W * 14 ms = 15 mJ

So I can compute the capacitance of the supercapacitor

            C = (2* E) / (V * V) = (2 * 15 mJ) / (5 V * 5V) = 1.2 mF

So 0.1 F super-capacitor should suffice all the power requirements and provide enough energy during the heating cycle of the sensor


That said, and assuming that not all the sensor will be switched on at the same time, the maximum power requirement will be of about 40 mA @ 3.3V, that is to say 0.132 W

The specifications of the Peltier cell state the following


The Peltier cell with a hot side temperature of 85 °C will provide 341 mW. This value provides a good margin in case the delta T between the hot side and cold side decreases (when, for example, the car is in queue)

Sensors for the competetion :

As i havent received the boards, to start with I am explaining in this post the sensors used in the competetion.

Air Pollution

For air pollution I will be using MQ series of sensors. Which sensor i will use will depend on budget and availability. Here i am detailing all such sensors that I am looking forward to.

The MQ series of gas sensors use a small heater inside with an electro-chemical sensor and are sensitive for a range of gases and are used indoors at room temperature.

They can be calibrated more or less but a known concentration of the measured gas or gasses is needed for that. Typical circuit diagram is:


Heater is for +5V and is connected to both 'A' pins.

The variable resistor in the picture is the load-resistor and it can be used to determine a good value.

The Vout is connected to an analog input of the Beaglebone.

The Heater

Some sensors use 5V for the heater, others need 2V. The 2V can be created with a PWM signal and a transistor or logic-level mosfet.The heater may not be connected directly to an output-pin of the Beaglebone, since it uses too much current for that.

If it is used in a battery operated device, a transistor or logic-level mosfet could also be used to switch the heater on and off.

The sensors that use 5V or 6V for the internal heater do get warm. They can easily get 50 or 60 degrees Celcius.

After the "burn-in time", the heater needs to be on for about 3 minutes  before the readings become stable.






The sensor needs a load-resistor at the output to ground. It's value could be from 2kOhm to 47kOhm. The lower the value, the less sensitive. The higher the value, the less accurate for higher concentrations of gas.

If only one specific gas is measured, the load-resistor can be calibrated by applying a know concentration of that gas. If the sensor is used to measure any gas (like in a air quality detector) the load-resistor could be set for a value of about 1V output with clean air.

Choosing a good value for the load-resistor is only valid after the burn-in time.




It is the time to burn-in the sensor. This is meant to make the sensor readings more consistent. A time of 12 or 24 hours is usually used for the burn-in time.

The Burn-in is achieved by applying normal power to the sensor (to the heater and with the 'A' and 'B' pins connected, and with a load-resistor).






Sensitive for Methane, Butane, LPG, smoke.

This sensor is sensitive for flamable and combustible gasses.

The heater uses 5V.

The MQ-2 at seeed:






Sensitive for Alcohol, Ethanol, smoke

The heater uses 5V

The Arduino blog about the "breathalyzer" using a MQ-3 :

The MQ303A (also on this page) is like this sensor, but uses a lower heater voltage.






Sensitive for Methane, CNG Gas

The heater uses 5V.





Sensitive for Carbon Monoxide

The heater uses an alternating voltage of 5V and 1.4V.






Sensitive for Hydrogen Gas

The heater uses 5V.





Sensitive for Carbon Monoxide, flammable gasses.

The heater uses an alternating voltage of 5V and 1.5V. It depends on the gases how to use that alternating voltage. If only Carbon Monoxide is tested, the heater can be set at 1.5V.

The MQ309A (also on this page) is like this sensor, but uses a lower heater voltage.






Sensitive for Ozone

The heater uses 6V.



The load-resistor is 100k...200k, which is a lot higher than for other sensors. This sensor is also very sensitive. It measures in ppb (parts per billion) where other sensors measure in ppm (parts per million).





For Air Quality

Sensitive for Benzene, Alcohol, smoke.

The heater uses 5V.

An example with calculation of the CO2 value:





Sensitive for Hydrogen Sulfide gas.

The heater uses 5V.





Sensitive for Ammonia.

The heater uses 5V.





Sensitive for Benzene, Toluene, Alcohol, Acetone, Propane, Formaldehyde gas, Hydrogen gas.

The heater uses 5V.






Sensitive for Natural gas, Coal gas.





Sensitive for Carbon Monoxide

The heater uses an alternating voltage of 0.2V and 0.9.

It detects the same gasses as the MQ-7, but uses a lower heater voltage.





Sensitive for Carbon Monoxide, flammable gasses.

The heater uses an alternating voltage of 0.2V and 0.9V. It depends on the gases how to use that alternating voltage.

It detects the same gasses as the MQ-9, but uses a lower heater voltage.




For Humidity and temperature sensors requirements I will be using the Sensor Hub BoosterPack from ti for it assuming the launchpads have libraries for the same on energia. The ambient light sensor will be used to complement smoke sensors of the MQ series.

Previous posts for this project:





Last week, I received my Beaglebone Black and my first order from the budget containing accessoires for the BBB. I've used the BBB before, in the Beaglebone Black Radio Challenge. Since then, Debian has become available which should simplify things on the software side (as opposed to using Angstrom).

photo 2.JPGphoto 1.JPGphoto 3.JPG


The parts used in this post are the following:


Let's get started!


Preparing the SD card


First thing I did was to prepare the SD card.


To have more space available, I decided to run Debian from the 8Gb SD card instead of burning it to the built-in storage of 4Gb.

On - latest-images , there are two different Debian images. One for running from the SD card and one to flash the built-in memory. I picked the first one.

Screen Shot 2014-10-25 at 12.50.14.png


I downloaded the image and unpacked it. Next, I inserted the SD card in my laptop and flashed it with the Debian image.


To avoid accidentally erasing the wrong disk, I first listed them:


Fredericks-MacBook-Air:Downloads fvan1$ diskutil list
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage                         250.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           *249.8 GB   disk1
                                 Logical Volume on disk0s2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *137.0 MB   disk2
   1:        Apple_partition_map                         32.3 KB    disk2s1
   2:                  Apple_HFS VirtualBox              137.0 MB   disk2s2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.9 GB     disk3
   1:                 DOS_FAT_32                         7.9 GB     disk3s1


I then unmounted the SD card:


Fredericks-MacBook-Air:Downloads fvan1$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful


And finally, I wrote the image to the card using "dd":


Fredericks-MacBook-Air:Downloads fvan1$ sudo dd if=bone-debian-7.5-2014-05-14-2gb.img of=/dev/disk3 bs=1m

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

1700+0 records in
1700+0 records out
1782579200 bytes transferred in 1069.609160 secs (1666571 bytes/sec)


After that, I inserted the SD card in the Beaglebone black and booted it. I connected a USB cable for networking, in order to be able to SSH into the BBB.

The default credentials are "debian"/"temppwd".


Fredericks-MacBook-Air:Downloads fvan1$ ssh debian@
Debian GNU/Linux 7 BeagleBone Debian Image 2014-05-14

debian@'s password:


The BBB booted correctly and was accessible via SSH. I verified the space available and noticed the 8Gb were not fully used.

That's because the image is meant for a 2Gb built-in memory or SD card.


debian@beaglebone:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          1.6G  1.5G  1.2M 100% /
udev             10M     0   10M   0% /dev
tmpfs           100M  640K   99M   1% /run
/dev/mmcblk0p2  1.6G  1.5G  1.2M 100% /
tmpfs           249M     0  249M   0% /dev/shm
tmpfs           249M     0  249M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /run/user
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/mmcblk0p1   96M   70M   27M  73% /boot/uboot
/dev/mmcblk1p2  3.4G  1.4G  1.9G  42% /media/rootfs
/dev/mmcblk1p1   96M   72M   25M  75% /media/boot



Expanding the filesystem


In order to fully utilise the SD card, the filesystem needs to be expanded. Instructions are provided online: Beagleboard:BeagleBoneBlack Debian -


debian@beaglebone:/opt/scripts/tools$ sudo ./
Media: [/dev/mmcblk0]

Disk /dev/mmcblk0: 239904 cylinders, 4 heads, 16 sectors/track
Old situation:
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start   End    MiB    #blocks   Id  System
/dev/mmcblk0p1   *     1     96     96      98304    e  W95 FAT16 (LBA)
  start: (c,h,s) expected (32,0,1) found (0,32,33)
  end: (c,h,s) expected (1023,3,16) found (12,93,17)
/dev/mmcblk0p2        97   1699   1603    1641472   83  Linux
  start: (c,h,s) expected (1023,3,16) found (12,93,18)
  end: (c,h,s) expected (1023,3,16) found (216,183,31)
/dev/mmcblk0p3         0      -      0          0    0  Empty
/dev/mmcblk0p4         0      -      0          0    0  Empty
New situation:
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start   End    MiB    #blocks   Id  System
/dev/mmcblk0p1   *     1     96     96      98304    e  W95 FAT16 (LBA)
/dev/mmcblk0p2        97   7496   7400    7577600   83  Linux
/dev/mmcblk0p3         0      -      0          0    0  Empty
/dev/mmcblk0p4         0      -      0          0    0  Empty
Successfully wrote the new partition table

Re-reading the partition table ...
BLKRRPART: Device or resource busy
The command to re-read the partition table failed.
Run partprobe(8), kpartx(8) or reboot your system now,
before using mkfs
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)


The last step generated an error, stating the device or resource is busy. I tried rebooting, but that didn't help.

I then came across this discussion:!msg/beagleboard/lJ8RWGzXebc/X_jMKTICRSwJ


As mentioned in one of the comments, I executed the following command:


debian@beaglebone:/opt/scripts/tools$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 1894400 blocks long.


Et voila, more space!


debian@beaglebone:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          7.1G  1.5G  5.4G  22% /
udev             10M     0   10M   0% /dev
tmpfs           100M  644K   99M   1% /run
/dev/mmcblk0p2  7.1G  1.5G  5.4G  22% /
tmpfs           249M     0  249M   0% /dev/shm
tmpfs           249M     0  249M   0% /sys/fs/cgroup
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           100M     0  100M   0% /run/user
/dev/mmcblk0p1   96M   70M   27M  73% /boot/uboot
/dev/mmcblk1p2  3.4G  1.4G  1.9G  42% /media/rootfs
/dev/mmcblk1p1   96M   72M   25M  75% /media/boot



Setting up Wifi


Wifi was really easy to set up.


I connected the USB dongle, and SSH'ed into the BBB. Listing the current network interfaces, wifi is not one of them:


debian@beaglebone:~$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet scope host lo
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet brd scope global usb0


Wifi can be enabled by editing the interfaces file, just like on the Raspberry Pi.


debian@beaglebone:~$ sudo nano /etc/network/interfaces

# WiFi Example
auto wlan0
iface wlan0 inet dhcp
    wpa-ssid "ssid"
    wpa-psk  "password"


After editing the file and saving the changes, I restarted the networking.


debian@beaglebone:~$ sudo /etc/init.d/networking restart
[....] Restarting networking (via systemctl): networking.service

. ok


That's it, that's all there is to it. Wifi is now running on the BBB.


debian@beaglebone:~$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet scope host lo
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    inet brd scope global wlan0
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet brd scope global usb0



Configuring for BB View


Finally, I decided to use a touch screen on the BBB for my project.


The steps are rather straightforward and properly documented in the BB View user manual. Here's a summary of what I did.


First, I dowloaded the patch files available on element14: element14: BB View LCD Cape Software Download Centre[1]

After downloading, I extracted the files and copied them over to the BBB via SCP.


Fredericks-MacBook-Air:BB VIEW Debian Image fvan1$ scp * debian@
Debian GNU/Linux 7 BeagleBone Debian Image 2014-05-14

debian@'s password:
am335x-boneblack-lcd4.dtb                                                           100%   23KB  23.2KB/s   00:00
am335x-boneblack-lcd7.dtb                                                           100%   23KB  23.2KB/s   00:00
am335x-boneblack.dtb                                                                100%   23KB  23.2KB/s   00:00
kernel_modules.tar.gz                                                               100%   34MB   8.6MB/s   00:04
xorg.conf                                                                           100%  564     0.6KB/s   00:00
zImage                                                                              100% 4243KB   4.1MB/s   00:00


After that, it was just following instructions to put the patch files in the correct locations:


debian@beaglebone:~/bbview$ sudo cp -f zImage /boot/uboot
debian@beaglebone:~/bbview$ sudo cp -f *.dtb /boot/uboot/dtbs/
debian@beaglebone:~/bbview$ sudo tar -xvzf kernel_modules.tar.gz -C /
debian@beaglebone:~/bbview$ sudo cp -f xorg.conf /etc/X11/
debian@beaglebone:~/bbview$ sudo sync
debian@beaglebone:~/bbview$ cd /boot/uboot/dtbs
debian@beaglebone:/boot/uboot/dtbs$ sudo cp am335x-boneblack-lcd7.dtb am335x-boneblack.dtb
debian@beaglebone:/boot/uboot/dtbs$ sudo sync
debian@beaglebone:/boot/uboot/dtbs$ sudo reboot




Tadaaaa, the Beaglebone Black is working with Wifi and LCD touch screen!

photo 1.JPG

Piecing things together and checking out some datasheets. Seems like an opportune time to add a more detailed overview and give structure to my project. I like to start with a basic flow diagram since its provides a quick visual representation of the system.


I've chosen the CC3200 as the base for my IoT sensor nodes. It has a 4 channel 12-bit ADC which I intended to make use of. Three air quality sensors have been chosen based on common air pollutants, size and cost. Part of my engineering design goals are to keep the form factor small (and ultimately pocket portable) while keeping cost to a minimum. For my air intake, I will be using a very cool piezoelectric air pump which will be driven using a PWM signal from the CC3200. The system will run from two AA batteries so a boost converter (TPS61200) will be used to generate the required 5V rail.


My next post will contain a project timeline which will include all the tasks that need to be performed and target competition dates. I intend to break the design components into sub-modules and integrate the final working system onto a single PCB. I imagine getting the CC3200 running and publishing data to the cloud as my first step. This would be followed shortly thereafter by a schematic. Once that is complete, I plan on prototyping the hardware on a launchpad break-out board.

Previous posts:

In the Air Design Challenge - Pollen & Allergen Sensing



Figure 1. Bad guy (Ambrosia pollen grain)


As I’m still waiting for my challenge kit I’m using the time to consider pollen sensing since that might be the weakest point of my project.



At this moment I have two alternatives for pollen sensor: Homemade and commercial one.

Using commercial one would make my project much easier and the focus would be on making some nice apps for desktop and mobile but with homemade sensor most efforts would be on making the sensor do its thing...


1) Homemade pollen sensor

As my plan is to detect pollen, I did some research and discovered a paper on pollen sensing that proposes an idea which seems feasible (Shigeto Kawashima et al. - An algorithm and a device for counting airborne pollen automatically using laser optics).

This task would require very much hard work and could easily turn out to be a failure but I can still try. Some optics would be required - hopefully I will be able to obtain all the necessary parts to build the prototype.

Screen Shot 2014-11-03 at 11.35.55 PM.png

Figure 2. Pollen sensor


Authors propose that red laser should be used but I think that maybe green or yellow laser would be more appropriate because pollen colour is usually the same (i.e. it reflects green or yellow). I bought the green (532nm) one locally to be used for this purpose.

In order to observe the photodiode sensor signals an oscilloscope is required so I decided to order one that fits in the budget (PicoScope 2204A). It arrived in just two days(!) and as I last used the oscilloscope ~15 years ago (at university) I spend some time testing it – It turned out it’s like riding a bike


2) Commercial sensor

Now some bad news regarding the commercial pollen sensor… The one that I found ( is not suitable for my location.

It only detects Japanese Cedar and Cypress but these pollen particles are bigger than those of Ragweed (which is the most common allergen in this part of Europe). This is not completely bad news as someone in Japan might find this project useful even with this sensor but for me that's probably not good enough.

Ragweed pollen presence in Europe:


Figure 3. Ragweed pollen presence in Europe (August 2014)



In short, I will most probably focus my work on homemade pollen detection.



I will update as soon as my challenge kit arrives (at this moment it’s being held at the local customs)

Comments and suggestions are always welcome.



Title: Low Cost Harmful Algal Bloom Monitoring

Recap: This is my second post. Last week, I gave a brief introduction on what is HAB (Harmful Algal Bloom) and its impact (economic, environmental and health). I also gave its cause including the role of climate change (temperature and Carbon dioxide) in frequent occurrence of HAB. On the technical side, I gave an overview on how the system would be setup and look like. Basically the system can be divided into two subsytems: the wireless sensor node part ( enclosed in a buoy and deployed in coastal water) and the base station (located inland near the coast).

For this week's post, detailed information on sensor node.



                                    Sensor node.jpg



A. Microcontroller:

    16 bit MSP430FR5969 is the main microcontroller for the wireless sensor node. This MCU has two UARTs: one can be used for the transceiver and the other for sensors. Since I will be attaching multiple sensors to  a single UART, I will be using a 74HC4052 Mux/Demux IC capable of connecting up to four asynchronous serial UART devices into one single microcontrollers UART RX/TX pins.


B. RF communication:

    Data acquired by the node through its sensors will be sent to the base station through RF transceiver and I will be using TI's CC110L transceiver. Ideally, transceivers with longer range and capable  of mesh topology  should be  used considering node will be placed far from base station and my ultimate goal is to build and deploy network of wireless sensor nodes ( if I have enough fund or if our local government will give ). So for a single node project, CC110L will do with limited budget.


C. Power source:

    3.7V lithium ion battery with charging circuit and solar panel.


D. Sensors:

    1. Carbon dioxide sensor

              - with analog interface and using MG811

    2. Temperature and Humidity sensor

              -measure air temperature and humidity using SHT10 sensor

        • Humidity Ranger:0-100%RH
        • Temperature ranger: -10-80℃
        • Humidity accuracy:±5.0%RH
        • Temperature accuracy:±0.5℃

    3. Submersible temperature sensor

              -  digital output temperature probe with UART interface

              -  accuracy +/- 1C operating at 3.1-5V

    4. Color sensor

              - color probe can be used to monitor slowly changing events like algal bloom

              - outputs 8-bit format R,G,B data

              - outputs light intensity in lux

              - operating at 3.1-5V

              - UART interface

    5. Dissolved Oxygen sensor

              - during algal bloom, D.O. level drops and this will be a good indicator

              - output range of probe is 0-20 mg/L

              - interface either UART or I2C


So, that's it for now.

Next week, I will be posting detailed information on the second subsystem: the base station.

Once I receive the challenge kit, I'll post my tinkering experience with the kits next week as well.

Pls do comment for suggestions and questions. Thank you.


AirMobile - Description

Posted by amgalbu Top Member Nov 3, 2014


This is a proposal for a distributed network of air quality sensors. In this document, I will write down details for making a sensor that can be installed on cars, but in the future handlebar-mounted and armband versions of the sensor can be designed.

The sensor is battery-free and harvest energy from car radiator heat by means of a Peltier cell. Data is transferred to a smartphone through a Bluetooth Low Energy link. The smartphone internet connectivity is leveraged to push data to a cloud service.

Data from all the installed sensors can be analyzed at home thanks to a plugin that will be developed as part of this project. Plugin will pull data from the cloud and make automation decisions thanks to the power and flexibility of the OpenHAB platform

Architecture overview




Figure 1 - System architecture



The air quality sensor is made of the following main components

  1. 1.      a low-power microcontroller, like the Texas Instruments MSP430 series microcontroller
  2. 2.      a Bluetooth Low Energy module, like the Texas Instruments LMX5252 module
  3. 3.      a dust sensor module, like the Sharp GP2Y1010AU0F, which features a low power consumption
  4. 4.      a N02 sensor, like the MiCS 2710 NO2 gas Sensor
  5. 5.      a C0 sensor, like the Figaro TGS 2442 CO gas sensor
  6. 6.      a humidity sensor
  7. 7.      a temperature sensor
  8. 8.      a Peltier element for energy harvesting. The use of energy harvesting makes the sensor installation absolutely unobstrusive



Figure 2 - Sensor schematic



Electrical scheme.png

Figure 3- Sensor electrical components and connections


Sensor will be enclose in a box designed to be easily fixed to the radiator grid



Figure 4 - Sensor case rendering




Figure 5 - Mounting position





Smartphone runs an application that

  1. 1.      pushes data to the cloud
  2. 2.      shows sensor current readings
  3. 3.      show sensor readings history


There are other products (like the Air Quality Egg) that make air quality data available on the cloud, so it would be advisable that data coming from car sensors contribute to enrich the amount of information available is these repositories instead of creating a new one


Data fusion

At home, a BeagleBone board runs OpenHAB gathers data from the cloud infrastructure by means of a plugin developed as a part of this project. The plugin leverage web API to read data from the cloud. Data will then be available in the OpenHAB platform and processed using all the facilities available in such a powerful automation system.

The OpenHAB could also get additional information from other sources to enrich air quality data. For example, reading

  • weather data
  • forecasts
  • air quality measurements provided by fixed stations and from the Air Quality Egg project devices


can help select the best time of day when an outdoor training session is advisable because both weather and air quality are good. Note that it is possible to detect time-dependant trends in the air quality. For example, air quality is likely to get worse during rush hours

With OpenHAB automation mechanism, user can get a tweet when air quality is good enough to have some outdoor training or suggest that it's better to stay at home (in that cause ventilators could be switched off to prevent polluted air from entering the house)

Thanks to air quality maps, a family could also plan the path with the best air quality for the Sunday bike trip with the children.

I am not the “read the manual” kind of person, so I searched for energia + cc3200, found this:

had a quick look at the instructions and started downloading/installing software. I’m runing windows 8.1 64bit, so I ‘ve installed drivers for FTDI via DPInst64.exe from cc3200_drivers_win

Then extracted and runned energia, selected correct COM, loaded blink sample, upload and….

Opening COM4

Read ACK failed

Failed to trigger bootloader

I later found this link which explains things:

CC3200 comes preloaded with a demo web server / access point. That's cool. I scanned for wifi on my Android, and simplelink, out of the box was there, working as it should…played with the demo apps, very nice way to start with these boards.


I continued with “project 0 guide” ..and realized that I had to move jumper from P58-VCC to SOP2. Tried to upload a blink sample code and..

Opening COM4

Getting storage list

Bootloader Version: 3

Silicon version ES1.32

Bootloader version is 2, 0, 3, 2

It's a CC3101 device: PG1.32

BlockSize is 4096, number of blocks is 64

erasing 1 blocks starting from  4

Switch to NWP bootloader complete

Silicon version ES1.32

Bootloader version is 2, 0, 3, 4

BlockSize is 4096, number of blocks is 16

erasing 12 blocks starting from  0

erasing file "/sys/mcuimg.bin"

deleting file "/sys/mcuimg.bin"

erase file completed

Downloading file "/sys/mcuimg.bin" with size 4128

..Download complete

However, still no led blink.. pressed reset, nothing changes, removed SOP2, pressed reset, and yes, we have a blink! :-)

Next post: [Air ex Machina] #03 CC3200 with CCStudio

When I found out about this competition, I did a search to find similar projects and get ideas.

I soon discovered these two:

A community-led air quality sensing network that gives people a way to participate in the conversation about air quality

Smart Citizen is a platform to generate participatory processes of the people in the cities. Connecting data, people and knowledge, the objective of the platform is to serve as a node for building productive open indicators and distributed tools, and thereafter the collective construction of the city for its own inhabitants.

These projects go beyond the typical diy approach. They have designed something that can really scale, trying to build communities that crowdsource data for the common good. I really like this concept of community-diy, ie lets solve a big problem all together. In many countries (like Greece where I live) weather forecast and air quality information is kind of poor to say the least. Government’s environmental agencies do not deploy fancy/expensive equipment like rain radars, air pollution sensors in many locations etc, hence people do not have accurate weather forecasts, short term hyperlocal rain forecasts and other important air pollution information. With the evolution of technology, citizens can solve this problem on their own without government support. I guess thats the case with, and many other similar projects. Once sensor-locations become dence in an area area, and all data are open/shared on a common server, it should be feasible to radar-animation of pollution or rain in real time. This can be used as a basis for hyper local, short term forecasts and various other services e.g. receive an alert on your mobile phone that it will rain at your location in 5 minutes or have pollution alerting mechanisms for people with health conditions, etc.

Introducing Air ex Machina...

Air ex Machina architecture.png

Outdoor unit:

The aim is to  create a compact, battery powered weather & air quality station based on CC3200 & MSP430FR5969 utilizing various sensors like:

  • Rain drops sensor (basic accuracy for low/high precipitation)
  • Temperature/Humidity Sensor (DHT22)
  • Grove - Air quality sensor
  • NO2/CO Sensor (MICS-4514)
  • Particle sensor (for dust or pollen)
  • Ozone (O3) Sensor
  • Volatile Organics (VoC) Sensor
  • ...or maybe an Air Quality Egg shield or an Smart Citizen ambient board.

Sensor set A,B,C will be finalized during the project - agile/prototype approach.

This outdoor, battery powered unit will require a cleverly designed box to keep the electronics dry, but expose the sensors to the elements. I am going to place it on my flat’s balcony. Wifi will be used for communication with the indoor controller (beaglebone).

Indoor controller/gateway:

Beagleboard will be located inside the house, connected with some of the above sensors again, for comparing internal with external air quality. In addition I will have openhab running on beagleboard, and configure the http binding of openhab to consume a simple http API which will be exposed by the web-server of CC3200.

Having OpenHab as an integration platform, gateway and controller, is really useful for applying some automation in the house using the OpenHab rule engine, e.g. turn ventilation on/off when certain threshold on some sensors has been reached. Also openhab will provide a mobile user interface, as well an easy way to stream sensor data to a cloud server in real time via MQTT or HTTP. I will attempt air-control with rules and some “zwave” plugs or roller shutter in order to approach the use case of opening ventilation when it makes sense based on external temperature and air quality, and will try to deploy it in my house and see if its actually realistic to have it running.

Cloud backend:

I am looking forward connecting all these things to AirVantage and see what's possible in terms of data analytics/ user interface presentation / rule engine control, etc. However as I am an opensource advocate I will also attempt to connect my things to an open source platform that could form the basis of a backend system for a new crowdsourced environmental observations community as inspired by smartcitizen and the rest. I initially had in mind, but then I found this project which seems even better suited, so I will give it a try, deploy it and connect my things with it through OpenHab.Will also need an MQTT broker like HiveMQ to have multiple backend systems running.  Of course all these cloud stuff make more sense if/once more people join the project and share their data. It would be cool, if other in-the-air competitors are interested to connect their sensors also to my backend once it’s online :-)

But first, lets play with TI's launchpads...

>>Link to next post: #02 LaunchPad cc3200 first play