我在我的项目中添加了SPOTAR服务，正如应用程序文档中所述，我已经验证了我的设备确实在宣传该服务及其所有特性，但无论是SUOTA移动应用程序还是SmartSnippets都没有检测到它具有SUOTA功能。我使用Proximity Reporter运行了这个例子，它运行得很好。我希望得到这两个平台的移动应用程序代码，看看它如何检测设备是否支持SUOTA，以及如何编写新的固件。谢谢,
你好，贾巴克，
邮件已发送。
谢谢你的对话
我发现我必须在我的应用程序头文件中更改为以下内容：#定义APP\u ADV\u DATA“\x09\x03\x03\x18\x02\x18\x04\x18\xF5\xFE”#定义APP_ADV_DATA_LEN (8 + 2)
事实证明，APP_ADV_DATA是在尝试连接之前宣传服务的一种方法。仍然在试图弄清楚APP_ADV_DATA值是如何确定的。
查看蓝牙核心4.0规范第3卷第C部分-通用访问配置文件第8章扩展查询响应数据格式。基本上，它是一种长度类型值格式，包含不同类型数据的列表。您拥有的广告数据可以按如下方式进行分析：\x09-长度\x03-用于“16位服务类UUID的完整列表”的类型标签\x03\x18-链路丢失服务UUID\x02\x18-即时警报服务UUID\x04\x18 - TX电源服务UUID\xF5\xFE-对话SUOTA服务UUID
你好，朱巴祖，
你是说应用程序ADV_数据是如何确定的？APP_ADV_数据值由用户根据其在设备中实现的服务进行设置。
@MT_DIALOG—我认为JBaczuk试图说的是，他不确定APP_ADV_DATA中的各种值代表什么，因此不清楚他可能如何修改APP_ADV_DATA以包括SUOTA服务。Joacimwe很好地展示了这些值代表什么，并告诉他在哪里可以找到这些信息。
以下是我对这一切的看法：BLE4.0规范相当复杂，如果不花大量时间阅读所有API文档之类的内容，我们这些刚刚起步的BLE开发人员根本不可能“知道”在哪里寻找，更不用说“知道”我们在寻找什么了。也许没有办法绕过陡峭的学习曲线，然而，Dialog在提供示例源代码方面非常有帮助，允许用户相当快地启动和运行。参考应用程序经过深思熟虑，它们很好地捕获了人们可能希望使用BLE的一般类型的应用程序，在本例中，DSP非常适合将旧的“有线”应用程序转换为BLE。更好的是，Dialog将根据请求提供对iOS和Android应用程序源代码的访问。因此，现在一个新的BLE开发者可以潜在地将他们的传统“有线”设备扩展到新兴的物联网。好东西。Dialog这样做并不是出于完全无私的原因——他们也不应该这样——他们希望出售大量的BLE芯片。
问题是：当足够多的人试图将一个有价值且广泛应用的实用程序（如DSP）与另一个同样有价值的实用程序（如SUOTA）合并时，他们失败了。显然需要更多的信息。Dialog的动机应该和以前一样——销售更多的可编程芯片！
所以这里有更多的动机：我目前正在研究这个问题，集成DSP和SUOTA实用程序。我已经设计了一款功能齐全的Android应用程序和一款功能齐全的iOS应用程序，这两款应用程序在我的设备上的性能都与预期一样，都可以在Play Store/app Store上使用。我的设备现在正处于设计的最后阶段（经过4次硬件修改），我准备将其推向市场，我的初始订单是5000台设备。基于我的设备最初的“有线”版本的成功，我预计还会卖出数万台。一旦我能够自信地使用SUOTA更新DSPS应用程序，我就“经得起未来考验”，我将开始发货我的设备，并购买更多的BLE芯片。
我的建议是：编写一个简单的应用程序说明，准确描述如何将DSPS实用程序与SUOTA实用程序集成。一个知识渊博的人（MT_Dialog）花在这方面的时间可能远远少于在这些论坛上反复回答问题所花的时间。此应用说明应与AN-B-029基本相同，其中描述了如何使用sample128修改模板项目。如果你能做到这一点，你将出售许多、许多、更多的BLE芯片，而这些芯片正是我将要购买的，这将使其他人能够快速、轻松地将他们的产品推向市场，而不用担心他们会发现自己“被固件限制所锁定”。
最好klim
嗨，克里姆9513，
感谢您的评论和提供的反馈，也许这种教程对于应用程序说明来说太小了，但我们计划在不久的将来以更维基的结构更新我们的FAQ部分，以便为用户上传小文章和教程。我同意这应该是第一批加入的条款之一。
BR MT_对话框
你好，贾巴克，
邮件已发送。
谢谢你的对话
我发现我必须在我的应用程序头文件中更改为以下内容：
#定义APP\u ADV\u DATA“\x09\x03\x03\x18\x02\x18\x04\x18\xF5\xFE”
#定义APP_ADV_DATA_LEN (8 + 2)
事实证明，APP_ADV_DATA是在尝试连接之前宣传服务的一种方法。仍然在试图弄清楚APP_ADV_DATA值是如何确定的。
查看蓝牙核心4.0规范第3卷第C部分-通用访问配置文件第8章扩展查询响应数据格式。
基本上，它是一种长度类型值格式，包含不同类型数据的列表。
您拥有的广告数据可以按如下方式进行分析：
\x09-长度
\x03-用于“16位服务类UUID的完整列表”的类型标签
\x03\x18-链路丢失服务UUID
\x02\x18-即时警报服务UUID
\x04\x18 - TX电源服务UUID
\xF5\xFE-对话SUOTA服务UUID
你好，朱巴祖，
你是说应用程序ADV_数据是如何确定的？APP_ADV_数据值由用户根据其在设备中实现的服务进行设置。
谢谢你的对话
@MT_DIALOG—我认为JBaczuk试图说的是，他不确定APP_ADV_DATA中的各种值代表什么，因此不清楚他可能如何修改APP_ADV_DATA以包括SUOTA服务。Joacimwe很好地展示了这些值代表什么，并告诉他在哪里可以找到这些信息。
以下是我对这一切的看法：BLE4.0规范相当复杂，如果不花大量时间阅读所有API文档之类的内容，我们这些刚刚起步的BLE开发人员根本不可能“知道”在哪里寻找，更不用说“知道”我们在寻找什么了。也许没有办法绕过陡峭的学习曲线，然而，Dialog在提供示例源代码方面非常有帮助，允许用户相当快地启动和运行。参考应用程序经过深思熟虑，它们很好地捕获了人们可能希望使用BLE的一般类型的应用程序，在本例中，DSP非常适合将旧的“有线”应用程序转换为BLE。更好的是，Dialog将根据请求提供对iOS和Android应用程序源代码的访问。因此，现在一个新的BLE开发者可以潜在地将他们的传统“有线”设备扩展到新兴的物联网。好东西。Dialog这样做并不是出于完全无私的原因——他们也不应该这样——他们希望出售大量的BLE芯片。
问题是：当足够多的人试图将一个有价值且广泛应用的实用程序（如DSP）与另一个同样有价值的实用程序（如SUOTA）合并时，他们失败了。显然需要更多的信息。Dialog的动机应该和以前一样——销售更多的可编程芯片！
所以这里有更多的动机：我目前正在研究这个问题，集成DSP和SUOTA实用程序。我已经设计了一款功能齐全的Android应用程序和一款功能齐全的iOS应用程序，这两款应用程序在我的设备上的性能都与预期一样，都可以在Play Store/app Store上使用。我的设备现在正处于设计的最后阶段（经过4次硬件修改），我准备将其推向市场，我的初始订单是5000台设备。基于我的设备最初的“有线”版本的成功，我预计还会卖出数万台。一旦我能够自信地使用SUOTA更新DSPS应用程序，我就“经得起未来考验”，我将开始发货我的设备，并购买更多的BLE芯片。
我的建议是：编写一个简单的应用程序说明，准确描述如何将DSPS实用程序与SUOTA实用程序集成。一个知识渊博的人（MT_Dialog）花在这方面的时间可能远远少于在这些论坛上反复回答问题所花的时间。此应用说明应与AN-B-029基本相同，其中描述了如何使用sample128修改模板项目。如果你能做到这一点，你将出售许多、许多、更多的BLE芯片，而这些芯片正是我将要购买的，这将使其他人能够快速、轻松地将他们的产品推向市场，而不用担心他们会发现自己“被固件限制所锁定”。
最好klim
嗨，克里姆9513，
感谢您的评论和提供的反馈，也许这种教程对于应用程序说明来说太小了，但我们计划在不久的将来以更维基的结构更新我们的FAQ部分，以便为用户上传小文章和教程。我同意这应该是第一批加入的条款之一。
BR MT_对话框