qtconnectivity / btscanner discussion ?

[anneranch]

I would like to connect with someone who actually , physically coded bluetooth application using Qt "examples" qtconnectivity.
I am not looking for "RTFM" advises, I like to talk to somebody who especially used / cloned the "btscanner" example.

After few weeks of using QtCreator (and RTFM) I feel pretty confident I finally have the QtCreator / QtDesigner concept.

Now I am ready to actually implement my version of "btscanner" and could use somebody real experience understanding specifics.

For starters

After starting the bluetooth inquiry - discover near-by devices - I IMMEDIATELY receive first signal "device discovered " then after EXPECTED delay I receive second signal " scan completed".
That makes no sense - the "device discovered" should be received AFTER scan in completed.
This implies that "device discovered" signal is not emitted from after the actual scan is finished , but from some yet unknown data base filled previously.

This is just one starting "problem" I could use some assistance with , if it is a real issue. I do not know.
I am not asking for assistance with a specific code.

Cheers

[d_stranz]

I am not looking for "RTFM" advises

You've been told to RTFM because the questions you have been asking about Qt slots, signals, UI programming and other aspects of Qt have demonstrated that you haven't grasped some really fundamental concepts that only RTFM and studying the many, many examples and tutorials can teach you.

I have tried to give you suggestions and written example code on how to accomplish most of the things you have asked about. If that hasn't been appreciated, then too bad. I've wasted a few hours of my time. Fool me once, shame on you. I won't be fooled twice. Maybe someone else will be foolish enoungh to jump in instead.

As for your current questions, it makes perfect sense that a scan would return intermediate results as it discovers them before it announces that it is finished. These are hardware devices, each of which might take a different amount of time to respond to a "who's out there?" broadcast. As each one responds, "I am", the scanner reports that. Some might be fast and discovered immediately, some the operating system might already have identified for other purposes and can report immediately as well. I would imagine that at the OS level, it is frequently pinging devices that are paired wirelessly, so has a good idea which ones are still in range and connected. Others it might have to ping again to make sure. After a certain time has elapsed and no more devices have responded, the scanner quits looking and reports it is finished.

But then, I haven't RTFM either, so I'm just making stuff up.

[ChrisW67]

After starting the bluetooth inquiry - discover near-by devices - I IMMEDIATELY receive first signal "device discovered " then after EXPECTED delay I receive second signal " scan completed".
That makes no sense - the "device discovered" should be received AFTER scan in completed.
This implies that "device discovered" signal is not emitted from after the actual scan is finished , but from some yet unknown data base filled previously.

To quote the friendly manual,


To retrieve results asynchronously, connect to the deviceDiscovered() signal. To get a list of all discovered devices, call discoveredDevices() after the finished() signal.

and in regards to deviceDiscovered() :


The signal is emitted as soon as the most important device information has been collected. However, as long as the finished() signal has not been emitted the information collection continues even for already discovered devices.

If you ask for the asynchronous signal, as the btscanner example does, then the process runs something like this:


Scan starts
While (scan not complete)
If a device is discovered (i.e. an inquiry response received)
emit a deviceDiscovered() signal as soon as enough information is known
add device to discovered list
keep scanning
emit finished() signal

So, it is perfectly logical for the discovery signal to appear before the finished signal... (It seems illogical to expected reports of new devices after it is finished looking)
It is also possible the same device might be discovered twice but I do not know if that leads to more deviceDiscovered() signals for the same device.

The time from the start of scan (Bluetooth inquiry out) to the first detected device (inquiry response) might be measured in milliseconds, more than fast enough to be considered "IMMEDIATELY", or it may be coming from an operating system maintained list of active devices. Either way the device exists.

If you want a single consolidated list then wait only on the finished signal (after about 10.24 seconds I guess) and use the discoveredDevices() to list all discovered devices in one hit. You should watch the error signal too.



This is just one starting "problem" I could use some assistance with , if it is a real issue. I do not know.

Does not seem like problem at all.

[anneranch]

As I said in original post - this is first time I am actually analysing the Qt (btscanner) bluetooth process.
I still have some basic issues with Qt, but working on that.

The bluetooth process starts with "scan" and from the point it is up to the "discovery process", not something I can control.
Having used HCI directly before I am aware that the actual "scan for nearby devices " takes time , again controlled by HCI or "bluez" .
Hence the already mentioned sequence of Qt signals scan - list discovered devices - scan completed is NOT under my control.

At this point I suspect that Qt bluetooth process is using something similar to

bluetoothctl list


z@z-desktop:~$ bluetoothctl list
[NEW] Controller 00:15:83:15:A2:CB z-desktop [default]
[NEW] Device B8:27:EB:11:3F:82 ARM
[NEW] Device 98:D3:31:F8:39:33 SPP-CA
[NEW] Device 00:50:B6:80:4D:5D z-desktop
[bluetooth]#



That command DOES not perform actual "scan for nearby devices" - no observable delay - outputs immediately.

Yes, it is a MY problem because my objective is to identify working, powered-up etc. bluetooth devices.

btsanner "masks" this "problem" by listing ALL previously identified devices , BUT fails to "pair" with device which is not active.

That is OK , but somewhat silly , after the fact - why allowing to "pair" non existent device ?

I do appreciate your comments , and I am not blaming anything on Qt process.

But I would like to empathize that until I check the Qt bluetooth source code this is just an academic " best guess / what if" discussion .
Since it appears that Qt bluetooth process is NOT doing what I like to have done - the solution is obviously to write my own code .




I should be good after I get more Qt experience.