This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWR6843ISK: Issue with IWR6843ISK Radar and MMWAVEICBOOST Evaluation Module

Part Number: IWR6843ISK
Other Parts Discussed in Thread: MMWAVEICBOOST, , UNIFLASH

Hello,

I am experiencing an issue with the IWR6843ISK Radar (reference PROC073D(001_IWR)/ES2.0 (RTM silicon)) and the MMWAVEICBOOST Evaluation Module (reference PROC074B), using SDK version 3.6.

The issue occurs after sending the configuration file to the radar and starting the test. After about ten identical tests with a reset each time, the radar sends an error message (see attached photo). To resolve this issue, it is sometimes necessary to reset the radar each time or to flash the radar with the uniflash software. However, despite these attempts, the same issue occurs sometimes, requiring a hardware reset by discharging certain capacitors on the evaluation module. One important thing we would like to know is why the radar bug occurs after 10 tests where nothing happens on the GUI (no signals).

To better understand this issue, we have visualized the various signals from the UART (VCC, XDSET_1_DM, and XDSET_1_DP) on an oscilloscope using a micro-USB. When using the GUI with the VitalSignsRadar_Demo software, we noticed that during normal operation (without bugs), the various signals appear correctly on the oscilloscope with a time between two data packets evaluated at 4 seconds and the time of a data packet evaluated at 2 seconds, with an interruption time of 12.7 seconds where there is no data. We would like to know why we have this interruption time and what is causing it.

During a test where the bug occurred, we noticed that despite the bug, data packets were still visible on the oscilloscope until the signals disappeared completely. However, on the GUI, there were no more signals. We would like to know why we still have data packets on the oscilloscope but not on the GUI.

We also noticed that if we press "stop" on the GUI, we still have data traffic on the oscilloscope and that we have to completely exit the GUI by closing it to stop the data traffic.

Finally, during a test, a buffer saturation message appeared on the command prompt. We would like to know what could cause this buffer saturation (latency, data processing errors, etc.).

We hope this information helps you understand the issue we are experiencing. We remain available for any further information.

Best regards, Lucien

  • Hi Lucien, 

    Thanks for posting your question. It seems there may have been an issue when you attached the pictures as I am not able to see them. Could you please post these pictures again in a reply? 

    Also you mention you are running the VitalSignsRadar_Demo software and GUI. Can you please let me know where you are obtaining this (Toolbox version) and if you have made custom modifications or if you are just running the example code provided by TI? Can you also share information about your chirp configuration (.cfg file used)?

    Best Regards, 

    Josh

  • Hello Josh,

    I am sending you back the questionnaires with the photos

    I am experiencing an issue with the IWR6843ISK Radar (reference PROC073D(001_IWR)/ES2.0 (RTM silicon)) and the MMWAVEICBOOST Evaluation Module (reference PROC074B), using SDK version 3.6.

    The issue occurs after sending the configuration file to the radar and starting the test. After about ten identical tests with a reset each time, the radar sends an error message (see attached photo 1). To resolve this issue, it is sometimes necessary to reset the radar each time or to flash the radar with the uniflash software. However, despite these attempts, the same issue occurs sometimes, requiring a hardware reset by discharging certain capacitors on the evaluation module. One important thing we would like to know is why the radar bug occurs after 10 tests where nothing happens on the GUI (no signals).

    To better understand this issue, we have visualized the various signals from the UART (VCC, XDSET_1_DM, and XDSET_1_DP) on an oscilloscope using a micro-USB. When using the GUI with the VitalSignsRadar_Demo software, we noticed that during normal operation (without bugs), the various signals appear correctly on the oscilloscope with a time between two data packets evaluated at 4 seconds and the time of a data packet evaluated at 2 seconds, with an interruption time of 12.7 seconds where there is no data. We would like to know why we have this interruption time and what is causing it.  (see attached photo 2)

    During a test where the bug occurred, we noticed that despite the bug, data packets were still visible on the oscilloscope until the signals disappeared completely. However, on the GUI, there were no more signals. We would like to know why we still have data packets on the oscilloscope but not on the GUI.  (see attached photo 3)

    We also noticed that if we press "stop" on the GUI, we still have data traffic on the oscilloscope and that we have to completely exit the GUI by closing it to stop the data traffic.

    Finally, during a test, a buffer saturation message appeared on the command prompt. We would like to know what could cause this buffer saturation (latency, data processing errors, etc.). (see attached photo 4)

    Regarding your questions, we are working on vital signs without tracking using the standard toolbox provided by TI, and there has been no code modification (we are using the code provided by TI). The chirp configuration file we are using is "xwr68xx_profile_VitalSigns_20fps_Front.cfg" (you can find information about the chirp configuration in photo 5).

    As there is an issue with sending the photos, I will send you a link containing all the photos (1 to 5).

    https://we.tl/t-mxsoBvalin

    The link will expire one week from today.

    Best Regards, 

    Lucien

  • Hi Lucien, 

    Thank you for reposting the images and giving answers to my questions. Unfortunately the specific demo software you are using has been deprecated for some time now so I am unable to help identify the root cause of the issue. One thing I would note is that I don't believe that demo was ever updated to support SDK 3.6 and it likely requires an earlier SDK version. You can check the user guide for that demo to find the specific version required which may potentially resolve the issue. 

    Please let me know, is there a reason you are unable to evaluate vital sign detection with our latest Vital Signs with People Tracking demo

    Best Regards,

    Josh