• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 174 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LP-CC2652RB: Long term connection status monitoring using the coordinator and pairing issues

A V
Prodigy 210 points
Part Number: LP-CC2652RB
Other Parts Discussed in Thread: Z-STACK

Tool/software:

I have been complaining for a long time that my end devices keep disconnecting from my coordinators and have decided to try using TI's provided coordinator to maybe reduce the risk of faulty implementation from various sellers. However, it seems that when using the LP-CC2652RB dev board I cannot get any device to pair. I have tried with another LP and with custom hardware, but neither works. Using putty for the console, I can see that the pairing countdown starts, but no device appears to connect. I've tried both my custom firmware and a sample project provided by TI. I've tried both my custom hardware and an additional LP for the end device, but again, it does not work. Both my firmware and TI's provided examples work with Sonoff and UZG coordinators, so I assume there might not be a problem with the end devices. I cannot sniff traffic for further debugging info. This gets me to my questions:

  1. What could be causing this issue and how can I get devices to pair to the coordinator running on LP?
  2. If I do manage to get them paired, how may I monitor traffic for extended periods of time? Devices might disconnect days or weeks after first pairing, so I might have to resort to other means of debugging than traffic sniffing.

I have built my custom sensor using SDK version 6.20 and have never been stable. Would there be any advantages to porting my code to the latest SDK version and switching from the Eclipse based CCS to Theia? Assuming the disconnects are not caused by a major hidden flaw within my code, should I expect better stability using the latest SDK version?

  • 0
    TI__Mastermind 38070 points

    Hi,

    Thank you for reaching out. Porting over to the latest SDK does bring many benefits such as bug fixes, additional features and optimizations. We have migration guides included in the User's Guide to assist with the porting process. I have linked these below:

    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/zigbee/html/zigbee-guide/migration_guide.html

    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/migration-cc13xx_cc26xx.html

    We will take a look at your other questions and get back to you as soon as possible.

    Best Regards,

    Jan

  • 0
    TI__Guru**** 209487 points

    Hi A V,

    Please try to erase all device memory or factory reset the ZC device to rule out any non-volatile memory issues.  Then make sure to follow the Zigbee Project Zero SLA to get started with a ZC and ZED.  Make sure you are using the same channels on both devices.  Although you do not wish to use a sniffer device, it would be very helpful for debugging.

    Using Zigbee APIs such as Zstackapi_sysNwkInfoReadReq(), Zstackapi_ZdoMgmtLqiReq(), and Zstackapi_ZdoMgmtRtgReq(), or assoc_list.h/nwk_util.h APIs, to gather network information and "discover" active devices.  You may also benefit from a ZNP interfaced with Z-Tool.  Here is the MT API for additional reference.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 210 points

    Hello Ryan,

    I tried to sniff traffic numerous times, but the existing tools are windows only and they do not work on my PC. I've explained it in the following reply to one of your colleagues about a month ago:

    Hello Alex,

    I've reached the office and tried sniffing again in two ways:

    1. Using this guide from TI: It does not work. I flashed the LP-CC2652 board with the firmware indicated there, but I cannot get SmartRF Packet Sniffer 2 to detect my board. I've made sure to have the Cebal drivers installed, flashed the board again, restarted Packet Sniffer a couple of times, reconnected the board, still nothing. Ubiqua Protocol Analyser worked a couple of months back (when I tried it the last time and Packet Sniffer wasn't working), but my free trial expired and they only let you buffer 1000 messages, which fills up in a few minutes. Not useful and not willing to pay 65$ a month.
    2. Using this guide from Zigbee2Mqtt: still not working. I've managed to use CC debugger to flash the board, configured ZBOSS Sniffer, but Wireshark does not decode any messages.

    Regarding my issue with Packet Sniffer 2: the program does not detect any boards, though I see them in device manager. If I try to manually configure serial settings, the port dropdown is not available and cannot see the ports listed in device manager to manually select the device COM.

    There do not seem to be any tools for traffic sniffing on Mac, though I might try again at a later date with a windows machine. Let me know if these issues are known and if a workaround exists.

    Until then, I will follow Jan's advice and begin porting my code to the latest SDK version. I will be more careful and come back with updates once I get things going.

    Additional question:

    The device I'm working on is a two-endpoint temperature sensor where both endpoints are temperature measurement clusters: one for a SHT40 on-board sensor for ambient temperature and the second endpoint for an NTC that gets mounted on radiator pipes for automations. Would using two temperature clusters for the endpoints pose any stability risks?

  • 0 in reply to A V
    TI__Guru**** 209487 points
    A V said:
    There do not seem to be any tools for traffic sniffing on Mac, though I might try again at a later date with a windows machine. Let me know if these issues are known and if a workaround exists.

    Packet Sniffer 2 only supports Windows and Ubiqua is not free, so I understand your concern.

    A V said:
    end devices keep disconnecting from my coordinators
    A V said:
    I have built my custom sensor using SDK version 6.20 and have never been stable

    Are your end devices crashing and completely unresponsive until being restarted, or do they simply lose the connection with the ZC and must rejoin the network?

    A V said:
    Would using two temperature clusters for the endpoints pose any stability risks?

    I'm not aware of any stability risks at the moment.  Have you observed anything for which you would ask?  I.e. your project wouldn't exhibit similar issues when you use only one endpoint?  I've seen other E2E instances where users are able to achieve reporting for many more endpoints and clusters.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 210 points

    Hello Ryan

    Ryan Brown1 said:
    Are your end devices crashing and completely unresponsive until being restarted, or do they simply lose the connection with the ZC and must rejoin the network?

    No crashes seem to happen. I have an alive led that I toggle every time I perform a sensor readout and the devices seem to be working fine. I assume something causes the connection to be lost without crashes. I have put a watchdog, so should the device be stuck in some loop, the watchdog should recover it. Also, I do not think the device restarts because I attempt a reconnect at each power-up:

    zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
