https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1691062/tps62a02a-schematic-review/6515658Tue, 20 Oct 2026 10:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:56803544-dfe8-44fa-9f5d-c8990bf2e887Josef MarsmannHi William, I have reviewed the schematic and have some commends: In the thread you mentioned TPS62A02A (FPWM) but the schematic shows TPSA02DRLR(PFM/PWM). What is correct? This device in general is not designed for remote sensing so, the customer has to check the stability on their board. Everything else looks fine to me. Best regards, Sepphttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1691062/tps62a02a-schematic-reviewTue, 20 Oct 2026 09:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9360ec68-5349-48c0-942b-a9f5d2452226William Lai(CFAE)Part Number: TPS62A02A Hi Team, Could you please help to review the schematic (U7606,U7605,U7706,U7707,U7805)? I have attached the corresponding files for your reference. Covey_TI_0921 (003).pdf Thanks. Best Regards, William LaiPC &amp; NotebooksTPS62A02Ahttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1676697/cc3220s-launchxl-cc3220s-launchxl-cc3220s-sl_af_rf-sl_sock_raw-millisecond-rx-indication-latency-under-busy-rf-conditions/6514618Mon, 19 Oct 2026 14:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f2778e63-46d5-4997-9e69-9fdb896cab75Josh PrushingHi Ashot, Apologies for the delay in response, I have been OoO. While I am sad to hear that you have decided to move away from the CC3220S for this project, I&#39;m happy to continue to provide any information I can. [quote userid=&quot;580659&quot; url=&quot;~/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1676697/cc3220s-launchxl-cc3220s-launchxl-cc3220s-sl_af_rf-sl_sock_raw-millisecond-rx-indication-latency-under-busy-rf-conditions/6503029&quot;] If possible, I would appreciate one final clarification: does the same 3-frame / 1.2-ms pacing mechanism, and the approximately 2-ms worst-case estimate, also apply to RX indications for SL_AF_RF / SL_SOCK_RAW ? [/quote] It seems like the RX path is very similar, but has a separate mechanism for high priority frames to make them fire immediately. The lower priority frames will still have the 1.2 mSec timeout, but the number of frames threshold is set to 0, which means they should be fired immediately. Please let me know if you have any additional questions on the CC3220S. I will share your feedback on the limitations of CC3220S for your project with the team in order to see if there is anything we can work towards implementing in the future to cover this use case. Best Regards, Josh Prushinghttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688789/cc2662r-q1-cc2662r-q1-wbmsctrl_bqedgeframersp-field-sources-and-v-i-sync-statistics/6509872Wed, 14 Oct 2026 01:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:01cb4fe4-1d50-48ff-9ffc-6670bd8aad19Chad OuHi Barbara, Thank you for the clarification and the information. We will review the API documentation and apply for the latest SDK version 3.20.02.05. Best regards, Chadhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688789/cc2662r-q1-cc2662r-q1-wbmsctrl_bqedgeframersp-field-sources-and-v-i-sync-statistics/6509254Tue, 13 Oct 2026 15:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:72f912d2-6002-4351-aed2-4c9ed406115cBarbara WuHi Chad, For Edge, the statistic command is not used. Instead, each edge response will have stats which contains the numbers you need. Please check the API doc: TI Wireless Battery Management System (WBMS) Protocol: (0x0E) WBMS_CMD_WD_BQ_EDGE_RSP. (simplelink_wbms_sdk_3_20_02_05/docs/wbms/doxygen/html/group__WD__BQ__EDGE__RSP.html) I noticed that you are not on the latest release. Please do move to 3.20.02.05. Best Regards, Barbarahttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688460/launchxl-f28p65x-need-contact-person/6508100Mon, 12 Oct 2026 17:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f5daca78-de19-41ef-8f26-8f87298982bfPeter LuongHi Jay, Do you have a sales engineer assigned to your myTI account? What product lines are you specifically targeting? Regards, Peterhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688789/cc2662r-q1-cc2662r-q1-wbmsctrl_bqedgeframersp-field-sources-and-v-i-sync-statisticsMon, 12 Oct 2026 11:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:95326dfd-d63f-4707-8fb4-a507495ad931Chad OuPart Number: CC2662R-Q1 Other Parts Discussed in Thread: TIDA-010976 , Hi TI team, We are using CC2662R-Q1 with SimpleLink WBMS SDK 3.20.00.07 and are aligning our test method with the PS and PDR results in the TIDA-010976 design guide. The V-I Sync documentation describes numTx , numTxAttempts , numRx , and numRetries . However, the corresponding members in WBMSCtrl_bqEdgeFrameRsp_t are commented out in the SDK header, and we cannot find a working SDK example that obtains or uses these values. Could you please clarify: Is numTx a WD-side counter for unique WD-to-WM packets, excluding retries? Or is it maintained by the WM from received packets? Is numRx maintained by the WM as the number of successfully received WD packets? If so, is it deduplicated from retransmissions? Does numTxAttempts include actual automatic MAC-layer RF retransmission attempts, including the initial transmission? If yes, which supported SDK API, callback, MAC statistic, or BQ Edge frame field provides the actual numTxAttempts and numRetries values to an application? Is WBMSCtrl_bqEdgeFrameRsp_t supported only for BQ Edge / V-I Sync traffic? Is there a supported example showing how to obtain these counters? We need the authoritative counter source and update method in order to calculate PDR and PS on the same basis as TIDA-010976. Thanks.TIDA-010976CC2662R-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688460/launchxl-f28p65x-need-contact-person/6507211Sun, 11 Oct 2026 12:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3d601216-1a7b-4248-a8a0-ec8dcc6fa84fStevan DuraskovicHi, I assigned thread to relevant expert please give some time for expert to respond back.https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673024/tms3705-tms3705-and-tms37145---communication-error/6506869Fri, 09 Oct 2026 20:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:65c08c65-99e2-406e-951a-744d59a49795Hideraldo De FilippoHello Isaac, Thank you in advance to you and your team for all the help and support you have been providing us. Regarding your questions: I extracted the SENSE and SFB signals again to confirm the signals that I previously provided. I am attaching the updated plots for your analysis. Regarding the UCC27424 driver, I am using it in both tests. In the successful reading configuration, the UCC27424 is connected directly to the LC circuit. In the unsuccessful reading configuration, the UCC27424 drives a full bridge, which is then connected to the LC circuit. The problem occurs specifically when this full bridge is introduced into the circuit. In both configurations, the transmission signal appears to be correct. However, when the full bridge is used, I am unable to obtain a valid signal on the receive side. The reason for using the full bridge is that it allows us to achieve significantly higher power in the transmission circuit. With the full bridge, we can reach approximately 630 V on the antenna. This higher transmission voltage is important for achieving the required FDX reading distance. For clarity: Successful reading: UCC27424 connected directly to the LC circuit. Unsuccessful reading: UCC27424 connected to the full bridge, with the full bridge connected to the LC circuit. Thank you again for your support. I look forward to your team&#39;s feedback on the waveforms. Best regards, Hideraldohttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688460/launchxl-f28p65x-need-contact-personFri, 09 Oct 2026 19:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5581f447-5e80-4435-9336-5cb0de10fafeJay SkwarloPart Number: LAUNCHXL-F28P65X We would like to speak with someone in the Irvine office that can help us determine which products best fit our needs.LAUNCHXL-F28P65Xhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688323/cc2662r-q1-is-wbms-officially-supported-on-the-cc2642r/6506462Fri, 09 Oct 2026 13:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:77215a0c-1a9e-404b-bd55-f0c93c0ad1bfEvan WHi there, No, WBMS is not supported on CC2642. First, the CC2642 is not a functional safety device - where as the CC2662 is a functional safety quality managed device and comes with the proper paperwork, DFMEA, etc that can enable functional safety systems (of which WBMS is one). Second, the license agreement for the WBMS SDK is only permitted to run on on specific devices - of which the CC2662 is the primary and CC2642 is not. To quote the License Agreement from the SDK which you have accepted by downloading: Important Note: The below licenses grant limited rights to use the Licensed Materials solely and exclusively with the CC2662R-Q1 TI device family with the orderable part number (OPN) CC2662R1xx or XCC2662R1xx (&quot;TI Devices&quot;).https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1688323/cc2662r-q1-is-wbms-officially-supported-on-the-cc2642rFri, 09 Oct 2026 10:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eff249f2-e526-4a0f-831f-ad6c6f39fb4fChad OuPart Number: CC2662R-Q1 Other Parts Discussed in Thread: CC2642R , A few years ago, TI stated that the CC2642R did not support WBMS.( CC2662R-Q1: CC26x2 Differences - Other wireless technologies forum - Other wireless - TI E2E support forums ) However, I recently tested the CC2642R using simplelink_wbms_sdk_3_20_00_07 . The WM and WD examples run, and their basic functions appear to work normally. Does this mean the CC2642R is now officially supported for WBMS? If not, could you clarify the difference between my observed results and TI’s official support status, including any known limitations?CC2642RCC2662R-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1686946/tps25981-please-provide-tps25981-certificate-report/6505684Thu, 08 Oct 2026 20:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ffd282aa-6f0b-4e6e-9f6f-eaeb2b59e00cMani RayHello Hung, Please email me, I will send the certificate. m-ray@ti.com Best Regards, Mani.https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1687986/cc2651r3-low-power-consumption-on-cc2651r3/6505624Thu, 08 Oct 2026 18:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:613b66b4-6c39-4c8b-8812-7abf374d9e02Alex FagerHello Reshmi senan, I used the CC2652R7 device for the following test; I started with the gpioshutdown example: I removed every jumper except for the 3.3V, GND, and red LED to produce the below result: Then I removed the red LED which means 3.3V and GND are the only jumpers present (should be standby): For the above I was able to reach close to the standby mode (0.8 uA). [quote userid=&quot;579489&quot; url=&quot;~/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1687986/cc2651r3-low-power-consumption-on-cc2651r3&quot;]Could you please help me troubleshoot this and guide me on how to achieve the target low-power?[/quote] Start with what the giposhutdown does, then remove all jumpers except the ones needed for your test (3.3V, GND) and if needed disconnect and reconnect the power USB as sometimes it gets into a state where it measures the wrong values. Thansk, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673024/tms3705-tms3705-and-tms37145---communication-error/6505608Thu, 08 Oct 2026 18:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1907caec-9efa-4058-b44d-ebaf7ce91c45Isaac LarsonHello Hideraldo, I apologize for the delay. I am working with the team to look into the plots you have provided. The first thing that really jumps out to me is the SCIO line on the second plots (first image) you provided. The data on the SCIO line from the unsuccessful attempt looks off. Additionally, it almost seems like the SFB and Sense pins are flip flopped between the successful vs the unsuccessful test. The start byte can be either 0x81 or 0x01. Have you tried using the UCC27424 as a driver or are you using your own circuit? I am looking into this further. Thank you for your patience. Thanks, Isaachttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1687785/cc2662r-q1-cc2662r-q1-condensation-water-protectioncoating-for-rf-trace-and-antenna/6505291Thu, 08 Oct 2026 14:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4d6efc00-d2c9-4137-bb0d-6c602aee68d4Evan WHi Aingeru, In general, we have not done any internal studies on reliability with our EVMs, but i would recommend that it&#39;s a good idea to avoid the antenna, at least if using a PCB antenna, as it may result in some detuning of the antenna itself which would then be tough to actually correct with tuning because of the conformal coating itself.https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1687986/cc2651r3-low-power-consumption-on-cc2651r3Thu, 08 Oct 2026 09:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f47babd1-05ae-4d5a-ab3f-a8d53776996fReshmi senanPart Number: CC2651R3 Other Parts Discussed in Thread: CC2652R7 I am developing a low-power application using the CC2651R3 microcontroller. My goal is to implement a routine where the device stays in a 30-second low-power sleep/standby mode, wakes up periodically to execute core tasks, and immediately returns to standby. Additionally, the system must remain responsive to external GPIO hardware interrupts to trigger immediate wake-ups. Currently, I am utilizing the TI Power Driver and have enabled the power policy using Power_enablePolicy(). However, I am only able to reduce the current draw down to 0.6 mA in this state. According to the datasheet, the CC2651R3 should achieve around 0.8 &#181;A in standby mode. Could you please help me troubleshoot this and guide me on how to achieve the target low-power?CC2652R7Wireless InfrastructureCC2651R3https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1687785/cc2662r-q1-cc2662r-q1-condensation-water-protectioncoating-for-rf-trace-and-antennaWed, 07 Oct 2026 23:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9dd5a237-a249-440b-baec-242b8202c852Aingeru Astigarraga LopezPart Number: CC2662R-Q1 Hi Team, My customer is using CC2662R-Q1 for a wBMS project and is wondering if we have any recommendations on which areas should be kept without conformal coating. They are also interested in knowing how much condensation or water droplets on the traces or antenna could affect the overall performance in case they do not use any coating. Could you please provide some overall guidelines on this? Regards, AingeruHybridelectric &amp; powertrain systemsCC2662R-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1676697/cc3220s-launchxl-cc3220s-launchxl-cc3220s-sl_af_rf-sl_sock_raw-millisecond-rx-indication-latency-under-busy-rf-conditions/6503029Tue, 06 Oct 2026 17:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c14691e0-500d-4e9c-be25-181f30c2f751Ashot AndrieievHi Josh, Thank you for the additional information, and especially for taking the time to discuss this internally with the team. The interrupt-pacing explanation is useful and helps explain part of the behavior we observed. Unfortunately, during this investigation we eventually made the decision to move away from the CC3220S for this particular project. The main reason was not the nominal throughput capability itself. In fact, one of our goals was to extract as much useful throughput as reasonably possible from the device using SL_AF_RF / SL_SOCK_RAW . The problem for our application was the amount of timing uncertainty and jitter in the host-visible radio events, particularly on the receive side. For our architecture, receive timing is not just a performance statistic. It is an important input to a deterministic bidirectional TDD scheduler. We could tolerate a known fixed latency, and even a relatively large fixed latency, but multi-millisecond variation that could not be bounded tightly enough made it very difficult to guarantee the TX/RX switching schedule. We instrumented the path down to the host NWP interrupt and found that most of the larger RX latency excursions occurred before the host IRQ, rather than in the application after the IRQ. We also found that application-visible RAW receive completion could occasionally be delayed by several milliseconds beyond the nominal behavior. So, although the CC3220S was quite attractive from the throughput and integration point of view, the timing behavior ultimately became the limiting factor for this project. I would have preferred to continue with it and push the RAW data path as far as possible, but we could not justify building a deterministic scheduler around a receive indication latency for which we could not establish a sufficiently tight upper bound. I am still interested in understanding the mechanism correctly, though. The explanation you provided seems to refer specifically to TX-complete interrupt pacing . If possible, I would appreciate one final clarification: does the same 3-frame / 1.2-ms pacing mechanism, and the approximately 2-ms worst-case estimate, also apply to RX indications for SL_AF_RF / SL_SOCK_RAW ? If RX has a different buffering/pacing path, or simply does not have a guaranteed host-delivery upper bound, that would also be a very useful conclusion for us and for documenting why we changed platforms. Thanks again for investigating this. Best regards, Ashothttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1686946/tps25981-please-provide-tps25981-certificate-reportMon, 05 Oct 2026 03:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:be83dd4d-ad21-447f-8eb9-5aa97f06b983Huang HanacoPart Number: TPS25981 We are using the TPS25981 component in our product that will require UL certification in the future. According to the datasheet, the component has obtained an IEC 62368-1 CB certificate, but I can&#39;t fine the certificate on TI website. Could you please assist us in providing this document? Thank you.TPS25981