PSoC 4 BLE 4.2 Throughput changes depending on connection

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AnSa_1225656
Level 4
Level 4
50 replies posted 25 replies posted 10 replies posted

I have a project based on the L2CAP throughput PSoC-4-BLE/100_Projects_in_100_Days/Day024_Throughput at master · cypresssemiconductorco/PSoC-4-BLE ...  example.  I am getting good through put much of the time, but I find that the number of packets I can send depends on the connection.  If I disconnect and reconnect, I get different results for throughput each time.  What could possibly affect that?  Is there some negotiation at connection that might be different each time?

StartAdvertisement Address: D2:C7:38:50:A0: 0

CYBLE_EVT_GAPP_ADVERTISEMENT_START_STOP

CYBLE_EVT_GAP_DEVICE_CONNECTED

L2CAP channel connection request sent.

L2CAP channel connection request accepted. Sending data.

Received MTU:498, MPS:251, Credits:1000

Up to about 70 packets a second or down to 10 packets a second depending on when I connect.  Once connected, the rate is pretty consistent 5-10% variance during connection.  If I disconnect and reconnect, the rate will likely be different.

0 Likes
1 Solution

Hello,

I will create a tech support case for you please share your complete project there.

For the L2CAP credit based flow control, we can have good throughput with MTU to 492 and MPS to 247 bytes and this will utilize the complete TX packets. We can use the connection interval to 7.5ms. Some of the phones have connection interval limitations to minimum of 37.5ms.

Please refer to the section 5.LE Data Packet Length Extension in the datasheet for more information on link layer packet format.

Thanks,

P Yugandhar.

View solution in original post

0 Likes
8 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello,

Could you please let me know how you are connecting the peripheral device. Are you using the BLE device or smartphone or Cysmart PC tool as central device. Also, please let me know how you are calculating the throughput?

Please check if you are changing the peripheral connection parameters during every disconnection and updating when connection established.

Can you please use the GATT_IN project for calculating the throughput by connecting with the GATT_OUT project in the Day024_Througput example and check the results with your project?

The amount of data that can be send/receive by the connected BLE devices depends on the negotiated MTU size. When the devices are connected the negotiated MTU size will be the minimum of (MTU of peripheral device, MTU of central device). Please check the MTU size in both the devices and check whether you are varying the MTU size during disconnection.

Thanks,

P Yugandhar.

0 Likes

Thank you for responding.  We have two PSoC4 BLE devices talking to each other.  Commands are sent over BLE GATT interface and high-speed data over an L2CAP channel from the device to master.  This all has been working well except for the difference in throughput (packets/second) between connections.  The MTU is statically defined on both devices to match since I have control over both devices.

On both devices:

On GAP Settings tab

Attribute MTU 498

Link layer TX payload 251

Link layer RX payload 251

On L2CAP Settings tab

MTU 498

MPS 251

Connection interval 7.5 to 10

****** My real issue is not the actual throughput at this point.  It is really a question of why it is so different between connections. ******

Here is the L2CAP connection maintenance code based on the PSoC-4-BLE/100_Projects_in_100_Days/Day024_Throughput

//---------------------------- Inside the BLE event handler

    case CYBLE_EVT_GAP_DEVICE_CONNECTED:

      connParameters = (CYBLE_GAP_CONN_PARAM_UPDATED_IN_CONTROLLER_T *)eventParam;

      CyBle_GattcExchangeMtuReq(cyBle_connHandle, CYBLE_GATT_MTU); // Important to make new MTU size active

      debugConsole_puts("\r\nCYBLE_EVT_GAP_DEVICE_CONNECTED");

      break;

    case CYBLE_EVT_GAPC_CONNECTION_UPDATE_COMPLETE:

      connParameters = (CYBLE_GAP_CONN_PARAM_UPDATED_IN_CONTROLLER_T *)eventParam;

      debugConsole_puts("\r\nCYBLE_EVT_GAP_DEVICE_CONNECTED");

      break;

    case CYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP:

      debugConsole_puts("\r\nCYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP:");

      if (*(uint16 *)eventParam == 0u)

        debugConsole_puts("\r\nAccepted");

      else

        debugConsole_puts("\r\nRejected");

      break;

//----------------------------

