Xbee button press -> Xbee UART

I am using the 802.14.5 (Series 1) Xbees with the firmware that the came loaded with (if it is important to the discussion, let me know and I’ll post it when I get home).

I have one Xbee attached to a computer with a USB Explorer, and 6 others on my window blinds. The computer Xbee is in API mode, the window ones are in transparent mode. The window Xbees have the computer Xbee address in DH and DL, because that is the only one they talk to. The computer Xbee uses the API to talk to each of the Xbees in turn. This works great.

I thought it would be simple to add a button to the remote Xbees, but I’m having trouble. Here’s how I thought it would work:

  1. Remote Xbee set up with a switch between a DIO pin and GND, pullup resistor enabled on that pin. The DIO pin is set to Digital mode in X-CTU.

  2. No transmissions while it is sitting there.

  3. Button pressed, send a DIO packet. Computer Xbee receives it, passes it out the UART. Computer parses the packet.

Instead, the remote Xbee is always sending packets. I can control the rate with one of the parameters, but I can’t seem to get it to ONLY transmit a packet with the pin state changes? Am I doing something wrong, or is this working as intended? I understand that the constant transmission would be for reading ADC values, but it is silly for a digital value (OFF OFF OFF OFF OFF OFF ON OFF OFF OFF OFF etc).

I have the “transmit on change” enabled, but that only adds another transmission to the mix. With (eventually) 10 Xbees chattering away like that, am I not bound to have problems?

To summarize: How do I use a DIO pin and ONLY have it transmit when the DIO pin changes? (Or when it receives serial data, as in the current setup)

Thanks.

Brian

That is a possible set-up but obviously not desired.

Check the IR command setting (Sample rate).

The Doc does not state but I believe that IR = 0 is sampling off.

as said, I think the sampling rate setting, if non-zero, overrides the transmit-on-change option.

Even if the sampling is a several/second, the bottleneck will be the baud rate into the computer. A packet on the air is less than a millisecond. And if you enable MAC layer ACKs, the CSMA/CA (CCA) in 802.15.4 will deal with coordinated transmissions and error correction.

I’ll give IR=0 a shot. Thanks.