Forums

Hi Kazola /Karl,

Even I am facing the same issue ,Kindly revert back ,

Thanks in advance for your valuable reply

Regards,

Senthil

Hi!

I would try values around 10 at least.

If not, I've experienced several issues with connection events.

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 10

#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 10

This should transfer your data in much less than 15 seconds. Do not stress the CC2540. If not, try higher values.

Good luck.

Thanks kazola for your very quick reply ,

I had one more quesiton , i have read that transfer speed of BLE is 1 Mb/sec ,but practically we could able to achieve only ~4 Kb/sec.

May i know under which circumstance that 1 Mb/sec (PHY layer data rate ) and 305Kb/sec (BLE data rate ) is calculated ? 

Please find the document(BLE_TechDay_2011.pdf)  in the link below , 

http://e2e.ti.com/support/low_power_rf/m/videos__files/653594.aspx

refer the page number Page number 19 and 55 ,where the data rate of BLE is mentioned .

Thanks again

Regards,

Senthil

Hey Senthil, thanks for the link :)

In the TI BLE implementation, you are going to achieve 10kBps at most (kilobytes per second).

The different with 1MBps is that this value is the raw theoretical capacity of the BLE PHY layer.

Around 300kBps is the theoretical capacity of the BLE APP layer, and you will not reach this neither :) Perhaps with other chips, but not tiny embedded things as CC2540, by the moment.

Please, close and verify the thread. New questions in new threads :)

Good luck!

Thanks Kazola for your reply.

I've tried couple of these values and minimum I could achieve is 10 seconds.

In my sendData function, I'm transmitting only 20 bytes. Could not transmit for 4 times in the same connection interval. And all the transmit failures are re-transmitted. I observed that If I've to transmit all the packets without fail, it takes atleast 10 seconds.

Again, here are my settings:

#define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 10

#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 10

#define DEFAULT_DESIRED_CONN_TIMEOUT          3000

I'm calling sendData at every 10 ms period.

The transfer speed is one issue, and another issue is supervision timeout. All the data transfer is successful most of the times. But soon after transfer, the link will be lost with supervision timeout. Is there any way to increase the connection interval once the data transfer is completed to keep the link alive?

Let's hear the opinion of others on this.

I'm able to achieve around 5kBps with BLE, sorry. Perhaps you are within a very crowded wireless environment?

Please remember 10 is NOT 10ms but 10 x 1.25 = 12.5ms.

Regarding the supervision timeout thing..... check the forum! Nick explained in this link the same issue you are facing :)

http://e2e.ti.com/support/low_power_rf/f/538/p/142874/515743.aspx#515743

Hi Vijay-

A couple questions for you:

Are you running this on your own hardware or on TI hardware (e.g. a CC2540 keyfob)?

Could you show us a sniffer capture in which this timeout occurs?

Are you using power management?

Are you using a 32.768kHz crystal on your board? If so, what is the accuracy of the crystal?

Failures like this are often due to clock drift, which causes the slave clock to become unstable and miss connection events from the master, though we see this less often in cases like yours with a short connection interval. This clock drift can occur if the board is laid out in a way in which there is noise on the 32.768kHz crystal input to the CC254x. Oftentimes sending a lot of data will make this issue worse.

Hi Willis,

    Here are my answers to your question.

    *  I'm running the code on TI's CC2540 Keyfob, as well as our hardware. Both are having the same performance.

    * I'm attaching the sniffer capture, which has data capture of 8960 bytes twice. And after 2nd attempt timeout occurs. Please refer to the attached file largedataxfer.psd

      6153.largedataxfer.psd

    *  I've enabled POWER_SAVING macro in my project.

    * Yes, 32.768KHz crystal is used in our board.

  Additional point of my observation -

       I reduce the connection interval to 6 and run my sendData function every 7 ms instead of 20 ms, I'm seeing the data 0x2300 bytes (8960 bytes) is being transferred within 5 seconds. From the sniffer capture, I can see the data is transmitted completely without error. After that I see BTool is dumping the received packets for the next 2 minutes (too long to wait for next data transfer command). After completing the dumping of the packets, BTool throws Supervision Timeout Is this the BTool overhead of processing the data.  But, if I'm slower in data transmission by increasing the connection interval to 80 - 800 (Min - Max) and call the event to sendData once every 20ms, the chances of timeout is very less. Is there any way to increase the speed without connection loss. By referring to sniffer capture, please suggest something.

Regards,

  Asha

Hi Asha,

May I ask, what is your slave latency setting?

I have seen a similar issue when using slave latency, I posted about it - http://e2e.ti.com/support/low_power_rf/f/538/t/196428.aspx

-Tyler

    I've set the slave latency to 0. And BLE stack is 1.2.0

Asha-

A few comments/questions:

1.I realized that you are still using the default connection interval of 100ms. After the connection is established with a 100ms interval, you are never sending the connection parameter update. To do this, you need to change the value of DEFAULT_ENABLE_UPDATE_REQUEST from FALSE to TRUE. This should improve your throughput significantly.

2. I would strongly recommend that you move to v1.2.1 (the latest version available at www.ti.com/blestack). They API is 100% compatible with v1.2, and it fixes some minor bugs in the stack.

3. As far as the supervision timeout goes, I can't really see anything wrong with what you are doing on the sniffer capture. One possibility could be that if there is any noise on the lines from the 32kHz crystal and the CC254x, it could cause clock drift which could then cause the supervision timeout. Does the timeout always occur at the same time, or is it somewhat random? Also, after you fix items 1 and 2 above please let us know if you see the issue still. Using a shorter connection interval would help reduce timeouts caused by clock drift, but would not fix the root problem.

Willis,

1. To get the sniffer capture of one complete 8K data and to show supervisor timeout occurs after completion of one or 2 packet transfer, I have set the DEFAULT_ENABLE_UPDATE_REQUEST to FALSE. This is taking 100ms connection interval.

2. I've tried by setting DEFAULT_ENABLE_UPDATE_REQUEST to TRUE. But with the updated connection parameters, the transfer fails after 3-4 packets (of 20 bytes each). I'm not even successful with one complete transfer of 8KB of data. When the same macro is set to FALSE, I'm able to complete the data transfer without any error. I'm also trying to set update gaprole parameter just before transmitting large packet and restoring back to higher connection interval once the transfer is completed. But even after updating the connection interval, it fails to transmit more than 4 packets. I may have to finetune the connection interval, to make atleast one full 8KB transfer.

3. Now I've moved to BLE stack v1.2.1

4. Regarding supervision timeout, depending on connection interval - when set to larger values the occurrence of supervision timeout is less. Whereas, with connection interval 80 - 80, after 1st or 2nd transfer of 8KB, supervision timeout occurs.

Sorry to keep popping in on this thread, but I have also seen the issue from item (2).  Please see 

http://e2e.ti.com/support/low_power_rf/f/538/t/183876.aspx

-Tyler