[Bluez-devel] Reading RSSI of non-connected devices

[Bluez-devel] Reading RSSI of non-connected devices

[Andreas Färber]

Hello,

We are trying to programmatically read the signal strength of Bluetooth 
devices at discovery time (not only for connections). Seeing through the 
source code it appears that in some cases (BT 1.2?) an inquiry gets an 
HCI response that includes the RSSI (struct inquiry_info_with_rssi). 
This information appears to be cached in struct inquiry_data if 
available, 0 otherwise. However the only way to access this information 
seems to be to get a pointer to a hci_dev struct (e.g. through 
hci_dev_get(int index)) and use its inq_cache member? Getting this 
information from the client side is not possible right now?

As I understand it from the code, the libBluetooth.so library does an 
ioctl on an HCI socket with specific predefined commands such as HCIINQUIRY.
How should we go about adding the functionality we need? Would we need 
to define a custom HCI socket command and handle it somewhere in a 
customized Kernel module? Or is there an easier way?

Thanks for any hints,

Andreas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> We are trying to programmatically read the signal strength of Bluetooth 
> devices at discovery time (not only for connections). Seeing through the 
> source code it appears that in some cases (BT 1.2?) an inquiry gets an 
> HCI response that includes the RSSI (struct inquiry_info_with_rssi). 
> This information appears to be cached in struct inquiry_data if 
> available, 0 otherwise. However the only way to access this information 
> seems to be to get a pointer to a hci_dev struct (e.g. through 
> hci_dev_get(int index)) and use its inq_cache member? Getting this 
> information from the client side is not possible right now?
> 
> As I understand it from the code, the libBluetooth.so library does an 
> ioctl on an HCI socket with specific predefined commands such as HCIINQUIRY.
> How should we go about adding the functionality we need? Would we need 
> to define a custom HCI socket command and handle it somewhere in a 
> customized Kernel module? Or is there an easier way?

the ioctl() is very old and number updated it to support Inquiry with
RSSI or Extended Inquiry. The main reason for this is, because you can't
update it without breaking backward-compatibility with older versions of
the library and the tools.

However you can program the HCI socket interface directly and read the
inquiry result directly. Example code for this is already available in
the mailing list archives.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Färber]

Hi Marcel,

>the ioctl() is very old and number updated it to support Inquiry with
>RSSI or Extended Inquiry. The main reason for this is, because you can't
>update it without breaking backward-compatibility with older versions of
>the library and the tools.
>
>However you can program the HCI socket interface directly and read the
>inquiry result directly. Example code for this is already available in
>the mailing list archives.
>  
>
Some posts say ioctl was bad because it's old, some posts say raw HCI 
sockets were bad because the messed with BlueZ. Your hcitool apparently 
is using ioctl for "hcitool scan" in its most recent version 
downloadable from your site...
Our software is a Java framework that shall continuously check the RSSI 
of devices around in a background thread (test code for this is in C). 
Another thread might be continuously using GPS data via BT and apart 
from that we don't want to keep the user from using the BlueZ stack in a 
"normal" way while our software is running. In this context is it safe 
to use HCI sockets in the way you have suggested?

I'm having a hard time finding the example you're mentioning over and 
over... Do you have any search words for me?
Not having found it I would assume you mean hci_open_dev and 
hci_send_cmd? Examples for the latter would be in the kernel driver 
which I already have.

Regards,

Andreas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> >the ioctl() is very old and number updated it to support Inquiry with
> >RSSI or Extended Inquiry. The main reason for this is, because you can't
> >update it without breaking backward-compatibility with older versions of
> >the library and the tools.
> >
> >However you can program the HCI socket interface directly and read the
> >inquiry result directly. Example code for this is already available in
> >the mailing list archives.
> >  
> >
> Some posts say ioctl was bad because it's old, some posts say raw HCI 
> sockets were bad because the messed with BlueZ. Your hcitool apparently 
> is using ioctl for "hcitool scan" in its most recent version 
> downloadable from your site...

you should avoid interfacing with the kernel, but listening for events
on the HCI socket was and will be always safe.

> Our software is a Java framework that shall continuously check the RSSI 
> of devices around in a background thread (test code for this is in C). 
> Another thread might be continuously using GPS data via BT and apart 
> from that we don't want to keep the user from using the BlueZ stack in a 
> "normal" way while our software is running. In this context is it safe 
> to use HCI sockets in the way you have suggested?

