We're looking to build a small device connected to a sensor that transmits data to an iPhone, which subsequently takes the data, stores it and graphs it. However we want the iPhone to be able to change the polling data on the device by sending small amounts of data. I've been doing some reading and it seems like bluetooth LE does not allow for this type of streaming connection. Is this correct? Would switching to an Android platform be better? What would you all suggest?
With Bluetooth LE, you have complete control over the flow, even on iOS.
That said, there are a couple of things to know:
BTLE devices only have read-only "characteristics" (but can be dynamic)
There is no way to "push" data, only notify a change to the listening devices
So instead of saying - "Hey, 'streaming_type' should change from 'wind' to 'temperature'", you would say - "Hey, 'streaming_type' has changed, come read it".
It is not specific to iOS, it is the way BTLE works. So if you want an iPhone to be able to control your device, your application simply needs to setup a BTLE "streaming_type" characteristic, and then update it when the user wants to change the type of data being streamed.
Your BTLE device would then look for this specific "streaming_type" characteristic, and go read it when it receives a update notification.
Related
I work on iOS application which is using BLE for communication with our custom made BLE unit.
We want to send specific commands via BLE to the unit automatically.
When user is near unit and specific criteria are met, the app should connect to the unit, "login" the user, send command via BLE and disconnect right away.
These specific criteria are based on manufacturer data from advertisement (i.e. the unit is in "available to login" state when manufacturer data has last byte 0x01, when it's "NOT available to login", last byte is 0x00).
In foreground, this mechanism works flawlessly.
We want to do this even when app is in background or terminated (swipe up in dashboard on iPhone).
The mechanism we have implemented:
the unit has capability of acting as iBeacon
when unit is NOT available for login, the iBeacon is OFF
when it IS available for login, the iBeacon will turn ON and wakes up application, upon that the BLE scan will start in background mode
background mode setting is bluetooth-central
Problem here is that no matter what I tried, the advertisement:
sometimes it's not discovered at all (looks like it's timing issue?)
when it's discovered, it does NOT contain manufacturer data
Did anyone come across something similar?
Any help is appreciated and have a nice day!
An app simply cannot read raw BLE manufacturer advertisement data when in the background on iOS -- the operating system prohibits it.
Two exceptions to this rule:
iBeacon, which itself is implemented as a specific type of manufacturer advertisement. An app can detect iBeacons in the background on iOS, although only four bytes of readable data (encoded in the major and minor fields) are fully usable. If you can modify your device to send information this way, it will do what you want. However you must use CoreLocation APIs to detect iBeacon, as CoreBluetooth does not allow reading manufacturer data from iBeacon advertisements. If you do use CoreLocation, you cannot use the detections to establish a Bluetooth connection with CoreBluetooth as the two APIs are sandboxed.
Overflow Area advertisements. Backgrounded iOS apps can read these special types of manufacturer advertisements when in the background but only if the screen is turned on. (It is often possible to force the screen on at specific times by sending a local notification.) See my blog post here for more info: http://www.davidgyoungtech.com/2020/05/07/hacking-the-overflow-area
An alternative to detecting manufacturer advertisements is to use BLE Service advertisements with attached data. For this to work, you'd need to define a 16 bit or 128 bit GATT Service UUID and send out an advert with attached data bytes. Eddystone beacon formats work this way, and allow detection in the background on iOS. This is probably the best approach if you can alter the BLE hardware.
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.
how is it possible to send data to an iPhone which acts as an iBeacon?
I am looking for an process as the following:
Search nearby iBeacons
Connect to some iBeacon
Exchange data between the devices
Does anybody know how to put the different bluetooth functions together to make
this possible?
thx in advance
Standard iBeacons are transmit-only devices that can be seen by mobile devices, but don't actually "connect" to them or exchange data.
But you can still do what you are asking if you have an app on all devices as well as a web service to do the data transfer. This would allow devices A and B to detect each other when they are nearby and exchange data. Here's how:
Your app on devices A and B alternates between acting as an iBeacon (advertising its presence with an application-specific identifier and a phone-specific identifier) and ranging for iBeacon signals including the application-specific identifier.
During its ranging cycle, your app on device A will detect an iBeacon transmission from device B, which includes both your application identifier and the device identifier of B.
App A then makes a "write" call to the web service with a source of "A" and a destination of "B", along with any data you want to transfer, like "Device A says hello to device B."
The app would also periodically make a "read" call to the web service. In this example, device B would read any information destined for B, and the web service would return a record that device A had send it a message with the data "Device A says hello to device B."
Because the same process is also running on both phones, this communication can happen both ways.
iBeacon is a proximity technology and isn't designed for data interchange. However, since the Bluetooth stack is going to be active on your iPhone acting as the beacon (so it can advertise its proximity UUID), you can use Core Bluetooth to connect to the beacon and exchange data between the devices.
Does it specifically need to use iBeacon technology? The reason I ask is that from reading your description of the process, you could achieve the same thing using iOS 7's Multipeer Connectivity. It's able to abstract out all the technical complexities of connecting 2 iOS devices together regardless of the interface, be it WiFi or Bluetooth. I've managed to build something similar using MCNearbyServiceBrowser, MCNearbyServiceAdvertiser, and MCSession classes.
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.
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.