https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653484/cc1352p-ble-rf-power-not-set-in-cc1352p-soc/6389875Mon, 22 Jun 2026 05:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:40800f7c-0ca0-4302-8541-83c1fccf7031Amrit DhakerDear sir, We observed conducted power as below. Kindly suggest, why lower power observed w.r.t. to set We will test HCI command work when using host_test and BTool. We will check return code of RF power &amp; confim. Measured Conducted Power Across the 2.4 GHz to 2.5 GHz Band Index Value Set Power (dBm) 2402 MHz (dBm) 2426 MHz (dBm) 2480 MHz (dBm) 0 -20 -42.63 -41.09 N/A 5 -9 -16.95 N/A N/A 10 1 -5.76 N/A -6.54 15 6 3.64 N/A N/A 18 9 9.30 8.82 7.15 19 10 8.32 N/A N/Ahttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655674/cc1352p7-issue-with-nvs-read-operation-causing-system-crash/6388972Fri, 19 Jun 2026 12:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a6177c7e-8425-4761-b551-e122a92db293Marie HHi, Can you verify that the NV initialization code has run at that time? Cheers, Marie Hhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655322/launchxl-cc1312r1-add-a-timer-function-to-the-rfuartbridge/6388803Fri, 19 Jun 2026 08:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:083239ea-f766-4bd8-9dd7-e4725050e10aSiriSetting params.period = 1000000 does not mean that the GP timer is going to count to 1000000. How much it should count to depends on the clock frequency and the pre-scaler value of the timer. The pre-scaler value is set based on the requested period you want (by the driver). The pre-scaler register (TxPR) is 8 bits, and the max pre-scaler divisor = TAPR + 1 = 255 + 1 = 256 If your device run at 48 MHz, the effective clock frequency = 48 MHz / 256 = 187.5 kHz With a 16 bits counter, that means that the max period is 65,535 / 187.5 kHz ≈ 349.53 ms = 349,530 &#181;s If you want to understand more of the Timer Driver, you should include the TimerCC26XX.c and GPTimerCC26XX.c into your project and step through the initialization. You can also find more info regarding the drivers here: TimerCC26XX.h File Reference GPTimerCC26XX.h File Reference Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1656395/cc2652r-cc2652-cmd_prop_rx_sniff-wake-on-radio-not-restored-after-standby/6388246Thu, 18 Jun 2026 20:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f6d73c5f-ef45-4380-bb73-83a51e53d108Alex FagerHello, Do you have the specific SDK you have tested with here? From what you describe above assuming that the device works and wakes up normally without the radio events then it does seem like some sort of issue is arising around the radio possibly about it state. Before going into standby/shutdown does your application check the state or forcefully stop the radio? Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655322/launchxl-cc1312r1-add-a-timer-function-to-the-rfuartbridge/6387452Thu, 18 Jun 2026 09:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bd65adb8-ecd0-4169-a5e3-4abbe10192c1TI-CSCHello Siri, So, you&#39;re telling me I can&#39;t count to 1 million with 16 bits? Regards, TICSChttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655047/cc113l-cc113l-gdo0-output-pulse-truncation-in-async-mode-at-low-signal-level/6387430Thu, 18 Jun 2026 09:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e6728db0-86de-47e8-9021-b2313aa288d7Diego PHi Lilian, There are glitches that will happen that should be filtered with an RC filter. From the datasheet :https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653115/cc1310-cc1310-security-error/6387406Thu, 18 Jun 2026 08:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:dd5d2fe7-7417-479d-816e-64ebd2ddf8eefaker wangHi Daniel, Okay, I will arrange the test again and provide feedback on the results Best regards, fakerhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653115/cc1310-cc1310-security-error/6387399Thu, 18 Jun 2026 08:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e3d1cbc1-4150-4ce6-b317-7a7b29f2d270Daniel Guarecuco AguiarYou are using non-beacon mode, not frequency hopping, is that right? In this mode only one channel is used by all devices, the channel is decided by the energy scan done by the collector at startup. After that, the channel is fixed. So I don&#39;t understand how you have these other devices in different channels. Can you do the following, setup up a second sniffer launchpad (so Wireshark records two channels), and restart the network, so that the association procedure (with each device MAC address) is recorded, and share the file again. Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653115/cc1310-cc1310-security-error/6387386Thu, 18 Jun 2026 08:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4ff757d5-09be-49c7-bbe8-9cafde075447faker wangHi Daniel, My network fixed the PANID during compilation The reason why only two sensors can be seen is that the other three sensors (0x0002, 0x0003, 0x0004) seem to be in other channels I observed in the logs of collecotr that five sensors are updating their data every minute Best regards, fakerhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655047/cc113l-cc113l-gdo0-output-pulse-truncation-in-async-mode-at-low-signal-level/6387374Thu, 18 Jun 2026 08:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:720db522-53eb-4648-aef1-b77c9395f7b2lilian MUAKA BALUThank you for your reply. We’re also seeing short ‘glitches’ lasting around 200 ns. Do you have any idea why this is happening?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653115/cc1310-cc1310-security-error/6387337Thu, 18 Jun 2026 08:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0dea81fa-718d-4d78-8c5c-6d66f7dc805aDaniel Guarecuco AguiarHi faker, Can you explain what devices are in your network? It seems you have two networks 0x9F27 and 0x4D0F, therefore two collectors on the same channel. I can only see two sensors (0x0001 and 0x0005), and not 5, where they are both in different networks. If you start the sensors with PAN-ID 0xFFFF, they would connect to either of the those two networks, or are you fixing the PAN-ID at compile time? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1643706/cc1310-communication-evaluation-using-launchxl-cc1310/6387274Thu, 18 Jun 2026 07:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5d483f2c-87ae-4a0e-84ba-3ab4fafd46d9Yutaka ShimizuHi, I&#39; sorry for late reply. I would like to try operating the LAUNCHXL-CC1310 that I have obtained. I plan to test it using a frequency range of 846.7 MHz to 854.5 MHz, a bandwidth of 1 MHz, and an output power of 20 mW or less. Best, regards.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655674/cc1352p7-issue-with-nvs-read-operation-causing-system-crash/6387005Thu, 18 Jun 2026 02:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cf6f634d-bd21-42fb-a6ec-cfc478a1e3b2L YBefore the 15.4-stack starts, the NVS read operation fails and causes a system crash.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1656395/cc2652r-cc2652-cmd_prop_rx_sniff-wake-on-radio-not-restored-after-standbyWed, 17 Jun 2026 22:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0978af40-f322-4b4a-bafc-4f29c67403acHooman SarvghadiPart Number: CC2652R Hi, I’m investigating an issue with CMD_PROP_RX_SNIFF after a Standby wake-up. Before entering Standby, the system behaves as expected: Low-power listening works correctly. Current consumption shows the expected periodic sniff pattern. After waking from Standby, I observe: The MCU wakes normally. The application continues executing. The code path reaches the section where RF activity is expected to restart. I can see a larger RF-related current burst immediately after wake-up. However, after that burst, the expected periodic sniff pattern never returns. Instead, current settles at roughly 3–7 mA and remains mostly flat. At this point I’m not completely sure whether the issue is: CMD_PROP_RX_SNIFF not being re-posted correctly, the RF command completing with an unexpected state, retained RF/runtime state surviving Standby, or some other RF driver behavior after wake-up. Has anyone seen a case where CMD_PROP_RX_SNIFF works normally before Standby but loses its low-power sniff cadence after waking? Are there any RF command structures, queues, or runtime state that should be explicitly rebuilt after Standby? Any suggestions for what status fields or RF driver state I should inspect next would be greatly appreciated.CC2652RWireless Infrastructurehttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1652508/cc1352r-cc1352r1-host_test-uart-hci-not-connecting-to-mt8852b-ble-test-set/6386043Wed, 17 Jun 2026 13:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b804feb9-67d8-4e2e-a373-ffbefee907e3Kosta LogutinWe found the root cause of the issue. It has been confirmed that both Global Flow Control and EUT Flow Control on the MT8852B must be set to Disabled when performing DTM testing. The EUT is running TI&#39;s official Host Test firmware for DTM operation. The UART DTM interface implemented by this firmware supports only TX/RX communication and does not implement RTS/CTS hardware flow control. If flow control is enabled, the MT8852B will wait for RTS/CTS handshaking signals, while the Host Test firmware does not provide these signals. As a result, DTM commands cannot be exchanged properly, which may lead to connection failures or command timeouts. Therefore, to ensure successful UART DTM communication, both flow control settings must be disabled. This behavior is a characteristic of TI official Host Test firmware communication configuration.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1653115/cc1310-cc1310-security-error/6385971Wed, 17 Jun 2026 12:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c0b41a8a-ae87-4ad7-aebd-d6e84cbe07defaker wangHi Daniel, Excuse me, have you found anything Best regards, fakerhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1654642/cc1352p7-large-networks---slow-to-join-and-high-data-loss/6385865Wed, 17 Jun 2026 10:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1516da2d-66bb-4daa-999b-9bd14dbe8ca3Daniel Guarecuco AguiarHi Tiago, You might also consider using Maximize Scalability, instead of the default Maximize Responsiveness when you have more than 100 nodes, otherwise some nodes might not be able to connecthttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655322/launchxl-cc1312r1-add-a-timer-function-to-the-rfuartbridge/6385820Wed, 17 Jun 2026 09:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8c7d8a5d-8d80-455e-8d48-12563f42b1e2SiriIn SysConfig, have you remembered to set up the timer a 32 bits (and not 16)? If I configure it for 16 and have a period of 1 s, opening the driver will fail. BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1656092/smartrf-studio-7-bug-report-smartrf-studio-7-v2-32-0-fails-to-prompt-xds110-firmware-update-resulting-in-unknown-device-error/6385770Wed, 17 Jun 2026 09:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8221e142-daf5-4b33-a3c4-46327e9daa31SiriThank you for the feedback. I will send this information to the team working on SmartRF Studio. BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1656092/smartrf-studio-7-bug-report-smartrf-studio-7-v2-32-0-fails-to-prompt-xds110-firmware-update-resulting-in-unknown-device-errorWed, 17 Jun 2026 07:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:68c36eab-69fe-42a7-b7ed-a07b0eb9b93euser6266216Part Number: SMARTRF-STUDIO-7 Other Parts Discussed in Thread: CC1310 Hi TI Support Team, I would like to report a potential bug regarding the XDS110 firmware update trigger in SmartRF Studio 7 (v2.32.0). Hardware Setup: Debugger: XDS110 Target: CC1310 (Custom Board) Issue: When using SmartRF Studio 7 (v2.32.0), I was unable to connect to the CC1310 target. The tool simply listed the target as &quot;Unknown&quot; in the Connected Devices list and failed to open the Device Control Panel. I spent a significant amount of time troubleshooting hardware and target configurations, assuming it was a board issue. Troubleshooting &amp; Workaround: As a test, I downgraded to an older version: SmartRF Studio 7 (v2.28.0). As soon as I connected the XDS110, v2.28.0 correctly detected a firmware mismatch and displayed the following prompt: &quot;A firmware update is required for the debug probe.&quot; After allowing v2.28.0 to update the XDS110 firmware, the issue was completely resolved. The CC1310 was instantly recognized, and I was able to connect and configure the device without any problems. Feedback for the Development Team: It appears that newer versions of SmartRF Studio 7 (like v2.32.0) have a bug where they fail to detect an outdated or incompatible XDS110 firmware. Instead of prompting the user for an automatic update, the tool silently fails to communicate with the target, leaving the user with an ambiguous &quot;Unknown&quot; device error. Could you please investigate the XDS110 firmware version check logic in the newer releases? Fixing this would prevent developers from wasting hours troubleshooting hardware when the actual issue is simply a missing XDS110 firmware update prompt. Thank you for your support.CC1310SMARTRF-STUDIO-7