I try to setup a remote control with Two Xbee Serie 1 (802.15.4).
The first Xbee is setup as a transmitter, the second as a receiver.
The system is running…so what’s the matter dude ? !!
I need 0V on the DIO1 pin of the receiver, so I setup it with a DO LOW and it works BUT only if the transmitter is unplugged. As soon as I turn the transmitter on, I have 3.3V on the DI01 of the receiver and when I push my button (DI01=3) on the transmitter, I have 0V on the receiver.
It sounds as though it’s working as it should. What behaviour are you expecting that would be different from what you describe?
If you could also save the configuration of each XBee as a .pro file (using X-CTU) and attach those files to your post, it would help in any diagnosis.
First of all, thank you for taking the time to answer me.
Sorry not to reply only now but I was on holidays.
Here are the .pro files…hope it will help to understand and solve my problem.
In fact, I was expecting to have 0v on DIO1 and DIO2 during the time my xbee receiver runs and waits for an order from the emitter and 3,3v only when it receives the command from the emitter. In this way, I expect that the battery consumption will be the least important.
But what I have today is the contrary: 3,3v when the receiver runs and waits and 0v when it receives a command from the emitter.
the global project consists to pilot a 2 coils relay per xbee receiver, wired with the roller shutters.
I’m very very new to xbee (been working with the modules maybe three weeks), but several things stand out to me. First, your pull-up resistors are set to FF on both modules. For instance, on your receiver, I think this means that even though D1 is set to DO LOW (4), the pull-up resistor will pull it to high in it’s undriven state. I could be wrong, but try setting both modules to PR=0. Then use your own resistors on the physical pin to pull it low to GND. This worked for me, and I’ve posted a schematic and .pro files of my setup in another post. I initially had trouble with pin high’s and low’s too.
Also, I don’t know what your setup is exactly, but for me IC=FF with IR=0 was not ideal. In theory this did what I wanted, but only for a few seconds before the DIO timed out. T4=FF is the highest timeout setting for the D4 pin and your pin will eventually time out. This means that if you trigger D4 on your emitter to go high, and leave it high, D4 on the receiver will eventually drop low if you wait long enough, even though emitter D4 is still high. You have to set IR to something other than zero, but ideally less than half of the timeout value (so I was told by Digi tech support, see Nyquist sampling Theorem on wikipedia).
Finally, I’m not sure if your IA settings are correct, I’ll defer to John or someone else about that.
Hopefully some of this helps. Again, go see my schematic and pro files in my topic about xbee timeouts. I really think you want to look into those pull-up resistors.
I agree with blake3 about the pullups on digital inputs, though they won’t matter on outputs because the XBee drivers can both source and sink current and they’ll easily overcome the pullup.
On inputs, it depends on what circuitry you have connected. With a pullup enabled, your circuit needs only to pull the pin low to register a 0, so a simple switch that shorts the pin to ground will do it. Without the pullup you need to drive the pin either high or low.
As blake3 says, using IR to set a sample rate is a good idea. The Tn parameters default to a timeout of 25.5 seconds after which, if no change detect signal has been received, the line will revert to its configuration setting (low in your case). If you set IR to (say) 10,000 decimal (0x2710) then you’ll get a sample every 10 seconds. Making the sample rate less than half the timeout guards against the possibility of a packet being lost through interference or whatever.
The IA parameter is fine: it’s set in the receiver to the MY address of the emitter, which means the receiver will accept change detect signals from the emitter and from no other module.
I can’t see any other issues with the .pro files, so maybe you could see whether any of this helps and then report back.
BTW, to both of you, I’ve mentioned my “little program” to analyze .pro files. If you have or would be willing to install the interpreter for Tcl I could use a couple of beta testers. I’ve been thinking for a while that I ought to publish this thing…