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.

CC2541 bitrate issue - too slow !!

Other Parts Discussed in Thread: CC2541

Hello,

I am downloading data file (about 150KB size) to device using OAD profile (SimpleBLEPeripheral).

It works OK but the problem is downloading is too slow (about 200-300 bps).

When I set PKT_INTERVAL = 50, the bitrate is about 300 bps.

If I set PKT_INTERVAL lower value, it stuck during the downloading process.

Which means, CC2541 does not give onCharacteristicWrite feedback.

I am desperate. Please somebody help me.

Any advice will be greatly appreciated.

Thanks.

BR,

YS

  • Hi,

    I think it's possible that you are using automatic parameter update to 1 second connection. This is default enabled in the SimpleBLEPeripheral example.

    Set the define
    #define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE // Was TRUE

    Best regards,
    Aslak

  • I have a similar problem. I am using the provided BIM, OAD Manager, the SimpleBLEPeripheral built for ImgA and ImgB. I have updated DEFAULT_ENABLE_UPDATE_REQUEST to FALSE. It takes almost 3 minutes to download 124kB. This seems too slow. Am I missing something else? I was guessing that 2 blocks would be transferred per connection interval. Is that incorrect?

  • Hi Erick,

    The speed depends on your connection interval as well as the number of blocks. By default, 4 blocks can be transferred per conn interval. I'm not sure what OAD Manager does, it looks like it only sends one block per conn int.

    Optimal settings are perhaps 20-25ms conn interval and calling HCI_EXT_OverlappedProcessingCmd(HCI_EXT_ENABLE_OVERLAPPED_PROCESSING); as well as sending as many blocks as possible (call GATT_WriteNoRsp until status is not SUCCESS).

    You can try using the CC2540USB dongle with the BTool firmware (HosTest) and TI BLE Device Monitor to update from your PC instead of via OAD manager.

    BR,
    Aslak

  • Thank you for your response.

    So I took a look at the example code and when the OAD Manager handles the Block Request notification it sends a single block with GATT_WriteNoRsp. On the peripheral, it handles the WriteNoRsp by storing the block and immediately sending a notification to request the next block.

    I ran an experiment to test the block transfer rate. It seems that, with the unmodified sample code, a block is sent every (2*CONN INTERVAL).

    @ 10ms Conn. Interval - each block takes 20ms to be sent.

    @ 20ms Conn. Interval - each block takes 40ms to be sent.

    I will make the suggested adjustments and go from there but I have a question in the meantime. Is there a limitation where you can only send data in one direction on a connection interval? The way I originally expected communication on a single connection interval is as follows...

    Peripheral: Notification - Block Request #N

    Manager: WriteNoRsp - Image Block #N

    Peripheral: Notification - Block Request #N+1

    Manager: WriteNoRsp - Image Block #N+1

    Thanks

  • I made the suggested changes and got it to work. Only problem I have now is that I can't get it to work with a faster connection interval of 10ms. Every time I try to download at that connection interval, the connection is lost. Not that it is a huge deal but I was wondering why that might be. I just want to understand this.
    I modified the code so it will only send a maximum 2 blocks every 10ms and still account for errors. This works.
  • Hi,

    The reason it doesn't work at 10ms is that whenever a block is received that is at the start of a page/2k boundary, then that page has to be erased before writing that block. Erasing takes ~20ms and halts the processor which unfortunately will drop the connection due to the scheduler deciding it was too late.

    If you set the connection interval to 20ms or above when doing OAD you should be safe because the scheduler can lose one connection event due to late code execution and still recover, but balks at two or more. That said, you can also get away with lower intervals when 2xCI > erase time, but this is less deterministic.

    BR,
    Aslak