I have looked at the BLE specification, and found that the Bluetooth SIG has predefined a number of services, like heart rate. I am just wondering if it is possible for me to define a service myself? If can, is there any example available? Thanks.
yes, it's perfectly possible to define services yourself.
Services and characteristics are all identified by a UUID. For example the BLE Services page lists all standardized services and the assigned UUIDs.
As you can see the Heart Rate services uses 0x180D, which is a 16-bit short form reserved for standardized services only. The only requirement when defining your own service is that you use a 128-bit long form UUID.
Use uuidgen (available on Mac OS X) to generate a random (unique) UUID yourself:
uuidgen
# example result: 94B01578-5603-4D5A-8DFF-9365A1C4AC93
You can use this to publish and identify your own service. This can either be done on your own custom hardware, or through software on iOS (since you mention core-bluetooth).
Create your CBMutableService:
CBUUID *serviceUUID = [CBUUID UUIDWithString:#"94B01578-5603-4D5A-8DFF-9365A1C4AC93"];
CBMutableService *myService = [[CBMutableService alloc] initWithType:serviceUUID primary:YES];
// add some characteristics, also identified by your own custom UUIDs.
Finally see addService: &
startAdvertising: on CBPeripheralManager to start publishing your custom service.
After publishing this service using an iOS device you can scan for and connect to that service using another iOS device or a Mac, using the CBCentralManager class.
Here's demo app with an example of setting up your own Bluetooth LE service on an iOS device: SimpleShare
You need to generate a UUID that's unique to your app's service. This site will generate one for you to use.
Related
I am using Core Bluetooth in iOS using Swift and Xcode with a Teslasz Fitness Tracker HR, which has the peripheral name "ID115Plus HR". This peripheral has a service with UUID 0AF0. However, that UUID is not present in the list of services on the bluetooth.com web site for GATT Services. I even searched the entire bluetooth.com web site for the UUID. It didn't find anything. Neither are the characteristic UUIDs -- 0AF1, 0AF2, 0AF6, 0AF7
I've been doing some work on my end with some of these generic and No-name Fitness Wearables. You have to subscribe to the characteristics before you can start getting data.
I’m using the custom gatt package found in movesense-device-lib/samples/bin/release/Movesense-custom_gattsvc_app_w_bootloader.zip for my project. I can't create my own package since there's a bug in the mac compiler.
I really need to the service and characteristic UUIDs for ECG (in fact if I could get the services/characteristics of the other features in the package that’d be great too)
There're links to a sites that give the uuid for certain characteristics and services, such as these ones:
GATT Services
GATT Characteristics
Unfortunately, since the movesense package is custom made, it uses different UUIDs. I tried backtracing them by writing a function on my client that pulls an arraylist of the services and the characteristics, but no luck :(
The custom_gattsvc_app is a sample app that shows how to use Movesense CustomGATTService to implement your own (or someone elses) GATT service. The sample shows how to do that by implementing the (partial) "Medical Thermometer" GATT service, nothing else.
To access all of the Movesense API over BLE you'll need to use the movesense-mobile-lib or implement your own protocol over your own GATT service. I'm not aware of any 3rd party ECG GATT service specifications.
The movesense-device-lib release 2.0 will include a sample that provides access to most of the Movesense API services and easy expansion over a simple GATT protocol.
Full Disclosure: I work for the Movesense team
I have a beacon device that broadcasts different UUID values based on a custom rotation scheme.
Usually, the developer has to set static UUID to be recognized by the app like that (example for iOS):
CLBeaconRegion *region = [[CLBeaconRegion alloc] initWithProximityUUID:uuid major:major minor:minor identifier:identifier];
I was wondering if there is a way to dynamically generate (or receive from a server) the UUIDs to be recognized.
Having said that I am still having difficulties understanding the internal mechanisms of how beacons are understood by iOS and Android. From my understanding, the BLE module of the phone forwards all well-formated iBeacons to the OS which maintains a list of recognized UUIDs. After a simple look-up and if a match is found the OS will bring the corresponding app to the foreground.
However, when does the app's recognized UUID(s) get registered with the OS? How often do they get re-registered? I would be grateful if anyone would point me to any relevant online material or at least the mention the mechanisms involved in this process.
On both Android and iOS registering for beacon ProximityUUIDs to detect amounts to nothing more than applying a filter on Bluetooth packets that match the byte pattern of the beacon and ProximityUUID. The important difference is that on iOS the operating system framework that does the filtering, CoreLocation, puts severe limits on the filters you can have. The iOS limits include:
You can have only 20 UUIDs monitored at any given time for a single app.
A device-wide limit of the first 30 UUIDs monitored gets hardware assisted fast detection. Later UUIDs to register get slower (several minute delays in the background) detections.
You cannot monitor or range for any UUID (global wildcard)
You can, however, change the 20 UUIDs you app is monitoring at any time -- even once every few seconds. The trick is that your app must be in the foreground to do this, or have a permitted way to run in the background to do this UUID rotation.
To register a UUID for monitoring on iOS, you simply declare a region with that UUID ( typically without specifying major and minor values) then call:
[locationManager startMonitoringForRegion:region];
To keep from going over your 20 region limit you also have to call:
[locationManager stopMonitoringForRegion:oldRegion];
On your old regions you do not want to monitor anymore. Otherwise if you go over the 20 limit you will not get detections on newly registered regions.
Of course, you may use a web service to provide the UUIDs for your new regions to monitor.
On Android it is much simpler -- you can monitor for all UUIDs by specifying a global wildcard using the Android Beacon Library and similar SDKs.
Full disclosure: I am the lead developer on the Android Beacon Library, the first beacon implementation on that platform.
In iOS 7, I am writing a core bluetooth app to get advertising packets from a series of peripherals. Each peripheral has an unique UUID in its advertising packet and is shown in the LightBlue sniffer app.
When I detect the peripherals in a central manager it assigns an UUID that is different from the UUID in the advertising packet.
According to the docs:
"The first time a central manager discovers a peripheral, the system assigns the peripheral a UUID, represented by a new NSUUID object. Your app can store this UUID and later provide it to a central manager for use in retrieving this specific peripheral. Peripherals are identified by NSUUID UUIDs instead of by the CBUUID objects that identify a peripheral’s services, characteristics, and characteristic"
Why does it do this?
Can I read the real peripheral UUID without connecting to the device?
How?
I think there is no such thing as a "real peripheral UUID". My understanding is that UUID (for the device/peripheral) is an Apple-specific concept, not a BLE concept. Take note of this discussion:
Corebluetooth, How to get a unique UUID?
OTOH, it appears that BLE devices do hold a IEEE-defined, unique MAC/BDADDR address. I was looking for a way to deploy platform-independent, static configurations of BLE devices. I was getting discouraged (Apple's UUIDs being +/- meaningless, and the MAC/BDADDR which can be obtained on most/all other platforms not being accessible from CoreBluetooth). Fortunately, I noticed that the "Device Information Service" profile (0x180A) contains a "System ID" attribute (0x2A23) which encodes the device's unique MAC/BDADDR address. I don't know if it is mandatory for a BLE device to expose this service, however.
As you can see from the specification System ID is optional in the Device Information Service
Link https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml
And in fact DIS itself is also an optional service, e.g. The Environmental Sensing Profile defines DIS as an optional service.
I would like to make iOS7 Application like MLB
I was reading Article is http://www.engadget.com/2013/09/27/mlb-to-use-ios-7s-ibeacon/
this article said to :
MLB application installed ,
Beacon(Bluetooth LE device) sendging Proximity UUID for MLB application,
MLB application make Passbook ticket or update ticket (and Lock screen update passbook)
This feature, Can only have one special applications for Apple authentication?
some articles said to :
Location based marketing and Passbook tickets
This particular application makes iBeacons an extension of the geofencing Apple enabled in last year’s Passbook, which lets an installed pass, ticket or loyalty card popup on the lock screen when you cross the geofence threshold of a defined GPS location. Using BLE, a merchant or other provider can define more targeted “micro-locations” to trigger an alert, in some cases requiring that you be in the presence of an iBeacon in order to validate a Passbook entry .
i don't understand 'particular application'...
iOS7 application can make publish passbook use iBeacon without user event?
(i don't know well english ;; sorry;;)
Bluetooth Beacons support is a new addition to iOS 7.
Rather than using GPS, it works by determining the phone's location relevant to a Bluetooth beacon. These beacons constantly broadcast a UUID that identifies them. Beacons offer more accuracy indoors as GPS doesn't work that well in covered spaces.
The standard CoreLocation framework defines a new class called CLBeaconRegion:
A CLBeaconRegion object defines a type of region that is based on the device’s proximity to a Bluetooth beacon, as opposed to a geographic location. A beacon region looks for devices whose identifying information matches the information you provide. When that device comes in range, the region triggers the delivery of an appropriate notification.
An apps can request to be informed when they are near these beacons. This is how the MLB app works. It is programmed to recognize these beacons and to provide the user with offers and information based on location.
In addition to support within apps, Passkit also provides the support these beacons. It works in roughly the same way. The pkpass file contains a list of UUIDs that identify various beacons and when the phone is near a beacon, the pass is shown on the lock screen.
You can read more about Passkit's support by looking at the package format guide
https://developer.apple.com/library/ios/documentation/UserExperience/Reference/PassKit_Bundle/Chapters/LowerLevel.html#//apple_ref/doc/uid/TP40012026-CH3-SW4
Hopefully that answers your question.