Skip navigation
1 2 Previous Next

In the Air Design Challenge

18 Posts authored by: Frederick Vandenbosch Top Member

Previous posts for this project:

 

 

Introduction

 

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

 

 

What I Learned

 

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

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

 

Launchpads

 

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

 

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

 

Surface Mount Components and Soldering

 

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

 

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

 

Solar Energy

 

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

 

LiPo Batteries

 

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

 

Conclusion

 

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

achievement-unlocked.jpg

 

What I Made

 

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

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

 

Central Unit

 

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


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


{gallery:autoplay=false} Control Unit

photo 5.JPG

Enclosure: the control units enclosure assembled and painted

Screen Shot 2015-02-22 at 13.53.16.png

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

Screen Shot 2015-02-22 at 13.52.57.png

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

Screen Shot 2014-11-27 at 14.29.55.png

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

photo 3.JPG

Enclosure: enclosure in the making

photo 5.JPG

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

photo 3.JPG

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

photo 2.JPG

Enclosure: making additional layers to create depth in the enclosure


 

Remote Sensor

 

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

 

{gallery:autoplay=false} Remote Sensor

photo 1.JPG

Remote sensor: Attached to window for solar charging

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

Screen Shot 2015-01-25 at 19.55.14.png

Boosterpack: board design

photo (4).JPG

Boosterpack: fully populated dust sensor boosterpack

photo 1.JPG

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

photo (3).JPG

Remote sensor: solar panel and window suckers in place

photo 2.JPG

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

 

Thank You

 

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

 

sponsors-final.png

Previous posts for this project:

 

 

Introduction

 

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

 

Boosterpack

 

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

 

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

 

OpenHAB

 

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

 

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

 

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

 

Group All

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

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

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

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






 

 

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

 

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






 

 

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

 

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

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






 

 

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

 

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




 

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

 

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




 

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

 

Enclosures

 

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

photo 2.JPGphoto 4.JPG

 

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

 

photo 1.JPGphoto 2.JPG

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

 

Conclusion

 

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

Previous posts for this project:

 

 

Introduction

 

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

 

Preparation

 

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


Soldering


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

 


Cleaning


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


Screen Shot 2015-02-21 at 00.50.45.png


Solder


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


I used Chip Quick SMD291AX10Chip Quick SMD291AX10 solder paste.


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


Components

 

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

 

Screen Shot 2015-02-21 at 00.58.40.png

 

Preheat

 

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


Screen Shot 2015-02-21 at 01.03.43.png


Reflow


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

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


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


Conclusion


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


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


Previous posts for this project:

 

 

Introduction

 

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

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

 

Plan A

 

Plan A sounded simple at first:

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

 

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

photo 1.JPGphoto 2.JPG

 

I underestimated the signal analysis and reproduction though ...

 

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

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

 

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

 

 

Plan B

 

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

 

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

 

void writeOne() {
  digitalWrite(pin,HIGH);
  delayMicroseconds(940);
  digitalWrite(pin,LOW);
  delayMicroseconds(300);
}

void writeZero() {
  digitalWrite(pin,HIGH);
  delayMicroseconds(290);
  digitalWrite(pin,LOW);
  delayMicroseconds(950);
}




































 

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

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

 

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

tek00001.png

 

I searched the world wide web for answers and came to following post: http://e2e.ti.com/blogs_/b/msp430blog/archive/2015/01/20/using-the-msp-exp430fr5969-launchpad-at-16mhz-in-energia

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

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

 

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

 

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

 

Control

Screen Shot 2015-02-14 at 15.31.50.png

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

 

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

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

 

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

 

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

 

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

 

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

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

 

photo 2.JPGphoto 3.JPGphoto 5.JPG

 

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

 

Vote

 

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

Previous posts for this project:

 

 

Introduction

 

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

 

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

 

Waste board

 

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

 

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

 

photo 2.JPGphoto 3.JPG

 

Inkscape & Makercam

 

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

 

The flow is as such:

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

 

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

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

 

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

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

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

 

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

 

Milling

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

photo 1.JPGphoto 2.JPG

 

Result

 

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

 

photo 3.JPGphoto 4.JPG

photo 5.JPG

 

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

 

Vote

 

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

