Setting Xbee Pro pins remotely?

aviator3.1

I have two XBee Pro modules talking to each other one as the coordinator and the other as an end device. I'm trying to signal the end device to set the D5 pin high or low through the X-CTU software remotely from the coordinator. In essence what I'm trying to do is get a piezo buzzer to either ring or not ring depending on whether the D5 pin is set high or low on the end device. I will be integrating the coordinator with a BS2 to do this automatically depending on whether certain conditions are met. I'm trying to emulate this in the X-CTU software for now and then I will be writing code for the BS2 which will mimic the X-CTU commands.

So for now I'm asking for some help with being able to set the D5 pin on the end device either high or low remotely through the coordinator.

Thanks
-Dan

aviator3.1

I was assuming that if I set the D5 pin on the end device to DI meaning verses Associate or ADC or D-high or D-low etc that it would read whatever the coordinator pin was set to namely D-high or D-low. Is this assumption correct or do I have it all wrong

Thanks

sylvie369

I think you're doing it the hard way. Take a look at this project:

http://www.faludi.com/2006/12/03/xbee-direct-io-with-adc/

For your purposes, you can ignore the part about ADC and PWM (unless you want to implement a remote volume control), but the digital switch part does exactly what you're trying to do.

You'll first make sure that the addresses are right (ATMY, ATDL, PANID) so that the base XBee can talk to the remote XBee. The PANIDs need to be the same, and then set up the XBees' MY and DL like this

Base
ATMY 0
ATDL 1

Remote
ATMY1
ATDL0

Then you'll need to set pin 5 on the base XBee as a digital input:
ATD5 3

Pin 5 on the remote will need to be set to the kind of output (default HIGH or default LOW) you need for the switch circuitry on you remote:
ATD5 4·· (LOW)
or
ATD5 5· (HIGH)

On the base station you'll need to set the sample rate and the number of samples before transmission. If it's just a switch, these can be fairly low. In the example I linked to, these are
ATIR 14 –> sample rate 20 milliseconds (hex 14)·· <--- For your project, this could be MUCH higher. Checking once per second would probably be fine, right?
ATIT 5 –> samples before transmit 5··················<--- But if you turn down the sample rate, you might want to transmit more often. You can mess with these until the lag is okay. Checking and transmitting less often will improve battery life.

You won't need to mess with ATIU, which controls whether or not the line-passing data are also sent through the UART. It defaults to ON, which is fine for testing, and won't make any difference when you're just using it as a switch. It doesn't sound like you even have anything connected to the remote's UART.

You will need to set the remote to "bind" it's pin states to those of the base station, using ATIA:

ATIA 0·· <--- in the example I linked to it's 1 because that's the MY address of the base station. Here I used 0 because that's what I put as the base station's MY here. You just need to make sure that the remote is bound to the base, whatever its MY is.





Post Edited (sylvie369) : 2/5/2010 4:43:10 PM GMT

aviator3.1

after following all the above steps will i need to still configure the modules as a coordinator and end device respectively?

Thanks

aviator3.1

ok, i followed all the steps listed above in sylvie369's post but when i power up the remote module the RSSI LED starts blinking but I can not communicate with the base module anymore through X-CTU. Also in the terminal tab I'm getting a bunch of garbage that keeps on displaying continuously. I set the D5 pin high on the remote as stated above. My piezo buzzer rings for a while and then turns off and it has turned back on etc "acts spontaneously". Also I was thinking about how when I begin programing the BS2 how will I flag the D5 pin on my base to set the D5 pin either high or low on the remote module. Its set as an input on the base module but thats just a setting so it can read inputs as I understand it. Am i thinking about that the wrong way?

-Dan

Franklin

I guess it's about time to show us your code and how you have things hooked up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Tracy Allen

Sylvie369, That's a neat site you pointed out, from Rob Faludi. Good info, including the link, "Common XBee Mistakes" (Required reading!)

Faludi's "direct i/o" is referred to on page 15 of the Digi XBee documentation as "I/O line passing". It opens many possibilities, especially when there are remote functions to be implemented that are simple enough that a microcontroller is not necessary. The i/o state of XBee#1 module autonomously controls the i/o state of XBee#2. (The bytes to support line passing are, I think, contained in the Digi header and are not part of the IEEE 802.15.4 standard (MM command).)

The XBee does offer additional more flexible control operations via the serial port. I think that may be what aviator3.1 is after. I am just learning this myself, but I think that it is necessary to use API mode in order to enable serial port commands sent via XBee#1 to control/read the i/o pins on a standalone remote XBee#2.

A BS2 #1 can use AT commands to read/set the i/o pins on its own XBee #1. On the other hand, if it wants to read/set the i/o on remote XBee #2, it has to put the commands in an API frame and send that to the remote XBee #2. The remote XBee#2 parses the commands embedded in the API frame, which can then cause effects on its outputs or cause it to pass back readings from its inputs. A roundabout way to do that would be to have a BS2 attached to XBee#2, and have it use its +++ command mode to set/read i/o pins on its XBee#2, then back into transparent mode. But that is indeed very roundabout when the capability is built into the API mode of the XBee itself.

I don't know if API frames to control i/o on a remote XBee can be sent from XCTU. I recall there is an API check box. Good question.

Aviator, I don't think any of what you are doing so far requires a coordinator. For this project, you know in advance the device serial numbers, pan ids, and channel numbers for your two XBees. Simple peer to peer should work fine, and its better to keep it KISS at first. The coordinator will become necessary if you need to use the cyclic sleep modes, or if the network components need to self-organize in some way.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Franklin

Take a look at this project. www.ladyada.net/make/tweetawatt It uses xbees to measure and send data to a computer without micros at either end.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

kavejska

Hello!

I have a problem triggering digital output (like DO0) on the remote ZigBee.

Case 1:
I know I can trigger it like this:
- setting digital input on the base ZigBee
- setting digital output on the remote ZigBee (DO LOW)
- and if configured right the input state on the base ZigBee is transferred to the digital output on remote ZigBee

I managed to do that, but I would like to trigger it via data packets.

Case 2:
So I tried with setting API packets that set the digital output on the remote ZigBee. I managed to change the digital output on remote ZigBee with commands ATD0=4 (DO LOW) ATD0=5 (DO HIGH).

DO LOW API command:
7E 00 10 17 05 00 13 A2 00 40 08 C9 80 00 02 02 44 30 04 21

DO HIGH API command:
7E 00 10 17 05 00 13 A2 00 40 08 C9 80 00 02 02 44 30 05 20

Problem:
But the problem I have is that sometime the communication between the base and remote might be lost. And if the digital output on the remote ZigBee is set to 3,3V (DO HIGH) and the communication is lost, the digital output would stay at the 3,3V. I want it to "reset" to 0V. In "case 1" when I tried to trigger the digital output with digital input, you can set the reset timer for that digital output (command ATT0) and it did the work (the digital input reset to value 0V), but you can't use that in the case 2.

Question:
Does anybody know what is the API format of the packet to simulate case 1 - I/O line passing (case 1 data packets)?
Do you have any other ideas how to "reset" the digital output to 0V.