Home/Support/Support Forum/Unexpected Broadcast Message Behaviour with Digimesh on XBP24

Unexpected Broadcast Message Behaviour with Digimesh on XBP24

0 votes
Hi,

would like to understand what is happening, so any suggestions would be helpful.
I am using XBee Pro DM modules with 8067 firmware and API mode. When I send a broadcast message (using a Tx Request API frame) to 3 other DM modules, they respond ok and I can send many broadcast messages and they get communicated to the three other modules.
If I now power cycle one of the 3 modules and then again send a broadcast, only the power cycled module gets the broadcast message. If I power cycle another module, then it is the only one that receives a broadcast message. Other messages, like requesting the Rx level of any of the 3 modules, results in a valid response coming back. Also doing a node discovery results in all nodes coming up as being present.
I was needing a broadcast message to be received by all nodes at any time, which is not the case here. Has anybody got any suggestions as to what might be going on? Eventually I will want to broadcast to many more modules (next step is 20 odd modules) and if power cycling a module kills the broadcast to the other modules, its not going to work. Thanks.
asked Jun 3, 2014 in RF Solutions and XBee by HEN New to the Community (1 point)

Please log in or register to answer this question.

1 Answer

0 votes
Are you changing any other settings or are they all at default settings? Are you using the routing capabilities or are they all in range of the sender?
answered Jun 3, 2014 by mvut Veteran of the Digi Community (11,300 points)
Hi, all are well within range so no routing should be needed.  My configuration is not the default, as I am trying to reduce the time the network is busy trying to get a message going through, should it not get through initially.  The config is as listed below :
xbp24-dm_8065.mxi
FE
0
241
8065
0
[A]CH=C
[A]ID=6F3B
[A]MT=3
[A]PL=4
[A]RR=4
[A]CA=2C
[A]CE=0
[A]BH=0
[A]NH=4
[A]MR=1
[A]NN=3
[A]DH=0
[A]DL=0
[A]NT=20
[A]NO=2
[A]CI=11
[A]EE=0
[A]BD=4
[A]NB=0
[A]RO=FF
[A]FT=BE
[A]AP=1
[A]AO=0
[A]D0=1
[A]D1=0
[A]D2=0
[A]D3=0
[A]D4=0
[A]D5=1
[A]D6=1
[A]D7=1
[A]D8=0
[A]D9=1
[A]P0=1
[A]P1=0
[A]P2=0
[A]PR=1
[A]M0=0
[A]M1=6
[A]LT=0
[A]RP=28
[A]IC=0
[A]IF=1
[A]IR=0
[A]SM=0
[A]SO=2
[A]SN=1
[A]SP=C8
[A]ST=1388
[A]WH=0
[A]CC=2B
[A]CT=64
[A]GT=3E8
[A]DD=50000
No it is not going to go quick as you are using mesh code. Try changing to the Point to point 802.15.4 code instead and you will have a lot better luck with what you want to do.
The broadcast is only one of the things I want to do.  I also need the nodes to have mesh capability as they will be on the move and communicating with each other occasionally.  The broadcast is for sending a controlling message from a "central" node to all the other nodes.  And I do need to use the mesh code as well to have the capability of all the other nodes being able to communicate between themselves, maybe using intermediate nodes.
What happens if you turn off RR or MT? Are you able to have all of the nodes then receive the packet? What about if you send a Unicast packet or a Node Discovery to one of the other nodes? Are they able to respond?
I was trying some of the tests you suggested when I realised that broadcasts were working ok.  So at this stage I am not sure what triggers this unusual behaviour.  It has happened a number of times (at inconvenient times!), so I am sure it will happen again.  Will get back when I have more info.  Thanks.
...