1 Reply Latest reply on Oct 18, 2020 8:16 PM by PY_21

    Bluetooth Low Energy Throughput ¿rfcomm over l2cap?

    CoDo_2762431

      Hello,

      I have a project with a PSOC 4, specifically CYBLE 222014-1.

      I need to make a 100MB data transfer in a reasonable time. We are considering compressing the data but I don't think it can be reduced to much more than half.

      In the example provided by CYPRESS called "Project #024: Bluetooth Low Energy Throughput - Pushing the Limits" they directly use the l2cap layer.

      The problem is that this transfer has to be done between the MCU and an ANDROID mobile phone.

      Android has implemented an l2cap socket in the latest version of the API, specifically the 29 (Android 10). This version offers the functions listenUsingL2capChannel() and listenUsingInsecureL2capChannel(). Probably with these functions you can replicate the example shown between mobile and MCU.

      The problem is that it is not compatible with previous versions of ANDROID.

      On the other hand from API 5 there is RFCOMM support in android (listenUsingRfcommWithServiceRecord()). It uses the l2cap layer to simulate a serial port. RFCOMM is a layer superior to l2cap that was used in previous versions of bluetooth.

      I am not sure if the RFCOMM protocol can be implemented with PSOC 4 in order to have compatibility with previous versions of ANDROID.

      In this other thread the topic is discussed: https://community.cypress.com/thread/1942?start=0&tstart=0 indicating that it is not possible.

      I would like to have a confirmation if it is possible or not to use RFCOMM.

      The other alternative is to use the feature set offered by classic BLE. But here again the limitations of ANDROID comes into play. Although in other websites it is specified that for each connection interval you can send up to 6 packets (features), I have not been able to send more than 2. Since the MTU in ANDROID cannot be changed and for each packet you can send 20 bytes per packet, and this is a problem.

      Apart from these limitations, there can be a maximum of 89 connection intervals. Although in previous versions of ANdroid a connection interval of 7 was allowed in higher versions it has been increased to 9. If we multiply 9 by 1.25 we have an interval every 11.25 seconds and if we divide 1000/11.25 ~89 packets.

      With all this we have that 40 bytes per interval * 89 packets per second we have 3560 bytes/s. Without considering losses this speed is quite low.

      Given this case, is there any way to make this type of data transfer faster?

      Thank you very much.

        • 1. Re: Bluetooth Low Energy Throughput ¿rfcomm over l2cap?
          PY_21

          Hello,

           

          RFCOMM protocol is not a feature of Bluetooth low energy(BLE). Bluetooth classic uses the RFCOMM to provide emulation of serial ports over L2CAP as shown in attached image. PSoC4 BLE device won't support Bluetooth classic. So, it is not possible to use RFCOMM.
          With default MTU size 23 bytes, throughput will be less. Please refer to the section 5.1 in the datasheet for more information on the throughput calculation. As you said it is not possible to change the MTU size at the android side so you can check with changing the link layer tx/rx payload values at android device and in BLE component (TX payload size = min(MaxTxOctects of slave ,MaxRXOctets of master), RX payload size = min(MaxRxOctects of slave, MaxTXOctets of master)). Please let me know the observations after changing the payload size values.

          In Bluetooth 4.2, the payload size is 251 bytes (2008 bits) and the total time is 2500 µs that gives the theoretical throughput of 784 kbps with a proper MTU size.

          For a notify/writewithoutresponse property, below configuration will give better throughput:
          ATT MTU- 498,
          GATT Characteristic length- 495,
          Link layer max TX/RX payload Size- 251bytes.
          This will send 495 bytes of data in two LL packets.

           

          Thanks,
          P Yugandhar.