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.

CC2530: I cannot open network with Zigbee 3.0 Linux Gateway Sensor to Cloud

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, CC2531EMK, , , CC1352P, CC2652R, CC2590

Hello.

I ran both of Zigbee 3.0 Linux Gateway Sensor to Cloud source and the guide in @ blog.

The guide of  worked fine and in Zigbee Gateway source I could not open network.

After comparing packages sent to ZNP, I see that  used APP_CNF_BDB_START_COMMISSIONING (0x2F05) with CommissioningMode: (0x02) Network Steering (0x2) and Zigbee Gateway source used NWK_SET_PERMIT_JOIN_REQ to open network.

So what is difference in here? 

Is NWK_SET_PERMIT_JOIN_REQ packet necessary?

Please help me undstand it.

Thanks

  • In Zigbee 3.0 Linux Gateway Sensor to Cloud solution, it uses BDB Network Steering+Finding and Binding which would also enable permit join on Zigbee network to open network for joining. In the blog, it use Network Steering to form network first and NWK_SET_PERMIT_JOIN_REQ to open network in next step to open network for joining. Fundamentally, they are the same. When you say "in Zigbee Gateway source I could not open network.", do you use sniffer to check what happens over the air?
  • It is my mistake when I added a define in ZNP, thank you for your explanation.
    But in "In Zigbee 3.0 Linux Gateway Sensor to Cloud solution, it uses BDB Network Steering+Finding and Binding which would also enable permit join on Zigbee network to open network for joining. In the blog, it use Network Steering to form network first and NWK_SET_PERMIT_JOIN_REQ to open network in next step to open network for joining.", are you confused? In the blog, it only uses APP_CNF_BDB_START_COMMISSIONING to form and open the network.
  • Yes, you are correct.
  • Hi YiKai Chen,

    Do you know this problem?

    When I open network in nodejs host of Zigbee sensor to cloud, It permit joining request, but the network still closes. Although it runs well in Z-tool.

    I attached my log here.

    start_arm.zip

  • Can you attach your sniffer log?

  • I just tried again. In first time, it ran normally. Then I stopped it and ran again, this problem has occurred.

    I attached my sniffer log here.

    networknotopen.zip

  • It's strange that I see your coordinator enable permit join for 180 seconds but the coordinator beacon frame shows disallow join. Can you do a factory reset to your whole Z-Stack Linux GW and ZNP to test again?
  • So sad. I tried many times but this problem still happened.
  • What HW do yo use as ZNP? CC2531EMK or LAUNCHXL-CC26x2R?
  • I see the CC2530 listed in the title, are you using the SmartRF05EB, CC2530EM, and CC2530_GW_ZNP_SRF05+EM_UART?  Try the attached binary ZNP image instead:CC2530ZNP-GwZ3.hex

    Please refer to the notes inside of Firmware/Readme.txt.  Have you tried running the zigbeeHAgw/start_application as described in Section 6.3 of the Z-Stack Linux Gateway User's Guide, and are there any changes in behavior if so?  Would you be able to evaluate with a CC2652R/CC1352P LaunchPad?  These platforms are more commonly used to evaluate the SENSOR-TO-CLOUD solution.

    Regards,
    Ryan

  • Thanks  and .

    I am using a custom cc2530 board without flow control.

    I make znp as follows:

    - choose 2530 ZNP with SBL

    - znpCfg1 = ZNP_CFG1_UART;

    znpCfg0 = ZNP_CFG0_32K_OSC;

    - add defines: ZNP_ALT | MT_UART_DEFAULT_OVERFLOW=FALSE | ZTOOL_P1 | HAL_PA_LNA_CC2590

    - decrease XDATA to 0x400

    - in Zigbee sensor to cloud, I follow Z-Stack Linux Gateway User's Guide, disable flow control and run nomally.

    I don't have cc2652/cc1352 now so I want it to run in cc2530. Do you have bin file for my cc2530?

  • If you test with Ztool, does it work?
  • I can't provide any plausible binary images if you are using custom board. I notice that earlier you had mention that it operates properly with Z-Tool so UART communication does not seem to be the issue (unless you have not changed the baud rate in NPI_Gateway.cfg accordingly). Have you disabled the flag SKIP_BOOTLOADER_VALIDATION in npi_lnx_ipc.c?

    Regards,
    Ryan