• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 402 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS: iwr1642boost - lost sync (pplcount lab)

oren golan
Intellectual 260 points
Other Parts Discussed in Thread: IWR1642, IWR1642BOOST

Tool/software: Code Composer Studio

hello,

i have tried to run pplcount lab 11 code from mmwave_industrial_toolbox_3_1_1 (from matlab and from the exe. file also) and i always repeatedly received a sync error.
the GUI stacked also because of the sync error ,like you can see in the picture below: 

my computer specification are as shown below: 

what could be the reason that caused to this problem (of repeated sync loss)? 

all the best,
Oren.

  • 0
    TI__Mastermind 28055 points

    Hi Oren,

    Sync errors happen when the PC gets bad frame data.  Usually, this happens when the Matlab script falls behind the device. Matlab is single threaded, and the graphing functions can take a significant amount of time.

    My recommendation - download the latest industrial toolbox and use the visualizer included with the 3D People Counting Lab - you won't have to install any other runtimes, and this one is built to run much faster.  There are instructions for use in the 3D People Counting user's guide. Make sure you select "Legacy - 2D People Counting" before clicking connect, and make sure to select the correct cfg file for the IWR1642 People Counting lab.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 260 points

    hi

    the lost sync is most of the time result of "TLV Size is wrong"  ,"No SYNC pattern",and  "Error: TID is wrong".

    i used sniffer to spy on the COM the matlab used to read the data from the serial . i wanted to see if the matlab gets the wrong package . 
    the  "Error: TID is wrong" for example can repeat itself many times for a few seconds and then to stop (repeatedly ) 

    the spy sniffer detect : 38 00 00 00 = TID OF 56.

    and the matlab detect : 56 0 0 0  -> TID of 56 

    so the matlab works well. 

    the lost sync exits the while loop and makes the plot looks stuck.

    what can be the reason? 

    i must say that we did some minor changes in the ppcount we burn to the radar.  we add some gpio output that changes its value when human detect ,and add the number 20 to the  TID the radar send, in the matlab we did -20 .   human detect when 20 samples of speed ,for example, are over 0.5 [m/s] (and more tests) but except adding the number 20, we did nothing to the data the radar sent.

    we removed the micro USB connector and connect the cable directly on the IWR1642BOOST board (1.5 [m] cable long). 

    the value of 56 ( and many other values 48,15640000 ,etc) is not suppose to be there. 
    it works great , but when there are many people it starts to show "TLV Size is wrong"  ,"No SYNC pattern",and  "Error: TID is wrong" errors. 
    and when there are 1 or 2 people it sometimes show "TLV Size is wrong"  ,"No SYNC pattern",and  "Error: TID is wrong" , but less frequently .

  • 0 in reply to oren golan
    TI__Mastermind 28055 points

    Hi Oren,

    So the data in Matlab matches the data found on UART. Then we need to determine if the data the device is sending doesn't make sense, or if there is some issue with the UART data.

    First, let's determine if there are any issues with the People Counting Data output:

    1. In the task_mbox.c file, in the MSS project, all of the data is sent out. 
    2. Add an assert() here. We want this assert to fail when the TID is above 20. (So if the device tries to send TID of 56, we will assert and stop the demo.)
    3. Run the demo in debug mode so that we can see if the assert is triggered.

    Next, if the assert does get triggered, it means the TID values are being set incorrectly, or there is some issue with the buffer being used to store the TID values. (The values after the wrong TID in your picture don't make much sense either, as these values should be much smaller.)

    1. Check to see if the tracker information coming out of the gtrack_step() function in task_app.c (MSS) are correct
      1. You can use the assert method for this as well
    2. Check that the number of Tracks report by gtrack_step is the same number of tracks your mbox task is trying to send (if we are sending more tracks than the tracker reported, then the data in the buffer may be uninitialized which will result in the incorrect values).
    3. If data from tracker is correct and task_mbox.c is faithfully send out the correct number of tracks, need to determine where the data is being corrupted.

    If the data is fine through the mbox task (all the way through UART write), and Matlab is decoding it well, the the issue is in transmission.

    Regards,

    Justin