Dear Bluez Team,
I am currently testing my bluetooth application using Bluez on Linux
(Fedora Core 11) and have HP Eltebook laptop that has Broadcom
bluetooth adaptor. The Bluez version installed is 4.37.
On running <hcitool scan> in one terminal and simultaneously viewing
results using <hcidump> on the other terminal, I had a very
interesting observation that has made me quite perplexed. I would
really like you to help me out.
The observation is that suppose a device(Nokia N73) with MAC address
M1 is discoverable, the response to Inquiry Request command is often a
set of multiple Inquiry Result each with the same MAC address M1.
I had expected that only one Inquiry result with MAC address M1 should
have been returned. But here what we find is that multiple such
results with the same MAC address are returned.
Please advise if this is an issue with bluetooth adaptor or bluez.
Kindly suggest some workaround.
--
Regards,
Saurabh Thukral
Hi,
> On running <hcitool scan> in one terminal and simultaneously viewing
> results using <hcidump> on the other terminal, I had a very
> interesting observation that has made me quite perplexed. I would
> really like you to help me out.
>r
> The observation is that suppose a device(Nokia N73) with MAC address
> M1 is discoverable, the response to Inquiry Request command is often a
> set of multiple Inquiry Result each with the same MAC address M1.
This is totally normal! It's related to how bluetooth inquiry process
works. The device doing the inquiry is jumping at a rate of 1600
hops/s (If I'm not wrong) over 32 channels and te device in inquiry
scan is jumpung at a way lower rate. So the radio might, and actually
will, find the same device multiple times per scan cycle. hcidump
shows you exactly which information is going on between the radio and
the stack.
The advantage of getting multiple results are many:
* RSSI depends on scanning channel: not all the channel have the same
noise level, so averaging RSSI with multiple results is way more
accurate than just one rssi value from one only channel.
* Faster response: hcitool inq will only show you the results once it
has solved both name and completed scanning, but actually it's getting
the results way before. I had been able to expermient dicovering a new
radio in less than 1 second so I could take action, and this can only
be done if you get multiple results per scan cycle.
Off course it requires more inteligence on you side. You need to
filter which results are new and which are not, but that is damn easy,
and you would be loose applications if it was otherwise.
Manuel
--
Manuel Francisco Naranjo
Software Department Argentina
Wireless Cables Inc
http://www.aircable.net
cel: +5493412010019
skype: naranjomanuelfrancisco
Hi,
On Sun, Jun 06, 2010, Saurabh Thukral wrote:
> This behaviour is observed on HP Elitebook using broadcom bluetooth
> adaptor. However when I run the same test on Compaq 510 laptop having
> the same adaptor, only a single Inquiry result is returned and then
> inquiry completes.
Is there any difference between the host operating systems and bluetooth
stacks on these two laptops?
> Please note that this is irrespective of whether there is standard
> inquiry or Inquiry with RSSI.
If you get the behavior for non-RSSI events it sounds like a bug in the
controller.
> I think having multiple inquiry results
> all having same MAC address is wrong for following 2 reasons:
>
> 1) The procedure of discovery of devices becomes longer
>
> 2) I programmed getting inquiry result by sending hci_send_cmd and
> then polling on hci socket fd for all the events. Since I would be
> getting multiple events all having result for the same MAC address,
> this creates a burden to weed out all duplicate entries and return one
> entry containing MAC address only. I think this way is wrong.
You're entitled to your opinion and I do understand it to some extent,
but unfortunately I'm not aware of any standard HCI commands or
parameters through which you could make the controller not exhibit this
behavior (the behavior with non-RSSI events seems like a bug in the
controller though). Btw, why not let bluetoothd take care of the
discovery for you? It already has code for detecting duplicate BT
addresses (though it will send multiple D-Bus signals for them in case a
UI is interested in the signal strength variations).
Johan
Saurabh Wrote:
>> The observation is that suppose a device(Nokia N73) with MAC address
>> M1 is discoverable, the response to Inquiry Request command is often a
>> set of multiple Inquiry Result each with the same MAC address M1.
>>
>> I had expected that only one Inquiry result with MAC address M1 should
>> have been returned. But here what we find is that multiple such
>> results with the same MAC address are returned.
>>
Johan Wrote:
>
> It's most likely neither, but simply as it's intended to be. I presume
> the inquiry results contain the RSSI which will most likely be different
> in each event. The purpose of the multiple events is to give you updates
> if the signal strength to the device changes.
This behaviour is observed on HP Elitebook using broadcom bluetooth
adaptor. However when I run the same test on Compaq 510 laptop having
the same adaptor, only a single Inquiry result is returned and then
inquiry completes.
Please note that this is irrespective of whether there is standard
inquiry or Inquiry with RSSI. I think having multiple inquiry results
all having same MAC address is wrong for following 2 reasons:
1) The procedure of discovery of devices becomes longer
2) I programmed getting inquiry result by sending hci_send_cmd and
then polling on hci socket fd for all the events. Since I would be
getting multiple events all having result for the same MAC address,
this creates a burden to weed out all duplicate entries and return one
entry containing MAC address only. I think this way is wrong.
--
Regards,
Saurabh Thukral
Hi,
On Sun, Jun 06, 2010, Saurabh Thukral wrote:
> I am currently testing my bluetooth application using Bluez on Linux
> (Fedora Core 11) and have HP Eltebook laptop that has Broadcom
> bluetooth adaptor. The Bluez version installed is 4.37.
>
> On running <hcitool scan> in one terminal and simultaneously viewing
> results using <hcidump> on the other terminal, I had a very
> interesting observation that has made me quite perplexed. I would
> really like you to help me out.
>
> The observation is that suppose a device(Nokia N73) with MAC address
> M1 is discoverable, the response to Inquiry Request command is often a
> set of multiple Inquiry Result each with the same MAC address M1.
>
> I had expected that only one Inquiry result with MAC address M1 should
> have been returned. But here what we find is that multiple such
> results with the same MAC address are returned.
>
> Please advise if this is an issue with bluetooth adaptor or bluez.
It's most likely neither, but simply as it's intended to be. I presume
the inquiry results contain the RSSI which will most likely be different
in each event. The purpose of the multiple events is to give you updates
if the signal strength to the device changes.
Johan