zstack_bdbStartCommissioningReq.commissioning_mode = 0;
Zstackapi_bdbStartCommissioningReq(appServiceTaskId,
                                       &zstack_bdbStartCommissioningReq);

    If I see that one of the sensors disconnected, taking out the battery and putting it back in is enough to get it repaired with the coordinator.

    Ryan Brown1 said:
    Have you observed anything for which you would ask?  I.e. your project wouldn't exhibit similar issues when you use only one endpoint?

    I was just curious. I've seen the exact same behavior with unmodified examples provided in SDK 6.20. The sample temperature sensor provided by ti would randomly disconnect from the coordinator in the same way my own project does. Have not noticed a difference in frequency of disconnects either. The sonoff and UZG coordinators I have work perfectly fine with off the shelf products from Aquara or Ikea. Moreover, I had a random Aquara temperature sensor that had been dead for a couple of months and putting in a new battery it repaired itself without any issues. When one of my own sensors has been disconnected(but still powered) for more than a week, I have to redo the whole pairing process to get it to work.

  • 0 in reply to A V
    TI__Guru**** 209487 points
    A V said:
    When one of my own sensors has been disconnected(but still powered) for more than a week, I have to redo the whole pairing process to get it to work.

    The Zigbee Coordinator has a End Device Timeout procedure (END_DEV_TIMEOUT_VALUE/NWK_END_DEVICE_LEAVE_TIMEOUT definitions in Z-Stack) for which ZEDs are removed from the network after being unresponsive for a designated amount of time.  

    If a sensor is disconnected then it will not receive a response from the Coordinator when pinging a ZCL packet.  You could try sending such a packet at infrequent intervals, and if the ZC does not respond then you can further debug the behavior to determine whether it is the same as your faulty instances or simply call SysCtrlSystemReset to mitigate the issue by resetting and rejoining.

    Regards,
    Ryan