快速蓝牙名称查找
我在快速检测附近蓝牙设备的名称（人名，而不是 BTADDR）时遇到问题 我在这里发现了一个非常有趣的基于Python的项目[http://code.google.com/p/python-bluetooth-scanner/]，但问题基本上是，虽然寻找BTADDR和RSSI很快，但检测“人类” “设备的名称需要更长的时间（即使他们说它应该在代码中工作）
我知道我可以使用以下方式查找名称：
- 简单的“hcitool scan”控制台命令，该命令很慢
- bluetooth.lookup_name(address) 方法 PyBlueZ 模块
- 项目中编写的
，报告如下-
sock = bluetooth.bluez._gethcisock(device)
timeoutms = int(timeout * 1000)
try:
name = bluetooth._bluetooth.hci_read_remote_name( sock, address, timeoutms )
except bluetooth._bt.error, e:
print e
logger.debug("Lookup Failed")
name = None
sock.close()
return name
简要见解：系统使用 2 个加密狗来检测附近的 BT 设备，如果我让它们查找名称，它们会花费更多时间，因此在发现新设备时保持锁定状态，设备仍然锁定在寻找前一个设备的名称，并且整个软件挂起。 我在 WindowsXP 环境中的 VirtualBox 中运行 Ubuntu 10.10 和几个 BT 2.1 加密狗。
除了创建一个“未命名”设备列表，以便在我的加密狗使用完以前的设备后立即查找。你知道我有什么办法可以更快地做到这一点吗？
I'm experiencing problems in fast detecting nearby bluetooth devices' names (human names, not BTADDR)
I found a very interesting Python-based project here [http://code.google.com/p/python-bluetooth-scanner/] but the issue basically is that, while looking for BTADDR and RSSI is fast, detecting the "human" name of the device takes longer (even if they say it should work in the code)
I know I can look up for names with:
- the simple "hcitool scan" console command, which is slow
- the bluetooth.lookup_name(address) method of module PyBlueZ
- as written in the project, reported below
-
sock = bluetooth.bluez._gethcisock(device)
timeoutms = int(timeout * 1000)
try:
name = bluetooth._bluetooth.hci_read_remote_name( sock, address, timeoutms )
except bluetooth._bt.error, e:
print e
logger.debug("Lookup Failed")
name = None
sock.close()
return name
A brief insight: the system uses 2 dongles to detect nearby BT devices, if I make them looking up for names, they spend more time hence remaining locked, when a new device is discovered, devices are still locked in looking for the previous one's name and the whole software hangs.
I'm running Ubuntu 10.10 in a VirtualBox in WindowsXP environment and a couple BT 2.1 dongles.
Apart from creating a list of "unnamed" devices to look for as soon as my dongles are done with the previous ones. Do you know any way I could do that faster?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
查找远程设备的友好名称通常分为两步。首先，您执行查询扫描“发现”附近可发现的设备。其次，您需要连接到
远程设备并“询问”它的友好名称。延迟的部分原因在于这两个步骤通常不以交错的方式执行（即发现设备然后查询名称）。通常，您会运行查询扫描直到完成（这需要一段时间），然后询问特定设备的友好名称。 （要交错发现和名称查找，您将开始发现，等到“发现”新设备，取消发现，查询名称，然后重新启动发现。重复直到找不到新设备。某些堆栈会这样做 如果两个设备都支持扩展查询响应（在蓝牙 2.1 规范中添加
），则会在发现过程中返回友好名称。这大大加快了速度，但它需要在堆栈中得到进一步的支持。
Finding a remote device's friendly name is generally a two-step process. First, you perform an inquiry scan "discovering" nearby device that are discoverable. Second, you need to connect to
the remote device and "ask" it for its friendly name. Part of the delay comes from the fact that these two steps are often not performed in an interleaved manner (i.e., a device is discovered and then the name is queried). Oftentimes, you run an inquiry scan until completion (which takes a while) and then you ask specific devices for their friendly names. (To interleave the discovery and name lookup, you would start the discovery, wait until you "discover" a new device, cancel the discovery, query for the name, then restart the discovery. Repeat until no new devices are found. Some stacks do this for you automatically. Some don't.)
If both devices support Extended Inquiry Response (added in the Bluetooth 2.1 specification), the friendly name is returned as part of the discovery process. This speeds things up considerably, but it needs to be supported further down in the stack.