xbee unreliable in broadcast mode?

Wireless & IoT
1

Hi,

I’m trying to start what I hope will be a network of many Arduinos in my house, each performing a task autonomously, but reporting status and accepting commands wirelessly via xbee.

I would LOVE for every bit of the xbee messages to be broadcast messages, so that ANY device could monitor the status of the other devices, so for example I could decide later to make a web-based monitor that would show the status of the garage door, without the garage door arduino having to have sent a specific message to each xbee that MIGHT want a copy of the message.

So, I’ve been testing with 2 xbees configured identically except for the “MY” id on them are different, 1, and 2.

From xbee #2, I can send

7E 00 0A 01 00 00 01 00 4F 50 45 4E 0D BE

which translates as a direct packet to xbee#1 with the message “OPEN”

THis message gets through to my #1 xbee EVERY TIME but when I try to BROADCAST the same message:

7E 00 0A 01 00 FF FF 00 4F 50 45 4E 0D C1

With destination FF FF instead of 00 01, the message is lost/ignored/corrupted about half the time. I know the message is correct because it works the other half of the time.

The 2 xbees are series 1 PRO versions, and are sitting across the room from each other, so range isn’t a problem. (I’ve tested it in direct mode WAY further in my house).

To me, it appears that the RF is just not that reliable, and that it’s working so well in direct mode because of the error correction that doesn’t occur in broadcast mode…

Is there anyone using broadcast mode successfully, or know what else could be wrong here?

-Steve

2

No RF medium is totally reliable. If your signal to noise ratio is adequate, and has margin for fading, and error correction, these work fine. IEEE 802.15.4 is very good- it has well defined, non-proprietary error detection via MAC layer ACKs. You must enable that mode for them to work.

But for frames sent to the broadcast MAC address (0xFFFF), there can be no MAC ACK because it IS a broadcast. Same thing with ethernet frames broadcast; same with any MAC addressing scheme with broadcast.

Reliable “multicast” at the network layer is frequently done in big IP networks.

Your application layer protocol can do some sort of error detection/correction.

But in general, frames sent to the broadcast address are by definition “unreliable datagrams”. Frames sent to a specific MAC address are unicast and are reliable if MAC ACKs are enabled in the radio config.

With XBee series 2, I believe you are FORCED to use the ZigBee network layer and that’s a big mess. You may want to disable the network layer and use MAC layer functions, bypassing ZigBee. This is inherent in XBee Series 1; not sure about Series 2.

3

I second stevech’s suggestion to incorporate error detection/correction on your own. Each broadcast message should include at the very least a checksum and better yet, error correction such as a Hamming code (so that one or more single bit errors can be corrected by the receiver). You should also consider broadcasting two or more copies of each message so that if one is lost the other might get through.

4

I’d recommend a different approach. Rather than broadcast every message everywhere, every time, why not have the web-based monitor ask the garage door for its status? This would be way less noise and is the way most home area networking systems accomplish the same task.

You also might want to look into the ZigBee application layer profile messaging, which is how devices exchange application-layer messaging between manufacturers. I’ve described this a bit in my book (http://www.sparkfun.com/products/10324), but it’s also directly available from the ZigBee Alliance (http://www.zigbee.org/Standards/Overview.aspx).

5

I think there’s a terminology problem:

“broadcast” means, in network/wireless terms, a data packet/frame transmitted with NO destination node network address.

“unicast” means the opposite.

The terms apply to wireless, ethernet, and other medium with addressing.

broadcast in radio terms, any kind of transmission of anything.

6

Agreed. Broadcast means transmission to all nodes at the same time, and I feel this may not be the right approach for 172pilot’s project. Personally I’d prefer to see devices request information only when they need it, so that’s what I’m getting at here. The other approach would be multicast (in between broad and uni) but that might be too much overhead for a personal home network.

Error correction is built in to the 802.15.4 transmission, however error packets would not be retransmitted and will result in information loss (sometimes that’s not an issue, depending upon the application of course). ZigBee will retransmit a broadcast packet three times, to help make delivery more robust. This creates considerable overhead and is not recommended on larger networks.

7

Above, the term “ZigBee” is used to talk about retransmission 3 times, etc. Actually, retransmissions are done first by the MAC layer in unicast- where the IEEE 802.15.4 standard enables (optional) MAC ACK timeouts/retransmissions, irrespective of the network layer called ZigBee.

ZigBee is a network layer routing protocol that is above 802.15.4 in the protocol stack. If you will, ZigBee is to 802.15.4 what IP is to IEEE 802.3 (ethernet). There are several alternatives to ZigBee in use with 802.15.4, such as Digimesh, 6LoWPAN, ISA 100.11a, and others.

So “ZigBee” is not a synonym for IEEE 802.15.4. Indeed, ZigBee is trademarked/owned/licensed by the ZigBee alliance while IEEE 802.15.4 like 802.11, 802.3, are truly open standards.

8

stevech, right-o. 802.15.4 and ZigBee are often conflated. It’s good of you to point that out.

I think Rob was making that point that the ZigBee APS datagram will be re-broadcast by every node in the ZigBee network 3 times, causing a lot of more data to be transmitted between nodes than most are otherwise aware of. This application layer retransmission behavior is defined in the ZigBee 2007 spec. Often this behavior results in poor network performance and a surprising amount of data loss when successive broadcasts are attempted in a short amount of time.

In addition to this high-layer retransmission behavior, the ZigBee broadcast between nodes can be re-transmitted multiple times by the 802.15.4 MAC.

When using Series 2, ZB firmware modules from Digi. Users only have access to send data at the ZigBee APS layer.

This is opposed to the Series 1 Digi XBees running the 802.15.4 firmware, which can send and broadcast data at the 802.15.4 layer.

9

yes, unless you MUST have a mesh, and it must be the ZigBee protocol, one should not choose Series 2 XBees.

Series 1 can use plain 802.15.4 MAC addressing or Digi’s DigiMesh or the open source 6LowPAN protocols.

10

yes, unless you MUST have a mesh, and it must be the ZigBee protocol, one should not choose Series 2 XBees.

Conversely, XBee Series 1 can use plain 802.15.4 MAC addressing or Digi’s DigiMesh or the open source 6LowPAN protocols.

11

Hey steve, are you aware of a 6LowPAN implementation that runs on the Series 1 XBee? I’d love to check it out!