I received my UDOO Quad today. I was not expecting to dust off my faithful home energy system I wrote a couple of years ago. It has been running well yet I feel guilty of having a home computer running 24×7 to act as my SCADA host. The UDOO is the board that will blend both the Arduino and Linux in a nice board and allow Solid State Drive to hold all the data. On its own without a SSD it consumes around 3.7 watts in-standby.
I currently have about three years worth of energy and temperature data that I also don’t want to lose and it has to be migrated as well. I’m hoping to analyze it using the R-Language one day. I’m hoping that it should be a relatively easy port as everything is cross platform.
Why GNU Octave
Learning image processing using C++ is not practical for a newbie like myself as it is not conducive to trial and error. Besides, I would like create a model and explore it in an iterative fashion before I code it in C/C++/ObjectiveC.
I opted to install GNU Octave on the Mac Mini since all my dev is on that platform. I did install it on Windows 7 a while back for an earlier project so I know what it can do. I also wanted a tool that was almost 100% compatible with MatLab code.
Installing GNU Octave
My dev box consists of a Mac Mini with 2.3 GHz Intel Core i7, 16GB RAM running OS X version 10.8.3 (Mountain Lion). There seems to be a lot of issues with installing Octave in OS X based on what I see on the web. I went down the MacPorts path since I used it for some other installation.
I read yet another book on iOS development and got the creative juices flowing with lots of ideas for some image processing. That said, I’m starting to feel like a hoarder of electronic parts and opted to put a couple SeedStudio Water Flow Sensors to some use. Besides someone asked me to describe how to use them in simple terms. So this side trip’s goal is put something together to measure the flow from kitchen faucets. The functional requirements include the following:
- Hot water line measurement
- Cold water line measurement
- Current flow rate in L/sec
- Running volume for the day in L
- Max flow Duration for the day in seconds
- Min flow Duration for the day in seconds
- Average Duration for the day in seconds
- Total flow duration for the day in seconds
- Integration with my existing M2M Mango instation over Modbus
Time to explore something outside my comfort zone. Image Processing. I’ve gone through a few geek books during hard to find spare time. There are so many apps in the iOS world that I needed to dig a little deeper to get a better understanding what is under the hood. iOS Programming: The Big Nerd Ranch Guide and Objective-C Programming: The Big Nerd Ranch Guide are good introductions. If you know C/C++ the Objective C book can be read rather quickly. I liked going through the exercises in the iOS programming book (well kindle version) to force me to navigate through the xcode/iOS documentation. My real motivation is to do some image processing and opted to read the OpenCV 2 Computer Vision Application Programming Cookbook.
I finally got around to tinker with things again and opted to digress from the zigbee standalone mote-like development to revisit the power measurement.
I have three types of sensors to measure currents lying around and decided that given I already wrote the C++ classes and modbus integration for total home energy consumption, I could easily create a spot measurement modbus slave device to monitor specific loads. Note that all my arduinos+zigbee are modbus slave devices and only the mote-like devices shall use a different protocol.
Making it work.
I got everything to function with a rather messy board setup as shown below.
The output from the Arduino shows the delta T between messages received from the end-devices. It is pretty close to the calculated ones. I will change the duration to be 15 minutes later on but for debugging purposes 10s intervals for pin sleep is tolerable.
Well everything is wired up and works as planned. Sort of. The journey there was not simple. The datasheets on the xbee around sleep modes covers everything one needs to set that up. The problem is that it is not a first pass approach for a newbie. I had to scratch my head a few times.
Upgraded to wordpress 3.2. Quite painless.
Setting up the Timer
I received my components from digikey to finish the mesh based data collection prototyping. One of the components is the LTC6991 timer chip. I never soldered surface mount devices before so I did my share of reading up on it. Mine turned out functional but not the best looking. Hats off to those who make it look easy. The IC is TSOT-23 and I purchased a breadboard friendly board to solder it to.
I opted for hardware driven sleep mode (SM=1) in the XBee. I felt that that cyclic sleep mode (SM=4) to be a pain to setup. I felt that that keeping the XBee asleep for extended durations, the device would be MIA from host. With a hardware based sleep, I could use a swith to to force it awake, configure remotely with the software tool I wrote, flick the switch back to the timer based sleep. Simple in my mind.
The resulting solution must run on batteries (coin type ideally) and I wanted to get a sense of the operating time between battery changes. The spreadsheet utilized the cells in red as variables. Assuming a wake up during of 30ms and sending a sample every 100 seconds, I can run for an acceptable amount of time. The problem occurs when I include a 78L33 level converter, 555 timer, and a sample sensor like the LM35. I will need to look into this as this might be a show stopper on the battery only constraint.