Reading RSSI of non-connected devices
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 10 lines
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 structinquiry_dataif available, 0 otherwise. However the only way to access this information seems to be to get a pointer to ahci_devstruct (e.g. throughhci_dev_get(int index)) and use itsinq_cachemember? Getting this information from the client side is not possible right now?
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 10 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 10 lines
Quoted 10 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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 meanhci_open_devandhci_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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 24 lines · 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_COMPLETEevent forOCF_EXIT_PERIODIC_INQUIRYand 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_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 2.0? Or do these responses depend on anything else?
Quoted 5 lines
Oh, and is it not possible to send HCI commands as a non-root user? We were getting EPERM from
hci_send_cmdand 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 <[email protected]>
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Quoted 3 lines · Bastien Nocera
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 8 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 17 lines · Marcel Holtmann
Hi Andreas,
Quoted 8 lines
Quoted 5 lines
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.
Quoted 9 lines
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 4 lines
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
Quoted 8 lines
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_COMPLETEevent forOCF_EXIT_PERIODIC_INQUIRYand 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.
Quoted 8 lines
Regarding the multitude of events, how do I distinguish between the
inquiry_info_with_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 2.0? Or do these responses depend on anything else?
The event code is different.
Quoted 5 lines
Oh, and is it not possible to send HCI commands as a non-root user? We were getting EPERM from
hci_send_cmdand 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 4 lines
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?
Quoted 9 lines
Quoted 5 lines
Regarding the multitude of events, how do I distinguish between the
inquiry_info_with_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 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?
Quoted 7 lines
Quoted 3 lines
[...] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Regarding the multitude of events, how do I distinguish between the
inquiry_info_with_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 2.0? Or do these responses depend on anything else?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
[...] 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_cmdfor a HCI socket withOGF_LINK_CTLandOCF_PERIODIC_INQUIRYreturned 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Regarding the multitude of events, how do I distinguish between the
inquiry_info_with_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 2.0? Or do these responses depend on anything else?The event code is different.
Quoted 9 lines
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Andreas,
Quoted 26 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 9 lines
Regarding the multitude of events, how do I distinguish between the
inquiry_info_with_rssiandinquiry_info_with_rssi_and_pscan_modestructs? They appear to be using the same event but would be incompatible due to the "inserted"pscan_modemember. Currently I am testing with an HCI 1.1 device and getting only theinquiry_infostruct. Which of the other inquiry+RSSI events map to which HCI version? Isinquiry_info_with_rssiHCI 1.2 andextended_inquiry_infoHCI 2.0? Or do these responses depend on anything else?The event code is different.
Quoted 8 lines
Quoted 4 lines
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_MODEdefined in the bluez-libs-2.22.tar.gzhci.hfile, at least not anywhere near theinquiry_info_with_rssi_and_pscan_modestruct. Theextended_inquiry_infostruct on the other hand I even mentioned in the above quote, so I did see it.
Quoted 5 lines
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_rssivs.inquiry_info_with_rssi_and_pscan_modevs.extended_inquiry_infostill 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel