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

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

anneranch — Tue, 19 Nov 2024 17:45:16 GMT

Thank you. Then Affix for "version 2.6" is also old? Besides - I do not want to install it anyway _ I am still searching for source code for "hci_inquiry".

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

javagoza — Tue, 19 Nov 2024 14:31:17 GMT

No, version 2.6 is quite old; it's over 20 years old.

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

anneranch — Tue, 19 Nov 2024 13:53:45 GMT

My Ubuntu kernel is "6".

Is it same as 2.6??

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

javagoza — Tue, 19 Nov 2024 08:21:36 GMT

Linux kernel version history - Wikipedia

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

anneranch — Mon, 18 Nov 2024 18:16:30 GMT

There is more affix. Looks as "updated" from the previous doc.

Now for stupid question.

It has file for "Linux kernel 2.6".

My Ubuntu kernel is "6".

Is it same as 2.6??

nov25-1@nov251-desktop:~$ uname -srm
Linux 6.8.0-45-generic x86_64
nov25-1@nov251-desktop:~$

Download for 2.6 kernels
ChangeLog: affix, affix-kernel.

NB. Install affix-kernel package first and then affix package.
NB.2. Affix 3.X.Y are for 2.6 kernels only ! (Support for 2.4 kernels here)

Latest testing version (for developers) Package File to download Latest patch
affix for 2.6 kernels affix-3.2.0.tar.gz
Size: 468K, MD5 affix_320_sec.patch
Size: 1.9K, MD5
affix-kernel for 2.6 kernels affix-kernel-3.2.0.tar.gz
Size: 260K, MD5 patch_hci_3_2_0
Size: 901 , MD5

Latest stable version (for end users) Package File to download Latest patch
affix for 2.6 kernel affix-3.2.0.tar.gz
Size: 468K, MD5 affix_320_sec.patch
Size: 1.9K, MD5
affix-kernel for 2.6 kernel affix-kernel-3.2.0.tar.gz
Size: 260K, MD5 patch_hci_3_2_0
Size: 901 , MD5

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

anneranch — Mon, 18 Nov 2024 17:29:07 GMT

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".

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

anneranch — Mon, 18 Nov 2024 17:05:08 GMT

Thanks for reply. Appreciate your contribution.

[quote userid="190458" url="~/technologies/code_exchange/f/forum/55289/implementing-bluetooth-technology---in-c-c-code/225298"]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.

[/quote]

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

BigG — Mon, 18 Nov 2024 10:41:33 GMT

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

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

anneranch — Sun, 17 Nov 2024 02:28:35 GMT

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;

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

BigG — Sat, 16 Nov 2024 23:26:28 GMT

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

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

anneranch — Sat, 16 Nov 2024 15:09:19 GMT

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.

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

BigG — Sat, 16 Nov 2024 12:31:45 GMT

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

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

shabaz — Sat, 16 Nov 2024 05:44:27 GMT

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.

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

anneranch — Sat, 16 Nov 2024 04:53:32 GMT

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...

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

shabaz — Fri, 15 Nov 2024 18:24:17 GMT

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.