802.15.4 blind broadcast loop

[TahuIndy]

I'm trying to setup a simple host node to broadcast a attention message with no definitive destination node.  I need any of the child nodes (primarily asleep) to see and process this message in the small window of time they are awake. They can check to payload of the broadcast message to see if they are being requested to wake and do some work.

Starting with 802.15.4 UART example, I've gotten pretty far. Outbound messages in example go out with the MCPS-DATA.request structure with:

    m_data_req.dst_addr_mode = MAC_ADDR_SHORT;
    m_data_req.dst_addr.short_address = CONFIG_OTHER_ADDRESS;

If I change these members to what I'd think is:

m_data_req.dst_addr_mode = MAC_ADDR_NONE;
m_data_req.dst_addr.short_address = 0;

My child node will no longer see the messages high enough up to progress the fixed state machine (fsm.h/.c).  

What am I missing that will allow the host to broadcast a message w/o a destination (nor requiring an ACK...fixed that already).  I'm really hoping I don't have to keep the child nodes awake long enough to catch 64 "targetted" messages. Wanting to keep them completely powered down and waking from an RTC every X out of Y seconds.

Thoughts and thanks!

[TahuIndy]

Found my answer through some more digging into the 802.15.4 specification. Looks (and verified) that setting the dst_addr.short_address to 0xFFFF is the key to open/blind broadcast and reception. So, the key then becomes creating/provisioning a PAN_ID and using the MAC addresses of each device to "white list" each other as the network is formed.

Anyone know if using 0xFFFF has other downsides or reasons that it's a bad idea in a commercial environment?

[Edvin]

Hello,

Glad to hear that you found the solution.

As you say, this channel is typically used for formation of networks, since it is an open channel. Other than this being a typical broadcast / subscription channel, which means that others may hear your data, and there may be some noise on this channel. 

FYI:

It is possible to have several devices listening on the same channel. E.g. if you flash two devices with the wireless_uart\raw\second, and one device with wireless_uart\raw\first, then messages sent from "first" will be received on both "second"s, and a message sent from any "second"s will be received on "first".

Best regards,

Edvin

[TahuIndy]

Good to know. For our design we are planning on having up to 64 battery operated child nodes. They will power up un-assigned, then negotiate to be added to the PAN controller node. They will then sleep for 99% of their lifetimes. Only waking up for a small time and picking up a 0xFFFF broadcast message with a bitmask payload. They will check this bitmask to see if they are required to take action.  If they need to wake, they will then start several message communication with the PAN controller.

Does that design make sense?  I don't think we will ever want 2 locks nodes to be duplicated. In fact, that would be very bad  :P.

[Edvin]

I see. Yes. It makes sense. Just be sure that when they wake up, they listen to the FFFF channel long enough to pick up at least one of the messages before going back to sleep. Maybe even a couple of messages, in case the first message is not picked up properly.

Best regards,

Edvin