Implementing Bluetooth technology - in C/C++ code.

The pairing, connect etc are all done by GAP messages. In the diagram below, you can see that those messages are ultimately converted down to a payload that is wrapped with a header and checksum, and then launched over the air to the remote device. There will be a state machine that is executed on both devices, to get through the entire negotiation sequences, i.e. the protocol is implemented with those state machines. Everything in the large blue box is within the Bluez library. It is indeed complicated to follow and has poor documentation, but it does work, and there's not much choice, it is what it is. It would be a very large effort to write your own implementation from scratch, because there are tens of thousands of pages of Bluetooth documentation to look through.

Regarding the second question, there are several manufacturers who have implemented this in firmware for their devices. It's very old technology, google 'serial port profile'. If you wish to do it using modern BLE (i.e. Bluetooth LE) then the answer is usually proprietary, since it's not defined in the standard. You could look at typical example devices like Silabs
BGM220P, and the website offers example code to implement serial communication over BLE ( https://github.com/SiliconLabs/bluetooth_applications/tree/ea5d14cc4884a6d8f5c3af4345d430716433e72d/bluetooth_serial_port_profile  ) . But because that's proprietary, you'd have to hope there are drivers for it for the PC (or whatever hardware you are using), if you're not using their devices at both ends of the communication link. 

Thanks for replies , but that is NOT what I am asking about.

This approach is all wonderful theory  of "Bluetooth stack", no argument there. I am asking for how to follow the "Bluetooth stack" process using  ACTUAL C code.

Here is a "work in progress" code snippet :

pET->start();
dev_id = hci_get_route(NULL);
text = "dev_id \t";
text += QString::number(dev_id);
m_ui->textEdit_37->setText(text);
m_ui->textEdit_52->append(text);

sock = hci_open_dev( dev_id );
if (dev_id < 0 || sock < 0) {

...

// actuall scan restart timer
pET->start();

num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags);
if( num_rsp < 0 )
{
text = "\t\t\tERROR no devices found ";
m_ui->textEdit_37->append(text); // local
m_ui->textEdit_52->append(text); // TRACE

So my question would be :
"how do "hci_get_route" and "hci_inquiry"  functions implements / fits into the above "blue box" ,  or similar "blue box" for standard Bluetooth stack?

PS.

I understand there are differences between "standard" and "LE" Bluetooth implementation. I am pretty much stuck with "standard" due to my available hardware.

PPS.

I am still searching for current bluez version source code to analyze "hci_inquiry"  function...

Thats a pretty rude response from you when someone is trying to help.

It is not my fault you have trouble articulating what you actually want to know.

So my answer will be brief, and you can figure out the rest yourself.

Your snippet of code is already at the lowest level in the BlueZ stack. The aircraft has not taken off yet. The code is operating at the bottom of the blue box.

You're not going to be able to see the C code of what then occurs at a lower level, because that's going to run within hardware/firmware on the Bluetooth processor, not the PC. The state machine that churns away to work at that lower level is inside the Bluetooth processor.

You can google for an explanation of HCI to understand this. No links, because I'm leaving that to you to figure out. You might also want to pick up some competence at responding in a polite manner.

Can you explain why you decided to implement the Bluez stack as there are a couple other C++ options out there.

ARM Mbed had a C++ implementation of a BLE stack: https://github.com/ARMmbed/ble

https://github.com/arduino-libraries/ArduinoBLE (C++ for Arduino devices)

Otherwise mainly c implementations (one example):

docs.zephyrproject.org/.../bluetooth-arch.html

github.com/.../hci

I am  not sure I get the " why you decided to implement the Bluez stack". I run Linux / Ubuntu and "bluez" is standard  package implemented in Linux kernel. Hence I see no choise. I initially used Qt, but it is missing an option to "clear unknown database"  containing previously found remote devices, or  more accurately - I did not find it. That is part of my reason to go "as close as feasible" to HCI. Not being able to physically control the actually  scan for remote devices.

I believe majority of  "improved (? with GUI ) Bluetooth stacks " are all based on "bluez" anyway.

Ah ok. Now that makes better sense, especially the "not documented" part in your initial post.

I believe the answers to the questions you asked would depend on the device driver chosen. There are a number of different hci implementations.

https://elixir.bootlin.com/linux/v6.11.8/source/drivers/bluetooth

I cannot vouch for this research paper but it popped up following a quick google search.

https://www.researchgate.net/publication/345032366_Bluetooth_Stack_and_how_Linux_OS_handles_it

Otherwise another suggestion is to search for yocto implementations of Bluetooth. Tends to throw up some info.

https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/release/v23.1/sw/yocto/app-dev/bluetooth/bluez/bluez-common.html#scan-some-advertising-bluetooth-device-nearby

Thanks for reply. I am little confused by "depends on device driver ". Allow me to get back to what I have as starting point.  Using "bluez" or actually HCI - my code  determines "dev_id" . I actually think it is wrong term , but will accept it for now.  That has no indication of any "dependency / relation" of actual physical device. In your terminology - no device driver is involved.

Next (logical) step is to assign a socket to this "dev_id" - still no device driver is involved. I would actually say - "locating dev_id and assigning socket to it is the lowest, basic "access " to Bluetooth INDEPENDENT of actual hardware in use.

Am I correct or not, so far ?

Since I eventually need the Bluetooth address of the

local device I am currently implementing ( a copy, not my original code  ) / modifying the following code:

Unfortunately this code ADDS usage of "ioctl" , to HCI usage , which I am NOT ready to analyze.

// Create a hci socket

// combines hci_get_route and hci_open_dev

int hciSocket = hci_open_dev(hci_get_route(NULL));
if (hciSocket < 0)
{
perror("Failed to open HCI device");
return 1;
}

// Create int and pointers to hold results for later
int devCount;
struct hci_dev_list_req *devList;
struct hci_dev_info devInfo;

// Allocate memory for devList pointer. Based on HCI_MAX_DEV (maximum number of HCI devices) multiplied by the size of struct hci_dev_req, plus the size of uint16_t (to store the device number)
devList = (struct hci_dev_list_req *)malloc(HCI_MAX_DEV * sizeof(struct hci_dev_req) + sizeof(uint16_t));
if (!devList)
{
perror("Failed to allocate HCI device request memory");
close(hciSocket);
return 1;
}

// Honestly not sure why we have to do this here?
devList->dev_num = HCI_MAX_DEV;

// Send the HCIGETDEVLIST command to get the device list.
if (ioctl(hciSocket, HCIGETDEVLIST, (void *)devList) < 0)
{
perror("Failed to get HCI device list");
free(devList);
close(hciSocket);
return 1;

Asking about device driver was just a framing question to understand your hardware config, as in my experience not all implementations are exactly the same - they're mostly the same. Reason being, at some point in the process (as noted byshabaz) the device driver takes over to perform the actual scanning process and return a data structure back to the bluez software for your application. This scanning process continues until it receives an instruction to stop. Once it stops you will be left with a device list (struct hci_dev_list_req *devList;)

Then it's really a case of checking each item in the device list to see if one of the BLE peripheral devices matches your search requirements, or using one of the predefined filtering options.

Usually steps involve a "power on" or initialisation process, then a "scan on" process to capture a list or to capture a device that matches the filter parameters. Then there's a connection process and finally, if requested, a bonding/pairing process.

Based on your code, it appears you've allocated some memory for the scan list data structure based on HCI_MAX_DEV and have a check that the list received is not empty.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/about/

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/client

https://people.csail.mit.edu/albert/bluez-intro/c404.html

Thanks for reply. Appreciate your contribution.

BigG said:

people.csail.mit.edu/.../quote]

The above is my "template". It is basically C code and if it does the job I do not argue with it. Yes , it identifies  "local devices(s) " and "inquires" about "remote devices". At this time I have a small issue - I  am not getting "remote device name" when I have TWO "local devices". So it is back to "hci_inquiry" source code. I am getting flustered with"bluez" using interchangeably "dev_id" or "socket" without much warning.

I think I found the answer to my problems with Bluetooth.

https://affix.sourceforge.net/affix-doc/index.html

It is "unofficial" but seems to "go lower' than "blueZ".