• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1350 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.

AWR1642BOOST: Is UART Packet Length is fixed to 288 in Vital Sign Monitoring?

LAXMI KANT TIWARI
Genius 3345 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: IWR1642BOOST

Hi,

I was writing a generic uart code on a master microcontroller to receive data via UART of IWR1642Boost. I would like to know about, is packet length always fixed to 288 bytes if not then which part in UART packet changes its length and when it changes? I think UART packet length might change if I change .cfg?

I understood that header contains the information of total packet length and header size is fixed to 40 bytes. So there is always a possibility to read the header in 40 bytes array and so as TLV header and VitalStats data as given in below image.

But I am not sure, what would be the size of Range Profile? Currently, it is 76 bytes in demo example. Is it always fixed to 76 or it varies with .cfg file and if yes then how?

As of now, I can read header 40 bytes, then TLV header of 8 bytes followed by 128 bytes Vital stats and 8 bytes TLV header but not sure about the size of Range Profile.

Moreover, the header says total packet length is 288 bytes and if I subtract sizeof(Header, TLV and VitalStats), I get 104.

104 = 288 - 40 - 8 - 128 - 8 
(remaining data to be send = total packet - sizeof(header + tlv + vitalstats + tlv))

Now, I get 104 with two variable Size of Range Profile and Padding, which becomes 

104 = sizeof(Range Profile + Padding)

To solve this puzzle, I have to know the size of any one variable in advance. In the current demo, it is fixed to 76 bytes and 28 bytes.

Long story in short, Is these sizes are always fixed (in which case I do not need to worry about the variable packet length read via uart)?

  • 0
    TI__Guru 70100 points
    Hello Laxmi,
    Length of header and each TLV is set in the byte sequence itself by the device while sending it out.
    Header->totalPacketLen: contains total length of this packet containing multiple TLV data in it.
    TLV_Header->Length: This is the length of current TLV sent by the device.

    TLV length of range profile is dependent on vitalSignsCfg CLI command params (startRange_m and endRange_m) where this TLV length will be fix for one iteration of this CLI command.
    Source code bookmarks-
    dss_data_path.c : MmwDemo_dataPathInitVitalSigns [obj->numRangeBinProcessed = obj->rangeBinEndIndex - obj->rangeBinStartIndex + 1; ]
    dss_main.c: MmwDemo_dssSendProcessOutputToMSS [itemPayloadLen = obj->numRangeBinProcessed *sizeof(cmplx16ImRe_t);]

    Regards,
    Jitendra
  • 0 in reply to Jitendra Gupta
    Genius 3345 points

    Hi Jitendra,

    Thanks for getting back to me but still I don't understand how can I calculate the size of Range Profile by reading the length in the header. For example, let's assume that following

    Header->totalPacketLen = 288;
TLV_Header->Length = 2;

    Now, How can I know the length of Range profile. Let's assume that the following is given already by seeing the UART data format

    HeaderLen = 40;
TLV1Len = 8;
VitalStatsLen = 128;
TLV2Len = 8;

Total = 40+8+128+8 = 184

RemainingBytes = PacketLen-Total = 288-184 = 104

    So from this remaining 104, there are two parameter which I need to read RangeProfile and Padding. I am lost here. How can make sure that I always right length. 

  • 0 in reply to LAXMI KANT TIWARI
    TI__Genius 15005 points
    Hi Laxmi,

    The 8 byte TLV2Len field indicates the length of the next segment.

    So you need to look at the value indicated in that field to figure out how long the next segment is.

    The padding will be the number of bytes left over after all segments have been decoded.

    Best Regards,
    Anand