//---------------------------- BLE main loop

  while(1)

  {

    CyBle_ProcessEvents();

    CySysWatchdogFeed(CY_SYS_WDT_COUNTER0);

    if (CyBle_GetState() == CYBLE_STATE_CONNECTED)

    {

      CONNECT_LED_ON;

      if (commandPending)

      {

        serviceCommand(&wrReqParam);

        commandPending = false;

      }

      switch(channelState) // State machine for L2CAP channel maintenance

      {

        case CHANNEL_CREATED:

          // Keep sending data as long as credits are available. Maximum of (peer device's MTU - 2) bytes can be sent in

          // one LE-frame. New data is sent only when the previous data is  transmitted completely.

          while (!commandPending && (pendingControlPacket || uxQueueMessagesWaiting(sendQ)))

          { // transmit all packets in queue unless we have a command to respond to

            transmitPacket();

            CyBle_ProcessEvents(); // make sure the packet gets sent immediately if possible

          }

          break;

        case CHANNEL_PSM_NOT_REGISTERED:

          debugConsole_puts("\n\rRegister a new PSM. ");

          if(CYBLE_ERROR_OK == CyBle_L2capCbfcRegisterPsm(LOCAL_DEVICE_PSM, 0)) // Register a new PSM

          {

            debugConsole_puts("\n\rRegister a new PSM. ");

            channelState = CHANNEL_PSM_REGISTERED;

            debugConsole_puts("-- Success. ");

          }

          else

            debugConsole_puts("-- Failed. ");

          break;

        case CHANNEL_PSM_REGISTERED:

          // Create a CBFC channel - send a request to the peer device.

          // Once the peer responds, CYBLE_EVT_L2CAP_CBFC_CONN_CNF event will come up on this device.

          CyBle_L2capCbfcConnectReq(cyBle_connHandle.bdHandle, PEER_DEVICE_PSM, LOCAL_DEVICE_PSM, &cbfcLocalParameters);

          debugConsole_puts("\n\rL2CAP channel connection request sent. ");

          channelState = CHANNEL_SENT_REQUEST;

          break;

        default:

          break;

      }

    }

    else

    {

      CONNECT_LED_OFF;

    }

  }

}

//----------------------------

0 Likes

As we are on the topic, what do you recommend for BLE 4.2 parameters to get maximum throughput?

0 Likes

Guess I stumped the experts.  I don't feel so bad now

0 Likes

Hello,

Apologize for the delayed response.

1. Could you please attach your complete project so that we can check why the packets are losing for every reconnection.

2. For BLE 4.2 maximum throughput calculation please refer to this thread which would be helpful BLE 4.2 max payload throughput

3. Maximum throughput for a device will mainly depends on No. of packets per connection interval and Packet length(which is Data Length Extension). The lowest connection interval allowed by spec is 7.5ms. This interval is supported by some smart phone devices, while others devices does not seem to allow intervals below 37.5ms. And the No. of packets per connection interval will be varied for different smart phone devices.

Thanks,

P Yugandhar.

0 Likes

Thank you for your response!

Is there a way that I can send the project privately?  Client will not allow me to publish on the forum.

Thanks for the answer on throughput settings.  Since we are using the PSoC 4BLE for both sides of the connection, I have set the connection interval to 7.5, the MTU to 498, and MPS to 251.  Is this the recommended for PSoC 4BLE to PSoC 4BLE communications?  I had looked at the article that you referenced and noticed that it had a longer connection interval of 37.5ms.  I had assumed this was because of a connected phone limitation?  7.5 still better?

Because the BLE lib is closed source, I am not sure what gets negotiated during a connection that might change from connection to connection, if anything.  Do you have some insight into that?

0 Likes

Hello,

I will create a tech support case for you please share your complete project there.

For the L2CAP credit based flow control, we can have good throughput with MTU to 492 and MPS to 247 bytes and this will utilize the complete TX packets. We can use the connection interval to 7.5ms. Some of the phones have connection interval limitations to minimum of 37.5ms.

Please refer to the section 5.LE Data Packet Length Extension in the datasheet for more information on link layer packet format.

Thanks,

P Yugandhar.

0 Likes

Thank you for the BLE 4.2 L2CAP tuning numbers.  This will be very helpful.  I'll drop the code for you when I get the ticket.

Thank you!

-Andy

0 Likes