• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 1577 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.

Original question:

IWR6843: IWR6843: Problem with BSS power up

IWR6843: Timeout using default Labs & Config files

Scott Tattersall
Intellectual 290 points
Part Number: IWR6843

I am trying to run the long range people counting lab (LAB0019) from the mmwave industrial toolbox v 3.1.1 for the IWR6843 and have the same issue as in the linked question, namely:

1) Successfully flash the board with the lab (see "Success" message)

2) Disconnect SOP2 per instructions and power cycle

3) Run GUI from Lab19

4) Connect to device from GUI, successful

5) Start tracking: receive timeout error messages:

Warning: Unexpected Warning: A timeout occurred before the Terminator was reached.
Warning: Unsuccessful read: The specified amount of data was not returned within the Timeout period..

6) But like the related question, sometimes it just works (I have no exact sequence of power cycles and resets that work consistently, but when it does work it seems to work fine until the next power cycle)

7) I have tried other labs (e.g. Lab0015) with the same results.

Separately: when it has occasionally worked, the long range lab doesn't actually achieve active "tracks" of people (though I can see point clouds that visually appear of the right size to be tracked). I'm guessing this is a config issue since I can see the point clouds in the gui, but I am using the default config for the long range people counting? Any suggestions on what to change in this file to achieve good tracking data?

Finally, and unrelated, the documentation for the lab does not include all the parameters in the default configuration file. Could someone elaborate on what the new additional parameter of the AllocationParam section, default config is: 

AllocationParam 40 100 0.1 3 2 2

whereas only the last 5 parameters are discussed in the customisation guide included with the lab. Also, what is the new AccelerationParam used for?

