Would this be a good / proper place to discuss C++ Bluetooth programming?
I am getting little gun shy posting in "wrong forum " so I decided to ask first.

Yes if you can isolate it to a networking issue. There is also a 'software' and a 'Programming' forum. You might even start in the Linux Mobile forum.

Now mark this solved, kill it off, and post your query in a new thread with the information you need in the forum you choose. People aren't fussy, really.

OK,
since I am after bluetooth concepts and not necessarily after C++ code I like to keep posting here.

Ok, fine. I don't know your setup, your device, your problem, nothing. I'm half interested in this. because I know the networking in theory but you're expected to do basic searches yourself.

Lay it on. What are you trying to achieve? What's your system? What's going wrong?

I am "connecting " Raspberry Pi to PC via bluetooth.
My objective is to display data Raspberry processed on PC monitor.
I am not interested in using commands , I need all code to be included in C++ application running on RPi.

After much frustration I have managed to compile and run "BlueZ / HCI " library on RPi.

My first bluetooth task is / was to let RPi , I do not like to use terms host /server ect,."scan" for nearby bluetooth devices.

I copied few "tutorial codes" only to find out that they all use "HCI" functions which are NOT documented.
Currently I have implemented "hci_inquiry" function.
It DOES find the bluetooth adapter on my PC.

The "problem" is - it supposedly finds ALL nearby bluetooth devices. It does not!

I have bluetooth speaker connected to PC , just for test purposes.

So basically that is my current "stopping point" using HCI.


I have coded system calls to "SDP" , however , I have not analysed "SDP" abilities.

I'll brutally honest , I am not impressed with "BlueZ / HCI " - it may be OK for single commands but not to use in C++ code.
I actually read somewhere that "HCI " is thing of the past anyway.

So I need somebody who can advise me which technology / protocol or whatever you want to call it is optimal to use in C++ to accomplish my objective.

At this point I am not stuck on HCI , actually would prefer anything but HCI.

Cheers

You have my sympathies.

It's not just HCI, which possibly did the stuff back in the '90s, but most of the donkey work is done by daemons in X. I tried to get my own PC going just to see what the story was, and the result is this thread in the Slackware forum

I ended up with Bluez, Bluez-firmware, & blueman installed. Blueman relies heavily on dbus and Polkit. Bluez seems like the console app, including hciconfig. My first thought about hciconfig was that it was like pppd - remember that?

Presuming you don't pppd did it all for dialup modems via console. It was written, I guess by some university guy who didn't go home at night and required you to type 3 lines of options just to make a phone call and dial up. So everyone used front ends.

Are you running X on your RasPi? If not, you've seriously got to go grokking man pages on your Bluez utilities. And you'll need firmware for your device. Firmware is coded for your hardware, whatever cpu that uses. Blues uses these binaries

Are you running X on your RasPi?
Please elaborate on the above statement.

Perhaps my aversion against HCI is - it is used by everybody (hcitools my last "discovery" ) and NOT documented.

I need to get pass "hci_inquiry" to be able to talk about real C++ programming.

I just started using SDP , as a next step.

I am very confused with all these "protocols" (HCI is a protocol, right ?) as far as in what sequence they should be applied.
So far - first HCI (scan) than SDP to investigate connection properties / class.

Real question - what is a difference between "SDP" and "sdpd" ? Is "sdpd" equivalent to "SDP" or subset of "SDP"

Here is the reference link
https://people.csail.mit.edu/albert/...ntro/x604.html

I am not sure why some tutorials go from SDP to RFCOMM, but I'll get there someday.

It's a simple question, actually. Have you X resources available or just console stuff?

I thought bluetooth was the protocol. The idea was from IBM - a super-secure radio protocol, which of course was an almighty PITA to connect. I think they had visions of people like bankers handing around ultra-secure bluetooth keys to trusted clients, but everybody went the auto-discovery route instead.

Software suites are I think referred to as 'stacks.'
https://en.wikipedia.org/wiki/Bluetooth_stack The HCI stack seems to be the linux one, and seems to be awkward.
The sequence is: scan; identify a partner; pair with partner; transfer stuff.
On Documentation: Be careful what you wish for; If somebody wrote a couple of megs of simplistic crap, would you want to read it? What you probably will find is an API for the libs - an Application Programmer's Interface.

Thanks - I have a little issue with Linux terminology.
In case of connecting between hardware I prefer to say so - this client / server /host / local / remote / native is to vague.

Referring to "BlueZ as bluetooth stack" tells zip about communication protocol used.
I "grew up " with "RS232" and in those days nobody got too confused with a gizmo which took more than two wires to communicate.

Perhaps bluetooth uses too many "connections" - starting with my simple case - RPi connect to "adapter " via UART,
PC connect using USB "dongle" ....

And you are correct - I would not read "novel" , but simple - this is what function does , here are the parameters it takes and this is what it returns is not that much to ask for. This does not exists in "BlueZ STACK".


I did not invent the "novel" term - somebody posted that about Linux "grub".

Cheers

Look for the API. Search for the API - like I searched for bluez (bluez.org) and came up with http://www.bluez.org/bluez-5-api-int...porting-guide/

I confess I haven't grokked it.

Addendum
I realize that these forums are mostly for resolving specific issue.
My main reason for posting here is that I really want to understand how bluetooth works.

Even such simple function as hci_inquiry is a mystery.
How can a function return data about a device NOT physically connected to "calling hardware" WITHOUT connecting ?
Most usages of hci_inquiry JUST return SINGLE number of devices found.
The info about device found MUST be transmitted via a connection to the "nearby bluetooth " hardware.

In an essence - there is a connection , but then people use SDP to make another one. Why?

Perhaps starting with hci and then switching to SDP is not necessary?

Sorry to be such pain.

Here, you have to go back to the original API. You can bet there are different standards for Bluetooth (1.0) to Bluetooth-4.0. The higher ones are probably all backwards compatible.
Like wifi, there is discovery, and that reveals a certain amount. Pairing is another possibility, or non trusted transmission seems to be a way of brute-forcing the thing to work. "Shut up and use this key." I would guess that discovery is unencrypted and paired transmissions are.

Now if you go writing all this yourself as a novice, you're ambitious, or a twit. You'll end up like a nutty professor. So grab someone's libs and use that API. Have you tried the Python bluetooth stack? There must be one.

What business_kid said about learning how Bluetooth works.

I'll just point out that ultimately, Bluetooth is just radio. Two-way radio. Devices can detect each other in much the same way as radios can detect radio stations or televisions can display pictures. The complex part (that, yes, doesn't need to be re-invented...it's a known thing that can be read about) is what gets put on those radio waves to make devices be aware of each other and communicate with each other.

Unfortunately things are not progressing the way I envision.
There are way to many "disconnects" , perhaps being called "twit" is one them.
So let me just sign off for a while.

The quick way to get it 'out the door' is to use existing libs. I see it as a major effort to rewrite existing code. Sure, sign off - it's a mess, and here's where
my bluetooth thread ended up/