I'm implementing iOS library that reads heart rate sensor data using Bluetooth 4.0 (AKA Bluetooth Smart AKA BLE).
I noticed that RSSI value is being updated only on demand (readRSSI) - otherwise is't always the same.
My doubt is: "Does reading or RSSI cause additional request to the sensor?".
My consideration is about power saving of the device.
I suppose my question is generally to BLE, don't think it's iOS-specific...
Any thoughts are appreciated.
readRSSI reports the RSSI being averaged over an active connection. So if you have a connection to your sensor, reading RSSI doesn't cause any additional overhead. Even if you aren't exchanging user data, your BT devices are periodically communicating to keep synchronized with an active connection, and RSSI can be measured from this ongoing communication.
If you are tearing down your connection, then yes, you will have to reconnect to actually measure RSSI.
Related
I have an app that acts as a Bluetooth LE peripheral. I have a single service with four characteristics. 2 out of the 4 are read and write only, the other two are configured as notify.
If I subscribe to one of the "notify" characteristics then the app will not disconnect until I do so manually, works well.
My issue is, If I read or write to the other characteristics, and the then am inactive for around 30 seconds, the BTLE connection disconnects from the peripheral. This may be a limitation set by apple, not sure.
Anyone know of a solution to keep the peripheral active even when there aren't any subscribers and no read or write command has been received in 30 seconds??
This is a by-product of the BLE 4.0 specs. Bluetooth Low Energy is explicitly designed to not maintain a connection for long periods which is what you are describing.
The only way to bypass this (beyond subscribing to a characteristic as you have found) would be to modify the implementation of the BLE stack on the peripheral you are connecting to and removing or elongating the interval of connection to a point that you find satisfactory.
Although this may not help you either as both sides of the BLE communication negotiate these values and iOS may impose a maximum below your requested threshold.
In my case reason was in a mismatch between characteristic properties. I wrote data to a characteristic with "waiting for response" option, but characteristic was in 'without response' state.
The symptom: write callback in delegate does not work when BLE peripheral did not write a response.
I am working on a project where I first wanted to advertise a device as an iBeacon and make it possible to connect to that device via Core Bluetooth at the same time. Besides the fact that this is not easily doable (a device cannot advertise as an iBeacon and CB device at the same time), I noticed that the iBeacon part seems unnecessary - discovering peripherals with Core Bluetooth seems to be basically the same as discovering iBeacons.
My first Question: Am I right in assuming this? Or does iBeacon provide anything that central/peripherals in CB do not? Especially in regard to background advertisement/searching?
The only issue I can see right now is that the CLBeacon gives me both an rssi and an accuracy (and from this, the approximated proximity is calculated). With Core Bluetooth, centralManager:didDiscoverPeripheral:advertisementData:RSSI: gives me only an RSSI. Is there any way to retrieve the accuracy here so I can calculate a proximity? This is important for me and I guess relying on RSSI only for the proximity will give me less accurate results?
My second Question: Can I get the accuracy that I get with iBeacon in Core Bluetooth or a similar measure to calculate the proximity?
You can calculate your own distance estimate with RSSI using an algorithm like the one I posted here:
https://stackoverflow.com/a/20434019/1461050
The trick is that you will need as many RSSI measurements as possible averaged over a time window of 20 seconds or so to reduce the noise on the estimate.
The main advantages of using CoreLocation APIs to detect standard iBeacons vs. using CoreBluetooth to detect custom beacons are:
A variety of cheap off-the shelf hardware is available for the iBeacon standard.
CoreLocation can scan for iBeacons in the background (likely using hardware assist on iPhone 5+) in a way that can automatically launch your app relatively quickly, even if the user did not manually launch it since boot. As of iOS 7.1, even if the user kills the app from the task switcher, CoreLocation can re-launch it into the background if an iBeacon is detected. I do not believe all this is possible with CoreBluetooth.
The iBeacon transmission allows you to easily read the UUID/major/minor identifier combination in iOS without pairing. This 20 bytes of data (with the major and minor fields able to be set to arbitrary values) is more than you can get from a 16 byte Bluetooth Service UUID.
You don't have to roll your own software for distance estimation.
Apologise for the probably use of the wrong word in my question but for the life of me I can't think of the right one.
Anyway, I've been playing about with the Bluetooth Low Energy and I'm trying to create something that is going to use the RSSI signal strength the BLE device emits. For this, I need it to emit its pulse multiple times per second.
Is there a way I can up the amount of times my devices either scan for a signal, or broadcast their signal through code on iOS devices?
No, there is no API for you to change the advertisement speed or radio power.
This aspect is fully controlled by the system. You can only start and stop the advertisement and add some metadata to the packets: device local name, advertised services, etc. Moreover, the contents of the advertisement packets will differ depending on whether your app is in the background or foreground and, additionally, in background it will be slowed down. These effects have been documented in various SO questions and in the header files.
If your clients are iOS applications, then they should use either the RSSI in the advertisement packets (centralManager:didDiscoverPeripheral:advertisementData:RSSI: method) or when connected, the readRSSI method on the peripheral object (just make sure you don't call it too often).
I am developing a system to locate an iPhone indoors. I am considering using Bluetooth triangulation based on signal strength.
Is it possible to get the signal strength of nearby bluetooth devices on iOS 6?
Is it possible to get the phone's bluetooth MAC (so I can identify the phone and do signal strength measurement from the other side)
Any other ideas to calculate position of iPhone based on bluetooth triangulation?
It's for a restaurant type app. The restaurant wants to know at which table the phone/app is sitting.
If your iOS device supports Bluetooth LE, you can easily obtain the RSSI between it and sensor stations, as well as a UUID for identifying the device. You can also read the MAC address if you're using the right software on your sensor side, but I don't believe that this information is exposed by Core Bluetooth in the same way that RSSI and UUIDs are.
There are two ways to approach triangulation if using Bluetooth LE. One is to do the triangulation by monitoring the iPhone from a series of placed sensor locations, and the other is to do triangulation on the iPhone itself by reading the signal strength between it and devices that are advertising from known points.
The latter can be done by placing a series of LE peripherals in known locations and having them advertise at regular intervals. Within the advertisement information, you could stamp the location of that peripheral in the room. The iPhone could read these advertisements, get the RSSI information from them using the -centralManager:didDiscoverPeripheral:advertisementData:RSSI: delegate method, and triangulate its location.
The former approach would be a little more involved. It would require that the iPhone itself be placed into an advertising mode using the new iOS 6.0 support for making the iPhone a Bluetooth LE peripheral. The sensor locations could then pick up the RSSI from them to the iPhone via these advertisement packets, as well as a UUID you generate for the phone. You can also pick up the MAC address of the phone is running the right software on the sensor nodes. A central server would then need to combine these readings to triangulate the iPhone's location.
You might need to experiment with the transmission strength to determine what kind of resolution this would provide. The RSSI information is noisy, and in my experience it only seems to resolve to +-30 feet at the normal transmission levels for my peripherals. You may be able to improve upon this with multiple sensor stations and a lower transmission strength.
Having looked upon the CoreBluetooth V4, not sure if i have missed to get the standard information about how may observers [ my case iPhone] can be bonded with single Bluetooth Low Energy Device?.
If peripheral could able to bond with multiple observers, then could it not be considered as a security issue ?
Kindly provide suggestion.
A peripheral device (the observed) can only have a single connection at a time. The number of devices that it can bond with depends on the HW and SW of the peripheral. A central device could even configure the peripheral to broadcast e.g. through advertising, rather than through a connection, to multiple listening devices.
Security and authorisation are required for bonding, what kind of security issue were you thinking of?
Here is an interesting use case:
1000+ runners at a marathon, say only ~10% have Bluetooth Smart sensors in their running shoes and a smart phone app to link to them. If a single user tries to poll for a connection to his shoe sensors, how is he going to identify them from the, potentially hundreds, of shoe sensors present in the environment?
;)