• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 734 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2530: Zigbee Broadcast msg for RSSI Location (AF_SKIP_ROUTING)

CC2530: Zigbee Broadcast Issue

Marcelo Kogik1
Prodigy 90 points

Part Number: CC2530

Hello there!

I noticed that, after sending a couple of broadcast mensages correctly to all routers and coordinator, sundely, only the parent starts to receive the same broadcast msg.

With the packetSniffer I've check out that the two first bytes from MAC Payload, changed from 08 02 to 08 22. Is it related to security options? Why this change?

In the attached file, the address 0xA82B is my ZED, which is sending broadcast. You can observe that, after a power cycle, this device does an Beacon Request, then broadcast a mensage. The first message goes well, but in the next msg only the parent receive the broadcast.

Below is a picture of this the MAC Payload difference.

By the way, I've attached the sniifer file.

Broadcast Work all.psd

  • 0
    TI__Guru**** 222287 points

    Hi Marcelo,

    I am unable to decrypt the sniffer log provided since the NWK key is not available, please provide it or capture the joining process for which the key is transferred.  The bit you are curious about is "End Device Initiator" and concerns messages being sent from a ZED child to its parent.  Per Section 3.3.1.1.9 of the Zigbee 2017 Specification regarding End Device Initiator bit settings: If the source of the message is an end device and the nwkParentInformation field of the NIB is a value other than 0, then this sub-field shall be set to 1. Otherwise this sub-field shall be set to 0. After validating the source, a router parent device shall clear this field when relaying a message sent by one of its end device children.

    Also 3.6.6.2:

    On receipt of a frame with the End Device Initiator sub-field of the frame control set to 1, the following processing shall take place.
    1. If the receiving device is an end device the message shall be dropped and no further processing shall take place.
    2. The receiving device shall search the neighbor table for an entry where the value of the Network Address matches the value of the Source Address field of the message, and the device type is 0x02 (end device). If no entry is found then the message shall be dropped and no further processing shall take place.
    3. The routing device shall issue a Mgmt_Leave_Req command to the sender with the Rejoin pa-rameter set to 1 and the RemoveChildren parameter set to 0.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    Hello,

    Thanks for you explanation. By the way I"ve attached the sniffer file with the joinning process.

    As you can see in the log file, I've joinned the device and power cycle it. My ZED is address 0xA82B, the others are coordinator and routers.

    The message number 116 and 138 are broadcast, but only the msg number 116 arrived to others routers + coordinator, which is what I need.

    With Joinning.psd

  • 0 in reply to Marcelo Kogik1
    TI__Guru**** 222287 points

    The new sniffer log only contains seven packets.  You could try manually changing the value of zgNwkParentInformation from NWK_PARENT_INFO_UNDEFINED to NWK_PARENT_INFO_MAC_DATA_POLL but the ZDO_Config_Node_Descriptor.CapabilityFlags may also need to be set to CAPINFO_DEVICETYPE_FFD instead of CAPINFO_DEVICETYPE_RFD (among other options).  Either of these methods is untested and could disrupt ZED operation, as explained previously this application lies outside of the Zigbee Specification.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    Sorry, I sent to you only the filtered msgs.

    Here are a new log.

    There's the joinning process, and I've power cycle twice the ZED with address 0xA82B.

    Msg number 106 is the first broadcast that works after the first power cycle, msg 125 is the same msg, but goes only to the parent. (I've use the same function call)

    After the second power cycle, msg 143 is the broadcast that works, and msg 161 is the same broadcast that only goes to the parent.

    Joinning 2x Power Cyle.psd

     

  • 0 in reply to Marcelo Kogik1
    TI__Guru**** 222287 points

    I agree that besides sequence numbers and counters, the packets are identical with the exception of the End Device Initiator bit.  This is due to the NV memory being restored and taking effect after the rejoin.  Routing devices will not process a message originating from an End Device which is not their child.  My previous comments still apply to this situation.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    Thanks for your explanation. I'll try this workaround, and see what happens.