Apple

On Tue, Jul 15, 2014 at 4:31 PM, Mike Wirth <email@hidden> wrote:

William and Spero,

Thanks for the comments. With them and reexamining the CoreBluetooth docs, I think I came to some useful conclusions. Will do some testing to confirm them.

Just to quibble and make a plea for precision in language, I have to comment:

On Mon, Jul 14, 2014 at 4:21 PM, Spero Koulouras <email@hidden> wrote:

The RSSI reported by CoreBluetooth is exactly what it says: The RECEIVED SIGNAL STRENGTH, measured on the receiving device. The receiver can be a central or a peripheral.

Well, yes, that's exactly what I was saying. The issue is "with respect to which device"? Perhaps you remember the never-ending arguments about CTS and RTS with RS-232 ports when the participants were assuming different ends of the connection :-)

Perhaps, part of my confusion arose from the CoreBluetooth method peripheralDidUpdateRSSI:error: from which I inferred that (or at least questioned if) the peripheral did the measurement. If I understand you correctly, this method name should be interpreted as "the iPhone received a packet from the peripheral device, measured the RSSI value of that packet and saved it in the CBPeripheral object's RSSI property. And if the app subsequently reads this property via readRSSI, the CBPeripheral's delegate will get called with this method to give it an opportunity to do something(?)" Whew! Complicated chain of events.

This does provide consistency with their usage of the delegate pattern and notion of asynchronous communication between centrals and peripherals.

But in any case, the "peripheral" actor in this scenario is not the remote device, but is at the iPhone end, arguably the local CBPeripheral object, Just think the method name is misleading.

RSSI is MEASURED by the bluetooth chip on the receiving device and reported up through the RSSI property. It is NEVER transmitted over the air, so there is no corresponding service or characteristic. The CoreBluetooth API's simply read the measured value from the chip and make it available in the property.

Hmm.... sounds a bit dogmatic. Would it be more appropriate to say "The current Bluetooth specs do not include a service or characteristic to report its RSSI measurements over the link, and probably won't in the future because "RSSI" is not well-defined, ...." I can certainly define a private service to convey RSSI (or anything else I want :-)

I don't think can be dogmatic. It's simply a fact on how RSSI is measured. RSSI exists at a much lower level than Bluetooth. It's a physical layer characteristic of using RF.

BTW, without getting too far into NDA material, in the API docs, I see a red line through some entries, with an "iOS x.y" version notation next to them. Does that mean "denigrated as of that iOS version" or "won't be available until this version"? I'm presuming the former.

Sorry for the long screed. I have to compliment the folks at Apple for the tremendous usability of Xcode (compared with other IDEs) and the quality of their docs.

Just wait. Xcode is great in many respects but is not without its faults. At some point XCode will surely cause you to curse at your computer.