Android 和其他设备之间的蓝牙 SPP、UUID 和 PIN 问题

发布于 2024-10-21 04:01:40 字数 2434 浏览 1 评论 0原文

我正在尝试实现一个 Android 应用程序来从医疗设备接收数据,但我无法完成发现过程并使手机和设备相互配对或连接。

描述医疗设备: 该设备正在使用服务发现协议 (SDP) 和串行端口配置文件 (SPP)。 它启动一个查询过程来发现(最多 10 个)具有匹配 COD 过滤器和服务名称的周围接入点。然后,它通过检查 PIN 顺序与接入点建立连接(使用寻呼过程)。一旦 PIN 码匹配,数据就会上传。上传数据后,设备等待确认。设备是主机并发起通信。

我无法控制该医疗设备。我所能做的就是启动它并等待上述过程(测量后)。

Android 应用程序: 我从开发者页面上的蓝牙聊天示例开始。到目前为止,我已将 UUID 替换为 00001101-0000-1000-8000-00805f9b34fb 以使用 SPP 并将服务名称设置为适当的名称。我可以通过计算机检查服务来确认这似乎是正确的。由于医疗设备是查询和发起通信的设备,因此我的服务使用 BluetoothServerSocketaccept() 方法开始侦听它。

  1. 在开发人员页面中,我读到 UUID 必须在尝试通信的应用程序之间匹配。由于我无法为医疗设备设置任何 UUID,我想知道这是否会成为问题,或者医疗设备使用 SP 配置文件是否足够?

  2. 如果服务名称和 UUID 正确,并且医疗设备实际上会尝试连接到正在侦听连接的蓝牙服务,Android 系统是否会提示我手动输入 PIN 以便能够配对设备(因为医疗设备有预设的 PIN)?

  3. 我在 Android SDK API 中没有找到任何可以让我为蓝牙服务设置 PIN 的内容(以防失败),这可能吗?

我读到,现在 PIN 通常由系统生成,唯一需要的是用户确认。我想我的系统中没有,因为该设备有点旧。

如果您愿意分享一些与我上述内容相关的知识、提示和猜测,我将不胜感激!

提前致谢, Fredrik


编辑:

现在我已经将设备与 bluegiga 盒子配对,并且它们可以正确通信。现在我正在寻找血压设备连接到我的手机所需满足的标准。我可以从 Linux 计算机(终端中的 sdptool search SP)检查 bluegiga 提供的蓝牙服务,并将其与我在 Android 上提供的蓝牙服务进行比较。这些值是我得到的:

~$ sdptool 搜索 SP

询问...

正在 8C:71:F8:E5:XX:XX 上搜索 SP。 。 .

服务名称:1808130054

服务记录句柄:0x10003

服务类 ID 列表:

UUID 128:00001101-0000-1000-8000-00805f9b34fb

协议描述符列表:

“L2CAP”(0x0100)

“RFCOMM”(0x0003)

频道:13

´

在 00:07:80:88:XX:XX 搜索 SP。 。 .

服务名称:1808130054

服务说明:1808130054

服务记录句柄:0x10005

服务类 ID 列表:

“串行端口”(0x1101)

协议描述符列表:

“L2CAP”(0x0100)

“RFCOMM”(0x0003)

频道:12

语言基础属性列表:

代码_ISO639:0x656e

编码:0x6a

基本偏移量:0x100

第一个找到的设备是手机 (mac=8C:71...Google Nexus S),第二个设备 (mac=00:07...) 是 bluegiga 。我注意到 Android 设备上没有服务说明。我认为最重要的区别在于服务类别 ID 列表。 Android 上的 UUID 128,但在 bluegiga 上描述这一点的格式完全不同。

  1. 是否可以在 Android 上使用除 UUID 之外的其他格式的服务类 ID 来实现?

  2. 您可以操作在服务发现DB中注册的服务记录吗?

  3. 是否可以使用本机开发 c/c++ 以某种方式直接实现 BlueZ?

/弗雷德里克

I'm trying to implement an Android application to receive data from a medical device but I can't get through the discovery process and get the phone and the device paired or connected to each other.

Describing the medical device:
The device is using Service Discovery Protocol (SDP) and Serial Port Profile (SPP).
It starts an inquiry procedure to discover (up to 10) surrounding access points with matched COD Filter and Service Name. Then it sequentially establishes a connection (using Page Procedure) with the access point by checking the PIN. Once the PIN is matched, the data is uploaded. Upon uploading data the device waits for an acknowledge. The decice is the master and initiates the communication.

I have no control of the medical device. All I can do is to start it and await the procedure described above (after a measurement).

The Android application:
I've started out from the Bluetooth Chat Example on the developer pages. So far I've replaced the UUID with the 00001101-0000-1000-8000-00805f9b34fb to use SPP and set the Service Name to the appropriate name. I can confirm this seems correct through inspection of the service from a computer. Since the medical device is the one that inquirys and initiates the communication my service is using a BluetoothServerSocket and the accept() method to start listening for it.

  1. In the developer pages I've read that UUID must match between the applications trying to communicate. Since I can't set any UUID for the medical device I'm wondering if this is going to be a problem or if it is enough that the medical device is using the SP Profile?

  2. If the Service Name and UUID are correct and the medical device would actually try to connect to my Bluetooth service which is listening for connections, would the Android system prompt me to input the PIN manually to be able to pair the devices (since the medical device has a pre-set PIN)?

  3. I haven't found anything in the Android SDK API that lets me set a PIN for my Bluetooth service (in case this is where it fails), is this possible?

