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.
Related
I use the BLED112 and want to make it act like a HID keyboard.
The BLED112 receives the keystroke from the Mobile. For example, "p".
Then the dongle act like a keyboard so we can see the "p" is written on Notepad of PC.
Sending data from Mobile to dongle is not matter. I have already done.
My problem is to send the keystroke event to the PC so the dongle works like a keyboard.
I want an example or the full guide.
Thanks.
BLED112 is a Bluetooth Low Energy dongle provided by Bluegiga (Now acquired by Silicon labs). If you have studied the BLED112 user manual and bluegiga API reference documents, you'd understand that there can be two possible ways to read/write data via BLED112:
Use bgscript
use the bglib library into your C/C++ application
BLED112 is enumerated as a virual com port. I don't recall the name of the windows application that comes with BLED112 but it sounded like BLEGUI or something. This application uses the APIs to handle connections, read and write events. In a nutshell, you need to implement the same thing that this application does. For that, you can leverage the logs it spits on the console. This log will help you with all the commands you need to send and all the response that you need to handle.
Then, you need to make your application communicate with the virtual com port over which these commands will be send and responses will be received at.
Once you establish this, you'd be able to display your keystrokes.
It is a substantial work if you haven't worked with BLE. But like people say, there aren't free lunches!
I am currently having some issues with connecting to my peripheral. The bluetooth module in our peripheral does not seem to be advertising a name initially. I've have found that once I connect to the peripheral for the first time it will update the name and my scanner is then able to see the correct name.
I have no understanding why this is the case. I have also tried it using the Swift app we are developing, as well as a range of Bluetooth scanners on iOS and Android so I do not believe that this is an OS or programming error on the scanner side.
Is there a specific parameter that should be set on the peripheral. As I am just the app developer I do not have very much understanding about how the module is handing the process.
Any help would be much appreciated.
Just to confirm the scanner does not see a name for the peripheral until it has connected once. After this it will start displaying the name. Once the peripherals name is changed the old name is still being displayed until I have connected to it once again.
To display the name of device you need to see in advertisementData Dictionary which contains several keys depending on your device, in callback of didDiscoverPeripheral from CentralManager.
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary<NSString *, id> *)advertisementData RSSI:(NSNumber *)RSSI
You can look for key CBAdvertisementDataLocalNameKey.
If you do not see the name, you can make changes in your firmware to include a name in GATT characteristic .
You can use LightBlue app to verify once. This is a good app on app-store to test your BLE device.
We've got a use case in which a BLE connection is used to do the basic configuration of an embedded device via an Android app (later also via an iPhone app). The embedded device runs Linux and thus uses BlueZ as Bluetooth stack.
Using the DBus-API of BlueZ, bonding is made possible by making the device pairable, discoverable, and activating advertising. After bonding the apps can access the GATT services and characteristics
(which require bonding to be read/written) on the embedded device.
After the setup is done the bonding of the device (running the app) that managed the setup process, is supposed to be removed. In order to do that we call RemoveDevice() of org.bluez.Adapter1.
The BlueZ documentation states the following
void RemoveDevice(object device)
This removes the remote device object at the given
path. It will remove also the pairing information.
Still the app is able to access the GATT characteristics afterwards.
If bluetoothctl is used to check the list of paired devices, the list is not containing that device anymore though. Before calling RemoveDevice() the bonded device was visible there.
If bluetootd is stopped and restarted the app is no longer able to read/write the GATT characteristics, but needs to re-bonded before doing so.
I can neither find any further information in the BlueZ documentation nor can I find anything about this topic searching anywhere else.
Is this intended behavior or is this a bug? Does "remove pairing information" also mean "remove bonding information"? If this is intended behavior, how do we properly terminate bonding with a device?
Should I use the BlueZ Management API instead of the BlueZ API? I'm not sure about this as multiple source state that the DBus-API is the way to go.
RemoveDevice() indeed removes the bonding information as well. So you have to disconnect first and then call RemoveDevice(). The next time you connect the bonding information will be gone.
However, note that if you only make use of encrypted characteristics, you can still connect and discover services. Only once you start reading/writing the encrypted characteristics will Bluez check if you are bonded.
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.
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.