In this case you should use periodic inquiry and listen for inquiry
result events on the HCI raw socket. This is a safe way of doing it. You
might wanna check out the D-Bus interface, but this new API might be
still changed at lot.

> I'm having a hard time finding the example you're mentioning over and 
> over... Do you have any search words for me?
> Not having found it I would assume you mean hci_open_dev and 
> hci_send_cmd? Examples for the latter would be in the kernel driver 
> which I already have.

Try to look for EVT_INQUIRY_RESULT_WITH_RSSI.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Faerber]

Hi Marcel, Hi Arpit,

I've made some progress on our periodic scan test code. I didn't find 
the example you referenced but I have managed to initiate a periodic 
scan, to read some events and to stop the scan. Some things I noticed 
however, for instance that when I ran my app twice a little time-shifted 
the second process didn't get any events once the first process was 
finished. Can I avoid this somehow? Currently I am catching the 
EVT_CMD_COMPLETE event for OCF_EXIT_PERIODIC_INQUIRY and restarting the 
search, but as I am not getting an event for the start of the periodic 
inquiry that I could process it would seem that if I do e.g. a 3 second 
period inquiry and during my scan afterwards someone else does e.g. a 30 
second period inquiry then it will change this on a global level so that 
I do not get my results as expected?

Regarding the multitude of events, how do I distinguish between the 
inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
structs? They appear to be using the same event but would be 
incompatible due to the "inserted" pscan_mode member. Currently I am 
testing with an HCI 1.1 device and getting only the inquiry_info struct. 
Which of the other inquiry+RSSI events map to which HCI version? Is 
inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
these responses depend on anything else?

Oh, and is it not possible to send HCI commands as a non-root user? We 
were getting EPERM from hci_send_cmd and had to setup a Linux box solely 
for this purpose so that I could be root - admins wouldn't allow that on 
the other University machines, and I'm concerned whether our potential 
users would all be able to run our software as root...

Best regards,

Andreas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Bastien Nocera]

On Wed, 2005-12-14 at 16:21 +0100, Andreas Faerber wrote:
> Hi Marcel, Hi Arpit,
> 
> I've made some progress on our periodic scan test code. I didn't find 
> the example you referenced but I have managed to initiate a periodic 
> scan, to read some events and to stop the scan. Some things I noticed 
> however, for instance that when I ran my app twice a little time-shifted 
> the second process didn't get any events once the first process was 
> finished. Can I avoid this somehow? Currently I am catching the 
> EVT_CMD_COMPLETE event for OCF_EXIT_PERIODIC_INQUIRY and restarting the 
> search, but as I am not getting an event for the start of the periodic 
> inquiry that I could process it would seem that if I do e.g. a 3 second 
> period inquiry and during my scan afterwards someone else does e.g. a 30 
> second period inquiry then it will change this on a global level so that 
> I do not get my results as expected?
> 
> Regarding the multitude of events, how do I distinguish between the 
> inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
> structs? They appear to be using the same event but would be 
> incompatible due to the "inserted" pscan_mode member. Currently I am 
> testing with an HCI 1.1 device and getting only the inquiry_info struct. 
> Which of the other inquiry+RSSI events map to which HCI version? Is 
> inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
> these responses depend on anything else?
> 
> Oh, and is it not possible to send HCI commands as a non-root user? We 
> were getting EPERM from hci_send_cmd and had to setup a Linux box solely 
> for this purpose so that I could be root - admins wouldn't allow that on 
> the other University machines, and I'm concerned whether our potential 
> users would all be able to run our software as root...

As Marcel mentioned earlier, the easiest is to use the D-Bus services in
hcid to do that.

---
Bastien Nocera <hadess@hadess.net> 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> I've made some progress on our periodic scan test code. I didn't find 
> the example you referenced but I have managed to initiate a periodic 
> scan, to read some events and to stop the scan. Some things I noticed 
> however, for instance that when I ran my app twice a little time-shifted 
> the second process didn't get any events once the first process was 
> finished. Can I avoid this somehow? Currently I am catching the 
> EVT_CMD_COMPLETE event for OCF_EXIT_PERIODIC_INQUIRY and restarting the 
> search, but as I am not getting an event for the start of the periodic 
> inquiry that I could process it would seem that if I do e.g. a 3 second 
> period inquiry and during my scan afterwards someone else does e.g. a 30 
> second period inquiry then it will change this on a global level so that 
> I do not get my results as expected?

