Hi Marcel,
Thanks for your reply.
why don't you use periodic inquiry instead and let the controller
handle
the timing.
Because the specific bit I am working on is a C++ library capable of
doing (among other things) asynchronous discovery while avoiding any
intermediate caches (that's why I don't use the D-Bus interface or the
ioctl call) and I do not have control over the periodicity of the
inquiry nor know when it is going to be cancelled or started again.
The API requirements were to provide an fast, not cached inquiry that
can be started and cancelled at will by the application.
Having examined the logs the amount of inquiry requests I am sending
is fairly low (every 30 seconds or so) and so I thought it wouldn't be
a problem for the HCI or USB layers to handle in terms of data volume.
Also should try the bluetooth-testing.git tree since it contains an
updated btusb.ko driver.
I will try it and let you know about the results.
Does this imply that it looks like a problem in the btusb driver? The
only other explanations that occurred me until now were:
- The problem is in the hardware (USB hub or BlueCores): I discarded
this possibility because I took a different hub and 3 dongles
containing Broadcom modules and reproduced it immediately.
- The problem could be the library sending commands directlly to the
HC and therefore conflicting with another source of commands
(bluetooth daemon or other): This seems unlikely given that the logs
show that on hci2 the only commands are the inquiry requests and
cancels being sent by the library.
Thanks!
Carles
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
