|
Hi Jason, as a scientist / hardware
engineer I don't really have an "opinion on the purpose of BLE".
For a given spec. and given hardware, one can determine what is or
is not possible. In fact, I am of the opinion that specs such as
BT BLE Zigbee etc etc be released as/with C code, so that with the
appropriate HAL the same code can be used on all platforms.
I have only submitted bug reports to BlueTooth.org regarding the
spec itself. Problems, such as restricting the number of packets
per connection interval, or not supporting target addressing in
Adv. packets, are not specific to Apple, so even if I were to be
able to get Apple to comply, I would still have to succeed with
T.I., Nordic, Broadcom, etc before I could release a product which
I would know to be usable in a wide arena.
Imagine if you were to make a printer which can connect to a Wi-Fi
network. You would not be in a happy situation if it would never
connect to a Cisco or IBM AP, or if it only connected to Samsung
Android phones at full speed, but with all other phones, whether
it connected at full speed, half speed or indeed at all, depended
on the phone maker or version of the OS. It is hard to imagine
something so dumb; everybody is on board with 802.11bgn, so why is
it not the case the BLE?
If you can't see now, how BLE is currently just Mickey Mouse, then
you are in the wrong field of work.
On 2015/04/07 1:20, Jason Conn 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.
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
|