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/1641692/awr6843-people_tracking-demo/6367757Tue, 02 Jun 2026 17:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:adf139da-b3ac-4b48-8a75-ba317760072cPedrhom Nafisi1. Regarding the issue of not being able to represent the value with 2 bytes — are you aware that this problem exists? We have seen this on a small number of very sensitive configurations. As long as data type integrity is maintained, increasing it to 4 bytes should not be a problem if that is needed for your application 2. If I scale the SNR value myself, will it affect the subsequent data chain? It definitely will. For example at the CFAR and tracker level, if the SNR calculations are changed and these data processing blocks are not adjusted accordingly, the performance of CFAR&#39;s filtering and Tracker&#39;s clustering will be affected significantly since the filtering and clustering criteria does take SNR into consideration. Best Regards, Pedrhomhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1639466/iwrl6844evm-raw-data-capture-problem-at-25-msps-iwrl6844evm-dca1000evm/6367752Tue, 02 Jun 2026 16:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8cc9b2eb-638a-46ce-b4ee-86837b77ebb1Pedrhom NafisiHello Kazutoshi -san, Start time is the &quot;tx start time&quot;, and &quot;idle time&quot; is something different. tx_start_time_us can be set to 0. The idle time is necessary to allow hardware APLLs and oscillator to &quot;settle&quot; before chirp start. Best Regards, Pedrhomhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1650216/iwr6843isk-ods-unable-to-to-flash/6367749Tue, 02 Jun 2026 16:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b56b6c73-02f0-42a5-8548-e9a6d846ddaePedrhom NafisiHello Padraig, Can you try flashing the radar sensor directly rather than through the MMWAVEICBOOST? EVM Setup Operational Modes Best Regards, Pedrhomhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1644951/dca1000evm-radar-dca1000-evm/6367735Tue, 02 Jun 2026 16:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3807215a-a2d8-47ff-b6fe-f4c057dac7e9Pedrhom NafisiCan you confirm the hardware switch is in the right position for reading from EEPROM? Best Regards, Pedrhomhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651606/awrl1432boost-bsd-unable-to-run-demo-or-visualizer-with-awrl1432boost_bsd-boardTue, 02 Jun 2026 16:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:226da085-e2fa-46ab-912b-727b7590aa77Jade TellezPart Number: AWRL1432BOOST-BSD I cannot run the BSD visualizer provided in the radar toolbox(4_00_00_05-latest version I can see) as suggested in the EVM User Manual. I get an error &quot;Error in bsd_visualizer_1432.m at line 711&quot;. I connected to the board using PuTTY and get the following information: Platform: xWRL1432 RFS Firmware Version: 03.01.06.00 mmWave SDK Version: 05.03.00.02 Parking_Demo When running on the mmWave visualizer (5.5.4.1) it tells me to flash the latest demo. I successfully flashed mmwave_demo.release.appimage. I uploaded the Low Power Presence Detection config and the Presence and Motion &amp; Tracking tab it sent me to said disabled. In the command window, it indicated mpdBoundaryBox is not recognized as a CLI command. On the duplicate board I have of this type, I tried upload the presence and detection .appimage and got the mmwave visualizer to detect 1 frame and then stop and have another thread to troubleshoot that so I didn&#39;t want to go that route again with this. Please help!Advanced Driver Assistance Systems (ADAS)awrl1432boostAWRL1432BOOST-BSDhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651439/iwrl6844evm-xds-unrecognized/6367732Tue, 02 Jun 2026 16:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a13a3401-ee60-4e28-928e-b7c5319d544ePedrhom NafisiWas it working normally before? This issue may have been caused by ESD. These EVMs are pretty sensitive when used in non-ideal ESD conditions. Best Regards, Pedrhomhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1642921/iwrl6432aop-flashing-guide-for-iwrl6432aop---jtag/6367700Tue, 02 Jun 2026 16:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6cd79ab7-ebed-4638-89c4-81305c2c5df7Mihit SharmaHi Ankit, I&#39;d like to correct my previous statement - Flashing through JTAG is possible. Please refer to the JTAG Flasher User Guide available in the Radar Toolbox at: https://dev.ti.com/tirex/explore/node?isTheia=false&amp;node=A__AJ2W9ZB8KcnIQfyCeO-c2w__radar_toolbox__1AslXXD__LATEST . Regards, Mihit Sharmahttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651397/pga970-pga970-how-to-get-the-phase-information-with-related-registers/6367687Tue, 02 Jun 2026 16:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:42e5d4ae-45b3-4886-92a4-50d73e6073d0Maggie LeeHi Ozge, The secondary phase in PGA970 is calculated relative to the primary excitation signal, which operates from a look-up table. The DAC_SIN_NDS registers tell the demodulator the points in the excitation signal look-up table where you want to measure the phase of the demodulator output. Both DAC_SIN_NDS registers are for DEMOD1 and DEMOD2. You don&#39;t have to set the DAC_SIN_NDS registers to 0 and WAVEFORM_TABLE_LEN (which is equivalent to a quarter-wave of the excitation signal), but then the math to calculate the phase from the two measurement points will look different. As Scott describes, if you set the DAC_SIN_NDS registers to 0 and WAVEFORM_TABLE_LEN, you get the following outputs: DEMODx_PH1DATA = A*sin(0 + phase) DEMODx_PH2DATA = A*sin(pi/2 + phase) = A*cos(phase) Then, since tan(x) = sin(x) / cos(x), you can use the inverse tangent to find the phase: phase = tan^-1(DEMODx_PH1DATA / DEMODx_PH2DATA). So if you were to select a value other than WAVEFORM_TABLE_LEN for the second DAC_SIN_NDS register, then the trigonometry to find the phase would be a little more complicated. The DEMODx_PHxDATA registers will be updated as the demodulator updates. Thanks, Maggiehttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651305/tmp118-incorrect-read-of-nist-id-unique-id/6367659Tue, 02 Jun 2026 15:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:355add20-9854-4225-bbdb-6244a85fd6c9GageFHello Ben, Could you provide us with oscilloscope shots of everything that happens before and after the transactions? I&#39;m going to investigate this further and attempt to replicate it on my end. Gagehttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651579/awrl1432boost-bsd-xwral1432-sends-one-parsed-frame-onlyTue, 02 Jun 2026 15:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:50f1dc69-11ae-4e78-bcd0-42fb7d0da854Jade TellezPart Number: AWRL1432BOOST-BSD Other Parts Discussed in Thread: SYSCONFIG Using the AWRL1432BOOST-BSD, the BSD visualizer would not work. It produced an error &quot;unrecognized function or variable &#39;motionDetectorRun&#39;. Error in ==&gt; bsd_visualizer_1432.m at line 711.&quot; Next I tried various setup items in the SDK mmwave_demo browser instructions that took me through setting up CCS, python, SYSconfig, and making Make files which I was not able to do successfully and it was so complicated with trying to troubleshoot each step that didn&#39;t work as the instructions directed, that I can&#39;t outline the flashing the board went through. I also tried the &quot;Getting Started&quot; instructions in the EVM User Guide for the inductrial demo and BSD demo and neither worked. To get the board to work with the mmWave Radar Visualizer (5.5.4.1), I flashed the motion_and_presence_detection_demo.release.appimage with the config &quot;Low Power Presence Detection&quot;. Looking at the Presence Motion &amp; Tracking tab, the sensor sends one frame back with Presence Detecion: Enabled and Tracking: Disabled.Advanced Driver Assistance Systems (ADAS)AWRL1432BOOST-BSDSYSCONFIGhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1650376/iwr6843aopevm-uart-bandwidth-bottleneck-vs-frame-periodicity-in-3d-people-tracking-demo-large-tlv-payloads/6367627Tue, 02 Jun 2026 15:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0723363e-e4c3-45ec-8c8a-cd312619a6e8David CassityHi Muhammad, Depending on the features you want to prioritize, yes, you may have to reduce the frame rate. Best, Davidhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1649996/tdc1000-c2000evm-tdc1000-c2000evm-only-read-31us/6367530Tue, 02 Jun 2026 14:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:98c872e3-9ab8-46f9-bb7a-f634617d65c0Amanda RatliffHi Fernando, It looks like you are connecting the transducer to RTD2 when you should be connecting it to TX1 and RX2. I also do not see any oscilloscope connections. The connections should be the same as this screenshot on page 5 of the guide I shared: Using Ultrasonic Sensing to Monitor Fluid Level in Tanks Best, Amandahttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1649955/pga305-error-while-calibrating-pga305-evm-gui/6367500Tue, 02 Jun 2026 14:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d38f44d3-e325-4819-88fe-f0a85ca167b1Siddesh K SHi Maggie, I am sharing the captured data from our PGA305 using I2C communication. I have not been able to successfully calibrate it yet. Could you please verify the data and let me know how to resolve this issue? ref circuit with respespect to PGA305 pin no. If i enter same data in calculator (wich u shared ) error iscomming if i choose 3P1T it will give h0,g0,n0 remainin all we should keep zero only? and AFEDIAG_CFG AND AFEDIAG bit mask configuration is for what full detailed vale and explation of all EEPROM variables and value for shared data .for 0-4 bar with 4-20ma configuration. VBR+ and VBR- are connected to sensor input do we need any external power to sensor ?https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651509/iwr6243-question-about-power-up-3-3v-firstTue, 02 Jun 2026 14:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:357912a3-4fee-47e0-9ea2-6d25e2916beeChris MengPart Number: IWR6243 Hi, I found below errata in other mmwave device. Does it also apply for IWR6243? In 3.3V IO mode, back power is observed on the 1.8V rail from 3.3V rail Thanks, ChrisIWR6243https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1650815/iwrl6432wmod-iwrl6432wmod-tuning-for-stationary-human-tracking-at-8m-resolving-ghost-clusters/6367376Tue, 02 Jun 2026 12:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:85eb02bc-8c49-49a1-b3c0-a34ae1874fe2Peter BaderHi David, thanks for your reply. Currently we tested all uDFP setting combinations and the output is always suboptimal. It feels and looks like the whole radar signal processing implemented in the current fw version on the WMOD is ignoring human targets. Even with stationary object removal off we don&#39;t get consistent points for humans. We get an overwhelming amount of noisy, jumping points and some persisting clusters which are either strong reflections or walls or obstacles. This sensor is nearly capable of the same as the non WMOD as they are the same chip, but the radar to point cloud pipeline implemented by TI feels only a dirty draft. We would really like to know what is the expected lifecycle of this product and especially the firmware. Is it expected that TI improves settings, processing and output on the WMOD or opens up the option to change the low-level configuration registers of the HWA and CFAR/DOA DPUs manually? As it stands, the uDFP abstraction layer treats the radar pipeline like an &quot;all-or-nothing&quot; toggle switch. If we cannot isolate a stable human target even below 4m (not even talking about longer ranges) without blowing up the noise floor with environmental ghost clusters, we need to evaluate whether we can expect a firmware patch to expose these granular hooks, or if we must pivot our product design to an entirely different chip family like the IWR6843. Would be nice also to know what is the stand from TI, what is the target audience or application for this product if there is any or it is more of sandbox in its current state. We would highly appreciate some transparency regarding the development roadmap for the IWRL6432WMOD processing chain so we can make an informed decision for our product. Best, Peterhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1649996/tdc1000-c2000evm-tdc1000-c2000evm-only-read-31us/6367319Tue, 02 Jun 2026 12:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:774dd564-b9cb-4f5e-853c-43dc5fdae003Fernando MoraesHi Amanda, Follow the connections pictures: Thankshttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1647786/pga970-how-to-correctly-scale-and-interpret-demodx_data-with-verified-secondary-sine-waves/6367312Tue, 02 Jun 2026 11:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6fd8a317-8550-4edd-b55d-88192759afceTeodora GrujicicHi Maggie, Thank you very muchhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651450/tda4vm-q1-unable-to-find-download-vhwa_c_models-package-for-processor-sdk-rtos-j721e-11-02-00-06Tue, 02 Jun 2026 11:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:816b6aaa-cdb1-4b58-b07e-3e24fd90a582Sorathiya HarshilPart Number: TDA4VM-Q1 Hi TI Team, I am building Vision Apps and camera drivers for the simulation target using Processor SDK RTOS J721E version 11.02.00.06. During the build process, I encountered missing dependencies related to the following VHWA C model directories: - vhwa_c_models/dmpac/ - vhwa_c_models/vpac1/ It appears that the required `vhwa_c_models` package is not available in my SDK installation. Could you please advise: 1. Where can I download the correct `vhwa_c_models` package compatible with **ti-processor-sdk-rtos-j721e-evm-11_02_00_06**? 2. Is there a separate package, installer, or access request required for these models? 3. Are there any specific setup instructions for enabling Vision Apps simulation builds that depend on these VHWA C models? Any guidance or download link would be greatly appreciated. Thank you. Best regards, Harshil.Advanced Driver Assistance Systems (ADAS)TDA4VM-Q1https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1651439/iwrl6844evm-xds-unrecognizedTue, 02 Jun 2026 11:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6822f040-4530-4a5e-bdad-ea4fced15361Micha&#235;l Mar&#233;chalPart Number: IWRL6844EVM Other Parts Discussed in Thread: IWRL6844 I had a issue with the IWRL6844 today where the XDS port do not appear anymore on my devcice management. it is connected to a DCA1000. Between two tests, I think I lost connection to the XDS port, maybe a Loose connection happened or a component behind the connection is dead. I do not see any problem on microscope but when playing with the cable connecting the xds, the leds sometimes oscillate USB Cable changed but still the same behavior, the led on are the following one : D6 (USER_LED2) / D3 (PGOOD) / D5(RESET_LED) and the 5V LED from the DCA1000 Just for information, I&#39;m connected the same ways as this guide: https://dev.ti.com/tirex/explore/content/radar_toolbox_3_10_00_05/hardware_docs/dca1000_perDevice/dca1000_mmwave_studio_xWRL6844.html when playing with the cable the 3 led from the IWRL are oscillating therefore my doubt about the connection or hardware problem even leaving only the xds cable, the leds are on but still no xds port appear on my computerIWRL6844EVMIWRL6844Test &amp; Measurementhttps://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1650800/awrl1432boost-bsd-how-to-apply-the-remaining-memory-of-hwass_shm_mem-to-radar-code-application/6367276Tue, 02 Jun 2026 10:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2e1f5167-680b-4caf-97da-7de9dab05505Sarvesh DubeyHi James &amp; liang, The particular thread: AWRL1432: How to use shared memory in the awrl1432_adas_bsd_demo_v4.1 project - Sensors forum - Sensors - TI E2E support forums dealt mostly with &#39;how to use the shared memory configuration&#39; more than the sharing strategy, can you please confirm if you/Albert Yip can now successfully share memory across regions and use them in the application? [quote userid=&quot;282354&quot; url=&quot;~/support/sensors-group/sensors/f/sensors-forum/1650800/awrl1432boost-bsd-how-to-apply-the-remaining-memory-of-hwass_shm_mem-to-radar-code-application&quot;]Our team has encountered a difficult problem,the HWASS_SHM_MEM memory has 512KB, but the remaining of HWASS_SHM_MEM memory has 308KB.Since we have now added the post-processing code, the remaining RAM is insufficient, resulting in a RAM overflow. Could we use the remaining 308KB of HWASS_SHM_MEM to store our additional code? If possible, could you please provide more detailed operation instructions?look forward to your reply.[/quote] You can try using a different Shared memory config which dedicates more memory for the APPSS RAM, this can resolve the memory overflow being observed. Using SH_MEM_CONFIG=1 should provide you 640KB of APPSS RAM which you can potentially use for the post processing. Best Regards, Sarvesh