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.

CC1352P: End Device Capacity

Part Number: CC1352P
Other Parts Discussed in Thread: CC2530, CC2430

In our application, our FFD will act as either a ZC or ZR depending on what it's connected to.  This is all working fine.

However, when it is in ZC mode, we want the "End Device Capacity" in the Beacon to always be FALSE so SEDs will only attempt to associate with ZRs.

For a ZC only device in the CC2530 1.2.2 stack we accomplished at compile time by setting... 

NWK_MAX_DEVICE_LIST = 14
NWK_MIN_ENDDEVICE_CHILDREN = 0
NWK_MIN_ROUTER_CHILDREN = 15

How can we dynamically accomplish this in the CC1352 SDK3.40 stack?

Thanks,

Bill

  • Hi,

    Currently, this cannot be done dynamically; the same macros are used to calculate the End Device Capacity bit of the Beacons.

    However, perhaps there could be a way for a ZED to recognize whether a beacon it receives is from a ZC or ZR.
    We know that ZC always has a short address of 0x0000. When a ZED receives a beacon, a beacon indication is passed up from the NWK layer to ZDApp (see ZDO_beaconNotifyIndCB). The beacon indication (data type of NLME_beaconInd_t) has a sourceAddr field. In this function, the ZED could then discard that beacon if it recognizes that the beacon is from a ZC.

    Regards,
    Toby

  • Hey Toby,

    There actually is a way to do this with a hack we made way back when in the CC2430 HA stack by masking off the End Device Capacity bit in the macPib BeaconPayload.  I was just hoping that there was a more graceful way of doing this today...but this works.

        /*****************************/
        /* Disable End Dev Joins     */
        /*****************************/
        // KLUDGE
        // don't allow end devices to join the coordinator by
        // clearing the deviceCapacity flag in the beacon payload
        // This is done periodically because this flag resets after a device
        // (router) joins.  There is a small window where an end device could
        // join, but its unlikely.  
        macPib.pBeaconPayload[2] &= 0x7F;