<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://e2e.ti.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Bluetooth®︎</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/</link><description>&lt;p style="display:none;"&gt;blank&lt;/p&gt;</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><item><title>Forum Post: RE: CC2745R10-Q1: Connect monitor sync data and cfg</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1641771/cc2745r10-q1-connect-monitor-sync-data-and-cfg/6336339</link><pubDate>Thu, 07 May 2026 12:45:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:930cebfc-e8bb-43bb-b97c-12f845e4aa17</guid><dc:creator>Isaac Larson</dc:creator><description>Hello, Can you elaborate on what you mean by sequential timing requirement relating to the function? Yes, the features need to be set at chip start up. This is done already within the stack using SysConfig, but if you want to alter the feature set, you will need to do this during chip startup. Thanks, Isaac</description></item><item><title>Forum Post: RE: CC2652P: Watchdog running speed: Dependent on system power modes?</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643365/cc2652p-watchdog-running-speed-dependent-on-system-power-modes/6336329</link><pubDate>Thu, 07 May 2026 12:42:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:a709c180-1936-4619-be1a-b3220bc29196</guid><dc:creator>Ryan Brown1</dc:creator><description>Hi Raphael, Here is the TRM (Section 17 for WDT) and Watchdog TI Driver APIs . Ultimately the WDT sources its timing from clocks which are only operational during active mode. The WDT is not able to count actively while the device is in Standby mode. Hence when you only get 200k counts per second this could indicate that the MCU is only active for ~13% of the second, and at 1M it is active for 67% of the second. You would observe similar issues if observing the General Purpose Timers (GPT). If you want to retain standby mode (recommended for low-power applications) and have an accurate timer then I recommend the use of ClockP which continues clock operations during standby mode. Otherwise you could choose to disable standby mode from the Power module of the SysConfig Editor. Regards, Ryan</description></item><item><title>Forum Post: RE: CC2340R5: Custom Board Boot Issue: Program only runs after Debug Restart, not on Power-On Reset</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643401/cc2340r5-custom-board-boot-issue-program-only-runs-after-debug-restart-not-on-power-on-reset/6336303</link><pubDate>Thu, 07 May 2026 12:27:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:1632e1e5-9749-403f-9459-c04c7cc13571</guid><dc:creator>Ryan Brown1</dc:creator><description>Hi bai, My first thought is that this is very similar to a recent E2E thread . It is a common mistake for custom boards which do not know how to properly set the ROM Serial Bootloader configuration. Please see my response below: This is a common issue likely related to the default backdoor bootload pin from the SysConfig Device Configuration settings. The Default FCFG bootloader settings are in the TRM : So likely your hardware has DIO21 (pinTriggerDIO) pulled to ground (pinTriggerLevel). To resolve this, you can disable the Bootloader in SysConfig (&amp;quot;Any bootloader forbidden&amp;quot;), use a custom CCFG settings (&amp;quot;Default FCFG bootloader, with CCFG settings&amp;quot;), or move your hardware away from using DIO21 entirely. Please let me know if this resolves your issue. Regards, Ryan</description></item><item><title>Forum Post: CC2340R5: Custom Board Boot Issue: Program only runs after Debug Restart, not on Power-On Reset</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643401/cc2340r5-custom-board-boot-issue-program-only-runs-after-debug-restart-not-on-power-on-reset</link><pubDate>Thu, 07 May 2026 09:30:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:7cca8607-cc1e-4bc2-83ee-750f13a798b8</guid><dc:creator>bai zhang</dc:creator><description>Part Number: CC2340R5 Other Parts Discussed in Thread: SYSCONFIG Body: Dear TI Support Team, I am working on a custom board using CC2340R52E0RGER and Code Composer Studio. Issue Description: My program does not execute when I simply power up the board (Power-On Reset). However, if I connect the debugger (e.g., XDS110), enter the Debug session, and click the &amp;quot;Restart&amp;quot; button within the Debug view, the program runs perfectly as expected. My Question: What is the fundamental difference between a Power-On Reset (POR) and the &amp;quot;Restart&amp;quot; command issued by the CCS debugger? Specifically, why would the debugger&amp;#39;s Restart cause the program to boot correctly, while a standard hardware power cycle does not? Relevant Context: MCU: CC2340R5 Debugger: XDS1110 CCS Version: 20.1.0.6 Custom Board: Four-layer PCB. Could this be related to the Boot Mode pins (e.g., GPIO pins for boot mode selection) on my schematic? Is it possible that debugger&amp;#39;s Restart bypasses the initial Boot ROM check, while the POR is getting stuck at a wrong boot mode (e.g., Wait Mode or SCI Boot)? Thank you for your help.</description><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/Datacom%2bmodule">Datacom module</category><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/CC2340R5">CC2340R5</category><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/SYSCONFIG">SYSCONFIG</category></item><item><title>Forum Post: RE: CC2340R5: I2C not detecting devices in SimpleLink Zephyr (CC2340R5), but works in LPF3 SDK and upstream Zephyr</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1641108/cc2340r5-i2c-not-detecting-devices-in-simplelink-zephyr-cc2340r5-but-works-in-lpf3-sdk-and-upstream-zephyr/6336106</link><pubDate>Thu, 07 May 2026 09:19:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:55b9a5a1-dabc-4ca8-b9a4-c66bc3e4095c</guid><dc:creator>Nafih Ahammed</dc:creator><description>Hi, Apologies for the delayed response. I was tied up with a few other high-priority tasks over the past week. I was able to resolve the issue on my side. The I&amp;#178;C bus started working correctly after: Explicitly configuring the controller usingi2c_configure(i2c_dev, I2C_MODE_CONTROLLER | I2C_SPEED_SET(I2C_SPEED_STANDARD)); Switching from i2c_transfer() to i2c_read() for the scanner logic. With these changes, both devices are now detected correctly and proper bus activity is observed. I had one follow-up question: is there a known reason why i2c_transfer() fails in this setup while i2c_read() works as expected? It would be helpful to understand if this is a limitation, configuration dependency, or something specific to the current driver implementation. Thanks for your support.</description></item><item><title>Forum Post: CC2652P: Watchdog running speed: Dependent on system power modes?</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643365/cc2652p-watchdog-running-speed-dependent-on-system-power-modes</link><pubDate>Thu, 07 May 2026 08:42:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:6faf8c57-2358-4cd9-bd66-6fbd7ae7978d</guid><dc:creator>Raphael Fischer</dc:creator><description>Part Number: CC2652P Other Parts Discussed in Thread: SYSCONFIG I have a problem with the watchdog: It seems to count much too slow! I made a little test application where I printed the watchdog value every second. The decrease was mostly around 200&amp;#39;000 per second, even though it is supposed to run at 1.5MHz. The decrease per second was also very variable with a spike up to 1&amp;#39;000&amp;#39;000 per second. This https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1128485/launchxl-cc1352r1-the-clock-source-of-the-watchdog-timer/4186750?tisearch=e2e-sitesearch&amp;amp;keymatch=watchdog%252525252525252520counting%252525252525252520speed#, and the TI reference manual are a bit confusing to me: They say that the watchdog is running at a constant speed with a prescaler of 32 (=1.5MHz) but also there are the INFRCLKDIVR, INFRCLKDIVS and INFRCLKDIVDS registers which explicitly state that they influence the infrastructure clock depending on the sleep mode. Additionally, in standby mode, the watchdog can&amp;#39;t be running because the fastest clock that is turned on is the 32kHz clock, right? I suppose that in our BLE application, the TI-RTOS is putting the system into standby mode a lot which is the reason why the watchdog is so slow. We would like the watchdog to fire at 3 minutes. How should we do this?</description><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/CC2652P">CC2652P</category><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/SYSCONFIG">SYSCONFIG</category><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/Test%2b_2600_amp_3B00_%2bMeasurement">Test &amp;amp; Measurement</category></item><item><title>Forum Post: RE: CC2745R10-Q1: Is there a way to set the transmission output level for each channel?</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643226/cc2745r10-q1-is-there-a-way-to-set-the-transmission-output-level-for-each-channel/6335654</link><pubDate>Thu, 07 May 2026 02:41:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:734ffcb5-07de-4a6d-9829-c36a8afb34d1</guid><dc:creator>Evan W</dc:creator><description>Hi Yasukane-san, This capability is not available. What would be the purpose out of curiousity?</description></item><item><title>Forum Post: RE: CC2340R5-Q1: Updating Notification Data</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1633438/cc2340r5-q1-updating-notification-data/6335604</link><pubDate>Thu, 07 May 2026 01:55:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:90de1601-ec8b-4113-987a-283d4ad79d26</guid><dc:creator>hrkunied</dc:creator><description>Hi Barbara, Thank you very much for your reply. Would it be possible to provide more specific guidance—for example, with code snippets? As our intended behavior may not have been fully conveyed, we have illustrated the desired operation in the diagram below. Thank you in advance for your assistance.</description></item><item><title>Forum Post: RE: CC2745R10-Q1: Connect monitor sync data and cfg</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1641771/cc2745r10-q1-connect-monitor-sync-data-and-cfg/6335585</link><pubDate>Thu, 07 May 2026 01:33:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:3c9c5030-4d63-42c6-a1c9-d24810869409</guid><dc:creator>snail leo</dc:creator><description>Is there a sequential timing requirement for using this interface（ HCI_EXT_SetLocalSupportedFeaturesCmd（） ）? Also, does this interface need to be configured every time the chip starts up?</description></item><item><title>Forum Post: CC2745R10-Q1: Is there a way to set the transmission output level for each channel?</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643226/cc2745r10-q1-is-there-a-way-to-set-the-transmission-output-level-for-each-channel</link><pubDate>Thu, 07 May 2026 00:28:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:9ef45f81-254b-4d6a-b369-5636a024c58f</guid><dc:creator>Yasukane Yamanaka</dc:creator><description>Part Number: CC2745R10-Q1 Is there a way to set the transmit power level for each channel used in a BLE connection? For example: 0 dBm for Channel 0, 2 dBm for Channel 2, and so on.</description><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/CC2745R10_2D00_Q1">CC2745R10-Q1</category></item><item><title>Forum Post: CC2340R5-Q1: Scanning with empty whitelist</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643145/cc2340r5-q1-scanning-with-empty-whitelist</link><pubDate>Wed, 06 May 2026 15:36:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:36b31098-8a8d-4629-87dd-30400a7c39fe</guid><dc:creator>Rahul Chowdary Pinnaka</dc:creator><description>Part Number: CC2340R5-Q1 Hi Team, I want to understand the behaviour of the BLE stack in case if we launch scanning with whiltelsit policy while whitelist being empty. How would the stack behave in this particulor scenario ? Would it behave like normal scanning since whiltelist is empty &amp;amp; forward all advertisement in the adv report to the application ? Would it discard all advertisemtns since we opted for scannign with whitelist policy with whitelist being empty ? Thanks. Regards Rahul</description><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/CC2340R5_2D00_Q1">CC2340R5-Q1</category></item><item><title>Forum Post: RE: CC2340R5-Q1: Updating Notification Data</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1633438/cc2340r5-q1-updating-notification-data/6334837</link><pubDate>Wed, 06 May 2026 14:47:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:123270d1-2afd-4306-8baa-4ad2177d1b7e</guid><dc:creator>Barbara Wu</dc:creator><description>Hi Hiroki-san, My idea is application layer holds the previous data which was sent successfully, and monitor the feedback value of GATTServApp_ProcessCharCfg when sending new data. If the feedback is success, then update the pervious data with the just sent one. So when application layer want to send the &amp;quot;new data&amp;quot; it can compare the &amp;quot;old data&amp;quot; with current one and see if it is the same or not. Best Regards, Barbara</description></item><item><title>Forum Post: CC2652P: What is SDAA for? Can we use it to optimize our connection?</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1643007/cc2652p-what-is-sdaa-for-can-we-use-it-to-optimize-our-connection</link><pubDate>Wed, 06 May 2026 10:35:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:118efce6-d9b1-4592-8aed-e908bdeafc6d</guid><dc:creator>Raphael Fischer</dc:creator><description>Part Number: CC2652P Other Parts Discussed in Thread: SYSCONFIG Dear TI team, We are working on making a BLE link as robust as possible over several dozens of meters in a challenging RF environment. We are already using the coded-8 125kbps mode. Now we noticed, that in ble_user_config.h which is generated from SysConfig, there is a long section about SDAA which lets you set thresholds for RSSI values and samples etc. But there is nothing to be found about that in sysconfig. Also nothing online... Can you please tell us what this is about and if this is a tool that can maybe help us to tune some thresholds to our environement? Thank you for your help!</description><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/CC2652P">CC2652P</category><category domain="https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/tags/SYSCONFIG">SYSCONFIG</category></item><item><title>Forum Post: RE: CC2340R5: MTU and PDU size issues with Latest F3 Stack</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1616441/cc2340r5-mtu-and-pdu-size-issues-with-latest-f3-stack/6334153</link><pubDate>Wed, 06 May 2026 06:22:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:91f8f200-5678-40f8-a4a2-0162c9abd5be</guid><dc:creator>Lea</dc:creator><description>Hi ! I&amp;#39;m in travel right now, I&amp;#39;m giving you a short answer because I don&amp;#39;t have much time, I&amp;#39;ll go more in depth next week sorry for that. The 241 bytes central is because I sent a 241 bytes long packet, it was just a long gibberish string and I didnt check if it was longer than 255. I could have sent something longer, it was just to prove that we can send more than 23 bytes in this version. I am definitely testing this with a dev board, since its the only thing I have in the office anyway lol. Do you see the DLU packet after the MTU update in a sniffer ? That&amp;#39;s the key part that tells you if this works or not. Kind regards, Lea</description></item><item><title>Forum Post: RE: CC2745R10-Q1: "Power Control" in sysconfig</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1640054/cc2745r10-q1-power-control-in-sysconfig/6333848</link><pubDate>Wed, 06 May 2026 01:42:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:8e03cc32-0d61-458a-90bc-45c14a14b84e</guid><dc:creator>Yasukane Yamanaka</dc:creator><description>Hello Barbara, I referred to the API documentation regarding the following HCI commands described in the “Power Control Feature” section of the user guide (User Guide: Developing with the SimpleLink Low Power F3 Software Development Kit &amp;gt;&amp;gt; Development Resources &amp;gt;&amp;gt; Adjusting CC23xx or CC27xx txPower). - HCI_LE_EnhancedReadTransmitPowerLevelCmd ( uint16_t connHandle, uint8_t txPhy ) - HCI_LE_ReadRemoteTransmitPowerLevelCmd ( uint16_t connHandle, uint8_t txPhy ) - HCI_LE_SetTransmitPowerReportingEnableCmd ( uint16_t connHandle, uint8_t localEnable, uint8_t remoteEnable ) - HCI_EXT_SendPowerControlRequestCmd ( uint16_t connHandle, uint8_t txPhy, uint8_t deltaPowerDb, uint8_t aprEnable ) However, as shown in the figure below, there are no detailed descriptions provided. Is there any documentation available that provides more detailed information on these commands? Best regards</description></item><item><title>Forum Post: RE: CC2340R5-Q1: Updating Notification Data</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1633438/cc2340r5-q1-updating-notification-data/6333748</link><pubDate>Tue, 05 May 2026 22:20:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:4559f8c6-b935-42f3-9a26-fc6a87c81eeb</guid><dc:creator>hrkunied</dc:creator><description>Hi Barbara, Thank you for your reply. We also agree that using GATTServApp_ProcessCharCfg is the correct approach. Could you please explain how the application layer should handle the data change, as you mentioned &amp;quot;Application layer need to handle the data change&amp;quot;? Thank you for your help.</description></item><item><title>Forum Post: RE: CC2745R10-Q1: Connect monitor sync data and cfg</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1641771/cc2745r10-q1-connect-monitor-sync-data-and-cfg/6333651</link><pubDate>Tue, 05 May 2026 20:22:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:d1f9edcb-63f2-429b-ac65-8add98dfedd5</guid><dc:creator>Isaac Larson</dc:creator><description>Hello, 1. The initiating PHY can be changed within Sysconfig in BLE -&amp;gt; Central Configuration -&amp;gt; Initiating PHY. To change the PHY during the connection, you will need to use HCI_LE_SetDefaultPHYCmd() or BLEAppUtil_setConnPHY() found within bleapputil_api.h. The CSA is more complex to alter. The specification states, &amp;quot;If the initiator sent a CONNECT_IND PDU in response to an ADV_IND or ADV_DIRECT_IND PDU and either or both devices’ PDU had the ChSel field set to 0, then Channel Selection Algorithm #1 (see Section 4.5.8.2) shall be used on the connection. Otherwise, Channel Selection Algorithm #2 (see Section 4.5.8.3) shall be used&amp;quot; (Vol 6, Part B, Section 4.5). Thus, we can conclude that the feature set for one of the devices needs to be changed to 0 for CSA to enable CSA #1. For this, the function HCI_EXT_SetLocalSupportedFeaturesCmd() should be used to set the CSA type. This is located within the first byte of the feature set pointer. You can find this in ll_common.h. 2. The channel map, determined by the CSA, is sent from the CMS to the CMR when a connection parameter update occurs. Additionally, the channel map may be updated, which will also send data from the CMS to the CMR. for the second part of this question, it is the same as what I just answered. The channel map will be known by the CMR if the CMS is coordinating the connection information correctly. Thanks, Isaac</description></item><item><title>Forum Post: RE: CC2340R2: Low Power Wireless communication</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1642662/cc2340r2-low-power-wireless-communication/6333541</link><pubDate>Tue, 05 May 2026 18:30:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:e64f9fec-ef94-4594-aa67-abcb90ce0815</guid><dc:creator>Alex Fager</dc:creator><description>Hello Drake Burtrum, If you need to connect to a desktop wirelessly (not via UART) then you would need to peruse a BLE solution. We do have quite a few useful getting started guides and examples in the SDK. SimpleLink Low Power F3 Environment Setup Guide SimpleLink basic_ble example As for device you may be able to have the sensors be CC2340R52 but the receiver would likely need to be CC2340R53 because it would need to store connection information so it would need more space for the NVS region. If the sensors communicate with each other then all devices would likely need to be CC2340R53. [quote userid=&amp;quot;648206&amp;quot; url=&amp;quot;~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1642662/cc2340r2-low-power-wireless-communication/6333530&amp;quot;]The devices will be placed close together. Around 6&amp;quot; apart if I had to guess. I&amp;#39;ve heard that radio signals can saturate when placing multiple transmitters in close proximity. Each device will need an address so that the receiver can identify which transmitter it came from. We can give each device a time slot to communicate and receive data with time to process. This will be a high-speed environment. Ideally, the whole communication process would take less than a second per signal transmission. [/quote] I have placed two CC2340R5 launchpads 1 inch from each other (TX/RX) and they were ok, the BLE stack should handle the address, timeslot and so on. Thanks, Alex F</description></item><item><title>Forum Post: RE: CC2340R2: Low Power Wireless communication</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1642662/cc2340r2-low-power-wireless-communication/6333530</link><pubDate>Tue, 05 May 2026 18:22:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:94f3ab11-3ba5-4cb8-94bd-10264e8a40cc</guid><dc:creator>Drake Burtrum</dc:creator><description>The device will most likely need to connect to a desktop. We will probably want a high data rate. 30 meters should be around the upper limit for range. This will be used in a factory setting. Obstructions can include walls, windows, and machines. The devices will be placed close together. Around 6&amp;quot; apart if I had to guess. I&amp;#39;ve heard that radio signals can saturate when placing multiple transmitters in close proximity. Each device will need an address so that the receiver can identify which transmitter it came from. We can give each device a time slot to communicate and receive data with time to process. This will be a high-speed environment. Ideally, the whole communication process would take less than a second per signal transmission.</description></item><item><title>Forum Post: RE: CC2340R2: Low Power Wireless communication</title><link>https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1642662/cc2340r2-low-power-wireless-communication/6333515</link><pubDate>Tue, 05 May 2026 18:05:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:5bfd48ba-ddd0-4738-912e-4553e8cba95b</guid><dc:creator>Alex Fager</dc:creator><description>Hello Drake Burtrum, There are a few paths here that we could take. First I want to ask if you ever plan on needing your device connect to a phone or laptop, if this is the case then you would need to peruse a Bluetooth application. If not using Bluetooth you can easily use our proprietary rf (proprf) PHYs like the GFSK or MSK PHYs in SmartRF Studio 8. Next what is the data rate? If you need a high data rate then 2.4 GHz would be a good option on the other hand if the data rate is slow you could switch to sub-1 GHz. For range sub-1 GHz is the best but if you are around 30 meters or so 2.4 GHz should be reliable (2.4 GHz can still go higher than 30 meters). [quote userid=&amp;quot;648206&amp;quot; url=&amp;quot;~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1642662/cc2340r2-low-power-wireless-communication&amp;quot;]multiple obstructions. [/quote] Can you describe these obstructions? I have tested the CC2340R5 device in office with ~8 cubicles in the way non line of sight at 30 meters while still being able to receive data. As for signal saturation I don&amp;#39;t know exactly what you are doing but if you are doing something like each device has an address, each device is given a time slot to communicate and the receive device can process the data in the windows between the time slots you should be ok; but details are important here to make a definitive conclusion. Thanks, Alex F</description></item></channel></rss>