Thanks.

  • 0
    TI__Mastermind 30405 points
    Hi Scott,

    This issue has already been addressed over email. Could you please confirm that you got the email response and close the thread if your problem is resolved? Thanks.

    Regards
    -Nitin
  • 0 in reply to Nitin Sakhuja
    Intellectual 290 points

    Hi Nitin,

    The first part of my question has been addressed over email (I will attempt the re-compile and fix this week and see if it works) but if someone could answer the second part of my question, namely:

    Separately: when it has occasionally worked, the long range lab doesn't actually achieve active "tracks" of people (though I can see point clouds that visually appear of the right size to be tracked). I'm guessing this is a config issue since I can see the point clouds in the gui, but I am using the default config for the long range people counting? Any suggestions on what to change in this file to achieve good tracking data?

    Finally, and unrelated, the documentation for the lab does not include all the parameters in the default configuration file. Could someone elaborate on what the new additional parameter of the AllocationParam section, default config is: 

    AllocationParam 40 100 0.1 3 2 2

    whereas only the last 5 parameters are discussed in the customisation guide included with the lab. Also, what is the new AccelerationParam used for?

    Thanks,

    Scott

  • 0 in reply to Scott Tattersall
    TI__Mastermind 30405 points

    Hi Scott,

    Please note that the BSS firmware fix is now officially available in MMWAVE SDK  3.01.01.02 so please download it. You'll still need to re-compile the People counting Lab binary with the new firmware as the lab has not been updated yet on TI Resource Explorer.

    I have informed our People counting expert wrt your questions on that that lab and they'll respond here with the details asap.

    Thanks

    -Nitin  

  • 0 in reply to Scott Tattersall
    TI__Mastermind 28055 points

    Hi Scott,

    AllocationParam 40 100 0.1 3 2 2 - bolded argument is the new parameter. This is the SNR Obscured threshold - if a new track is behind an existing track, the bold value is used as the SNR threshold instead of the 1st value. A new track (A) is considered behind another track (B) if B is between the sensor and A. So in that case, the cumulative SNR of A would need to be greater than 100 to be allocated.

    Since you are not getting detections, please check the Allocation Parameters of the configuration you are sending. There is an error in the current version of the lab where the configuration file in the quickstart folder has these allocation parameters: AllocationParam 40 100 0.1 40 2 2.  Try changing the bolded value 40 to 3.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 290 points

    Hi Justin,
    Unfortunately this change did not work. So, to recap:
    1) I'm using the Lab 19 - "People tracking at 50m" from the latest industrial tooboxand the IWR6843
    2) I'm using the default configuration file from this lab, except with the single change you mention in your reply (AllocationParam, 4th param, 40 changed to 3)
    3) I'm using the default GUI from this lab

    The results I'm getting I captured in a screen video (attached in separate post below - for some reason I couldn't add it to this post). This is a field test of one person walking away at boresight out to 55m and walking back again. I don't mind too much about the ghost tracks at the start (this is a street lined with cars and there are likely more reflections that there would be at a different location). What I want to fix is the fact that it is clear (enough) from the point cloud data that the person should be tracked much further out than is occurring. Please let me know what I can change in the configuration file to try and address this issue.


    Thanks,
    scott

  • 0 in reply to Scott Tattersall
    Intellectual 290 points

  • 0 in reply to Scott Tattersall
    TI__Mastermind 28055 points

    Hi Scott,

    I have tested this configuration:

    dfeDataOutputMode 1
    channelCfg 15 5 0
    adcCfg 2 1
    adcbufCfg 0 1 1 1
    profileCfg 0 61.00 35 6 43.0 0 0 8.241 1 125 3433 0 0 48
    chirpCfg 0 0 0 0 0 0 0 1
    chirpCfg 1 1 0 0 0 0 0 4
    frameCfg 0 1 128 0 50 1 0
    lowPower 0 0
    guiMonitor 1 1 0 0
    cfarCfg 4 4 4 16 16 4 4 40 40 0 1
    doaCfg 1 1 1047 3 600 10 100
    SceneryParam -15 15 0.5 50
    GatingParam 4 6 6 10
    StateParam 4 10 60 600 20
    AllocationParam 40 200 0.5 3 2 2
    AccelerationParam 1 1 1
    trackingCfg 1 2 250 20 78 121 50 90
    compRangeBiasAndRxChanPhase 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
    sensorStart

    This will detect out to 50 meters.  We can discuss false detection if need be.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 290 points
    Hi Justin,

    I think I've realised what the problem is: the default SceneryParam in the lab is set for 22m rather than 50m. I had also assumed (incorrectly) that setting the scenery params in the GUI would override the ones in the config file, but I think now that the GUI params are only used in the GUI for rendering. I will try your config file next week and hopefully get better results. Thanks,

    Scott
  • 0 in reply to Justin Curewitz
    Intellectual 290 points

    Hi Justin,

    That configuration file did fix the tracking problem, latest test shows much better long range result.  

    Could you have a look at the screen video of the latest tests and let me know what I could try to change to avoid the "ghosts" I'm seeing (both the large number of noise / ghosts near to the device and the more persistent "reflection" type ghost that follows the tracked person quite far out?)

    Thanks,

    Scott

  • 0 in reply to Scott Tattersall
    TI__Mastermind 28055 points
    Hi Scott,

    I believe this video is showing two separate issues:

    1) When the tracked person is close to the device, they create multiple tracks.
    2) When the tracked person is walking away from the device, they maintain two tracks.

    For 1, you can solve this with tuning - you can further modify the allocation parameters, or you can modify the gating parameters. Since we want to detect targets at range, you should not increase the detection threshold. Instead, consider modifying the max Distance threshold (argument 5), and the max Velocity threshold (argument 6) - by increasing these thresholds, the size of the allocated track will potentially be larger, and include more points - it seems currently, the tracker is allocating multiple tracks for 1 person since multiple small clusters are making up the person. Increasing these thresholds may alleviate that.

    Also consider the gating parameters. Increasing the first parameter - gating volume, will increase the area around the tracked person from which points can be associated. Each point can only be associated with 1 track, so if the first existing track takes all the points, other tracks cannot be allocated.

    For 2, is the target walking along a wall? It seems that the device is seeing a multipath reflection off of a wall that the person is walking alongside. This reflection keeps a track alive that was erroneously allocated at the beginning of your test.

    Finally, are you aware of the fhist replay tool available with the Traffic Monitoring demo? This tool can be used to replay fhist data captured by pressing "Exit" on the People Counting gui. This can be used to try tuning modifications without running the demo live. If you try this and have problems, please open another thread so that this issue can be tracked separately.

    Please let me know about the scenery around the person so I can help with the second issue.

    Regards,
    Justin
  • 0 in reply to Justin Curewitz
    Intellectual 290 points

    Hi Justin,

    I finally got a chance to redo the testing with the updated config file and it is now achieving the desired range of 50m+, thanks for your help with this.

    I am very interested in using the fhist replay tool, but it crashes when I try to use it on the ppl counting data -  I will create a separate thread on it as you suggested if I can't figure out what's up with it.

    Thanks,

    Scott