I want to advertise a single id lets say "stackoverflow1" on a ble device. So people close to the sensor can get this message (welcome to wwdc2012) as popups on the iPhone. That's it! meaning that there is no update on the value or anything else in other words I just want to know which room I came in. In another room there's another sensor adversing "stackoverflow2".
Now the question is, should I put the rooms' sensor (advertiser) as Peripherals and visitors' iPhones as Centrals?
If your answer is yes, can I send this Id in advertising packet? i.e. can I skip connection to the room's peripheral? Please guide me a little but on this
Thanks
Yes, the iPhones should be centrals and the in-room device should be a peripheral. It's perfectly fine to put enough data in the advertisement that the iOS app can do something useful after simply seeing the peripheral advertised without actually connecting to it. That way, multiple centrals/phones can detect proximity at once without a single phone tying up an exclusive connection to the device. Instead of specifying the room in the service name, you should be able to put it in the advertisement data for the device, giving them all the same service name. That way the iOS app doesn't need to know the completely list of rooms (i.e. services) in advance and they can be added to without changing the app.
In short, the gist of what you described should work fine, and seems like a sound approach to me.
You can include information in the advertisement from the peripheral as "Manufacturer Specific" data. Then the iOS application can get it from the advertisement data dictionary using the CBAdvertisementDataManufacturerDataKey.
Related
I have two BLE devices with the same UUID. Is there any way to connect to both of them so that they are both connected at the same time?
Right now I'm not able to even see both devices simultaneously using a bluetooth explorer, so I assume for the system they appear as just one device. Is it still somehow possible?
I assume that with UUID you mean the MAC-Address (Bluetooth address) of the device. UUIDs are typically used for services and characteristics.
All connection procedures work with the Bluetooth address as the main parameter. So two devices with the same address will be treated as the same device. (In fact, it is a common requirement that MAC-Addresses of Bluetooth devices should be unique, exactly for this reason.)
So it is not possible to connect to two devices with the same address at the same time. (*)
You can find more information about how connection is done in the Bluetooth Core Spec, Vol. 3, Part C, chapter 9.3.5 - 9.3.8.
(*) This is meant in the common way of having a connection to two different devices. Since incoming messages are not distinguishable on Link Layer level between the two devices with identical address (your control will always think there is only one device with the given address out there), you could mess around with this fact, especially in non-encrypted connections (since encryption is negotiated on a device-to-device basis, another device could not join in an encrypted connection, even if it has the same Bluetooth address). But it is definitely not recommended to do so.
If two devices are having the same UUID , then I think they would be consider as a single device. What I would suggest , send a trigger notification to the UUID and check which device will respond first . Secondly , try to send notification to devices put them far apart . The nearer to your smartphone/bluetooth explorer , will get notify first . Bluetooth works on the distance basis, the device which is near to the source will get the notification than the other one.I tried the same with Beacons but end up like you.
I'm writing a suite of Bluetooth Low-Energy app for iOS 7.
When the app launches, there's a fair chance the peripheral I'm interested in is still connected to the iOS device, and to avoid scanning for the peripheral it would be great to connect immediately. retrieveConnectedPeripheralsWithServices: looks perfect for this, and indeed seems to work as advertised: I get a list of CBPeripherals which are connected to the device via some backgrounded app.
So far so good, but here's the issue:
There's information in the AdvertisementData which I want, but I don't know how to get the AdvertisementData when going this route.
As far as I can see, advertisementData is only available as a result of scanning.
So my question is this:
* Given a CBPeripheral returned by retrieveConnectedPeripheralsWithServices:, how can I get the associated advertisementData for that peripheral ?
One workaround would take advantage of the fact that the device was likely connected to another of the apps in my own suite, so I could persist the advertisement data myself in storage shared between the apps, but this is neither clean nor ideal, because there's a chance the device was connected to someone else's app, and so I'd have no insight into the advertisement data in that scenario, and would need to resort to a scan.
Unfortunately, the advertisement data is available only if you scan. It is not possible to retrieve it from Core Bluetooth or any other framework in any other way. You should revise your design if the advertisement is so important and rather go along the scanning route.
I am currently writing an application that uses BTLE to pass small strings of data between 2 or more phones.
Currently in the foreground I am passing though: CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey. I am able to recover (via NSLog) the string passed through the CBAdvertisementDataLocalNameKey when the app is in the foreground.
However when the app is in the background, the CBAdvertisementDataLocalNameKey is not passed through. The BTLE UUID is still passed through along with the RSSI integer, the CBAdvDataChannel and the CBAdvDataIsConnectable.
After combing through what seems to be an unending circle called Apple Documentation, I have found no way to pass a small string while the app is in the background. It seems to me that they wouldn't allow BTLE in the background if there was no way to pass data.
My question is does anyone know a workaround to pass data in the background with BTLE or a method that may allow me to do so? Any help or tips would be appreciated.
Edit: I should make clear that the Library I am trying this with is called Vicinity https://github.com/Instrument/Vicinity which uses CoreBluetooth to get around the background limitations of CoreLocation.
You might get some use out of this project, which lets devices share arrays of strings (such as userIDs) over Bluetooth LE, even while backgrounded: SimpleShare
It can still share data while the app is in the background because it only sends the data when a device subscribes to the advertised bluetooth characteristic by changing the characteristic's value to send each piece of data. You don't need the name key to transfer the information.
Hope that helps!
iBeacons are not made for transmitting data between two devices. BLE beacons are used to determine the current location of an iDevice. to unique identify the beacon it broadcasts the advertising data, wich contains an uuid(32 hexdigits), a major(4 hexdigits) and a minor number(4 hexdigits). thats all. if you want to transfer data you have to use any other service.
I have a fitness app that is already in the app store and now I want to implement a bluetooth device that users can purchase if they wish. This is my first time dealing with bluetooth and after reading "Core Bluetooth Programming Guide", I have the following questions.
My app contains information that my bluetooth device requires simply to display the data. If I'm not mistaken, this makes the app the "Peripheral" because it has the data. The bluetooth device wants the data from the app so that makes the bluetooth device the "Central". Am I correct about this?
Finally, here is where I get confused. The bluetooth device has a button that I want when pressed to trigger the app to get the app to send new values to the bluetooth device. Is this possible? The reason I ask because in this scenario, would this now mean that the bluetooth device is the peripheral and the app is the central? If yes, will I have to break the current connection between the two in order to switch their roles (manager, and peripheral)?
Thank you in advance, really appreciate it!
Ted
As you have control over coding the app and coding the device, you can make it work either way around (Assuming the device is to be used specifically with your app and nothing else).
Both central and peripheral have methods to read and write data from/to the peripheral.
Without more information on the data and how often it's updated, it's difficult to suggest the best way to do it.
You say your device will have a button that will tell the app to send data over to it, well the app won't need to send anything it simply keeps values up to date then your button would tell your device to read the latest value.
Or (Again without knowing the purpose this may not suit) you do away with the button completely and your device subscribes to a characteristic in the app and is notified every time the value is changed by the app.
I'm developing an iOS app with an accompanying Bluetooth LE peripheral. The one step I don't seem to be able to solve is how to actually transmit the data from my app to the peripheral or vice versa.
What I've built so far is a test app that can connect to my sample Bluetooth peripheral, and read all of its services/characteristics/descriptors. It can toggle notifications for a given characteristic, and write to given characteristics. It is just this last step of "transmit n bytes to the peripheral, and receive m bytes from the peripheral" that I can't seem to figure out.
Looking at the External Accessory Framework (what I would use if Apple would actually give me MFi approval for this project), they give you input and output streams on a given session to communicate with the accessory, but no such object exists for CoreBluetooth.
Is this simply an oversight on Apple's part on the functionality of CoreBluetooth? Or do I simply need to develop my own Bluetooth service profile to handle the inflow/outflow of data to and from the peripheral?
LE is fundamentally designed to work with these GATT based profiles, which are suited for monitoring sensors, not for data streams. While LE does allow for additional L2CAP streams to be opened for custom protocols, Apple's CoreBluetooth doesn't provide access to do so.
You can build a custom profile with private services and characteristics and have it work kind of like SSP; that's the way I'm using my BLE module to get data from some sensors to my app. The module I bought (Microchip's RN-4020) already has a custom profile made specifically for this known as MLDP (Microchip Low-energy Data Profile).
The way I get the data in my iOS app is by subscribing to the private characteristic, thus being notified when the values are updated. So far it has been working great, and the data rate can go up to 20 kbps according to Microchip (I haven't tested its limits, since I don't need much speed). Here's a link to Microchip's product page: http://www.microchip.com/wwwproducts/Devices.aspx?product=RN4020
Good luck!
You can use the bluetooth.org 'Immediate Alert Service' uuid=1802 with characteristic uuid=2A06 with property=write_no_response to send one byte values to your peripheral device from your iPhone. The peripheral device must be programmed to act on the data that is sent. For example, you might use a button on an iPhone app to send a hex address that causes one or more port pins to turn on or off on the peripheral. While this is not using the Alert Service as it was intended, it does provide an easy way to test out data transfer to a peripheral device. The same process could be used to send sequential data bytes similar to a serial data stream. I have not yet tried sending more complex data streams. The write_no_response does not provide any feedback to the app as to whether the data was received by the peripheral.
The IOS TemperatureSensor.xproj is an example of code for reading temperature data from a peripheral. The OSX HealthThermometerClient.xproj has the code needed to decode the somewhat complex thermometer data structure. The IOS TI-BLE-Demo.xproj TIBLECBKeyfob.m has code for reading and writing characteristic values, such as, reading temperature or battery levels from a peripheral device.