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.
Continue reading
Upgraded to wordpress 3.2. Quite painless.
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.
I needed a project to dabble and distract me in a constructive manner. The goal for this project is to build a low power data collection network to sample slow changing analog data such as temperature, ambient lighting, among other things. The constraint given was to use XBee Series 2, run in API mode, and operate on batteries.
I purchased 5 XBee Series 2s to experiment with. I used X-CTU software to configure the Xbee chips as per the last project I did. The difference this time is I did not want to use AT mode but API mode to give me more control over XBee interactions from the Arduino host software. The project context is as shown below.
