作为其他人的说明，我有perused the docs/ forums, looked at reference projects, read through white papers, even contacted Dialog directly. After all this, I find there is a key point that I believe that they have failed to communicate. If I am wrong, this would be a GREAT place to correct me.
That said, you can, of course use a bonding process that requires a PIN. The problem, at least for me, is that the PIN is the SAME FOR EVERY INSTANCE of the peripheral device.
So if there were 5 of my devices in the same room, any person with my app could connect to any of the 5 devices (if they had the universal PIN).
Moreover, the iPhone/Android device would have NO WAY to distinguish WHICH of my devices it was connected to (the only difference from one to the next would be the BD Address).
So, please tell me that I HAVE THIS WRONG. If I am wrong, tell me, if not , here is an outline of a simple, but extremely VALUABLE reference project that I anticipate will help pretty much any developer that intends to use an iPhone/Android as the Central:
REFERENCE PROJECT: BUTTON-PRESS BINDING A CENTRAL TO A PERIPHERAL - 允许任何中央设备启动扫描的项目，其中外设响应广告。 --The Reference project has a custom characteristic that, in its advertising, contains some peripheral runtime data (a single byte would be sufficient, initially the btye could be 0x00). --The developer configures his app, at first ever turnon, to scan for peripherals of a certain name, then look at the data in that custom characteristic (without connecting). --The developer configures his app to refuse connection to ALL BD ADDRESSES for any peripherals, until the data in that characteristic reads a specific value (say 0xFF). - 当按下设备上的按钮时，参考项目配置为将自定义特性的值更改为0xFF 10秒钟。 --The developer configures his app to READ AND STORE the BD Address of the peripheral that shows the custom characteristic with 0xFF. --The developer configures his app so that at startup, it reads a list of stored BD Addresses and thereafter ALLOWS a connection to a peripheral that matches that stored BD ADDRESS.
In the end, all that is really required is that the developer write the custom characteristic to do what I described above, which is what I am in the process of doing now. If I am making this harder than it needs to be then please let me know. If anyone else sees the value of this idea, and wished Dialog to put together a reference project, please comment here. I bet one of their guys could accomplish this in less than an hour. For me, I will see how it goes....
I think the Bluetooth 4.0 standard is not really thought out. There is a "directed advertisement" solution which should be used to only connect to a known central, by including the central's bd address in the advertisement packet. But it's quite useless today since both Android and iOS use "resolvable private addresses". This means you first have to establish a connection before the peripheral can resolve the address and see if it is a known one. Bluetooth 4.2 will change this.
I don't understand what you mean by that in order to have an "exclusive" connection to a central you need to know the central's bd address at compile time (which also doesn't make sense since they use random resolvable addresses). And regarding pairing with PIN, it's up to the programmer of the DA14580 how this should be configured. Please check "RW-BLE-GAP-IS" and the Bluetooth specification. First, the IO capabilities settings define if the PIN should be entered on the central side or the peripheral side. The other should show a random PIN using a display, or a hardcoded one for each device the user can find out about somehow. If you want to have a different hardcoded PIN for each device, you can for example use some field in the OTP header to store this info. This way you can use the same application code.
Thank you for the response and your insight, I have seen many comments and posts from you here in the forums and you strike me as a solid source of information.
I have not read through all the various RW-BLE-xx API documents, it's a daunting process. and I am sure that a more thorough understanding of the layering and abstractions would be of great benefit to me and assist as a BLE device developer.
So to me, the simplest solution is what I describe above, and which you were good enough to confirm is a common requirement -- "to have different advertisement data for a "connectable" device and a device that only bonded devices should connect to is in fact quite common." That is what I had hoped to hear that this is a common enough requirement that Dialog would see the sense in having one of their developers put an hour or possibly less into a reference design which simply changes the advertisement data when a button on the peripheral device is pressed.
Thanks again for your input on this Joacimwe, I hope that I am not asking for something that you and the Dialog team find to be terribly trivial and beneath further attention. I have tried on this forum to help out others whenever I am in the position, I appreciate your time and help and will continue to pay it forward.
Hi again. I unfortunately don't have direct code, but rather some hints.
About the whitelist thing. It's not mandatory to store the addresses in OTP. If you look in RW-BLE-GAP-IS, there are some APIs in GAPM_WHITE_LIST_MGT_CMD to add/remove devices from the white list. For some reason you can only have 3 devices though... But this solution is quite worthless with iOS/Android since most of these phones use resolvable random addresses.
If you want to block non-known centrals connecting to you, you need to use the GAPM_RESOLV_ADDR_CMD functionality, which in response gives you a GAPM_ADDR_SOLVED_IND message if a known central was connecting (unless someone spoofs the address so you should still require encryption to be sure if you want security), or a GAPM_CMP_EVT with status GAP_ERR_NOT_FOUND if not, and if so you can disconnect the link.
I don't know your use case but it seems you don't really need security?
Anyway, to change the advertisement data, look at the app_adv_func if you're using SDK3. In SDK5, check out the user_profile.c in the ble_app_profile example. 然后，只要你想要重新启动广告的问题就是一个问题。
嗨马特拉德，
请参阅第5.6章中的差距界面纸“RW-BLE-GAP-IS”，有关粘合的详细说明。
Regards!
PY
如果我将中央设备的BD地址添加到白名单，我如何重新连接到这个中心设备？可以与否，哪个API？
作为其他人的说明，我有perused the docs/ forums, looked at reference projects, read through white papers, even contacted Dialog directly. After all this, I find there is a key point that I believe that they have failed to communicate. If I am wrong, this would be a GREAT place to correct me.
我断言，如果您希望在iPhone或Android设备之间拥有独占连接，则该设备的BD地址必须在编译时以（并添加到白名单）。
That said, you can, of course use a bonding process that requires a PIN. The problem, at least for me, is that the PIN is the SAME FOR EVERY INSTANCE of the peripheral device.
So if there were 5 of my devices in the same room, any person with my app could connect to any of the 5 devices (if they had the universal PIN).
Moreover, the iPhone/Android device would have NO WAY to distinguish WHICH of my devices it was connected to (the only difference from one to the next would be the BD Address).
对于我的设计，我希望用户能够将他的手机连接到自己的设备，忽略同一附近的其他用户的设备。我也不希望其他用户的手机能够连接到彼此的设备，只有他们先前已经建立了“绑定”（而不是债券，这是使用上面讨论的引脚的判配/加密的过程）））。
So, please tell me that I HAVE THIS WRONG. If I am wrong, tell me, if not , here is an outline of a simple, but extremely VALUABLE reference project that I anticipate will help pretty much any developer that intends to use an iPhone/Android as the Central:
REFERENCE PROJECT: BUTTON-PRESS BINDING A CENTRAL TO A PERIPHERAL
- 允许任何中央设备启动扫描的项目，其中外设响应广告。
--The Reference project has a custom characteristic that, in its advertising, contains some peripheral runtime data (a single byte would be sufficient, initially the btye could be 0x00).
--The developer configures his app, at first ever turnon, to scan for peripherals of a certain name, then look at the data in that custom characteristic (without connecting).
--The developer configures his app to refuse connection to ALL BD ADDRESSES for any peripherals, until the data in that characteristic reads a specific value (say 0xFF).
- 当按下设备上的按钮时，参考项目配置为将自定义特性的值更改为0xFF 10秒钟。
--The developer configures his app to READ AND STORE the BD Address of the peripheral that shows the custom characteristic with 0xFF.
--The developer configures his app so that at startup, it reads a list of stored BD Addresses and thereafter ALLOWS a connection to a peripheral that matches that stored BD ADDRESS.
问题现在解决了。授予，其他应用程序开发人员可能会编写他的应用程序来连接到任何用户的设备，尽管是自定义特征的值。所以这不是一个'安全'连接。但如果我们不需要它，我们所需要的只是在同一区域运行的多个外围/中央设备，这会很好地解决问题。甚至更好，它使用户可以将他的iPhone / Android连接到多个外围设备，只要用户先前在每个外设上执行了“绑定”。
我们可以随时稍后将App / Wipheral配置为上述操作，但也执行键，此时连接现在安全。
In the end, all that is really required is that the developer write the custom characteristic to do what I described above, which is what I am in the process of doing now. If I am making this harder than it needs to be then please let me know. If anyone else sees the value of this idea, and wished Dialog to put together a reference project, please comment here. I bet one of their guys could accomplish this in less than an hour. For me, I will see how it goes....
Cheers --klim
你好。具有不同广告数据的解决方案对于“可连接”设备和仅粘合设备的设备应该连接到实际上非常常见。这可以以任何方式实现，使得广告数据是不同的。例如，宣传包含0或1的服务数据项。我猜使用“制造商数据”类型更常见。
I think the Bluetooth 4.0 standard is not really thought out. There is a "directed advertisement" solution which should be used to only connect to a known central, by including the central's bd address in the advertisement packet. But it's quite useless today since both Android and iOS use "resolvable private addresses". This means you first have to establish a connection before the peripheral can resolve the address and see if it is a known one. Bluetooth 4.2 will change this.
I don't understand what you mean by that in order to have an "exclusive" connection to a central you need to know the central's bd address at compile time (which also doesn't make sense since they use random resolvable addresses). And regarding pairing with PIN, it's up to the programmer of the DA14580 how this should be configured. Please check "RW-BLE-GAP-IS" and the Bluetooth specification. First, the IO capabilities settings define if the PIN should be entered on the central side or the peripheral side. The other should show a random PIN using a display, or a hardcoded one for each device the user can find out about somehow. If you want to have a different hardcoded PIN for each device, you can for example use some field in the OTP header to store this info. This way you can use the same application code.
Hi Joacimwe,
Thank you for the response and your insight, I have seen many comments and posts from you here in the forums and you strike me as a solid source of information.
I have not read through all the various RW-BLE-xx API documents, it's a daunting process. and I am sure that a more thorough understanding of the layering and abstractions would be of great benefit to me and assist as a BLE device developer.
事实是我是一个孤独的开发人员，因此我是任务在我们的设备上开发从硬件设计（第4个Gen Prototyp）对我们的BLE设备的应用程序级开发（在IOS和Android中的第四个原型）上开发所有内容目前，胜利遵循）。
所以我按时缩短了我可以通过BLE API文档读取阅读。这就是为什么我看过这里的论坛的洞察力，以及为什么我在对话对话的非常有用的参考设计上放置这样的价值。这也是为什么我在上面的评论中问我是否错误或遗漏了一些东西，我很可能是我。如果是这样，在我看来，这是一个完美的校正所发布的地方，因为我没有能够找到一个我认为的解决方案是一个非常普遍的目标。
我将尝试更好地解释我对一个中央的“独家”的连接。我传达了我写到上面的对话的本质，他们足以向我发给我的白皮书，就白名单的主题发给我。我读过这篇论文（我现在没有和我在一起），我的白皮书的外卖就是白名单策略只能用来仅允许具有已知的BD地址的设备来连接，而必须知道该BD地址编程时间并将其放入OTP中的白名单。所以对我来说，白名单策略不起作用来限制与单个设备的连接。
写一个随机数PIN到OTP对我来说不起作用两个原因，一个原因，即我从外部闪存启动而不是没有编程OTP，更重要的是，我需要找到一种传达该PIN的方法来传达该PIN的方法最终用户如此，当他们第一次设置设备时，他们就会武装这些信息。将销钉压在设备上或在某种类型的文档中包括它伴随设备似乎充满了潜在问题;如果用户失去了纸张怎么办？如何在设备的壳体上启动正确的销钉？但也许我错过了一个明显的解决方案......
So to me, the simplest solution is what I describe above, and which you were good enough to confirm is a common requirement -- "to have different advertisement data for a "connectable" device and a device that only bonded devices should connect to is in fact quite common." That is what I had hoped to hear that this is a common enough requirement that Dialog would see the sense in having one of their developers put an hour or possibly less into a reference design which simply changes the advertisement data when a button on the peripheral device is pressed.
Thanks again for your input on this Joacimwe, I hope that I am not asking for something that you and the Dialog team find to be terribly trivial and beneath further attention. I have tried on this forum to help out others whenever I am in the position, I appreciate your time and help and will continue to pay it forward.
Cheers --klim
Hi again. I unfortunately don't have direct code, but rather some hints.
About the whitelist thing. It's not mandatory to store the addresses in OTP. If you look in RW-BLE-GAP-IS, there are some APIs in GAPM_WHITE_LIST_MGT_CMD to add/remove devices from the white list. For some reason you can only have 3 devices though... But this solution is quite worthless with iOS/Android since most of these phones use resolvable random addresses.
If you want to block non-known centrals connecting to you, you need to use the GAPM_RESOLV_ADDR_CMD functionality, which in response gives you a GAPM_ADDR_SOLVED_IND message if a known central was connecting (unless someone spoofs the address so you should still require encryption to be sure if you want security), or a GAPM_CMP_EVT with status GAP_ERR_NOT_FOUND if not, and if so you can disconnect the link.
I don't know your use case but it seems you don't really need security?
Anyway, to change the advertisement data, look at the app_adv_func if you're using SDK3. In SDK5, check out the user_profile.c in the ble_app_profile example.
然后，只要你想要重新启动广告的问题就是一个问题。
Hi Joacimwe,
谢谢你的提示,我将探索的方法changing the advertisement data, that seems to be the best solution to my problem.
Cheers, klim