Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

How to simulate Zigbee PAN Id conflict condition?

Hello Nordic support,

I am working on a Zigbee coordinator application, in which I would like to have some customised functionality when a pan id conflict is detected. I understand that Zigbee stack generates ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED signal when PAN Id conflict is detected. 

In order to test this part of my code, I am trying to generate the condition of PAN Id conflict. For this, I programmed one nrf52840 hardware with Zigbee coordinator application which does not perform anything when ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  signal is detected. I programmed the 2nd nrf52840 hardware with Zigbee coordinator application which has the customised code when ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED signal is detected and run this one in debug mode with breakpoint for the case ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED in Zigbee signal handler. To generate PAN Id conflict condition, I set the same PAN Id for both Zigbee coordinators and force them to operate in only one and the same channel (Channel 11). However, by doing so, I did not notice the breakpoint in case  ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED being triggered. 

Could you please let me know if I am missing something to generate PAN Id conflict condition? Is there some other way to simulate this condition?

Thanks,

Anusha 

Parents
  • Hello,

    How did you set the PanID in your coordinators?

    Did you see the description for ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  in zboss_api_zdo.h:

      ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED,        /*!< PAN ID conflict has been detected. Application
                                                     * has to decide whether to initiate its resolution
                                                     * or not.
                                                     * @par Signal parameter
                                                     * @see zb_start_pan_id_conflict_resolution
                                                    */

    Of you look at the zb_pan_id_conflict_resolution in zboss_api_nwk.h:

    /**
       Allow/disallow network joining
    
       @param param - pointer to a structure containing PAN ID conflict
       information - @see zb_pan_id_conflict_info_t
    
     * @b Example:
     ZB_ZDO_SIGNAL_CUT_HEADER macro may be used to remove from the buffer everything but the signal parameter (zb_pan_id_conflict_info_t structure in this case)
       @code
    
    void zboss_signal_handler(zb_uint8_t param)
    {
      zb_pan_id_conflict_info_t *info = NULL;
      zb_zdo_app_signal_hdr_t *sg_p = NULL;
      zb_zdo_app_signal_type_t sig = zb_get_app_signal(param, &sg_p);
    
      if (ZB_GET_APP_SIGNAL_STATUS(param) == 0)
      {
        switch (sig)
        {
          case ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED:
            info = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_pan_id_conflict_info_t);
            ZB_ZDO_SIGNAL_CUT_HEADER(ZB_BUF_FROM_REF(param));
            zb_start_pan_id_conflict_resolution(param);
            break;
        }
      }
    }
       @endcode
     */
    void zb_start_pan_id_conflict_resolution(zb_uint8_t param);

    Perhaps the device that you are not debugging on is using this, so that the conflict is not detected on the device that you are debugging on. 

    But perhaps what you are really looking for is to implement a workaround similar to what is already present here? I see that the coordinator (zigbee_light_coordinator) does this by default in zigbee_helpers.c.

    Best regards,

    Edvin

Reply
  • Hello,

    How did you set the PanID in your coordinators?

    Did you see the description for ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  in zboss_api_zdo.h:

      ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED,        /*!< PAN ID conflict has been detected. Application
                                                     * has to decide whether to initiate its resolution
                                                     * or not.
                                                     * @par Signal parameter
                                                     * @see zb_start_pan_id_conflict_resolution
                                                    */

    Of you look at the zb_pan_id_conflict_resolution in zboss_api_nwk.h:

    /**
       Allow/disallow network joining
    
       @param param - pointer to a structure containing PAN ID conflict
       information - @see zb_pan_id_conflict_info_t
    
     * @b Example:
     ZB_ZDO_SIGNAL_CUT_HEADER macro may be used to remove from the buffer everything but the signal parameter (zb_pan_id_conflict_info_t structure in this case)
       @code
    
    void zboss_signal_handler(zb_uint8_t param)
    {
      zb_pan_id_conflict_info_t *info = NULL;
      zb_zdo_app_signal_hdr_t *sg_p = NULL;
      zb_zdo_app_signal_type_t sig = zb_get_app_signal(param, &sg_p);
    
      if (ZB_GET_APP_SIGNAL_STATUS(param) == 0)
      {
        switch (sig)
        {
          case ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED:
            info = ZB_ZDO_SIGNAL_GET_PARAMS(sg_p, zb_pan_id_conflict_info_t);
            ZB_ZDO_SIGNAL_CUT_HEADER(ZB_BUF_FROM_REF(param));
            zb_start_pan_id_conflict_resolution(param);
            break;
        }
      }
    }
       @endcode
     */
    void zb_start_pan_id_conflict_resolution(zb_uint8_t param);

    Perhaps the device that you are not debugging on is using this, so that the conflict is not detected on the device that you are debugging on. 

    But perhaps what you are really looking for is to implement a workaround similar to what is already present here? I see that the coordinator (zigbee_light_coordinator) does this by default in zigbee_helpers.c.

    Best regards,

    Edvin

Children
  • Hi Edvin,

    Thanks for your response. 

    Regarding your questions, here are my answers:

    How did you set the PanID in your coordinators?

    The PAN Id is taken from flash memory. If flash memory is not written, a random value is generated and assigned as PAN Id. There is also provision to set PAN Id via UART (i.e using Modbus protocol). I am setting the PAN Id via UART, which gets saved to flash memory. On reboot, the flash memory is read to get the PAN Id. So, for my test, I read the PAN Id of nRF52840 sample 1 hardware and set this same value to nrf52840 sample 2 hardware. Then, after reboot of nrf52840 sample 2, I expect the same PAN Id for both samples and generation of PAN Id conflict detected signal.

    However, when checking with Zigbee sniffer, what I noticed is that nrf52840 sample 2 changes its PAN Id to some other value after reboot even though I have set zb_enable_auto_pan_id_conflict_resolution(ZB_FAALSE) before starting Zigbee stack and also commented all function calls of zb_start_pan_id_conflict_resolution.

    Did you see the description for ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  in zboss_api_zdo.h or you look at the zb_pan_id_conflict_resolution in zboss_api_nwk.h?

    Yes, my intention is to create the condition of Pan Id conflict so that I get ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  signal.

    Perhaps the device that you are not debugging on is using this, so that the conflict is not detected on the device that you are debugging on.

    I have flashed the same firmware in both nrf52840 samples. 

    But perhaps what you are really looking for is to implement a workaround similar to what is already present here? I see that the coordinator (zigbee_light_coordinator) does this by default in zigbee_helpers.c.

    I have seen that in zigbee_helpers.c, zb_start_pan_id_conflict_resolution is called when ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  is detected. However, what I am looking for is a way to store the changed PAN Id in flash memory (if there is a PAN Id conflict). So, I was planning to do this when ZB_NWK_SIGNAL_PANID_CONFLICT_DETECTED  signal is generated.

  • Do you have a project that I can use to replicate this without implementing everything myself? Where you set the panid manually, and print the panid at a later point in time?

    Best regards,

    Edvin

Related