• State Resolved
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1829 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.

CC2642R: Slow data exchange on the BLE Communication

Pablo Jean Rozario
Prodigy 50 points

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

Hi,

Sorry for the inconvenience, but, I have a problem that I spending days solving. It's two, but the second one I think it's a problem on the Android Application side.

First Problem: Data Throughput

I have a communication protocol implemented on a device, that has the FOTA. The firmware is downloaded over Bluetooth and stored in flash memory.

So, the average speed of the download is around 330 Bytes/second. I know, I have a protocol implemented, encryption, a flash writing time, and a response time (because the communication is synced by a OK, the next block is only sent when an OK is returned). But, I have measured in ms the time of the reception of the packet and it's around 60ms, and each block has a length of 160 bytes (firmware data) and 201 bytes (for all data with a header, etc).

And I have tested a bunch of configurations on connection parameters, that which the speed is more influenced.

The script that uploads the firmware, looks at the speed Disappointed

 

Look, below, I will post the code on the simple peripheral for send and receive. The application script on the Windows, is fast, when the response reaches, the next packet was fastly ended. But, the timing between the next packet, measured on the microcontroller, is 300-400ms.

Receive data from the Application.

Transmit data to the Application.

So, I can't think that the problem is here, but, let's go to the sysconfig configuration;

So, about this is that I can't figure out, so, if you can give me documentation, a road, or some tips to find to improve this communication speed.

Second Problem: BLE connection from App

When I try to connect from the app to the device, 25% of the connections failed :( but I think it's a problem with the Android Application and the advertising interval of the device.

But, it's that, if anyone can help, I will be very happy.

  • 0
    TI__Mastermind 25810 points

    Hey Pablo,

    Have you taken a look at our throughput central/peripheral examples? They were configured to maximize throughput.

    I don't see any obvious issues with your configuration. Do you have Bluetooth sniffer logs? If yes, we can analyze them to see if the problem is over the air communication or just an issue at the application layer. You could also add some GPIO toggles before and after the do-while statement to see how much time that takes to run to completion. The sniffer logs will also be critical in debugging the second problem as well.

    Can you clarify which SDK you are using?

  • 0 in reply to Ammar N
    Prodigy 50 points

    Hy Ammar,

    The code is based on the Simple Peripheral example, I'm using all the stack of the application of simple peripheral, just customized services, and small things to meet requirements. And all data is pushed Up to the application.

    I have installed the packet sniffer 2 and use the Wireshark, but, I only can log the advertising packets, and can't see the connection packets and data transfer, have you a tutorial to use the ble sniffer to the get the data packets and connections?

    The do-while statement is fast, I have measured them, and take around 10ms, I think, I will need to recheck them when going to work on the Monday, but ins't take much time.

    The SDK that I'm using is the SimpleLink CC13x2 and CC26x2 5.20

  • 0 in reply to Pablo Jean Rozario
    TI__Mastermind 25810 points

    Hey Pablo,

    Unfortunately packet sniffer 2 does not have the capabilities to help in this situation. If you have an Ellisys or Frontline sniffer, these tools are highly recommended when developing a Bluetooth LE application.

    I would take a look at the throughput examples for guidance on configuring better throughput.

  • 0 in reply to Ammar N
    Prodigy 50 points

    So, it's hard to buy a tool like this, I work in Brazil, and these products it's very very expensive, and I will talk with the team to acquire the tool soon. It's sad that the packet sniffer can't read communication packets.

    But ok, I will keep tracking the application to find the fault that causing the low throughput. If you get any information, I will be very grateful.

  • 0 in reply to Pablo Jean Rozario
    TI__Mastermind 25810 points

    Hey Pablo,

    I completely understand.

    Another method you can try to debug is to use an out of box simple_peripheral OAD example, and modify the connection settings to match your example. I know the Simplelink Starter mobile app also records the transfer time, perhaps you can use this as a second data set to confirm the calculated throughput is correct. You might also be able to use BTOOL for this, I am not sure if there is a "time elapsed" display on that tool.

    Have you tried removing the dependency on waiting for an OK to be transmitted back (this to me sounds like you are using indications)? If you take a look at our throughput examples, we use notifications and essentially flood the queue and do not wait for an acknowledgment that the packet was received. You might be doubling your time by waiting for the OK to be received before sending the next packet.

  • 0 in reply to Ammar N
    Prodigy 50 points

    Hy Ammar,

    I will make some tests with OAD and collect the throughput. 

    About the BLE, we are using notifications instead of indications. The OK/ACK is generated by the protocol that we've developed, and we need this OK, to sync with the fash timing. But, the timing is too slow for a short process.

    And, I can use the nRF52 DK to make the sniffer, this device can sniff the ATT and L2CAP packets, not only the BLE Advertise. So I will try to run the test ASAP to collect the logs on the Wireshark, to help us to find the problem.

  • 0 in reply to Ammar N
    Prodigy 50 points

    I have made a fota process and collected the LOGs. The Wireshark file is on the link bellow:

    drive.google.com/.../view

  • +1 in reply to Pablo Jean Rozario
    TI__Mastermind 25810 points

    Hey Pablo,

    Looking at the logs, I see a few things. The effective connection interval looks to be ~105ms and not 30ms. This will contribute to the added latency. On this, check to see what your central device is setting. At the end of the day, the peripheral can only dictate its preference (the central can decide what it wants the connection interval to be and reject an incoming request).

    Additionally, you can see a number of empty PDUs of delay in between each ATT write request. These empty PDUs are connection events where no data is transferred, meaning the MCU does not have data queued to transfer. This is another source of the additional latency.

    I would revisit these items to see what (at the application) is causing it. Again, take a look at some of the throughput and OAD examples linked in this thread (and available in the SDK) for some guidance.

  • 0 in reply to Ammar N
    Prodigy 50 points

    Hi Ammar,

    I found the fault. Was on the application that sends the firmware, was fixed by removing some delays. And, for some reason, the BLE plugin is setting the connection interval for max value. I change the max value for a lower time, and the data transfer is increased. Reaching 680-700 Bps.

    Isn't fast enough, but much better, and with the sniffer is easier to find where is the problem. Thank you so much for the support

  • 0 in reply to Pablo Jean Rozario
    Prodigy 30 points

    Hi Pablo,

    I am having the same issue you had. Could you go into detail on which parameters you changed or added please? Where did you change the connection interval value specifically? 

    Any help is much appreciated, I am out of solutions right now. Thank you very much.

  • 0 in reply to Ricola
    Prodigy 50 points

    Hi ,

    On the side of the server, I have removed some delays on the communication, which has caused troubles on the communication speed. And in the client, the CC2642 application, I've changed the connection parameters interval to 15ms(min) and 30ms(max).

    A suggestion is to insert a timer to generate counts, and measure the interval on some specific code sections, to be sure if the low throughput is on the communication exchange.

  • 0 in reply to Pablo Jean Rozario
    Prodigy 30 points

    Hi Pablo,

    Did you change the minimum connection interval in the initialization function of the server? Or is there a clock with a long delay somewhere else?

    For the client, did you have to add a parameter function to change the connection interval? I cannot find where that is configured in the simple serial socket client code.

    Thank you very much.