I've read that normally the PIN is generated by the system nowadays and a user confirmation is the only thing needed. I guess not in my system, since the device is a bit older.

I would be greatful if you would like to share some knowledge, hints, guesses of anything related to what I've described above!

Thanks in advance,
Fredrik


EDIT:

Now I've got the device paired with a bluegiga box and they communicate correctly. Now I'm searching for the criterias to fulfil for the blood pressure device to connect to my phone. I can inspect, from a Linux computer (sdptool search SP in a terminal), the Bluetooth service provided by the bluegiga and compare this to the Bluetooth service I provide on the Android. These values are what I get:

~$ sdptool search SP

Inquiring ...

Searching for SP on 8C:71:F8:E5:XX:XX . . .

Service Name: 1808130054

Service RecHandle: 0x10003

Service Class ID List:

UUID 128: 00001101-0000-1000-8000-00805f9b34fb

Protocol Descriptor List:

"L2CAP" (0x0100)

"RFCOMM" (0x0003)

Channel: 13

´

Seaching for SP on 00:07:80:88:XX:XX . . .

Service Name: 1808130054

Service Description: 1808130054

Service RecHandle: 0x10005

Service Class ID List:

"Serial Port" (0x1101)

Protocol Descriptor List:

"L2CAP" (0x0100)

"RFCOMM" (0x0003)

Channel: 12

Language Base Attr List:

code_ISO639: 0x656e

enconding: 0x6a

base_offset: 0x100

The first device found is the phone (mac=8C:71...Google Nexus S) and the second (mac=00:07...) is the bluegiga. I notice that there is no Service Description on the Android device. I think the most important difference is in the Service Class ID List. UUID 128 on the Android but a totally different format describing this on the bluegiga.

  1. Is it possible to implement using Service Class IDs with other format than UUID on Android?

  2. Can you manipulate the Service Record registered in the service discovery DB?

  3. Would it be possible to somehow implement towards the BlueZ directly, using native development c/c++?

/Fredrik

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

以酷 2024-10-28 04:01:40

如果您可以提供医疗设备的名称/链接(如果是商业设备),则可能有助于阅读其指南以猜测更多可能发生的情况。
以下是一些建议:

  1. 除了串行端口 UUID 之外,SPP 上的每个服务都可以有一个自定义的特定 UUID - 例如,医疗设备可以使用此自定义特定的 UUID 来查找与其兼容的服务。
    如果医疗设备当前成功连接到 PC 或其他某个接入点并传输数据,您可以尝试读取该设备的 SDP 记录并确定除 SPP UUID 之外正在使用哪些特定 UUID(如果有),并使用在您的应用程序中也是如此。

  2. 如果医疗设备无法找到您的手机/应用程序,可能是因为它无法被发现。默认情况下,即使您是服务器,Android 设备也是不可发现的,它只能连接而不可发现,您可以尝试通过编程或通过设置使其可发现,并查看医疗设备是否可以找到您的设备。
    请参阅此处 - 在 Android 中启用可发现性

  3. 有关 PIN 码配对, 当未配对的设备尝试连接时,Android 设备应该开始配对过程,您可以在完成建议 (1) 和 (2) 后尝试,
    如果其中一个设备的版本低于蓝牙 2.1,则使用 PIN 配对,即使使用较新的设备,也需要在手机上进行一些用户干预/确认的 6 位密钥才能进行配对(这只是一个良好的安全策略)为了不允许这种情况在没有用户干预的情况下自动发生),希望配对仅在第一次连接发生时才需要,稍后后续连接不需要任何用户干预。

If you can provide the name / link to the medical device (if it is a commercial device) it might help to read up its guide to guess more on what might be going on.
Here are a few suggestions :

  1. In addition to the Serial Port UUID , each service over the SPP can have a custom specific UUID - example the medical device could look for the service with which it is compatible using this custom-specific UUID.
    If the medical device currently connects to a PC or some other access point successfully and transfers data , the you could try read the SDP record of that device and determine what specific UUID in addition to the SPP UUID is in use if any, and use the same in your application also.

  2. If the medical device is not able to find your phone / application it could be because it is not discoverable. Android device by default is not discoverable even when you are a server, it will be only connectable and not discoverable, you can try to make it discoverable programetically or through the settings and see if the medical device can find your device.
    See here - Enabling Discoverability in Android

  3. For PIN pairing , The android device should start the pairing process when a non paired device tries to connect to it, you can try it after getting through the recommendations (1) and (2),
    PIN pairing is used if one of the devices are prior to version Bluetooth 2.1 , Even with newer devices a 6-digit passkey with some user intervention / confirmation will be required at the phone to allow for the pairing (its is just a good security policy to not allow this to just happen automatically without user intervention) , hopefully pairing will only be require the first time a connection happens, later it will not require any user intervention for subsequent connections.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文