I seem to understand it is possible to customize HCI communication with custom commands (OGF==0x3f), but I wasn't able to find specific info about how to register such commands with BlueZ stack and, in general, specifics on how to handle them.
Can someone point me in the right direction?
A bit of background (ask if more is needed):
I have a fairly standard Yocto-based Linux installation I can control.
BLE is provided by a Nordic nRF52832.
Communication is via standard UART (btattach -S 460800 -B /dev/ttyHS0).
Since nRF is doing also "other stuff" and should report to main SoC some non-bluetooth data over the same channel (the only channel I have between the two processors) I need to multiplex.
It seemed adding custom frames is the simplest way, but I need details on how to proceed.
I need information mainly on the host/Linux side as I have nRF side "more under control".
Related
I would like to have a discussion about modifying Bluetooth stack and thinking about what are the important factors that should be considered in general. I have proposed some solutions related to the IP for Bluetooth and now I am in the step to decide which one is more suitable to implement. My different solutions could be implemented on top of GATT or as an adaptation layer on top of L2CAP or on top of Link Layer. My questions are
is there any difference in the energy consumption if the solution is implemented on the top of the Link layer or on top of, for example, L2CAP?
is the Bluetooth stack implementation open source? is the firmware of LL open source?
what else should I consider for the selection of the layer positions?
Is operating system important? why?
The Bluetooth HCI Commands and Events are interoperable; Only the vendor defined(proprietary) HCI commands and Events are not. Top of the HCI layer is called Host. Bottom of the HCI is called Controller.
For Example: BlueZ (Initated by Qualcomm and maintained by Intel now) stack is usually present on Linux. But the Bluetooth Controller might be from Broadcom. They are interoperable until the HCI commands follow the Bluetooth Specifications.
Both L2CAP and GATT are layers above HCI. The Power Consumption always is dependent on Application. Radio Modem and the CPU Core are the most power consuming part of the Bluetooth Communication. The CPU core needs to put the Radio IP to sleep whenever it is not needed. There needs to be an Idle Thread which monitors the application activity and put the Radio to sleep and wakeup.
Most of the Bluetooth Protocol are Finite State Machines and can be implemented using State (Event-driven) design pattern.
Do not give the memory management overhead to applications; it needs to be taken care by the Bluetooth stack.
There are couple of Open source BLE stacks as mentioned by #Youssif here.
I dont understand your 4th Question though.
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.
I need to display the status of the ethernet connection (eth0) on the GUI, i.e. is the link up or not.
I have a Davicom DM9000 PHY.
I know there are various ways to skin this cat, like parsing ifconfig, polling /sys/class/net/eth0/operstate, etc.
However, as I will need to monitor other devices also, like USB, I would like to use libudev for this as a more generic implementation.
Furthermore, I would like to use the monitor mechanism (using a select() ) and in doing so prevent having to poll.
I have wrapped the libudev functionality in a Qt class and intend on using signal/slot mechanisms to indicate events to my program.
Problem is, I can't seem to generate UDEV events from eth0 no matter what.
I have also tried using
udevadm monitor
but no events either when unplugging my ethernet cable.
I don't think my code is too far off, because I am able to generate events for USB (hidraw) devices by unplugging my keyboard, for example.
Also, I am able to see eth0's attributes using the libudev enumerate mechanism (but this is a polling process)
My question - is this possible, i.e. to use libudev's udev_monitor functions to catch events on eth0?
Sorry for the long post.
Have already looked at D-bus? Via D-Bus and underlying services you can get all the info you need. See this a little bit outdated article to understand the concept. See Qt/D-Bus documentation.
I've seen several references to this capability being available with Bluetooth 4.0/LE but I'm not sure where to start or how to implement it.
To be clear, I mean truly connectionless with only a receiver on one device and a transmitter on another. (or, more specifically a powerful transmitter on one device and a weak transmitter on the other, so the devices can be paired).
Something like the "Immediate Alert Service" sounds good, but is it too good to be true? It's difficult to tell over which layer a signal is 'connectionless'. Could anyone perhaps point to some documentation/implementation examples of this?
Take a look at the Core Spec V4.0 and do a search for "connectionless". There's details about using a connectionless L2CAP method.
I'm trying to use the bluetooth extended inquiry response to package a brief message, but I can't seem to find any API that allows access to this information (I'm language agnostic, I just need to find a way to get this to work!) nor any examples where this data is even being utilized. From what I have found, I BELIEVE that most stacks now send EIR data when they respond to an inquiry response? Although even that isn't really documented other than "this "supports" EIR. Is there anyone that can point me in the right direction?
FYI, I have access to machines running Ubuntu, Win 7, and probably a couple of other OS's if need be.
On Linux you can use the BlueZ utilities hciconfig and hcitool.
For hciconfig, check out the options inqmode (extended is mode 2) and inqdata. With hcitool, you can put a device in inquiry using inq.