Zigbee PORCUPINE

[dwblair]

• Click here to navigate back to the PVOS wiki home page. 
• This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License

Background

A Zigbee-based solution for the PORCUPINE (Pulses-Of-Remote-Camera-Use-Ping-If-Not-Enduring) project.

The basic problem: how to transmit information about the battery status of an aerial camera platform to the user on the ground, over a range of up to around 1000 feet?

This issue is about exploring solutions to this problem that involve the Zigbee radio protocol. The main emphasis will be on finding the lowest-cost, most-straightforward and accessible solutions; but en route, we'll likely be discovering and documenting some neat ways of doing fancier things as well, for advanced users / applications.

Zigbee Info and Tutorials

Related Links and Resources

[mbockmann]

Here is one way I think we can do this. We'd build one circuit for the kite to sense the voltage level of the battery, and one circuit on the ground to listen to the kite and alert when the kite circuit senses danger.

Kite Voltage Detector: (1) Zigbee (1) 3.3V power source (1) shunt regulator diode* (TL431ACLPG maybe) some passive components to utilize shunt regulator diode a circuit board. An early design would be a perfboard with adapters for Zigbee pins, a later design might be a PCB.

Ground Circuit/Noise Maker (1) Zigbee (1) 3.3V power source (1) transistor (1) buzzer**

I believe we can configure the shunt regulator diode w/ passive components to make a pin on the Zigbee go high when the battery voltage drops below a given threshold. With the Zigbees running in API mode, I believe we can make a pin on the Ground Circuit/Noise Maker go high. If we make this pin the input to a transistor, we can feed DC to a buzzer that will make noise. Additionally, I believe if we research sleep modes on the Zigbee we can save battery on the kite by only checking the battery level at a set interval, maybe five minutes. I'm going to look into getting a shunt regulator diode to test with to demo the concept. Maybe we'll find something doesn't work quite like I thought it would... so a proof of concept is necessary.

*A sparkfun kit works off of this concept. We probably would not want to have more PCBs on the kite then necessary, so to save space I want to look into building the circuit onto the perfboard. If we can find a good way to interface this kit to a Zigbee without creating a new circuit board that might be better since they already have a PCB. Here is the kit: https://www.sparkfun.com/products/11087

**there are two common types of buzzers. We want an electromagnetic buzzer instead of a piezoelectric buzzer to save cost. We can apply DC to the electromagnetic buzzer to make sound, but a piezoelectric buzzer would need a signal applied to it which would cost us additional components or an Arduino. TDK has posted some slides on Digikey that describe the two types of buzzers: http://dkc1.digikey.com/us/en/tod/tdk/Buzzers_NoAudio/Buzzers_NoAudio.html

[Fastie]

Matt -- This is a great plan.

The batteries on a KAP rig that you might want to monitor could be:

• the camera battery
• the controller/RC radio receiver battery pack

The camera battery is usually either a Li-ion pack or some AAs, and are a little hard to get to. For example, the battery in Don's new Powershot SD1100 (below) has its contacts deep inside the camera with little space for wires to reach them.

Accessing AA batteries in those Powershots that use them might be easier, but could still require surgery on the camera.

Controllers used to point the rig with pan and tilt servos and to trigger the shutter via USB typically use around 5 volts from three or four AAA cells. These same battery packs can power the radio receivers used for remote control of servos or shutter release. Below is a switched box (black) with four AAA cells powering a receiver (white box, more here). These batteries would be easy to access.

The battery which has caused the most problems and prompted this whole effort to monitor camera operation is the battery powering the 555 timer circuit used to trigger two cameras at once. The timer below is powered by a single 4LR44 6v battery. That one would be easy to access.

Finding a way to monitor this battery might make a worthwhile contribution to PLOTS kite and balloon mappers, at least those using the dual camera NIR tool. I always use rechargeable batteries in the camera and rechargeable AAAs for the 5v servo and shutter controllers, and they last plenty long when I start with freshly charged ones. But the 6 volt battery powering that 555 timer circuit is not rechargeable, so it is harder to know how many more hours of service it might provide, and it;'s expensive to start with a new one for every flight.

[dwblair]

Wow, this is all great!

Based on a quick read of both of your posts -- and just to check that I'm on the same page -- is the following a good first set of goals to aim for by Sept 22nd? (If so, I'll copy them up to the main description of this issue, above -- or e.g. set a milestone ...)

Goals

1. Get two Zigbees talking to one another with minimal equipment, as per Matt's suggested setup
2. Monitor the level of a battery in a simple geometry, such as the 555 timer in the last photo that Chris posted
3. Send a signal that indicates the battery level from Zigbee to Zigbee, using Matt's piezo scheme.
   • Sounds like Matt already knows how to do (1) above (and set something like this up already for the July workshop). Btw: quick link -- Lady Ada's Xbee Adapter Kit -- Matt, did you say you didn't like this setup so much? I'm eager to learn how this is done. Matt, can we order Zigbees, and set it up, and describe our process in this issue thread?
   • Sounds like Matt is already honing in on monitoring battery level using the shunt regulator diode setup Matt suggested above. Matt -- let me know how I can help with that, I'd like to learn this method as well.

Exciting! Instant fantastic progress!

[mbockmann]

