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
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.
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).
_______________________________________________
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
|