Previous posts for this project:

 

 

Introduction

 

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

 

Parts

 

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

 

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

photo 2.JPG

 

PCB

 

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

 

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

 

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

 

Screen Shot 2015-02-01 at 20.38.05.png

Previous posts for this project:

 

 

Introduction

 

In the past weeks, I experimented with the GP2Y10 dust sensor from Sharp. Using an Arduino all was well, but I was however running into problems when using it with the CC3200. It's not the only issue I encountered with the CC3200. There was also the fact that the I2C pins of the CC3200 and FuelTank did not match.

 

I've tried to tackle both issues with a custom BoosterPack (my first!).

 

 

Templates

 

To start, I searched for BoosterPack templates. I quickly came across the ones from TI: Build Your Own BoosterPack for TI LaunchPad

 

The BYOB kit from TI contains a variety of files for different tools: Eagle, Fritzing, ... Very nicely done and easy to find!

 

 

Eagle

 

Using Eagle, I created a schematic and board. Now, I don't have much experience with Eagle. I did fiddle a bit with it during the Forget Me Not challenge, but never got to making an actual PCB. Fritzing seems to be more up my alley, but anyway ... let's proceed.

 

I loaded all the required parts in the schematic and started connecting all the dots. There are four parts to this schematic:

  • the opamp circuit as suggested by shabaz in Week 11
  • the circuit required to hook up the dust sensor
  • the launchpad headers
  • an optional I2C connection to overcome the mismatch between FuelTank and CC3200

 

This is the schematic:

Screen Shot 2015-01-25 at 19.55.27.png

 

For the board, I laid out the components across the available space and let Eagle do the routing. This is the resulting board:

Screen Shot 2015-01-25 at 19.55.14.png

 

Nothing spectacular, but I'll be more than happy if I manage to get it soldered and working

Previous posts for this project:

 

 

Introduction

 

I'm using a Beaglebone Black and BB View as the main user interface. Because the BB View is a touch screen, I want to avoid the need for another input device such as a keyboard.

In this post, I'll set up openHAB and Chromium to start automatically and visualise the openHAB GUI without having to enter an URL or open a browser manually.



openHAB

 

First, I created a script which will launch the desired application, in this case: openHAB. The script will be put in "/usr/bin".

 

debian@beaglebone:~$ sudo nano /usr/bin/openhab.sh

#!/bin/bash
/opt/openhab/start.sh













 

The script needs to be made executable so it can be launched successfully.

 

debian@beaglebone:~$ sudo chmod u+x /usr/bin/openhab.sh

 

Next, create the service. Some prerequisites can be specified, for example the need of having the network up and running first.

 

debian@beaglebone:/usr/bin$ sudo nano /lib/systemd/openhab.service

[Unit]
Description=openHAB
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/bin/openhab.sh
[Install]
WantedBy=multi-user.target













 

Create a symbolic link to let the system know where to find the service:

 

debian@beaglebone:~$ cd /etc/systemd/system
debian@beaglebone:/etc/systemd/system$ sudo ln /lib/systemd/openahb.service openhab.service


 

Try starting the service to check for mistakes/errors. If all is well, the service can be enabled.

 

debian@beaglebone:/etc/systemd/system$ sudo systemctl daemon-reload
debian@beaglebone:/etc/systemd/system$ sudo systemctl start openhab.service
debian@beaglebone:/etc/systemd/system$ sudo systemctl enable openhab.service


 

As a final check, reboot the Beaglebone Black to confirm it's working as expected.

 

debian@beaglebone:/etc/systemd/system$ sudo reboot













 

After reboot, the openHAB start script seems to be running, this is a good sign. Checking the logs, openHAB is started as expected!

 

debian@beaglebone:~$ ps aux | grep start

root       758  0.0  0.0   1336   440 ?        S    18:59   0:00 /bin/sh /opt/openhab/start.sh
root       996  0.0  0.5   5864  2676 ?        Ss   18:59   0:00 /usr/sbin/apache2 -k start
www-data  1003  0.0  0.3   5644  1996 ?        S    18:59   0:00 /usr/sbin/apache2 -k start
www-data  1005  0.0  0.4 227056  2364 ?        Sl   18:59   0:00 /usr/sbin/apache2 -k start
www-data  1007  0.0  0.4 227048  2356 ?        Sl   18:59   0:00 /usr/sbin/apache2 -k start
debian    1323  0.0  0.1   1576   592 pts/0    S+   19:00   0:00 grep start


 