you don't need to stop the periodic inquiry. It will restart itself.
That's the whole point behind it.

> Regarding the multitude of events, how do I distinguish between the 
> inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
> structs? They appear to be using the same event but would be 
> incompatible due to the "inserted" pscan_mode member. Currently I am 
> testing with an HCI 1.1 device and getting only the inquiry_info struct. 
> Which of the other inquiry+RSSI events map to which HCI version? Is 
> inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
> these responses depend on anything else?

The event code is different.

> Oh, and is it not possible to send HCI commands as a non-root user? We 
> were getting EPERM from hci_send_cmd and had to setup a Linux box solely 
> for this purpose so that I could be root - admins wouldn't allow that on 
> the other University machines, and I'm concerned whether our potential 
> users would all be able to run our software as root...

The inquiry related commands and events are accessable by all users.
Some other are protected by the HCI security inside the kernel.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Faerber]

Hi,

Bastien Nocera wrote:

>As Marcel mentioned earlier, the easiest is to use the D-Bus services in
>hcid to do that.
>
He didn't. He said the safe way would be to use raw HCI sockets and (in 
other words) that the D-Bus interface was unstable. Also, I am currently 
testing this on desktop and notebook machines but it was actually 
supposed to run on mobile devices (Zaurus) where we would not be able to 
update the kernel and require the latest D-Bus/BlueZ interfaces.

Nontheless we will evaluate D-Bus, but for the time being my boss is 
content with HCI sockets under root account.
I'm familiar with socket programming in general but haven't used D-Bus 
before and so we are worried whether introducing another layer such as 
D-Bus might be of disadvantage for our software which needs non-cached 
data, nearly in realtime (just as with HCI sockets). The D-Bus page 
itself says it's not stable yet and I did not find documentation on how 
to use it with BlueZ. The BlueZ library was very helpful in getting my 
code to work, whereas I have no clue on where to find any such hints for 
D-Bus both in the BlueZ 2.22 downloads and in the 2.6.13.4 kernel which 
were the latest respectively when I downloaded them some weeks ago. I 
can only guess from the examples at freedesktop.org that it'll be 
/org/bluez/something.

Anyway, some clarification on the events/structs and a recommendation by 
Marcel on suitable Bluetooth reference hardware in Germany would be very 
appreciated.

Kind regards,

Andreas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Faerber]

Hi Marcel,

>you don't need to stop the periodic inquiry. It will restart itself.
>That's the whole point behind it.
>  
>
I know, that's why I'm doing a period inquiry after all! :-) But I 
thought I should stop it when my application exits so that it does not 
consume unnecessary battery power when we don't need it?

>  
>
>>Regarding the multitude of events, how do I distinguish between the 
>>inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
>>structs? They appear to be using the same event but would be 
>>incompatible due to the "inserted" pscan_mode member. Currently I am 
>>testing with an HCI 1.1 device and getting only the inquiry_info struct. 
>>Which of the other inquiry+RSSI events map to which HCI version? Is 
>>inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
>>these responses depend on anything else?
>>    
>>
>
>The event code is different.
>  
>
For the two I mentioned it is not, there is none defined for the latter. 
Only its size is - in bluez-libs-2.22.tar.gz.
But what about practical availability of those? When do we get which 
response? Do you have any link on that or a short answer?

>>[...] is it not possible to send HCI commands as a non-root user? We 
>>were getting EPERM from hci_send_cmd [...]
>>    
>>
>The inquiry related commands and events are accessable by all users.
>Some other are protected by the HCI security inside the kernel.
>  
>
As I said, hci_send_cmd for a HCI socket with OGF_LINK_CTL and 
OCF_PERIODIC_INQUIRY returned errno==EPERM for user and runs fine as 
root. Same for plugging in Bluetooth dongles - doesn't work for user 
(driver loaded in dmesg but not listed in hcitool dev), works fine for root.

Regards,

Andreas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> >>Regarding the multitude of events, how do I distinguish between the 
> >>inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
> >>structs? They appear to be using the same event but would be 
> >>incompatible due to the "inserted" pscan_mode member. Currently I am 
> >>testing with an HCI 1.1 device and getting only the inquiry_info struct. 
> >>Which of the other inquiry+RSSI events map to which HCI version? Is 
> >>inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
> >>these responses depend on anything else?
> >
> >The event code is different.
> >  
> For the two I mentioned it is not, there is none defined for the latter. 
> Only its size is - in bluez-libs-2.22.tar.gz.
> But what about practical availability of those? When do we get which 
> response? Do you have any link on that or a short answer?