I'll try to get a rough demo running this month. It may be just a couple XBees and the sparkfun kit; with a battery and potentiometer to demonstrate a battery voltage dropping to the danger zone. I'll start considering the 555 timer battery pack, and warn if the voltage drops to around 5.5 V. Once we have a working proof of concept, we'd want to figure out what voltage is our danger voltage. Responding to Don's comment on the Adafruit XBee adapter - I don't like it because it uses an FTDI cable instead of a USB cable. It's easier for me to find a spare USB cable right now. The Adafruit kit is a lot less expensive than the XBee explorer, so if you had FTDI cables handy it might be a good choice. Earlier I had said the XBees should be running in API mode, but what really matters is that we use Zigbee direct.

[mbockmann]

Just a quick status update. My order of the uh oh battery detector kit from spark-fun came in today but I'm having some difficulty getting the cut-off to work far above 3V. I have to play around with it more and maybe do some more research. I don't understand the TL431ACLPG well enough yet. I may also look into alternative single source low voltage detectors.

[mbockmann]

So I hadn't left myself enough time to get this demo up and running before Leaffest. The low voltage detector has some kinks to iron out, and I want to research and experiment with alternative ways to do this part.

I thought I could get XBee Direct working in a few hours. I'm sure it's very simple, I just don't know how to do it yet. I've used some slides by Rob Faludi as a guide, but the errors I see when using the same configuration in the slides for XBee direct suggest there have been some changes in the firmware, requiring some tweaking to the configuration suggested (slide 15). (http://wireless.ictp.it/wp-content/uploads/2012/02/Basic-Doorbell-Project.pdf )

The major difference between XBee direct and the romantic lighting sensor example in Rob Faludi's book is that there is no extra Arduino parsing packet data. One XBee input forces another XBees output to change. It must be terribly simple to do... I just haven't gotten there yet. Hopefully I'll figure it out soon...

[dwblair]

Hey Matt -- no worries, I'm pretty sure life hadn't left yourself enough time, starting that new job and all!

It'll be fun to talk at LEAFFEST about the setup you're trying to make work, and what might be currently amiss.

Btw: I have an Arduino Mini Pro that I'll be bringing -- it's super lightweight -- if it's easier to do for the sake of this weekend, could we use the Mini + XBee as one node, and another XBee on the ground + Arduino Uno as the other node -- i.e., use this as the "vanilla" XBee configuration (rather than the more advanced XBee direct config)?

On Fri, Sep 21, 2012 at 12:57 AM, Matthew notifications@github.com wrote:

So I hadn't left myself enough time to get this demo up and running before Leaffest. The low voltage detector has some kinks to iron out, and I want to research and experiment with alternative ways to do this part.

I thought I could get XBee Direct working in a few hours. I'm sure it's very simple, I just don't know how to do it yet. I've used some slides by Rob Faludi as a guide, but the errors I see when using the same configuration in the slides for XBee direct suggest there have been some changes in the firmware, requiring some tweaking to the configuration suggested (slide 15). ( http://wireless.ictp.it/wp-content/uploads/2012/02/Basic-Doorbell-Project.pdf)

The major difference between XBee direct and the romantic lighting sensor example in Rob Faludi's book is that there is no extra Arduino parsing packet data. One XBee input forces another XBees output to change. It must be terribly simple to do... I just haven't gotten there yet. Hopefully I'll figure it out soon...

— Reply to this email directly or view it on GitHubhttps://github.com/Pioneer-Valley-Open-Science/pioneer-valley-open-science.github.com/issues/13#issuecomment-8755133.

voice / SMS: +1-651-252-4765 skype: dwingateb

[dwblair]

Nice tutorial on using the openLog from sparkfun: http://www.sunshinehere.com/blog/?p=104

[mbockmann]

I'm still fighting with firmware issues and have some distance to cover. Digi's XCTU software for updating XBee firmware is only designed for Windows. It isn't hard to set up in Linux using Wine, but you can't automatically get Firmware updates through the automatic download. You can still download firmware through Digi's website, but choosing the correction option with all the hardware they've released is difficult. I believe the modules I purchased on Sparkfun are listed on Digi as "XBee / XBee-PRO ZB (S2) Modules" and "XBee / XBee-Pro (S2B) Modules". After performing this to upgrade to 21A* firmware, I was able to get my configuration strings to complete with only one error:

Router/Sensor ATRE, ID 2001, DH 0013A200 ,DL #DEVICE SPECIFIC#, IR 64, D0 5, WR

Coordinator/Buzzer ATRE, ID 2001, DH 0013A200 ,DL #DEVICE SPECIFIC#, IR 64, D0 3, IA 0xFFFF, WR

The error was IA on my coordinator. Afterwards, my coordinator gave out. Now two of my three XBees are in a bad state where I can't send serial AT commands or update firmware in X-CTU. There are walkthroughs I can follow that I might be able to recover them.

On another note, two standard Xbees could get 300 ft line of site under good conditions, but I think with an Xbee Pro on the kite and a standard Xbee as the receiver we can make 1000 feet. I think there are cheaper and easier to configure alternatives. Maybe a simple RF transmitter if it's small enough, or Synapse which can run Python code. I'm going to stick with XBee for now just because it's what I set out to learn.