debian@beaglebone:~$ less /opt/openhab/logs/openhab.log

2015-01-14 19:00:39.422 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.6.0).
2015-01-14 19:00:50.451 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2015-01-14 19:00:51.111 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
2015-01-14 19:00:51.168 [INFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2015-01-14 19:00:51.180 [INFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'eclipseiot'
2015-01-14 19:00:57.860 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'rrd4j.persist'
2015-01-14 19:00:59.817 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'intheair.items'
2015-01-14 19:01:11.457 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'intheair.sitemap'
2015-01-14 19:01:15.109 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
2015-01-14 19:01:21.365 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /openhab.app













 

 

Chromium

 

To automatically start applications when the desktop loads, an "autostart" file can be edited to add the required applications.

 

At the end of the file, I appended a line to start Chromium automatically and open the openHAB web interface. I've also added the "--kiosk" option, which will load Chromium in full screen mode without the possibility to close it. This will be useful to avoid anyone accidentally closing the application or tampering with the system.

 

debian@beaglebone:~$ sudo nano /etc/xdg/lxsession/LXDE/autostart

@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@chromium --kiosk "http://localhost:9090/openhab.app?sitemap=intheair"





 

The result after having applied the changes and rebooting the system, is the following:

photo 1.JPG

 

There are two issues with the above screenshot:

  • Chromium is started and attempting to open the openHAB GUI before openHAB is fully started
  • There is a warning message at the top regarding missing API keys

 

On the good side: Chromium is started in kiosk mode and trying to open the correct URL, meaning the command works.

 

To solve the first issue, I chose the quick and dirty solution of adding a delay. Because other "custom" commands might be needed, I moved the delay and startup of Chromium to a separate script and called that script in the "autostart" instead.

 

I added a 2 minute sleep before starting Chromium, giving openHAB enough time to start properly.

 

debian@beaglebone:~$ sudo nano delayed-chromium.sh

#!/usr/bin/sh
sleep 120 && chromium --kiosk "http://localhost:9090/openhab.app?sitemap=intheair"






debian@beaglebone:~$ sudo chmod u+x delayed-chromium.sh

 

debian@beaglebone:~$ sudo nano /etc/xdg/lxsession/LXDE/autostart

@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@sh /home/debian/delayed-chromium.sh








 

After rebooting, Chromium is started 2 minutes later as expected and the openHAB GUI loads properly. Ideally, I should check for openHAB's status until fully started and then launch Chromium.

photo 2.JPG

 

The get rid of the second issue, the Google API keys warning, some environment variables need to be set:

 

debian@beaglebone:~$ export GOOGLE_API_KEY="no"
debian@beaglebone:~$ export GOOGLE_DEFAULT_CLIENT_ID="no"
debian@beaglebone:~$ export GOOGLE_DEFAULT_CLIENT_SECRET="no"








 

Using "set", it is possible to confirm the variables have been set. Unfortunately, setting them like this is not permanent and a reboot will lose the information.

 

debian@beaglebone:~$ set

...
GOOGLE_API_KEY=no
GOOGLE_DEFAULT_CLIENT_ID=no
GOOGLE_DEFAULT_CLIENT_SECRET=no
...








 

This is where the custom script from earlier comes in handy. I added the "export" statements into the script, which results in them being executed at every startup.

 

debian@beaglebone:~$ sudo nano delayed-chromium.sh

#!/usr/bin/sh
export GOOGLE_API_KEY=no
export GOOGLE_DEFAULT_CLIENT_ID=no
export GOOGLE_DEFAULT_CLIENT_SECRET=no
sleep 120 && chromium --kiosk "http://localhost:9090/openhab.app?sitemap=intheair"




 

The annoying warning is finally gone:

photo.JPG

 

Conclusion

 

After powering on the Beaglebone Black, the openHAB GUI will open automatically on the touch screen without user intervention. Hooray!

Previous posts for this project:

 

 

Introduction

 

As you'll notice, week 9 and 10 have gone missing. I wasn't able to put enough time in the project during the holiday period to justify a blog post (or two).

With the family visits all over Belgium done, I'm gradually able to put more time back in my projects. Here goes week 11 ...


During week 7, I experimented with my dust sensor using an Arduino. This made it easier to understand the sensor using a microcontroller I'm familiar with.

For this post, I thought I'd hook up the dust sensor to the CC3200. Shouldn't be too hard, right ? Well ... just a little bit harder than expected!

 

 

AnalogRead

 

It would seem that the ADC on the CC3200 only supports input levels up to 1.46V and not the 5V I had on the Arduino!

For testing purposes I used a voltage divider, with a ratio of 1/3. Because the maximum analog output voltage of the dust sensor is approximately 3.5V, that should do.

 

Another thing to be aware of, is that the analog value read using the analogRead() function results in a value between 0 and 4095 (as opposed to 0 and 1023 on Arduino).

 

I adapted my measuring function to the new conditions as follows:

 

void readDustSensor() {
  digitalWrite(ledPin, LOW); // turn LED on
  delayMicroseconds(delaySampling); // wait before sampling

  sensorValue = analogRead(sensorPin); // sample
  delayMicroseconds(delayLed); // wait before turning LED off

  digitalWrite(ledPin, HIGH); // turn LED off
  delayMicroseconds(delayCycle); // wait for end of cycle

  // max voltage of 1.46V, represented by values from 0 to 4095, times 3 to compensate for the voltage divider
  voltage = sensorValue * (1.46 / 4095.0) * 3;
}















 

I was expecting this to return the same value (or at least close to it) as during my tests with the Arduino. Somewhere around 0.74V.

 

Unfortunately, I'm getting values reported around 2.0V! Why ?!

Screen Shot 2015-01-09 at 22.56.40.png

 

Using the TBS 1052B oscilloscope from the previous challenge, I tried to understand what was going on. With both probes, I tried to visualise the (divided) output of the dust sensor and the trigger of the IR LED.

 

This was the resulting snapshot:

F0000TEK.png

Using the cursors, I measured 0.280ms between the IR LED being turned on (fCursor 1 - falling edge on Ch2) and the dust sensor's (divided) analog output (Cursor 2 - Ch1).

 

As you can see, the snapshot matches the expected behaviour as documented in the sensor's datasheet rather well:

Screen Shot 2014-12-11 at 20.11.39.png

Cursor 2 on Ch1 reports an amplitude of 220mV, times 3 to compensate for the divider, that results in 660mv. So why is the analogRead() reporting 2.0V ??

 

With the scope reporting a plausible value, I'm thinking the issue lies in the analogRead() itself. So I started searching for similar issues online.

I came across following issue where multiple analogRead() attempts must be made before a correct value is obtained (what's the deal with that?).

Not having better options at this stage, I decided to give it a try. But adding multiple analogRead() calls would surely affect the sampling timing.

 

To assess the impact, I report the microseconds using micros() right before and after the four dummy analogRead(), measuring how long it takes to execute.

This delay is then subtracted from the 0.280ms sampling delay.

Screen Shot 2015-01-09 at 22.42.19.png

The four dummy analogRead() introduce a delay of 0.040ms, so that's what I'll subtract from the 0.280ms delay.

 

The good news is that the readings after those changes are much closer to what I had measured with the Arduino, and are in line with what is measured with the scope.

The bad news is that the results fluctuate a lot more, losing the ability for proper monitoring of dust levels.

Screen Shot 2015-01-09 at 22.55.06.png

 

Smoke however, is still properly identifiable at 3.6V, as it results in the maximum output value of the sensor.

Screen Shot 2015-01-09 at 22.54.30.png

 

Conclusion

 

Well, that wasn't as easy as I had expected ... at all.

 

Unfortunately, it looks like this approach won't give me reliable and stable readings. I'll have to find another solution and make it work in the remaining seven weeks of the challenge.

That will be a challenge on its own On the bright side, I now know these limitations/issues with the CC3200/Energia and am able to take it into account for future projects. Oh well.

 

(Unless I did something very wrong in all of this and someone will point out the obvious ...)

Previous posts for this project:

 

 

Introduction

 

I didn't have time to work on my project this week, but here's a small update.


Energia 14 finally came out, and with it, support for the MSP430FR5969 (with EnergyTrace) which was part of the challenge's kit. Time to test it!


Energia 14


As you might remember, I was struggling to get the MSP430FR5969 to work with Energia, and ended up resorting to Code Composer Studio.

After talking to some people of Texas Instruments at electronica, I understood the new version of Energia would support that board.


Version 14 was recently released (9th December), you can find it here.

 

I installed it, and gave it a try.

 

Trying to put a sketch directly on the MSP430FR5969 failed. A popup appeared stating the firmware needed to be upgraded first, so I did.

Screen Shot 2014-12-21 at 13.48.09.pngScreen Shot 2014-12-21 at 13.49.20.png

 

After the firmware upgrade, I was able to upload a sketch to the board! Finally!

Screen Shot 2014-12-21 at 13.50.07.png

With these issues out of the way, I can finally start using this Launchpad.

 

The coming two weeks might be quiet from my side with the upcoming holidays and all .... you know how that goes. I'll post if I manage to produce meaningful content.

 

Happy holidays everyone!

Previous posts for this project:

 

 

Introduction

 

For this week's post, I experimented with the Sharp GP2Y1010AU0FSharp GP2Y1010AU0F dust sensor which I plan to use in my project.


Sensor info


The Sharp GP2Y1010AU0F dust sensor uses an IR LED and detector to provide information on the dust concentration in the air.

The output of the sensor is analog and provides a voltage which can be used to correlate the dust concentration. (See paragraph "Measurements" in this post)

DSCN3116.JPGDSCN3117.JPG

In the pictures above, you can see a disassembled sensor with both the LED and detector crossing paths at the ventilation hole.


The sensor is also low power, with a typical supply current of 11mA and maximum supply current of 20 mA (at 5V).


Circuit

 

An example circuit is provided in the datasheet. It provides the function of every pin and indicates the need of an RC circuit on the LED input.

Screen Shot 2014-12-11 at 20.38.13.pngScreen Shot 2014-12-11 at 20.41.41.png


I didn't have the exact same values available, so I used the closest I could find.


To be able to test the sensor, I soldered breadboard friendly headers on the sensor cable.

sensor-pin-order.pngphoto 2.JPG


The test setup:

photo 4.JPG

The white cone contains a fan used to create an airflow to the sensor. I plan on 3D printing a more compact version so that it will fit inside the build.


In the circuit above, the fan is always on. This will not be the case in the final solution: the fan should be turned on before sampling, and turned off after it.

Through testing, I will need to find the best timing between turning the fan on and sampling, as initially, turning the fan on might give different results (dust on fan blowing through sensor).


Sketch


Based on the datasheet information on sampling timing, I made a quick Arduino sketch i order to test the sensor and the circuit.

Screen Shot 2014-12-11 at 20.11.39.pngScreen Shot 2014-12-11 at 20.35.28.png

The resulting sketch is as follows:


int sensorPin = A0;
int sensorValue = 0;

int ledPin = 2;

int delaySampling = 280; // wait 280 us before sampling after turning on LED
int delayLed = 40; // wait 40 us after sampling before turning off LED
int delayCycle = 10000 - delaySampling - delayLed; // 10ms cycle

void setup() {
  Serial.begin(9600);

  pinMode(sensorPin, INPUT);
  pinMode(ledPin, OUTPUT);

  digitalWrite(ledPin, HIGH); // turn LED off
}

void loop() {
  digitalWrite(ledPin, LOW); // turn LED on
  delayMicroseconds(delaySampling); // wait before sampling

  sensorValue = analogRead(sensorPin); // sample
  delayMicroseconds(delayLed); // wait before turning LED off

  digitalWrite(ledPin, HIGH); // turn LED off
  delayMicroseconds(delayCycle); // wait for end of cycle

  Serial.print("Sensor Value: ");
  Serial.println(sensorValue);

  float voltage = sensorValue * (5.0 / 1023.0);

  Serial.print("Voltage Value: ");
  Serial.println(voltage);
  Serial.println();

  delay(1000);
}















Measurements


I performed two measurements for initial testing.


The first test, was to use the sensor as is, measuring the dust concentration in the room.

The second, was to trigger an extreme condition using a smoking matchstick.

Screen Shot 2014-12-11 at 22.07.00.png

 

The change in value is clearly indicating the smoke was detected. Looking further in the datasheet, following graph is provided.

Screen Shot 2014-12-11 at 22.14.26.png

The maximum value in the graph matches the result when using the smoking matchstick, meaning a density larger than 0.6mg/m3.

As for the dust, it would seem there is an approximate concentration of 0.05mg/m3 in the room I was testing.

 

I'll be testing the sensor further and porting the Arduino code to the Launchpad (which should be straightforward with Energia ?!).

I'm curious to see the results when measuring in different rooms (who has the dirtiest room).

Previous posts for this project:

 

 

Introduction

 

Last week, I set up openHAB to visualise data on my FuelTank's battery state. But how did I access this data from the CC3200? Let's find out ...

 

Energia & CC3200 on Mac

 

But first ... another problem was solved!

 

At long last, the CC3200 is working with Energia on my Mac, thanks to pmohan for pointing me to the solution. The issue was caused by the latest version of OSX (Yosemite) not allowing to run unsigned drivers ("kext").

Screen Shot 2014-11-19 at 20.50.30.png

Using a manual fix which disables the signature checking in OSX, the driver can be loaded and the CC3200 detected in Energia! Woop!

 

Trial & error

 

During my research, I came across some posts and reviews by peteroakes in which he created an Energia sketch to retrieve some statistics from the Fuel Tank BoosterPack via I2C.

 

I hooked up the Fuel Tank Boosterpack to the CC3200, loaded the sketch in Energia and monitored the serial output. Nothing spectacular happened.

Screen Shot 2014-11-23 at 18.34.01.png

 

All values were "0". This meant that either the sketch would somehow not be compatible with the CC3200 or that the I2C slave was unreachable.

Searching a bit more, I came across a library (it's at the bottom of that page - or here) doing the same thing, and the result was unfortunately the same. (What was I expecting ??)

 

Recovering the battery

 

At some point, I connected the Fuel Tank to the CC3200 and had it run on the battery without charger.

Unfortunately, the battery discharged a bit faster than expected, while I was away at work.

 

The result ? By the time I got home, the battery would no longer charge via the Fuel Tank when connected to a power source.

 

Looking through the Fuel Tank's documentation, there is a trick to "kickstart" the charging of the battery in case it was discharged too much.

The procedure is described in paragraph 6 of the user guide and helped me recover the battery, after which it was charging with the Fuel Tank again.

 

Pinout diagrams

 

In order to troubleshoot the problem, I searched pinouts of both the CC3200 and the Fuel Tank BoosterPack. I found both on the Energia website.

cc3200lppinmap.jpgfueltankbppinmap.jpg

 

What I noticed based on these diagrams, is that the Fuel Tank BoosterPack seems to have multiple I2C pins!

Using jumper wires, I tested the different I2C pins of the BoosterPack with the CC3200, until I found a working set.

 

After that, I connected the BoosterPack to the CC3200 and used the jumper wires on the CC3200 directly. Like so:

Screen Shot 2014-12-05 at 12.56.26.png

(Fritzing part for the CC3200 was found here: New CC3200 Launchpad Fritzing Part)

 

I removed the jumpers connecting the onboard sensors to the I2C bus and connected jumpers to the I2C pins attached to the underlying BoosterPack.

Because I removed the jumpers of the onboard sensor, I had to ensure the "pull-up" jumper on the BoosterPack was in place. You can verify the pull-ups are ok if the green and orange LEDs of the CC3200 are on.

 

With this little manipulation, I was finally having proper readings on the Fuel Tank's data with both Peter's code and the library:

Screen Shot 2014-11-23 at 22.33.50.pngScreen Shot 2014-11-23 at 22.42.08.png

 

Glitches in the readings

 

I did notice some glitches in the values read when doing the following:

  • connecting/disconnecting a charging source
  • having the CC3200 connected via USB to PC (for Serial output) at the same time

 

Sketch

 

This is my current sketch. It's still very basic and rough, but it does the trick for now.

It will need to be improved to go into deep sleep after sending the values, until the next set of values is to be sent.

 

#include <WiFi.h>
#include <PubSubClient.h>

// Core library for code-sense
#if defined(WIRING) // Wiring specific
#include "Wiring.h"
#elif defined(MAPLE_IDE) // Maple specific
#include "WProgram.h"
#elif defined(MPIDE) // chipKIT specific
#include "WProgram.h"
#elif defined(DIGISPARK) // Digispark specific
#include "Arduino.h"
#elif defined(ENERGIA) // LaunchPad MSP430, Stellaris and Tiva, Experimeter Board FR5739 specific
#include "Energia.h"
#elif defined(CORE_TEENSY) // Teensy specific
#include "WProgram.h"
#elif defined(ARDUINO) && (ARDUINO >= 100) // Arduino 1.0 and 1.5 specific
#include "Arduino.h"
#elif defined(ARDUINO) && (ARDUINO < 100) // Arduino 23 specific
#include "WProgram.h"
#else // error
#error Platform not defined
#endif

// Include application, user and local libraries
#include "Wire.h"
#include "FuelTankLibrary.h"

WiFiClient wclient;
byte ip[]     = { 172, 16, 0, 100 };
PubSubClient client("iot.eclipse.org", 1883, callback, wclient);
FuelTank myFuelTank;

#define       WIFI_SSID         "wifi57"
#define       WIFI_PWD          "**********"

void callback(char* inTopic, byte* payload, unsigned int length) {
// Handle callback here
}

void setup() {
  Wire.begin();
  myFuelTank.begin();
}

void loop() {
  publishData();
  delay(300000);
}

void publishData() {
  WiFi.begin(WIFI_SSID, WIFI_PWD);
  while(WiFi.localIP() == INADDR_NONE) {
    delay(300);
  }
  // Give some time to settle
  delay(5000);

  char content[10];

  if (client.connect("CC3200-Room-1")) {
      myFuelTank.get();
      sprintf(content, "%d", myFuelTank.voltage_mV());
      client.publish("cc3200-fvan\/voltage", content);

      sprintf(content, "%d", myFuelTank.timeToEmpty_mn());
      client.publish("cc3200-fvan\/tte", content);

      sprintf(content, "%d", myFuelTank.stateOfCharge_Percent());
      client.publish("cc3200-fvan\/soc", content);

      client.disconnect();
  }
  delay(500);

  WiFi.disconnect();
}







 

The result of the data being received, as seen from openHAB:

Screen Shot 2014-11-27 at 14.57.12.png

Previous posts for this project:

 

 

Introduction

 

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.

 

Preparation

 

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.




 

Java

 

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 http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | sudo tee /etc/apt/sources.list.d/webupd8team-java.list
debian@beaglebone:~$ echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | sudo tee -a /etc/apt/sources.list.d/webupd8team-java.list
debian@beaglebone:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
debian@beaglebone:~$ sudo apt-get update
debian@beaglebone:~$ sudo apt-get install oracle-java8-installer














 

Easy enough, and Java was installed!

 

openHAB

 

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 https://github.com/openhab/openhab/releases/download/v1.6.0/distribution-1.6.0-runtime.zip
debian@beaglebone:~$ wget https://github.com/openhab/openhab/releases/download/v1.6.0/distribution-1.6.0-addons.zip







 

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/distribution-1.6.0-runtime.zip







 

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/distribution-1.6.0-addons.zip







 

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 start.sh


...
# set ports for HTTP(S) server
HTTP_PORT=9090
...




 

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







 

openHAB was installed successfully!

 

MQTT

 

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
mqtt:eclipseIot.url=tcp://iot.eclipse.org:1883

# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a default one is generated.
mqtt:eclipseIot.clientId=bbb-openhab-fvan

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

# Optional. Password to authenticate with the broker.
#mqtt:<broker>.pwd=<password>

# 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.
#mqtt:<broker>.qos=<qos>

# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#mqtt:<broker>.retain=<retain>

# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
#mqtt:<broker>.async=<async>

# 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.

Previous posts for this project:

 

 

Introduction

 

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 (ti.com I believe), lighting up an LED for every successful test.

cc3200-wifi57.PNG

 

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.

 

 

MQTT

 

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*

Previous posts for this project:

 

 

Introduction

 

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.