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.
So now that I have the latest firmware installed on a coordinator, router, and 2 end devices all set up for PAN ID=47, it is time to write some software to experiment with the other settings. I am not a fan of the X-CTU software and decided to write a simple test application to configure my devices. The vision is to use X-CTU software to upgrade the firmware, set the API mode, and Pan ID. After that, the rest of the provisioning would occur from the software I wrote to configure the devices. I want to commission new XBees for the “field” with just a few clicks of a mouse. I tend to forget things after a while so tacit information should be captured in the software.
I used the Java API for Digi XBee/XBee and jformdesigner within Eclipse to write a simple application as shown below. The software I wrote allows me to discover devices and drill down a given device to change parameters.
I also needed a way for me to experiment with I/O settings and sampling modes as well. This allows me to configure a device and poll the data values. The XBee sheet I use is found here.
In the end, the goal is to have the end device send their values after a sleep time so I added a listen that posts IO from end devices along with deltaTs between samples.
Time to experiment.