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 TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 50 subscribers
  • Views 6318 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.

SPP Maximum Payload

emna abdelkefi
Prodigy 90 points
Other Parts Discussed in Thread: MSP430F5438

Hi Freedy

I'm trying to connect the MSP430F5438 experimenter board and PAN1315 to the PC via Bluetooth link and test frame transmissionFor all PCs that I test with, when I send a frame with datalen>121 bytes,the PAN 1315 receives a frame with datalen=121 and another frame wich contain the rest of data.

For example when I send a frame (length=200):

The PAN1315 respectively receive :

First frame: datalen=121

Second frame :datalen=79

 Do you meet this problem when you worked with the ethermind Bluetooth stack?

thanks

Emna

  • 0 in reply to Miguel
    Prodigy 120 points

    Hello,

     I have a problem with my bluetooth module PAN1315 used with the MSP430 Experimented board (MSP430F5438) and I hope that you help me to reslove this problem.

    In fact, I establish a Bluetooth connexion between my PC and the PAN1315 Bluetooth moduleI using  the "Advanced Serial Port terminal"  software. I try to send a bluetooth frame and  visualise the frame received by the PAN1315 using the Terminal Input/output of the IAR.

    when the number of bytes in the sent frame become higher than 121 bytes, the PAN1315 will receive this frame in paquets of 121 bytes.

    For example, when I send a frame of 506 bytes, I obtain:

     SPP_RECVD_DATA_IND 

     data length= 121

     received data = the 121 first bytes of the data sent     // (from byte1 to byte 121)

    SPP_RECVD_DATA_IND 

     data length= 121

     received data = the 121 second bytes of the data sent   //(from byte 122 to byte 242)

     SPP_RECVD_DATA_IND 

     data length= 121

     received data = the 121 third bytes of the data sent   // (from byte 243 to byte 362)

    SPP_RECVD_DATA_IND 

     data length= 121

     received data = the 121 fourth bytes of the data sent  // (from byte 363 to byte 482)

    SPP_RECVD_DATA_IND 

     data length= 23

     received data = the 23 last bytes of the data sent // (from byte 483 to byte 506)

  • 0
    TI__Mastermind 23565 points

    Emna,

                This behavior is expected since the L2CAP MTU size is 128 Bytes.

    Regards,

  • 0 in reply to son am
    TI__Genius 9990 points

    Son Am,

    "when the number of bytes in the sent frame become higher than 121 bytes, the PAN1315 will receive this frame in paquets of 121 bytes."

    There is a limit of bytes which can be sent and this is usually 110 bytes. Where are you sending 121?

     

    Gustavo

  • 0 in reply to Miguel
    Prodigy 90 points

    Thank you Miguel:

    we suppose that the L2CAP MTU length=128,where 4bytes of the L2CAP MTU are reserved to length of frame and for Channel,and I suppose 121 bytes are reserved for data .

    The 3 other bytes of the L2CAP MTU is reserved for what?

    Regards

  • 0 in reply to emna abdelkefi
    Intellectual 440 points

    During the L2CAP Channel configuration, each side informs its peer entity about its MTU.
    The MTU represents the largest SDU (Service Data Unit) that it can receive over the corresponding L2CAP Channel.

    The BlueMSP430 EtherMind SPP SDK uses 128 as the MTU size for the RFCOMM. This means that the maximum size of the L2CAP payload for this channel for the RFCOMM protocol/service is 128.
    This size of 128 does not include the L2CAP header.
    In this case L2CAP payload is RFCOMM packet including the RFCOMM related header/trailer.

    The maximum data packet length for any layer using the RFCOMM (like SPP in this case) is decided by 'Frame Size', exchanged in the 'Parameter Negotiation' stage during the RFCOMM connection establishment.

    L2CAP MTU is asymmetric and can have different values in each direction. 'Frame Size' is symmetric and shall have same values in each direction. Therefore while calculating the Frame Size, the minimum of the L2CAP MTU of both side is taken.

    The UIH Frame Header (which carries the SPP data) could be 3 or 4 Bytes depending upon the length of the Information field - if the length is more than 127 header is of 4 bytes, otherwise 3.
    There is 1 byte of FCS in the end of each UIH Frame.
    So, at most, we can have 5 (4 + 1) Bytes of UIH Overhead. And hence, RFCOMM Frame Size should at least be 5 bytes less than minimum of L2CAP MTUs.

    The same UIH packet is also used by RFCOMM to exchange credit packets, required for flow control and this credit packet can be piggy backed while UIH packet is carrying SPP data. Many implementations discount that 1 Octet for the Credit also during frame size calculation.

    With the credit in the UIH packet along with data/information payload, the RFCOMM packets can be represented as follows

    +----------+----------+--------------------+----------+--------------------+---------+
    | Address  | Control  | Length Indicator  | Credits   | Data/Information   |   FCS   |
    +----------+----------+--------------------+----------+--------------------+---------+
      1 Octet     1 Octet     1 or 2 Octets       1 Octet                        1 Octet

    Now if the BlueMSP430 SPP SDK is connected to a PC stack (say Microsoft Bluetooth Stack running by default), typically the MTU size of the PC stack will be higher than 128, as it has lots of memory and hence is capable of receiving larger data packets.
    So the minimum MTU size will be that of BlueMSP430 SPP, i.e. 128.
    Removing the 6 octets (including the octet required for Credits), the frame size negotiated is typically 122 (= 128 - 6).
    It can be easily seen in the air sniff log, when the Microsoft PC stack connects to BlueMSP430 SPP.

    According to the RFCOMM specification, with 'Frame Size' configured as 122,
    ** In the UIH packet, with no credit field, the maximum size of the data/information field is 122
    ** In the UIH packet, with credit field, the maximum size of the data/information field is one less, i.e. 121

    In fact, many implementations do the mistake of counting the credit field during the 'Frame Size' calculation. But once the frame size is agreed, which is symmetric then again 1 octet is required from the negotiated size for the credit field. Because of the symmetric nature, if the BlueMSP430 SPP initiates the SPP connection and during parameter negotiation in this case suggests 123 (= 128 - 5) as the frame size, in the response the peer stack requests lesser value 122 (= 128 - 6) and which has to be agreed upon.

    Although the credit fields are not sent in all the UIH packets, many implementations like to reserve that field and only allow the ('Frame Size' - 1) as the largest payload for upper layer, like SPP. Therefore with many such implementations, one can observe 121 (='Frame Size of 122' - 1). as the largest SPP data being sent from the peer implementation.

    Corresponding data reception indication in SPP, reflects the same.