https://e2e.ti.com/support/sensors-group/sensors/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694341/iwrl6432-iwrl6432---rtc-configuration-examplesSat, 31 Oct 2026 17:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:131a0dfb-fd99-4b59-8b3c-26b132360f12Nicolas KrausePart Number: IWRL6432 Hello, I&#39;m investigating using the RTC as a wake source for the IWRL6432 from it&#39;s low power modes. I&#39;ve looked at the power examples in the 05.05.04.02 SDK, but the documentation states &quot;Example doesn&#39;t support wakeup using UART and RTC. &quot; The sleep counter wakeup example is just a blocking semaphore with a timeout set to 50 seconds. There&#39;s some answers to questions on this forum from a number of years ago stating that there&#39;s an example in the drivers folder for the RTC, but I do not see the examples in the current version of the SDK. Is there a piece of documentation I&#39;ve missed or an example TI can point me to? Thank you in advance for your help! Nicolas KrauseIndustrial AutomationIWRL6432https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694338/mmwaveicboost-mmwaveicboost-iwr6843isk-works-standalone-but-not-on-mmwaveicboostSat, 31 Oct 2026 13:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fe239ba2-db37-43bf-91d7-252a7285c5c7Alexander KirfelPart Number: MMWAVEICBOOST Other Parts Discussed in Thread: IWR6843ISK Hello, I am having problems using an IWR6843ISK together with an MMWAVEICBOOST carrier board. Both boards were configured according to the TI documentation for the intended operating mode, including the required switch and SOP jumper settings. This setup had previously been working correctly. However, communication through the MMWAVEICBOOST recently stopped working without any changes to the hardware configuration and has consistently failed since then. The IWR6843ISK continues to work in standalone mode. Setup: IWR6843ISK MMWAVEICBOOST External power supply: SDI-18-5-U, 5 V Radar Toolbox 4.0 mmWave SDK 03.06.02.00-LTS OOB binary: radar_toolbox_4_00_00_05/source/ti/examples/Out_Of_Box_Demo/prebuilt_binaries/out_of_box_6843_isk.bin Radar configuration file: mmwave_sdk_03_06_02_00-LTS/packages/ti/demo/xwr68xx/mmw/profiles/profile_3d.cfg XDS110 firmware: 3.0.0.43 Ubuntu Linux Industrial Visualizer Test: I tried to bring up both boards together using the Industrial Visualizer. The Visualizer can open/connect to the serial ports, but when I click &quot;Start and Send Configuration&quot;, it fails with the following message: Ensure that the device is in the proper SOP mode after flashing the correct binary, and that the cfg you are sending is validThe radar also works with the Industrial Visualizer When the IWR6843ISK is used in its standalone configuration it starts up normally and the Industrial Visualizer displays radar targets. I investigated the issue further and found that communication with the IWR6843ISK through the MMWAVEICBOOST fails: Standalone CLI test: In standalone mode, the ISK exposes its UART through the onboard CP2105 as /dev/ttyUSB0 Opened /dev/ttyUSB0 directly at 115200 baud Sent a newline character (&quot;\n&quot;) to the CLI UART The radar immediately responded with the CLI prompt: &quot;\nmmwDemo:/&gt;&quot; Carrier CLI test: When mounted on the MMWAVEICBOOST, the radar&#39;s UART is exposed through the XDS110 as /dev/ttyACM0 Opened /dev/ttyACM0 directly at 115200 baud Sent the same newline character (&quot;\n&quot;) No response was received (0 bytes) The second XDS110 serial port was also tested and did not return a CLI response Additional observations: The hardware setup, switch configuration and LED states exactly match the reference setup shown in Figure 3-23 of the MMWAVEICBOOST and Antenna Module User&#39;s Guide (SWRU546E): https://www.ti.com/lit/ug/swru546e/swru546e.pdf The XDS110 enumerates correctly and both serial ports can be opened. Updating the XDS110 firmware to version 3.0.0.43 using CCSudio IDE did not change the behavior. Reflashing the prebuilt .bin on the radar (in standalone mode) did not change the behaviour. The issue is fully reproducible: standalone operation works, while operation through the MMWAVEICBOOST does not. To summarize, both boards appear to be working fine when used individually. The failure appears to be specific to the communication path through the MMWAVEICBOOST. I would appreciate any recommended troubleshooting steps or checks to determine whether this is a configuration issue or potentially a hardware problem. Thank you.IWR6843ISKMMWAVEICBOOSTTest &amp; Measurementhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694246/lmp91000-part-replacement/6526876Sat, 31 Oct 2026 10:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d401ca95-e10c-41cb-af06-cbaa345fc3b1fudong chenThe LMP91000SDX/NOPB is not difficult to source, but it is now obsolete; I recommend that you prepare to switch to a replacement part.https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694330/tmcs1108-tolerance-of-internal-resistanceSat, 31 Oct 2026 09:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d56b3113-47ec-4ec7-85a5-54c80ecbdab4NIKOLAOS ADAMOPOULOSPart Number: TMCS1108 Hello, I would like to use the TMCS1108A1BQDR to measure higher current than its capabilities. So I plan to bypass the sensor with either a sense resistor or with a copper polygon. I would like to know the internal resistance tolerances. Thank you, NickIndustrial AutomationTMCS1108https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1685782/iwrl1432boost-bsd-iwrl1432boost-bsd-error-mmwave-factory-calibration-failed-on-evk/6526869Sat, 31 Oct 2026 07:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4038532a-25fb-4b24-a089-7a071eea7cf8manikandan kHi Blake, Thank you for the guidance. We updated the switch configuration as requested: - S1.5 and S1.6 set to ON. - S1.1 set to OFF for flashing via UniFlash after power cycling. - S1.1 returned to ON after de-energizing the EVM. However, the error still occurs. Could you advise on the next steps or any additional diagnostics/logs we should collect to identify the issue? I have attached the relevant log files for your reference. e2e.ti.com/.../1207.Log.txt Best Regards, Manikandanhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694324/hdc3021-how-to-place-hdc3021-sensor-on-pcb-for-optimal-resultsSat, 31 Oct 2026 06:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1cdc4dab-4ca0-40d3-a285-77cc641de618Samrat TikonePart Number: HDC3021 Hello Team, We are developing a humidity sensor using TI HDC3021 and we request technical recommendations regarding the optimal sensor placement on PCB inside enclosure to achieve the fastest possible humidity response while maintaining high measurement accuracy. Note: We are using HDC3021 breakout board by 7semi and not the bare sensor,please find its image attached.HDC3021https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694323/tmp117-how-should-be-the-sensor-positioned-on-pcb-for-optimal-measurement-of-temperatureSat, 31 Oct 2026 06:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b4060f61-9a43-44d0-85b2-ed19f0db6cdcSamrat TikonePart Number: TMP117 Hello Team, We are developing a temperature sensor using TI TMP117 and we request technical recommendations regarding the optimal sensor placement on PCB inside enclosure to achieve the fastest possible ambient temperature response while maintaining high measurement accuracy. Note: We are using TMP117 breakout board by 7semi and not the bare sensor,please find its image attached.TMP117https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694317/tida-01624-need-source-and-object-codeSat, 31 Oct 2026 02:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8177aff7-7c6d-4a22-8e23-8314072f1d9fJohn JurgensmeierPart Number: TIDA-01624 Is the object code to program the TIDA-01624 available.TIDA-01624Wearables (non-medical)https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694314/tmp112-what-is-differences/6526810Fri, 30 Oct 2026 23:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d919e58e-437a-42ba-bf55-a212e128f6f9HarryGHello Felipe, TMP112AIDRL R is a larger 4000 qty reel orderable while TMP112AIDRL T represents the smaller 250qty reel. There is no functional difference between these two orderables aside from the reel size, however just FYI, the TMP112AIDRL T is no longer available . Regards, Harryhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694314/tmp112-what-is-differencesFri, 30 Oct 2026 22:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f5944a37-1cb2-40bd-a631-0da4380b9b43Felipe SerranoPart Number: TMP112 Hello, could you help me understand the difference between the TMP112AIDRLR and TMP112AIDRLT devices?TMP112https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694154/awr2188-awr2188-spi-bus-multidrop-support-in-the-cascade-mode/6526793Fri, 30 Oct 2026 22:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5edabf77-7f94-4263-820f-91a4cf72d375Ahanaf AhmedHi Juha, Yes! CLK, MOSI, and MISO can be shared, provided each AWR2188 has its own chip select. Sharing the SPI bus with separate chip-select lines per device is explicitly stated to work 1 . What must stay per-device Signal Shared? Note MSS_McSPIA_CLK / MOSI / MISO Shared Standard multidrop MSS_McSPIA_CS0 Per device Required for device selection MSS_GPIO_0 (SPI_BUSY) Per device Handshake is per-transaction MSS_HOSTIRQ Per device Async events must be attributable A working two-device AWR2188 cascade has been implemented using a single SPI instance with separate CS, IRQ, and BUSY lines per device 2 . The pin set and the BUSY handshake sequence (wait for SPI_BUSY low → send CMD_HEADER → device drives SPI_BUSY high → send CMD_LONG_MSG → SPI_BUSY returns low) are defined per device 3 , which is why BUSY cannot be bussed. Cascade mode is orthogonal to the control interface Cascade vs. non-cascade is selected purely by the SOP3 pin, independent of which control interface you use 4 . So the EVM&#39;s separate SPI routing is a board-layout choice, not a cascade-mode requirement — the retrieved documentation states no cascade-specific prohibition on multidrop. Two things to watch in your design Frame sync must physically reach the slave device. In the referenced cascade design, missing frame-sync signaling not the SPI configuration was the root cause of absent slave monitor-done events 2 . Host SPI timing must meet spec. Transfers are two bytes at a time, big-endian, and CS may be raised after each byte or each two-byte transfer 5 . One reported failure was traced to an SS8 interval reduced from 40 ns to 20 ns 6 . AWR2188: Powering AWR IO with 1.8V, SPI boot question AWR2188: Cascading - no monitor done async event from slave device AWR2188 Application Note (SPRADT3), p.12 AWR2188EVM: Config control path via I2C AWR2188 Application Note (SPRADT3), p.13 AWR2188: SPI timing issuehttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1692968/awr2188-awr2188-vpp-input-voltage-level-input-tolerance/6526783Fri, 30 Oct 2026 22:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3a79e068-c795-4814-b375-c4c8a4ede835Ahanaf AhmedHi Juha, AWR2188 have multipel power rails: 1.2V Digital Core Rail: This serves as the primary digital core logic supply (the equivalent of a standard digital \(V_{DD}\)). On the evaluation board, this is driven by a dedicated buck regulator (such as the 1.8V Digital &amp; I/O Rail: Supplies power to the peripheral digital blocks, memory, and dual-voltage I/O pins. Dual 1.0V Analog &amp; RF Rails: The system requires two separate 1.0V rails to power different internal RF circuit sections (such as the VCO, LO distribution, and amplifiers). These must remain distinct to isolate high-frequency noise and maintain phase accuracy across cascaded systems The VPP_1P7 rail must be powered externally . You can: Tie to 1.8V (with caution): In many TI mmWave architectures, if you do not plan to perform production-line OTP memory calibration/burning in the field, the VPP pin can simply be tied to the main 1.8V digital I/O rail or grounded based on the final pin-out checklist in the AWR2188 Datasheet. Isolate for Production: If you do need factory OTP calibration, you must design an external 1.7V–1.8V supply circuit that can be gated (turned on/off) via a GPIO from your host processor or an external test fixture. The VPP_1P7 programming voltage pin must be powered by a digital rail , not an analog rail. Thanks, Ahanafhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694043/pga460-pga460/6526628Fri, 30 Oct 2026 19:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c56ee693-6cc5-42af-bd21-df0ecfdeddacEddie LaCostHello Jack, Register decode Register Value Meaning DEV_STAT1 0x18 Bit 4 = IOREG_UV, Bit 3 = AVDD_OV — both asserted 1 DEV_STAT0 0xE5 Device revision/option ID fields plus CMW_WU_ERR and THR_CRC_ERR 1 EE_CNTRL 0x20 Not decoded in the retrieved documentation — flagging as a gap Note: THR_CRC_ERR is asserted at power-up to indicate an uninitialized threshold map, so that bit alone is not evidence of damage 1 . 1. Is the chip broken? The register read alone does not establish that. A directly comparable case reported DEV_STAT1 = 0xE4 with regulator flags set, and the cause was reading regulator status too soon after power cycling rather than a damaged device; TI&#39;s guidance there was to wait at least 10 ms after power-up before communicating 2 . Status bits are cleared when read over the interface, and electrical diagnostics use a 25-&#181;s deglitch, so a single read captured during startup transients is not conclusive 1 . That said, your replacement test (new PGA460 works in the same board) does point toward the installed device, not the board design. 2. What to check as the cause Measure the rails at the pins against spec: AVDD (pin 16): 1.74–1.90 V nominal; OV threshold is 1.95–2.30 V 1 IOREG (pin 14): 3.3 V mode UV threshold 2.57–2.90 V; 5 V mode UV threshold 3.80–4.50 V 1 From your schematic, items to verify specifically: - DECPL (pin 13) — the core regulator decoupling connection is not clearly resolvable in the provided image. Confirm it is populated per the datasheet. - AVDD/IOREG decoupling — you have 100 nF on each (C3, C4). I do not have the datasheet-recommended values in the retrieved findings; confirm against the datasheet&#39;s application section. - Grounding — pins 1/4 route to system ground through the 0 Ω net-tie R89, while GNDP (pin 6) returns separately. Verify this does not create an offset at the regulator sense points under burst current. - Power sequencing — the TPS22810 load switch means VPWR ramps on enable, not at board power-up. Your firmware&#39;s 10 ms wait must be referenced to VPWR_RF rising, not to MCU boot 2 . Also confirm your read timing: DEV_STAT0/DEV_STAT1 should be read before a burst or after measurement results are retrieved, never during the active measurement window 3 . 3. Can it be salvaged? Try this sequence on the failing unit before scrapping it: Power-cycle VPWR_RF via the load switch, wait ≥10 ms, then read DEV_STAT0/DEV_STAT1 2 . Read a second time — status bits clear on read, so the second read shows persistent vs. transient faults 1 . If flags persist, issue the Reload EEPROM command. The PGA460 has no dedicated reset command, and TI recommends Reload EEPROM to reinitialize settings when abnormal status persists 4 . All device status error bits must read zero for normal operation; a set bit indicates either a fault or a corrupt register map 5 . If AVDD_OV/IOREG_UV still latch with measured rails in spec and after a Reload EEPROM, the internal regulators are compromised and the device is not recoverable.https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694036/tmp432-tmp432bdgs-olb-or-dsn-file-for-cis-symbol/6526595Fri, 30 Oct 2026 18:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7fb22362-f4dc-4f63-8b0e-5bd61cab5a9bHarryGHello Sean, If you&#39;re looking for a CAD symbol file for the TMP432, you can find it on the product page here: https://www.ti.com/product/TMP432#cad-cae-symbols When on the product page, scroll down and under the &quot;Design &amp; development&quot; section the CAD symbol will be under &quot;CAD symbols, footprints &amp; 3D models&quot;. Please let me know if you need additional assistance, Harryhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694246/lmp91000-part-replacement/6526588Fri, 30 Oct 2026 18:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:58eae1af-8886-4dd3-a5fe-356926e62416HarryGHello David, There shouldn&#39;t be any functional difference between the orderables. The SDE orderable represents the Small 250qty reel that is no longer made, so the only orderable remaining is the Large 4500qty reel. Hope this answers your question, Harryhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1693642/iwr6843isk-ground-connection-for-apll-and-synth-decoupling-capacitors/6526584Fri, 30 Oct 2026 18:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:75d9f10a-336e-4273-a8b7-ede7e394956eBlake KisshauerYuke-san, The original goal was to create a split ground to protect the XTAL from noise coupling. However, the ground cuts cause increased radiation by increasing the length of the ground return path. Our newer EVMs do not use ground cuts as shown in this EVM, bringing them into alignment with modern EMC design practices. Thanks! Blakehttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1694178/pga900-dac-gain-tolerance/6526533Fri, 30 Oct 2026 17:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7c13fffd-48ba-4890-8fee-4904d55e1244Eric.PreissHi Florian, The PGA900 DAC output amplifier four selectable gain settings are achieved through internal feedback resistors, with the 10 V/V setting corresponding to a specific feedback resistor value of 135 kΩ 2 . The PGA900 datasheet does not specify a tolerance for the DAC gain stages. It is standard practice to compensate for DAC gain, offset, and sensor-specific non-linearities during the device calibration process 3 . In typical applications, you would measure the actual output across your devices to calculate specific gain and offset coefficients 3 . These coefficients are then stored in the device memory to programmatically correct the output response to your target requirements. If you are observing a consistent 10.1 V/V across your hardware, this can be effectively normalized using the digital gain-correction registers during your end-of-line calibration. PGA900 Product Page PGA900 Design Guide: Configuring the PGA900 for Different Sensor Applications E2E Support Forum: Questions Regarding Calibration for the PGA900 Best, Erichttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1693928/awrl6888evm-access-denied-for-downloading-mmwave_l_sdk_06_01_03_04/6526524Fri, 30 Oct 2026 17:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:afa2eaa5-c3ea-4eba-bcd2-f17dbd17ca1aRyan Brown1Hi Eric, I&#39;m seeing this as well for the package downloaded from TIREx. I will alert the SDK R&amp;D Team, meanwhile I&#39;ve packaged the contents of the visualizer folder for your use. e2e.ti.com/.../visualizer.zip Regards, Ryanhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1693928/awrl6888evm-access-denied-for-downloading-mmwave_l_sdk_06_01_03_04/6526474Fri, 30 Oct 2026 16:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:83dced26-de60-46a5-b506-34880f39f42fEric SmithYes. It is empty.https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1687499/awr2188evm-dca2000evm-availability/6526466Fri, 30 Oct 2026 16:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:136960d4-2861-4eba-9beb-4a478b1c9aecLiam HeuserHi Bill, Just wanted to follow up on this to see if there are any updates on how I might be able to purchase the DCA2000EVM. Thanks, Liam