Electronic – Wireless Sensor to Internet

ZigBee (and more generally 802.15.4) targets different uses compared to WiFi (control vs data streaming), thus has lower data rate (250 kbps max) but also much lower power consumption (few tens of mW transmitting and receiving).

For sure you can make star networks, but also more complex tree and mesh networks. In fact, meshing is one of the main selling points of ZigBee.

But concerning reconnect times, it depends on how good the reception is. If you use standard power modules, they are limited to 1/100 of the transmission power of 802.11 thus you might need to use high power modules or use routers to relay messages. You may need to tune the frequency of the reconnect attempts since nodes are typically configured to operate in a duty-cycled manner, waiting for a certain time between transmissions in order to reduce power demand.

Latency is generally low, as the collision avoidance scheme is lighter (read "less sophisticate") than the RTS/CTS used in WiFi. But if you have to send large amounts of data, the throughput will limit your responsiveness as well.

If you want to retain IP networking, consider using either 6LoWPAN on bare 802.15.4 or ZigBee IP.

And if you want to stick to Atmel you can also consider replacing the whole microcontroller with a one-chip MCU with transceiver. Link

The data transmitted by the radios in 'transparent' mode gets packetized after a configurable packetization timeout (RO). There may be a way to force packetization and transmission before this timeout. The default delay for the XBee/XBee Pro (XB24-A.../XBP24-A...) is 3 character times. So long as you send your string with the characters 'back to back' (don't pause while sending data), it should end up as a single packet. Note that there is a limit on the packet length (100 bytes for the XBee/XBee Pro) - if your message is too long, it will get split into more than one packet. This should not be an issue if you are sending, say, 64 byte packets once per second. Also, XBee modules should be using CSMA to limit collisions, making it less likely for two nodes in range of each other to try to transmit at the same time. XBee modules also support retransmitting when operating in unicast mode (single destination address) so if a packet is not ACK'd by the receiver then the transmitter will try sending it again. The retransmit delay and count appear to be fixed by the MAC implementation and are not configurable, though ACKs and retransmits can be disabled completely.

Depending on what you are doing, it might be worth looking in to using the radios in API mode. With API mode, you can queue up explicit packets to send that are guaranteed to be 'atomic' and not split up. It's also the only simple way to manage networks that are more complicated than simple point-to-point as you can specify destination address on a per-packet basis as well as extract the source address from received packets. It is also possible to get status reports on transmitted packets to see if they have been ACK'd or not by the receiver.