look again, because they are different and bluez-libs-2.22 even contains
the definitions for extended inquiry already.

> >>[...] is it not possible to send HCI commands as a non-root user? We 
> >>were getting EPERM from hci_send_cmd [...]
> >>
> >The inquiry related commands and events are accessable by all users.
> >Some other are protected by the HCI security inside the kernel.
> >
> As I said, hci_send_cmd for a HCI socket with OGF_LINK_CTL and 
> OCF_PERIODIC_INQUIRY returned errno==EPERM for user and runs fine as 
> root. Same for plugging in Bluetooth dongles - doesn't work for user 
> (driver loaded in dmesg but not listed in hcitool dev), works fine for root.

Oh yes, the periodic inquiry must be started as root. If you recompile
your kernel, you can of course change the HCI security filter and allows
all commands by normal users.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> >As Marcel mentioned earlier, the easiest is to use the D-Bus services in
> >hcid to do that.
> >
> He didn't. He said the safe way would be to use raw HCI sockets and (in 
> other words) that the D-Bus interface was unstable. Also, I am currently 
> testing this on desktop and notebook machines but it was actually 
> supposed to run on mobile devices (Zaurus) where we would not be able to 
> update the kernel and require the latest D-Bus/BlueZ interfaces.

the D-Bus interface has nothing to do with used kernel.

> Nontheless we will evaluate D-Bus, but for the time being my boss is 
> content with HCI sockets under root account.
> I'm familiar with socket programming in general but haven't used D-Bus 
> before and so we are worried whether introducing another layer such as 
> D-Bus might be of disadvantage for our software which needs non-cached 
> data, nearly in realtime (just as with HCI sockets). The D-Bus page 
> itself says it's not stable yet and I did not find documentation on how 
> to use it with BlueZ. The BlueZ library was very helpful in getting my 
> code to work, whereas I have no clue on where to find any such hints for 
> D-Bus both in the BlueZ 2.22 downloads and in the 2.6.13.4 kernel which 
> were the latest respectively when I downloaded them some weeks ago. I 
> can only guess from the examples at freedesktop.org that it'll be 
> /org/bluez/something.

The D-Bus interface works quite good, but I won't guarantee a stable API
at the moment. If needed, I am going to break it.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Färber]

Hi Marcel,

>>>>Regarding the multitude of events, how do I distinguish between the 
>>>>inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
>>>>structs? They appear to be using the same event but would be 
>>>>incompatible due to the "inserted" pscan_mode member. Currently I am 
>>>>testing with an HCI 1.1 device and getting only the inquiry_info struct. 
>>>>Which of the other inquiry+RSSI events map to which HCI version? Is 
>>>>inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
>>>>these responses depend on anything else?
>>>>        
>>>>
>>>The event code is different.
>>> 
>>>      
>>>
>>For the two I mentioned it is not, there is none defined for the latter. 
>>Only its size is - in bluez-libs-2.22.tar.gz.
>>But what about practical availability of those? When do we get which 
>>response? Do you have any link on that or a short answer?
>>    
>>
>
>look again, because they are different and bluez-libs-2.22 even contains
>the definitions for extended inquiry already.
>  
>
No, all I was saying is that there was definately no 
EVT_INQUIRY_RESULT_WITH_RSSI_AND_PSCAN_MODE defined in the 
bluez-libs-2.22.tar.gz hci.h file, at least not anywhere near the 
inquiry_info_with_rssi_and_pscan_mode struct. The extended_inquiry_info 
struct on the other hand I even mentioned in the above quote, so I did 
see it.

So you are saying that (theoretically) I should be able to distinguish 
all responses by event code. In that case my question on when do I get 
the respective event codes for an inquiry_info_with_rssi vs. 
inquiry_info_with_rssi_and_pscan_mode vs. extended_inquiry_info still 
stands...

Kind regards,

Andreas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Andreas Färber]

Marcel Holtmann schrieb:

