This is my first post to the new forum. I am not sure if I am in the right place. Please advise and I will move the post.
Is there any error checking on the Arduino side for Xbee packets received by the Arduino? My Arduino is connected to a Zigbee coordinator by the Tx and Rx pins on both processors. My test application sets DIO pins HIGH on all endpoints, delays and then sets DIOs to LOW.
My Setup() routine does the following. First I send broadcast set LOW DIO1's on all four endpoints. Then I delay for 2000 ms. Then I send another broadcast to turn on DIO3's. I then delay for another 2000 ms before reversing the DIO's in the same way.
If I change the values of the delays the results differ.
Altogether I am Sending four Type 17 Packets broadcasted from the Coordinator to four remote Xbees (series 2 with AT = 2). Then I poll the Coordinator for Type 97 reply packets from the Endpoints. I receive Type 97 packets with no error (SUCCESS). The number of type 97 packets I receive varies with the length of the delays between sending the commands. Sometimes I receive eight 97 Packets and sometimes a low as three. In some cases the DIOS are not set even if the 97 packets return SUCCESS.
Is my problem in the communication between the Arduino and the coordinator or do I have a queueing problem in my coordinator?
Be careful with the term "broadcast" as it has a special meaning. "Broadcast" can mean sending a single packet to address 0x000000000000FFFF, then the network handles delivery to all nodes. I haven't worked with Zigbee broadcasts, but everything I read says they can be extremely inefficient, and easily cause congestion on the network. Anyway, sounds like the broadcast address is not being used, correct?
Are all the endpoints getting the transmission OK, i.e. is there something connected to the IO pins that can be observed? Are the "endpoint" devices really configured as ZigBee "End Devices" or as "Routers"? If they are End Devices, are sleep modes being used?
If I am reading correctly, it sounds like four Type 17s are sent, before looking for any Type 97s in reply. I might try it one at a time, i.e. send the T17, wait for the T97. Responses should be fast. XBees do not have the resources to queue up a lot of packets.
This made me curious, I had no idea of transmit-to-response timing, so I checked it out. On a very simple two-node network, the time from sending a Transmit Request packet (0x10) with a very small data payload, to getting the Transmit Status (0x8B) back, is typically in the 28-35mS range. The first packet after power-up can take quite a bit longer, 150-200mS, and I saw one ~600mS. I assume the XBees are setting up their address tables on the first packet so that may account for part of that.
BTW, I don't transmit then wait, or not exactly. In the loop() function, I check the XBee as often as I can (however fast the loop runs) for incoming traffic, with no delays involved. Transmissions are timed, and I usually only transmit every 10 to 60 sec. As soon as the transmit request is sent to the XBee, the main loop goes back to checking for incoming traffic, and at some point the Tx Status packet comes back.
As for where to post, I might have chosen Networking, Protocols, and Devices. But I sure wouldn't lose much sleep over it 