https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1641416/cc2755r10-radio-frequency-plan/6329345Thu, 30 Apr 2026 06:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0c432ca0-2c27-4f80-8293-10d7a8ca5231Flemming Noerskov LarsenHello Alex Reading the How to Certify Your Bluetooth Product (Rev. N) one more time I see the CC27XX products are covered Thanks Flemminghttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1641416/cc2755r10-radio-frequency-plan/6328708Wed, 29 Apr 2026 20:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5b962c3b-cb53-4e62-b048-079793167869Alex FagerHello Flemming Larsen, Can you possibly provide the specific question or field for more context? The How to certify your Bluetooth Product should be a good document to reference for FCC certification. Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1641416/cc2755r10-radio-frequency-planWed, 29 Apr 2026 08:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f85947f4-d726-4495-af0d-8126989335e1Flemming Noerskov LarsenPart Number: CC2755R10 Hi Are currently running a FCC approval, got a question on the radio frequency plan LO osc, IF freq. I guess frequencies are about the same as stipulated in &quot;How to certify your Bluetooth Product&quot;. Please elaborate on this. B.R. Flemming LarsenCC2755R10https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1640899/cc2755r10-sw-package-with-aliro-standards/6326338Tue, 28 Apr 2026 12:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:576b1dd9-43b1-4122-84f0-1002a841fb1dRyan Brown1Hi robin, There are currently no plans to support Aliro, however I have informed the Systems Team of this request so that it may be considered for the software roadmap. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1640899/cc2755r10-sw-package-with-aliro-standardsTue, 28 Apr 2026 04:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:655ce4b3-f823-4d91-9161-434c0b9e06d9robin MoonPart Number: CC2755R10 Other Parts Discussed in Thread: CC2340R5 Hi experts, My customer is looking for a device that meets the Aliro(CSA Standard). https://csa-iot.org/all-solutions/aliro/ do you have any plans to provide aliro standard library among cc2755 or cc2340R5? thanksCC2755R10CC2340R5https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6322697Fri, 24 Apr 2026 13:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d3560a44-9fb1-4238-9302-0b506ce20117lu zhengThank you for your help. Unfortunately, we do not currently have a TI official evaluation board (EVM) on hand, so we are unable to perform this test. Thanks.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6322664Fri, 24 Apr 2026 13:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d85b0188-a124-4915-899d-dd366be455f6Ryan Brown1You can submit your design to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for further review. Have you replicated the issue with a TI EVM? I have no concerns with implementing a 10 nF capacitor on an unused IO if it resolves the issue for your system. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6322088Fri, 24 Apr 2026 05:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4898c89-998f-4f4b-b515-5f4c75375452lu zhengDo you have any better solutions to resolve this issue? Thankshttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639071/cc2652psip-maximum-total-internal-capacitance-for-atex-certification/6321713Thu, 23 Apr 2026 22:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3b65d8c8-460d-4720-835a-8e6460d77140robin Moonhi FI They need the value of ATEX parameter as below for ATEX certification. Please let me know the value for each parameter of CC2652PSIP. thanks.https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6321159Thu, 23 Apr 2026 15:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:01ea90bf-f9eb-4610-ad0e-2875b77f05beRyan Brown1Thanks for reporting your findings, unfortunately I do not have further suggestions. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639071/cc2652psip-maximum-total-internal-capacitance-for-atex-certification/6321052Thu, 23 Apr 2026 15:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8890fd5f-8484-46b2-8154-0a7de8576cfaFIHi, We do not do ATEX certification, this is to be done by the end user. Total capacitance of the module is around 47uF. thanks,https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6320319Thu, 23 Apr 2026 06:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a77da258-d459-456f-85c6-696ba956d185lu zhengThe internal Op-Amp output function on P0_2 is disabled by default, which is the chip&#39;s default setting. We also tried configuring the P0_2 pin as a general-purpose I/O input with an internal pull-up resistor, but the issue persists. Thank you!https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6319977Thu, 23 Apr 2026 00:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d9068694-b5ba-4ac4-9606-962733324f22lu zhengWe have not tried configuring these pins as general-purpose I/O inputs with internal pull-up resistors. Under normal conditions, the current consumption is around a dozen milliamps or so, but when the abnormality occurs, the current draw can reach over 400 mA. We tried adding a 10K pull-down resistor to the corresponding pin, but it was ineffective. The only solution that worked was adding a 10nF ceramic capacitor between P0_2 and GND. Thank you,https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6319499Wed, 22 Apr 2026 17:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7b8f2bcd-a78b-4bbe-b84c-19f7cad143e6Ryan Brown1Have you tried setting the pins as a general-purpose I/O input with internal pullup resistor? P0_2 is the output of the internal Op-Amp, have you made sure that this feature isn&#39;t being enabled? Can you quantify how large the current draw is? Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6319268Wed, 22 Apr 2026 15:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:91e614ce-a958-4abd-b9ab-e4f92c476ea3lu zhengHi Ryan, Thank you for your quick response. We have only tested this on our custom PCB, and the same phenomenon was observed across multiple identical chips. When debugging in IAR, we confirmed that P0_2 and P0_3 have identical register configurations, both configured as outputs and driven low. Based on your analysis, under what circumstances would this phenomenon occur? Thank you!https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-high/6318948Wed, 22 Apr 2026 12:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1a31497f-4468-4385-94fd-02223d7407eaRyan Brown1Hello lu, Have you tested this behavior on both a TI EVM as well as a custom PCB? When debugging in IAR are you able to confirm that the register configurations of both P0_2 and P0_3 are identical? Please note the following advice for unused IO pins from the CC253X User&#39;s Guide Unused I/O pins should have a defined level and not be left floating. One way to do this is to leave the pin unconnected and configure the pin as a general-purpose I/O input with pullup resistor. This is also the state of all pins during and after reset (except P1.0 and P1.1, which do not have pullup or pulldown capability). Alternatively, the pin can be configured as a general-purpose I/O output. In either case, the pin should not be connected directly to VDD or GND, in order to avoid excessive power consumption. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639071/cc2652psip-maximum-total-internal-capacitance-for-atex-certificationWed, 22 Apr 2026 04:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:48741d16-742e-4926-9241-a43145a1402crobin MoonPart Number: CC2652PSIP Hi experts, My customer requested Maximum total internal capacitance of CC2652PSIP for ATEX certification. Also, could you please provide us with a guide document for ATEX certification? ThanksCC2652PSIPhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1639057/cc2530-after-interference-on-the-cc2530-p0_2-p1_0-pins-the-power-consumption-becomes-extremely-highWed, 22 Apr 2026 03:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5753c3e3-7376-4c06-9385-d68ad88693b6lu zhengPart Number: CC2530 Hello! We encountered the same configuration in a project where both P0_2 and P0_3 are configured as output low. Neither of these IOs is connected to any external device. When P0_2 is touched with tweezers, the power consumption increases dramatically. At this point, the measured voltage on this pin is around 0.63V. Touching P0_3 in the same way does not cause this issue. When this problem occurs, it can only be restored to normal by power cycling. Could you please help analyze what might be causing this and how to resolve it? We look forward to your reply. Thank you!SIMPLELINK-2-4GHZ-DESIGN-REVIEWSCC2530https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1636508/cc2652r7-zed-unexpected-network-leave-nlme_restorefromnv-returns-false/6309746Wed, 15 Apr 2026 14:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2dd8c3c4-cea5-4d18-ad01-4bf560f03786Ryan Brown1Hello Rafal, Here are some similar E2E threads although I do not believe they are identical to your observations. CC2652R7: ZED Randomly leaves network CC2652P: why ZC send a Leave request to ZED automatically? Issue 1: You have a firm grasp on mechanisms which could be causing a network Leave without rejoin. Are you using a SimpleLink F2 device for your ZC/ZR parent as well? If this source code is not from TI then it becomes even more difficult to determine what could be causing the Leave without having a sniffer log. You could try to force the issue by leaving the ZED off for a few hours, or the same for turning off all available network parents while leaving the ZED on. You can also debug the ZED code by placing breakpoints at each call to NLME_LeaveReq and bdb_setFN as based on issue 2 it appears that a factory reset is being performed. Does your ZED rejoin as expected when it is simply reset, and how many messages does it send on average over time? Can devices fail in the field regardless of how long they have been active, or are older devices more susceptible? Issue 2: Since NLME_RestoreFromNV returns FALSE we have reason to believe that the ZED is initiating a factory reset. This is most commonly performed through the bdb_setFN API. This would erase all existing NV flash memory and start the device in a new network state configuration (ZDApp_RestoreNetworkState). So your idea of storing NVS would be ineffective if using the Zigbee application NV memory section which is reset on a factory reset (zgReadStartupOptions). ZEDs should be perfectly capable of restoring network settings on a reset, the exception being if they have been instructed to start into a new state. You could modify the application to not allow a factory reset of the NV memory and force a rejoin, however this could be rejected by the parent if it sent a Leave without rejoin command. What you&#39;ve described sounds a bit like Zigbee Cloning which you can read more about in this App Note . If you don&#39;t want your custom NV to be affected by the Z-Stack state machine then you would need to add a different NV section to SysConfig which is directly controlled by the NVS TI Driver . This would need to be accounted for in your command linker file. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1636508/cc2652r7-zed-unexpected-network-leave-nlme_restorefromnv-returns-falseTue, 14 Apr 2026 16:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3fd4555a-efca-45b7-9323-de0405efe0d2Rafal WisniowskiPart Number: CC2652R7 Other Parts Discussed in Thread: Z-STACK , SYSCONFIG Hello, I&#39;m working on a battery-powered Zigbee End Device (ZED) project and need assistance with two related issues: Hardware/Software Environment: - Device: CC2652R7 (custom board) - Z-Stack Version: 3.x (SDK 8.30) - Configuration: Zigbee End Device (sleepy end device) --- Issue 1: Unexplained Network Leave Events Our battery-powered end devices occasionally leave the Zigbee network unexpectedly (very rare occurrence, ~0.1% of devices in field). Since this is intermittent and difficult to reproduce in our lab, I don&#39;t have sniffer logs or device traces yet. I do have information that this issue also happened on older version of SDK (6.20). Questions: - What are the known mechanisms that can cause a ZED to leave the network without explicit application request? - Should I be looking at: parent loss timeout, poll rate issues, security failures, low battery behavior, or something else? - Are there specific NV items or runtime flags I should monitor to detect why a leave occurred? --- Issue 2: NLME_RestoreFromNV() Returns False To work around Issue 1, I&#39;m implementing a network backup/restore mechanism that saves network parameters to a separate custom NVS region. After a device leaves the network, I want to restore the parameters and rejoin the closed network (permit join disabled). Current Implementation: 1. On successful join: - Save NIB data to custom NVS region - Save Security Keys 2. On boot/rejoin attempt: - Restore NIB data from custom NVS - Restore Security Keys from custom NVS - Calling bdb_setNodeIsOnANetwork() - Tell BDB that device has network parameters so it can attempt secure rejoin - Clear startup options to allow network state restoration on next boot - Writing NIB via osal_nv_write - Restart the device Problem: NLME_RestoreFromNV() consistently returns FALSE. Since this is a precompiled library function, I cannot debug why it&#39;s failing. Questions: - What conditions cause NLME_RestoreFromNV() to return false? - Is there a specific initialization sequence or NV items that must be set before calling this function? - Should I be using a different API for restoring network state after a leave event? - Does the network key need to be handled separately from the NIB structure? What I&#39;ve Tried: - Verified NV write operations succeed - Verified NIB data integrity with CRC checks before restore - Called restore at different points in initialization sequence Any guidance on either issue would be greatly appreciated. For Issue 1, even general debugging strategies would help. For Issue 2, understanding the restore API requirements would unblock my prototype. Thank you!Z-StackCC2652R7SYSCONFIG