>Hi Andreas,
>
>  
>
>>>As Marcel mentioned earlier, the easiest is to use the D-Bus services in
>>>hcid to do that.
>>>
>>>      
>>>
>>He didn't. He said the safe way would be to use raw HCI sockets and (in 
>>other words) that the D-Bus interface was unstable. Also, I am currently 
>>testing this on desktop and notebook machines but it was actually 
>>supposed to run on mobile devices (Zaurus) where we would not be able to 
>>update the kernel and require the latest D-Bus/BlueZ interfaces.
>>    
>>
>
>the D-Bus interface has nothing to do with used kernel.
>
>  
>
>>Nontheless we will evaluate D-Bus, but for the time being my boss is 
>>content with HCI sockets under root account.
>>I'm familiar with socket programming in general but haven't used D-Bus 
>>before and so we are worried whether introducing another layer such as 
>>D-Bus might be of disadvantage for our software which needs non-cached 
>>data, nearly in realtime (just as with HCI sockets). The D-Bus page 
>>itself says it's not stable yet and I did not find documentation on how 
>>to use it with BlueZ. The BlueZ library was very helpful in getting my 
>>code to work, whereas I have no clue on where to find any such hints for 
>>D-Bus both in the BlueZ 2.22 downloads and in the 2.6.13.4 kernel which 
>>were the latest respectively when I downloaded them some weeks ago. I 
>>can only guess from the examples at freedesktop.org that it'll be 
>>/org/bluez/something.
>>    
>>
>
>The D-Bus interface works quite good, but I won't guarantee a stable API
>at the moment. If needed, I am going to break it.
>  
>
Yes, that's exactly how I understood your earlier post.

But that does not give me any clue on how to use D-Bus either. I've seen 
through the D-Bus specification, but it does not define anything 
BlueZ-specific and I couldn't find anything related to D-Bus on the 
BlueZ.org or Holtmann.org pages. Again, I have no clue on where to start 
learning about specifically the BlueZ D-Bus interfaces - what path and 
properties etc I can use with D-Bus to access the information we need.

Andreas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Reading RSSI of non-connected devices

[Marcel Holtmann]

Hi Andreas,

> >>>>Regarding the multitude of events, how do I distinguish between the 
> >>>>inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode 
> >>>>structs? They appear to be using the same event but would be 
> >>>>incompatible due to the "inserted" pscan_mode member. Currently I am 
> >>>>testing with an HCI 1.1 device and getting only the inquiry_info struct. 
> >>>>Which of the other inquiry+RSSI events map to which HCI version? Is 
> >>>>inquiry_info_with_rssi HCI 1.2 and extended_inquiry_info HCI 2.0? Or do 
> >>>>these responses depend on anything else?
> >>>>
> >>>The event code is different.
> >>>
> >>For the two I mentioned it is not, there is none defined for the latter. 
> >>Only its size is - in bluez-libs-2.22.tar.gz.
> >>But what about practical availability of those? When do we get which 
> >>response? Do you have any link on that or a short answer?
> >
> >look again, because they are different and bluez-libs-2.22 even contains
> >the definitions for extended inquiry already.
> >  
> No, all I was saying is that there was definately no 
> EVT_INQUIRY_RESULT_WITH_RSSI_AND_PSCAN_MODE defined in the 
> bluez-libs-2.22.tar.gz hci.h file, at least not anywhere near the 
> inquiry_info_with_rssi_and_pscan_mode struct. The extended_inquiry_info 
> struct on the other hand I even mentioned in the above quote, so I did 
> see it.
> 
> So you are saying that (theoretically) I should be able to distinguish 
> all responses by event code. In that case my question on when do I get 
> the respective event codes for an inquiry_info_with_rssi vs. 
> inquiry_info_with_rssi_and_pscan_mode vs. extended_inquiry_info still 
> stands...

my bad and I totally forgot about it. This is an ugly hack for these
stupid devices around that support inquiry with RSSI, but followed the
0.7 version of the Bluetooth 1.2 specification instead of the final one.
They removed page scan mode before they made the specification final and
thus you have to hack around it. So far I've seen Silicon Wave based
chips with this behavior (this includes AVM actually).

So in general if you get an EVT_INQUIRY_RESULT_WITH_RSSI you should only
expect to deal with inquiry_info_with_rssi. If you wanna really deal
with a broken device then you need to compare the length of the event
(don't forget the number of results) and then decide if you need to work
around a broken device or not. Actually the kernel is doing this now,
but I never implemented that in any userspace routine. However I think
that I also made hcidump aware of it.

I personally won't bother with inquiry_info_with_rssi_and_pscan_mode ;)

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel