IWR6843ISK: Can't identify data elements try to do parsing of long range counting people

Tomas Alarcon

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

Hello experts,

As linked from the previous question I'm connecting a iwr6843+mmwaveicboost to a nrf52832 mcu. But preparing the code for parsing I have evaluated the user guide of that lab for long range counting people.

but the results have some issues:

0201040306050807  //Magic word 8 bytes
03000303          //Software version 4 bytes
43680024          //A6843 4 bytes, Why the last 2 bytes always change?
5c768aa0          //Time in cycles  4 bytes
010000ac          //In bytes  4 bytes
0e000000          //frame number 4 bytes
00000000          //sub-frame num 4 bytes
00000000          //time left after chirp 4 bytes
00000000          //time after frame 4 bytes
00000000          //time to run traker 4 bytes
00000004          //time to send uart message 4 bytes, I always find number 4 in this line
00ad              //Number of TLVs in this frame 2 bytes
8d06              //sub-frame 2 bytes

//This should be the head of first TLV
000000d0   //But the type that appears in the guide does not include number 208
00000061   //Ignoring the previous issue shall have 97 bytes 
987a405f1580bd000000
0000000000b7f58c4049
48c0bd00000000000000
003d9f9c404948c0bd00
00000000000000b7f58c
40560500bd0000000083
34003e3d9f9c405f1580
bd000000008334003ecf
9bcb40560500bd000000
008334003e6198
//But after extract 97 bytes the new head TLV is even more weird
7a40f05500be00000000833480beb7f58c40f05500be00000000833480be3d9f9
c40f05500be00000000833480be61987a404948c0bd00000000833400beb7f58c
404948c0bd00000000833400be3d9f9c404948c0bd00000000833400be5545db4
05f1580bd00000000833400be090000003400000095008402c3008002b0007802
a000a402a80095026a008d0287009c02c1009202b00087027f00c002bf00b402b
900a4027c009002070000002800000001000000a77751bd28af8d4012a6ad3e92
fc58bc62ba4008b3283e010000801300008000000000080000000d00000001010
101010101010101010101000000000003130000000000e93f0100010000

It is possible to see that some data received do not match with the expected values shown in the guide.

My question:

1._ What could be introducing this weird values? (could be an imprecision in the baud rate one of the reasons ?)

2._Is it possible to reduce the amount of data that the sensor provide with out change the configuration of the sensor?, in order to design the code to parse the data in an incremental approach. (if yes where in the code?)

3._Is it possible to reduce the default baud rate from the mmwave sensor ? (if yes how?)

over 5 years ago

0 Akash Gondalia over 5 years ago

TI__Guru 50240 points

Hi Tomas,

We'll need more information. Would you be able to show us some data about the supposed inaccuracy?

Regards,

0 Tomas Alarcon over 5 years ago in reply to Akash Gondalia

Intellectual 470 points

Hi AG,

From the HEX I had posted it is possible to see there were some inconsistencies, but I found out doing different tests that it was a problem with the way I was reading the UART port with python.

Actually I found out that is the software that introduce a delay that corrupts the data but didn't realize which instruction does.

Now the problem I am having is that when I am reading the UART with the MCU the data get corrupted as well. I think is because I couldn't find a way to collect it faster that it is arriving, so I get right the first few bytes and later just useless data.

As now I am sure the data on the Tx of the IWR6843 is Right, I have this questions:

1._Do you have any idea of a good approach to collect data using the nrf52832 mcu? Maybe a faster way to save the data in memory without stop listening the UART, even a generic approach.

2._Is it Possible to reduce the baud rate of the data string? If yes, how the configuration shall change?

3._In which source code can I find the baud rate configuration for the IWR6843ISK?

4._Is it possible to reduce the amount of data that the sensor provide with out change the configuration of the sensor?, in order to design the code to parse the data in an incremental approach. (if yes where in the code?)

I hope you can answer my questions, please consider that we have about 12 hours different and it takes at least one day between messages. I am attaching a file with The right data I could collect from the sensor running the LRPD with hard configuration.

Best Regards,

Tomas

Post Edit:

5.- where in the documentation can I find more information about the Target Index codification?

6. - In the guide mentioned that 253, 254 and 255 are related to points not associated, Does it means that for actual targets the targetindex will use from o to 252 to indicates actual targets?

7. - Does the demo assign target index only to the objects that are considered as a person? or any object get a targetIndex?

0 Justin Curewitz over 5 years ago in reply to Tomas Alarcon

