I have a wider range question here, so if someone could point me to a doc or article that could explain this, that would suffice. Needless to say, a days worth of googling has gotten me nowhere, and I could use a helping hand.
I am connecting to a BeagleBoard with BlueZ 5.9, and my intent is to:
Create a Gatt server,
Load it up with some writeable attributes, and
Advertise that server to connect to an android device.
I've created the Android app that will connect and operate as the central, rendering 3 basically complete. I don't know how the commands - the literal things to type - to initiate a Gatt server / create attributes on the BeagleBoard. I am knew to hardware writ large, so it is possible I just have my terminology completely incorrect - that said, any help would be a appreciated in completing 1 and 2, even if it is just a shove in the right direction. Thanks!
Your terminology is mainly correct.
Typically, a GATT database has the services 0x1800 (Generic Access) and 0x1801 (Generic Attribute) at least. The Generic Access service contains two mandatory characteristics: Device Name and Appearance. The Generic Attribute service should be empty.
Therefore, the minimal GATT database looks like this:
Handle Description
0000 Service: Generic Access (1800)
0001 Characteristic: Device Name (2A00, readable)
0002 Characteristic Value (string)
0003 Characteristic: Appearance (2A01, readable)
0004 Characteristic Value (16bit enum)
0005 Service: Generic Attribute (1801)
After these two services, you can add your own services. In your case, you don't seem to target a well-known service, so you'll create an own one.
First, create a 128-bit UUID, for example using the uuidgen tool on your Mac's command line
$ uuidgen
DCDF2725-56C8-4235-A4BC-F7951D5C3762
This will be your service UUID
0006 Service: Custom defined Service (DCDF2725-56C8-4235-A4BC-F7951D5C3762)
Then, you mentioned that you want several writeable characteristics. So, let's create another UUID for that one.
$ uuidgen
4C06C6F4-C90D-4C58-8E31-20C8C74FF832
And add a characteristic to the service
0007 Characteristic: Custom Characteristic (4C06C...FF832, writeable)
0008 Characteristic Value (hex, 20 bytes)
Your characteristic value shouldn't exceed 20 bytes, and you should select "Write Request" to ensure that acknowledgments of writes are sent to the central. If you choose "Write Command", writes may be discarded by either your phone's stack or the peripheral.
After you have defined this characteristic, you are ready to start coding.
I don't know the BeagleBoard SDK, but typically, you start by initializing the GATT library and additional modules (for example, to support writes, you have to initialize a second part of the library).
After this initialization, you register your GATT database. If you don't have a nice tool for generating the binary data, you may have to write them yourselves. That's explained in the Bluetooth Core Spec V4.0. Let's hope you can find an API that does the transformation for you :-)
When the registration is successful, you'll have to set the advertising parameters and can start advertising (consult your SDK's documentation and samples for this, again).
What happens now, is that at some time, you will get a callback that a connection has been established, and later, you'll get an attribute request for a given handle. Then, you just have to process the request by looking at the handle, the supplied value and the type of the operation (read / write). Don't forget to always return a success value or an error code in response to the request, as otherwise, you'll lock up the Bluetooth communications.
Normally, those Bluetooth chips always work with asynchronous operations. You'll send a request, and then have to wait until the request is completed before sending the next one. Remember that when programming, it saves you time :-).
If you want to try on Android first because it's more familiar for you, you can try the Galaxy S 4 with Android 4.2. It also has an LE peripheral mode - I haven't tested its reliability, though. The most reliable smartphone stack at the moment to act as LE peripheral is currently in iOS 7 - so it may be worth picking up an iPod touch if it's affordable to play around with it.
Checkout bleno, it's a BLE peripheral stack library I created for node.js recently. It currently supports Linux (tested with BlueZ 4.101) and OS X 10.9.
There are examples of how to use it here and here.
The key to customize gatt service is the daemon program bluetoothd of bluez.
I have described how to customize a gatt service in my blogger, please check it.
Related
I implemented the org.bluez.Agent1 interface using QDbus and I would like to set a fixed pin (that I will provide to the users) in order to authenticate all the pairing request and reject them if the pin is wrong. The agent capabilities should be "NoInputNoOutput" because the project will be deployed on the RaspberryPi 3 without keyboard or display. Is there a way to deal with this? Thank you
You should not initialize the capability as "NoInputOutput" for fixed key pairing. NoInputOutput means there is not display and there is no keyboard/UI possible for this device. Mentioning this capability for your Agent when registering with BlueZ means, instructing BlueZ (bluetoothd) not to call any Agent API for authentication.
This is typically useful to autopair without any manual intervention. You can see this sample code, which uses NoInputOutput capability to connect the device without any intervention.
What you need is "DisplayOnly" capability to instruct BlueZ to call "DisplayPinCode" or "DisplayPasskey" based on SSP support of your device.
You can implement DisplayPinCode/DisplayPasskey in your Agent to reply constant PIN always. So the Bluetooth device which tries to connect can use the same constant PIN for pairing.
Here Display Pin /Passkey is just the naming convention or hint to Agent developers to write wizard/UI or any form of display operations. But you can completely ignore the displaying operation and reply with static/constant 6 digit key for pairing.
Typically this Agent API is called by Bluez (in rasperry pi) when the device (iPhone/Android mobile/any bluetooth capable device) trying pair calls "RequestPasskey" or "RequestPinCode" from the device end.
We had the same issue in a project, and i moved on LE device do to the fact that apple device are only capable to connect to LE device for "safety" reasons.
I don't have that much ref to that but if this could help you in your researches.
We have bought BLED112 to interface our target via BT.
An android app interacting with target via BT & USB (HID).
We have used some Bluetooth communication to write a program and send data to dongle.
Now can somebody here having any experince in converting that BT data to a HID signal.
Have anybody tried that?
Is there any BGScript code which we need to write to achieve that?
Please let me know if the thought is completely wrong.
Referring to a comment above which states,
We are writing an Android App which can send data to BLED112 over BLE interface or GATT. My question is how can I convert that data (basically a command) to an HID (key event), correct me if my understanding is wrong?
If I understand the use-case correctly, I think, in the initial stages of the development, you will need to use the BLE-GUI utility that BlueGiga provides.
With that utility you can see the communication between the BLED112 Dongle and the BLE112 Module. BLED112 shall be simulating what the android app would do?
First, you will need to know the GATT structure stored in BLED112 to write to or read from the BLED112.
Secondly, the way BLE112 works is an event-based implementation. Going through the API reference document for BLE112 shall help you understand the events generation conditions and codes that are generated modified when a characteristic value is updated by the android application, or read by android application. You get events for connection, disconnection, read from, write to, notification enabled for, indication enabled for, etc.
On the BLE112 side, depending upon what service and what characteristics in that service is going to be used for data transfer between Client (Android App) and Server (BLE112), you need to write suitable implementation in event callback handlers.
There is a standard service called Human Interface Device which has a reserved UUID: 0x1812.
Once you configure your BLE112 as a HID over GATT device, your android app shall see a service with UUID: 0x1812. Parse the service descriptor and get the characteristics bundled up into the service. You can read from or write to that service depending upon access parameters set in gatt.xml
As an example, say, if it is a Keyboard, you can send the scancode for (make and break) of the key depending upon what key is pressed. How to get a scancode is out of the scope of this question anyway, and sadly I had worked on PS2 keyboards, so I don't really know how to get the scancode from a USB keyboard.
So, you have the scancode for the key pressed, and you know the characteristics to write that into. Write it, the application should enable the Notifications for that characteristics, so that it is notified whenever the key is pressed and value is written into the characteristics. To let application enable notifications or indications for the characteristics, study the developer guide that talks about how to write a gatt.xml for Bluegiga-based BLE devices. I'll give you a hint: in xml, in the characteristics configuration you have to write notify="true".
About parsing of the service and characteristics in Android, Unfortunately I am not an android developer, but an embedded developer, I know how the BLE112 module part is to be implemented, while I have no insight of how android parses the data. But, there are plenty of question and discussions about it online, which you might understand better than me since you have an android background.
As a 3rd party is there a viable way to correctly interpret data from a Bluetooth Low Energy device for which there is not a published GATT profile specification?
The BLE device is a body scale that supports weight, BMI, body fat, and hydration level. My understanding is that there is no adopted GATT profile for body scales like there are for, say, blood pressure devices or heart rate monitors (https://developer.bluetooth.org/gatt/profiles/Pages/ProfilesHome.aspx).
Using the following tools:
iPod (iOS 6.1.3) with various BLE utility apps (Ti BLE Multitool, LightBlue, and BLE Utility)
Android (4.3) tablet (Dell Venue 8 3830) with nRF Master Control Panel, plus a custom Xamarin developed solution
I can scan for, locate, connect to, and read the GATT services available on the scale. All of the above tools give me the same service information. There are 5 services discovered on the scale:
Generic Access (0x1800)
Generic Attribute (0x1801)
Device Information (0x180A)
Battery Service (0x180F)
An unknown service with a custom 128-bit UUID
All of the above tools are able to read from the known services, like retrieving the battery information or the device name. My assumption is that the unknown service with the custom UUID is the service that provides the scale data.
This service has 5 unknown characteristics with custom UUIDs:
Characteristic 1 is Read/Write
Characteristic 2 is Read
Characteristic 3 is Read/Write
Characteristic 4 is Notify
Characteristic 5 is Read
Using the tools that were specified above to read from characteristics 1, 2, and 3, each returns it's own value, but that value never changes. For example, a read of characteristic 1 always returns a value of 20 octets 0x01-0x05-0x06-0x07-0x08-and 15 0x00 octets. Subsequent reads of characteristic 1 always return that value. Characteristic 2 reads always return a value of 20 octets 0x02-and 19 0x00 octets. And so on.
Reading characteristic 5 appears to either not return a value, or more commonly on Android, issue a pairing request. No common pairing code (like 0000 or 1234, etc.) is valid.
Characteristic 4 appears to be what actually transmits the scale data. Using the tools above I can enable notifications and the applications retrieve 13 octets. For example:
FF-16-09-00-03-04-01-00-83-6F-F4-18-0F
FF-16-09-00-03-04-01-00-3E-88-F4-18-E3
FF-16-09-00-03-04-01-00-C8-89-F4-18-6E
Obviously all of those values begin with the same set of octets. The main problem though is what do those octets represent and how do they translate to weight/bmi/hydration/body fat values, if in fact they do at all.
The scale is built with the Ti CC2541 chip (http://www.ti.com/product/cc2541).
Using Ti's SmartRF Protocol Packet Sniffer along with the CC2540 USB Evaluation Module Kit I can capture packets going between an iPhone 5S (iOS 7.1) and the scale. This has provided some additional insight, but mostly just shows what I've already observed using the other tools, though albeit it at a lower level. Any additional information provided by the packet sniffer still leads back to the same question: what do these sets of octets the scale is sending represent and how do they translate to weight/bmi/etc? I've utilized the Bluetooth Core Specification documentation and that has helped to understand what octets for standard functionality mean/do, but that isn't helping understand the actual scale data.
I'm very new to Bluetooth development and this exercise has basically resulted in a crash course in the technology. Any help is appreciated.
Thanks.
You must contact the manufacturer and ask for clarification about the custom service and characteristics.
Characteristic 5 seems to have higher security settings, hence why it triggers pairing when you try to read it. Most likely contains some sensitive data.
Characteristics 1,2,3 are likely for configuration, while 4 notifies the useful data.
Since these are all custom, there's simply no way to find out what they mean without information from the manufacturer.
It's like you create your own "We're out of yogurt" notification profile... one can only guess by looking at the data.
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.
I am experimenting with Bluetooth Low-Energy (BLE) for the purpose of connecting a hardware device to an Android application. My goal is to send a recognizable piece of data to an Android phone.
I am using the keyfob from Texas Instrument's CC2541 Mini-development kit, and am programming it using the IAR Workbench (which I am learning on the fly). My issue is that I cannot figure out what code should be used to send data from the keyfob to the phone.
I understand that this is somewhat vague, but because of the non-disclosure policies of my company I cannot share the code that I am working with. Does anyone have any references to code for the IAR Workbench that will allow the CC2541 to send a piece of data? Right now, I prefer to use GATT if that helps.
Thanks, and please ask me more questions if I need to clarify anything.
Assuming you're working from a pre-existing service profile, there is a function for every service called ServiceName_SetParameter(). Calling that function will change the characteristic value. When the characteristic is read by the phone, it will receive this value. If the characteristic supports notifications, and your phone has registered for notifications on that characteristic, the new value will be transmitted whenever SetParameter is called.
You can implement any proprietary protcol to connect to and interact with your beacon device. It can assume other roles than just the beacon task. It can also listen to and respond to connection attempts thus expanding into a lot more than a regular beacon.
If you study the cc2541 close you realize it is a pretty advanced IO controller that offers a lot of IO signal possibilities. That way you could use the cc2541 as the heart of an IO control application where you measure and control equipment. Mobile apps can then easily connect to your beacon/IO Controller device and interact with the machinery it is hooked up to. As you see, it´s a remarkably versatile system on chip and a cool circuit to learn to program.