Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 17 subscribers
  • Views 362 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652R: rfPacketErrorRate 15.4 mode, TX data format compose question

YZ
Intellectual 1980 points
Part Number: CC2652R

Hi Team,

In the rfPacketErrorRate, while using 15.4 mode, got confused about the TX data formation.

The TX data seems assigned by below code:

The first and second bytes of data buffer are assigned as sequence number, not the packet length.

But when use other RF mode for example 2-GFSK mode, the received data first byte is actually the length information, 30(0x1E) is the length predefined (0xAE 0xAE are values I added to distinguish data):

While using 15.4 mode, I got this, no length information is added, 

As we can see on the RX side, it uses the first byte to determine the data length, so in this case 15.4 will not apply. 

How ever, when I use smartRF studio to receive data, it shows the data length (please ignore the data content, that's some test code I made, just modified the content, no other changes), not sure value 0x1e is generated by smartRF studio or is it actually received data.

Then I looked into code again, I see "currentDataEntry->data" which is an instant of "rfc_dataEntryGeneral_t" seems confusing to me, I got some questions:

1. Does the "data" member store actually the first byte of TX data buffer? 

2. How the length information is inserted into TX data buffer since we can see the first and second bytes are already assigned in the code as sequence number?

3. Does "rfc_dataEntryGeneral_t" also apply to 15.4 mode?

Thanks! 

  • 0
    TI__Mastermind 32790 points

    Hi,

    My initial comments:

    • There must be some form of length that is included in the packet sent over-the-air. If you look in SmartRF Studio, you will see there is a field for length. My guess is that the RF core will add this length field before transmitting.
    • I believe rfc_dataEntryGeneral_t should apply to the general case, including 15.4

    I have passed this to the relevant team for insight.

    Regards,
    Toby

  • 0 in reply to Toby
    TI__Guru* 82561 points

    For CMD_IEEE_TX, the packet length is given by payloadLen and is not written as part of the packet payload (pPayload):

    Ex:

    packet[] = {0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
RF_cmdIeeeTx.payloadLen = sizeof(packet); //0x06
RF_cmdIeeeTx.pPayload = packet;

    On the RX side, you need to set

    RF_cmdIeeeRx.rxConfig.bIncludePhyHdr = 1;

    for the length to be included in the data entry.

    BR

    Siri

  • 0 in reply to Siri
    TI__Intellectual 1980 points

    Hi Siri,

    Yes, i actually figured it out myself of adding RF_cmdIeeeRx.rxConfig.bIncludePhyHdr = 1.

    The thing is after adding that line of code, the rx data buffer, the length byte shows 2 bytes larger than the actual TX data length, for example, the TX data length is 30 (0x1E), while in the rx data buffer, it shows 32(0x20), seems extra 2 bytes information is added, do you know what are the two bytes?

    Thank you!

  • 0 in reply to YZ
    TI__Guru* 82561 points

    What you are receiving is the PHY header. On the TX, txOpt.bIncludePhyHdr = 0, meaning that the radio CPU inserts a PHY header automatically, calculated from the payload length. Since also txOpt.bIncludeCrc is 0, the radio CPU appends two CRC bytes, calculated according to the IEEE 802.15.4 standard.

    Not an Expert, but I think that if you write 6 bytes in Studio to be transmitted, the PHY header is actually 8, and this is what you see when you set bIncludePhyHdr = 1 on the RX side.

    Another option is to set bIncludePhyHdr = 0, and set config.lenSz  = 1 for your queue. then you will have a length byte added as the first byte in the entry, replecting how many bytes are actually in the entry (and not necessarily received by the radio). It will account for appended bytes etc.

    BR

    Siri

  • 0 in reply to Siri
    TI__Intellectual 1980 points

    Siri,

    Thanks for your answer, helps a lot!