TI__Mastermind 28055 points

Hi Tomas,

This can be device dependent, I recommend contacting the manufacturer for support.
You can do this. Note that this may require you to increase the frame time. The baud rates are set in mss_main.c
1. commandBaudRate = 115200 - this is used for cli
2. loggingBaudRate = 921600 - this is the data output
See above, mss_main.c
The output is also in mss_main.c. Look for the UART writes. You could remove information, so send less points, or just skip sending the point cloud or other data. However, you could also try compressing the point cloud data. We do this in the 68xx_3D_People_Counting demo - you can see the source for an example of how the data can be compressed. (also mss_main.c of that demo)
I will answer here. Target index relates a point in the point cloud to a target. So if the index value is 2, then the point is associated with target ID 2. 254 is un-associated and 255 is out of bounds. Index values are in the same order as the points.
Target index will be from 0 to 19, as we allocate memory for 20 targets.
Every point gets a target index. Indexes are assigned before classification occurs (they are needed by the classifier) so non-human objects will give points an index.

Regards,

Justin

0 Tomas Alarcon over 5 years ago in reply to Justin Curewitz

Intellectual 470 points

Hi Justin,

Thank you so much for your accurate answers. These rose other doubts:

Justin Curewitz said:
You can do this. Note that this may require you to increase the frame time. The baud rates are set in mss_main.c

commandBaudRate = 115200 - this is used for cli

loggingBaudRate = 921600 - this is the data output

1. Do you mean the Frames per second? I was looking for frame time in the documentation and at least in the SDK user guide does not have a configuration command for it. But it refers to the DPU and the chirp configuration to modify the range determination.

Justin Curewitz said:
Every point gets a target index. Indexes are assigned before classification occurs (they are needed by the classifier) so non-human objects will give points an index.

2. Are "targetId" and "trackId"int the TLV explanation the same information? Or already when there is a track it is considered a human. I would direct my question as:

3. When the classification happens, in the xwr68xx or in the GUI?

I will do some tests and Update you in a bit.

Regards,

Tomas

Edited:

I could reduce the BR successfully, but still have he doubt with the meaning of the frame time.

4. I facing now the issue of how to determine which targets refers to a human person to be able to count them, or at leas for a first step to determine there are people in the area of coverage. De first Idea is to check the Tids that repeat most in a Group of frames, because I understand that those Tids shall point to the most suitable targets of ppl present in the are. Am I right with this assumption?, What other more elaborated calculations could I perform to count people. I want to clarify that at the moment I don't want to cast the location of the people but just to identify and count them.

Thank you again for you useful help

0 Justin Curewitz over 5 years ago in reply to Tomas Alarcon

TI__Mastermind 28055 points

Hi Tomas,

I was referring to frame period, which is set in the frame config command. A new frame will start every frame period milliseconds.
Target ID and Track ID are equivalent.
To be clear, Long range people detection doesn't do any classification, the tracker allocation is set to filter out objects that aren't of interest. The Indoor False Detection Mitigation demo does do classification, and this is done on device in the MSS right after the tracker runs (gtrack_step()).
If you are seeing a large number of false detections (tracks that aren't people) we need to modify your allocation parameters to better identify people (or other targets) of interest.

Regards,

Justin

0 Tomas Alarcon over 5 years ago in reply to Justin Curewitz

Intellectual 470 points

Dear Justin,

Thank you for your answer, I will try your suggestions.

I have checked the Indoor False Detection Mitigation demo, but could not find the gtrack_step() is. I will keep for now with the long range detection people, but i would like to have access to more documentation in how to use better the sensor, I noticed that it use a lot of machine learning but it is difficult to follow the code for some impressions in the comments along it and the amount of sub-files it has. I would appreciate if you could address me to some documents that can help me to do my own development and to really adapt some demos for specific applications.

best regards

0 Justin Curewitz over 5 years ago in reply to Tomas Alarcon

TI__Mastermind 28055 points

Hi Tomas,

In the IFDM folder, you can see how the classifier is implemented in the document at docs/indoor_false_det_68xx_algorithm_overview.pdf

Long Range People Counting is based on the 68xx Out of Box demo (with DSP enabled). You can find documentation on this at: <mmwave_sdk_03_03_00_03>/packages/ti/demo/xwr68xx/mmw/docs/doxygen/html/index.html

Regards,

Justin

Sensors

Sensors forum

IWR6843ISK: Can't identify data elements try to do parsing of long range counting people