• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: send data rate more than 32Kbps on ble issue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: send data rate more than 32Kbps on ble issue

  • Subject: Re: send data rate more than 32Kbps on ble issue
  • From: Martijn The <email@hidden>
  • Date: Fri, 24 Apr 2015 10:10:44 -0700
@Nick,

From my experience / testing:
- There is an outbound queue. When I tested, I used iOS 8.1. If I would flood the queue, I would start seeing dropped writes w/o responses after ~20 packets of 155 bytes payload (158 including the ATT header). I have not tried using smaller payloads, so not sure if the queue is bound by number of bytes or by number of packets.
- That said, there is no API to let the app know when the queue is full (that's my bug report about http://www.openradar.me/radar?id=5845858713075712). It's unfortunate, because many stacks / APIs do provide this (Android for one). I think the spec describes Write w/o Response is unreliable, but IMO it's kind of silly if it's possible to detect when your local queue is about to overflow, to not provide a API for it... Especially since at the lower layers automatic retransmits and error checking is happening...
- Instead of a timed approach, I'm using a "number of packets in flight" counter (sliding window). I think the timed approach is tricky. This implies you'll need to do (async) acking. I've seen iOS devices (as master) start a connection at intervals between 15ms and 30ms.
- If you're going for throughput, negotiate a bigger (G)ATT MTU (search for MTU Exchange in the spec doc). Not all stacks can though it unfortunately (I heard that Nordic's can't at the moment).
- For throughput you also want to avoid "draining the pipe". This means you need to make sure there are always packets queue'd up, so the connection events can be stuffed as much as possible. Using a sniffer you can check how you're doing on this front.

Using these thing, I've been able to get up to 13Kbytes/s throughput ("one way at a time").


Martijn

Pebble: E-Paper Watch for iPhone and Android
http://www.getpebble.com
Tel: +1 (650) 308-9383

On Fri, Apr 24, 2015 at 2:36 AM, Nick Brook <email@hidden> wrote:
Hi Jason,

Because this queuing does not exist, I have implemented data transfer using timed intervals. I think this is the only/best way to do it? Anyway, it is causing problems because it seems to take longer on some Apple devices than others. 30ms between 20 byte chunks seems too fast, and that is pretty slow already. What do you advise?

Thanks
Nick

On 7 Apr 2015, at 16:31, Jason Conn <email@hidden> wrote:

Yep, this is on our //TODO list.

On Apr 7, 2015, at 8:22 AM, Nick Brook <email@hidden> wrote:

I filed a bug a while back relating to central -> peripheral data transfer, rdar://16419865, which was closed as a duplicate of rdar://16061239. iOS does not send out all data written to a characteristic when its queue is full. The only way to solve this problem would be to implement transmit queuing as has been done in CBPeripheralManager. I don’t understand why this is absent in CBPeripheral. Perhaps Apple expects us to be using write with response before sending the next packet, but this is impractically slow for data transfer, and as far as I know should not be necessary as the link layer acknowledges packets anyway.

Nick

On 6 Apr 2015, at 17:20, Jason Conn <email@hidden> wrote:

Interesting perspective. It sounds like we might have a fundamental difference of opinion on the purpose of BLE.

Either way, I’m sorry to hear of your frustrations - if you’d like to send me a list of bug reports that you filed, I’d love to take a look at the issues you encountered.

On Apr 2, 2015, at 6:03 PM, karel <email@hidden> wrote:

I haven't written to this list for a long time, in fact it's about two years since we gave up on BLE.

Yes, the spec will allow the transfer of a megabyte of data in about one and a half minutes, and it allows you to do lots of other cool stuff too. But the features which allow you to do these things are hidden from you by Apple because they a not mandatory in the spec. If you think you've got problems now, just wait until you want to connect to 100 medical data loggers in turn to collect their data records.
To be fair though, it's not just Apple who are the cause of the problem, companies who provide closed source stacks also put in many restrictions, just in case their customer were to do this or that. A classic case is this "able to cram in" feature
Martijn > You should be able to cram more than one ATT packet into one connection event
Martijn > (in my experimentation, I was able to cram up to 6 in one connection event when
Martijn > using the maximum MTU that iOS allows).
when I was looking at BLE, we could only cram in 4 packets; What? that's an improvement of 150%!!! Amazing! How do they get such big improvements?!?. They must be experts!! (changing a #define MAXBLAHBLAH 4 to #define MAXBLAHBLAH 6)

The reality is, the industry has adopted BLE to be a switch or a thermometer or a signpost, or in my language a baby carriage. An engineer inspecting this baby carriage will find a Formula F-3000 racing car inside, but then discover that the accelerator has been removed, the fuel line cut, and a handle attached to back. Yes, you put the baby in the "driver's" seat and then push it along by the handle.

In short, it is wrong to think of BLE as anything more than a Mickey Mouse version of,  well,  anything you can think of.
If you push the limits now, your App will probably break when the next version iOS comes out.

On 2015/04/03 1:42, Martijn The wrote:
You should be able to cram more than one ATT packet into one connection event (in my experimentation, I was able to cram up to 6 in one connection event when using the maximum MTU that iOS allows).

Martijn

Pebble: E-Paper Watch for iPhone and Android
http://www.getpebble.com
Tel: +1 (650) 308-9383

On Thu, Apr 2, 2015 at 5:12 AM, steven lin <email@hidden> wrote:

---------- Forwarded message ----------
From: steven lin <email@hidden>
Date: 2015-04-02 20:08 GMT+08:00
Subject: Re: send data rate more than 32Kbps on ble issue
To: Martijn The <email@hidden>


hi ,
thank for your reply.

>13 KBytes/s in my experimentation
about this item, that mean iphone should be 13KBps(about 104 Kbit per second,104 bps). i only 16 k bits per second now  .


>flow control for CBCharacteristicWriteWithoutResponse
i don't miss any packets,but that send one packet every 10ms.
So,that is too slow on my request and i check it send every 1ms one packet in the phone.

Can you give me a common for these?

2015-04-02 11:37 GMT+08:00 Martijn The <email@hidden>:
> data rate more than 32Kbps
Should be accomplishable. I've been hitting rates of 13 KBytes/s in my experimentation.

> So, i think at iphone that have some limit on packet queue.
Yeah, empirically, I've experienced the limit of the outbound queue to be ~20 or so packets. Note that flow control for CBCharacteristicWriteWithoutResponse seems to be missing. So there's no direct way to know you've overflow iOS' queue. You can build it into your protocol (and you probably should because the other end might drop them as well) but it's annoying there's no way to know that iOS / CoreBluetooth is dropping the packets the app just gave it right away.

I've just filed this bug about it:
http://www.openradar.me/radar?id=5845858713075712

Martijn

Pebble: E-Paper Watch for iPhone and Android
http://www.getpebble.com
Tel: +1 (650) 308-9383

On Wed, Apr 1, 2015 at 5:58 PM, steven lin <email@hidden> wrote:
hi all,
i need to send file to my peripheral and need data rate more than 32Kbps for it.
but , i can't do that .
Anyone have suggestion about to it.


First,
i have know that data type should be set "WriteWithOutResp."
and build gatt service on peripheral; so,iphone as the central.
then in peripheral setting the connect interval 20ms(min :10ms ; max :20ms)
when start send packet, every 10ms send one packet from iphone .
so, that only 16Kbps on it .
every connect interval has two packet to send.
how to Increase packet number between connect interval.?

Second ,
i rebuild the system for measure that, and change the devices role.
(iphone as gatts(peripheral) ; devices on gattc(central)).
Set "Notify" on characteristic at gatts ,to send other data type .
But, that can't do it also.

So, i think at iphone that have some limit on packet queue.

Platform:
iphone 4s
ios 8.2

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden




 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Follow-Ups:
    • Re: send data rate more than 32Kbps on ble issue
      • From: Nick Brook <email@hidden>
References: 
 >send data rate more than 32Kbps on ble issue (From: steven lin <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Martijn The <email@hidden>)
 >Fwd: send data rate more than 32Kbps on ble issue (From: steven lin <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Martijn The <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: karel <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Jason Conn <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Nick Brook <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Jason Conn <email@hidden>)
 >Re: send data rate more than 32Kbps on ble issue (From: Nick Brook <email@hidden>)

  • Prev by Date: Re: send data rate more than 32Kbps on ble issue
  • Next by Date: Re: send data rate more than 32Kbps on ble issue
  • Previous by thread: Re: send data rate more than 32Kbps on ble issue
  • Next by thread: Re: send data rate more than 32Kbps on ble issue
  • Index(es):
    • Date
    • Thread