[问答]

BlueNRG-MS v7.2c Central为什么不能接收MAX_ADV_DATA_LEN？

问答对人有帮助，内容完整，我也想知道答案 0 Hello - wrt BLE广告的最大总大小或31字节的扫描响应： BlueNRG-MS v7.2c外设可以产生最大预期长度。但是当我运行BlueNRG-MS v7.2c Central时，如果任一数据包的总长度> 18字节，然后相应的ADV_IND或SCAN_RSP事件从未作为EVT_LE_ADVERtiSING_REPORT事件接收。除了iOS和Android设备上的BLE堆栈之外，我评估的其他3个供应商平台的嵌入式BLE堆栈的中央设备都可以接收广告或扫描响应的最大总长度。这种观察是由我在实施ST BlueNRG Central中的错误引起的，还是已知且有记录的限制？怀疑BlueNRG-MS外设可以产生最大长度为31个字节，但中心总共限制为18个字节。更可疑的是，观察到的18的限制小于20字节的全长通知，我的BlueNRG Central实现一旦连接就可以接收。可以肯定的是，bluenrg_gap.h包含这个常量：＆amp; sharpdefine MAX_ADV_DATA_LEN（31）＃bluenrg-MS-ADV_IND-SCAN_RSP-max_adv_data_len 以上来自于谷歌翻译以下为原文 Hello - wrt the maximum total size of a BLE advertisement or scan response of 31 bytes: The BlueNRG-MS v7.2c Peripheral can generate either at max expected length. But when I run the BlueNRG-MS v7.2c Central, if the total length of either packet is > 18 bytes, then the corresponding ADV_IND or SCAN_RSP event is never received as a EVT_LE_ADVERTISING_REPORT event. The Central device of the embedded BLE stack of the 3 other vendor platforms I have evaluated can all receive up to the maximum total length of either the advertisement or scan response in addition to the BLE stacks on the iOS and Android devices. Is this observation caused by an error in my implementation of the ST BlueNRG Central, or is it a known and documented limitation? It is suspicious that the BlueNRG-MS Peripheral can produce either at the max length of 31 bytes, but the Central is limited to 18 bytes total. Even more suspicious is that the observed limit of 18 is less than a full length Notification of 20 bytes, which my implementation of the BlueNRG Central can receive once connected. To be sure, bluenrg_gap.h contains this constant: &sharpdefine MAX_ADV_DATA_LEN (31) #bluenrg-ms-adv_ind-scan_rsp-max_adv_data_len 0
2019-3-4 07:39:30　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × wang21cj 该类别下有 44 个回答。邀请回答新星之火12138 该类别下有 41 个回答。邀请回答 chm5 该类别下有 39 个回答。邀请回答 hgimtk 该类别下有 33 个回答。邀请回答 HengDu 该类别下有 30 个回答。邀请回答 hwp0415229 该类别下有 28 个回答。邀请回答 jghgfdssas 该类别下有 28 个回答。邀请回答颜刚YanG 该类别下有 26 个回答。邀请回答可口可甜该类别下有 26 个回答。邀请回答 kingnet6688 该类别下有 26 个回答。邀请回答 jenny042 该类别下有 25 个回答。邀请回答 kingnet9999 该类别下有 25 个回答。邀请回答 andyfly7 该类别下有 25 个回答。邀请回答麻酱该类别下有 25 个回答。邀请回答 zyh34997 该类别下有 25 个回答。邀请回答柱子图宁该类别下有 25 个回答。邀请回答云汉007 该类别下有 24 个回答。邀请回答 ggfvxv 该类别下有 24 个回答。邀请回答 heks 该类别下有 24 个回答。邀请回答 iyfhnvbn 该类别下有 24 个回答。邀请回答举报周丽相关推荐 • BlueNRG-MS如何写入远程特性 1518 • 如何计算最佳连接间隔？ 1886 • 如何检查BlueNRG-MS版本是否会影响其他任何命令？ 1928 • BlueNRG-MS v7.2c Mode4同步扫描和播发示例？ 2087 • BlueNRG-MS GATT不能执行 2670 • BlueNRG-MS fw 7.2c挂断 2493 • BlueNRG-MS（IDB05A1）怎么与BLE上的第三方设备连接 1634 • BlueNRG-MS fw 7.2c挂断问题如何解决？ 177 • BlueNRG-MS的包装标记规格在哪里可以找到？ 1305 • 硬件重置时BlueNRG-MS SPI事务意外响应怎么解决？ 245 2个回答

答案对人有帮助，有参考价值 0 请注意，今天我已经更改了这个问题的标题，因为它可能看起来像我在询问社区广告数据或扫描响应的最大长度是多少。为了清楚起见，我知道它总共有31个字节并且记录得非常好。我正在报告一个观察结果，当使用v7.2c运行ST BlueNRG-MS时，在模式4中配置为GAP_CENTRAL_ROLE_IDB05A1（模式4：主/从，4个连接，RAM1和RAM2同时扫描和广告），如果BLE外设实现的话一个超过18个字节的广告或扫描响应（是的，我知道，那些字节必须根据规范仔细构造为长度字节，数据类型，数据;长度字节，数据类型，数据......）然后ST BlueNRG-MS Central设备从不为应用程序生成相应的ADV_IND或SCAN_RSP事件。我注意到使用配置为GAP_PERIPHERAL_ROLE_IDB05A1的带有v7.2c的BlueNRG-MS，ST BlueNRG-MS外设可以使用MAX_ADV_DATA_LEN字节生成通告和扫描响应，并使用其他供应商的嵌入式BLE Central演示，中央可以获得此最大值长度。因此，我要求社区寻求帮助： - 你可以复制这个观察吗？ - 如果没有，你能想象我正在使用可能导致这种限制的ST BLE Central示例应用程序的错误吗？ - 如果是，是否将ST BLE Central的限制记录为错误和/或计划在BlueNRG-MS即将发布的f / w版本中修复？以上来自于谷歌翻译以下为原文 Note that today I have changed the title of this question since it may have looked like I was asking the community what is the max length of the advertising data or scan response. To be clear, I understand that it is 31 bytes total and very well documented. I am reporting an observation that when running the ST BlueNRG-MS with v7.2c, configured as a GAP_CENTRAL_ROLE_IDB05A1 in Mode 4 (Mode 4: master/slave, 4 connections, RAM1 and RAM2 simultaneous scanning and advertising), if a BLE Peripheral implements an advertisement or scan response that is longer than 18 total bytes (yes, I know, those bytes have to be carefully constructed according to specification as length byte, data type, data; length byte, data type, data...) then the ST BlueNRG-MS Central device never generates the corresponding ADV_IND or SCAN_RSP event to the application. I note that using the BlueNRG-MS with v7.2c, configured as GAP_PERIPHERAL_ROLE_IDB05A1, the ST BlueNRG-MS Peripheral can generate advertisements and scan response with MAX_ADV_DATA_LEN bytes, and using the embedded BLE Central demos of other vendors, the Central can receive this max length. Thus I am asking the community for help with this: - can you duplicate this observation? - if not, can you imagine the mistake that I am making working with the ST BLE Central sample application that could cause this limitation? - if yes, is this limitation of the ST BLE Central documented as an erratum and/or scheduled to be fixed in an imminent f/w release for the BlueNRG-MS?

2019-3-4 07:54:29 评论举报周丽

答案对人有帮助，有参考价值 0 多么尴尬 - 我甚至不能删除这篇文章（只对帖子发表评论）： - / 无论如何，当我最初移植ACI示例应用程序代码〜2年前，我只专注于BLE外设，而我见过的最大数据包是22 + 3字节，所以我向上舍入并设置了最大预期数据包大小从BlueNRG-MS到FreeRTOS队列的30 + 3字节，我将它们推入BlueNRG-IRQ中断，以便在任务级别进行后续处理。嗯，这个最大尺寸足以让很多有用的东西工作，即使是作为一个BLE Central ...当然，直到现在，当我遇到这个无法找到广告外围设备更广告的问题/扫描响应数据大小。现在是一个hci_uart_pckt - ＆gt; hci_event_pckt - ＆gt; evt_le_meta_event - ＆gt; le_advertising_info具有31字节的广告/扫描响应有效载荷（以及BlueNRG-MS一次只能传递1个广告/扫描响应的经验结果，即使#of消息的字节意味着可能有更多，但从未有过）所有这些都需要至少43 + 3字节的接收缓冲区。因此，我会相应地提高最大Rx buf尺寸，看看在我做另一个令人尴尬的帖子寻求帮助之前可以持续多少年......或者我可能仍然能够找到这一个并且仁慈地提醒我在哪里看： - 0 以上来自于谷歌翻译以下为原文 How embarrassing - and I cannot even delete this post (only comments to posts) :-/ Anyway, when I originally ported the ACI sample app code ~2 years ago, I was only focused on the BLE Peripheral, and the biggest packet I had ever seen was 22+3 bytes, so I rounded up and set a max expected packet size from the BlueNRG-MS to 30+3 bytes for the FreeRTOS queues that I push them into in the BlueNRG-IRQ interrupt for later processing at the task level. Well, that max size has been good enough to get a lot of useful stuff working, even as a BLE Central ... until now, of course, when I ran into this issue of not being able to find an advertising Peripheral with bigger advertisement/scan response data sizes. Now a hci_uart_pckt --> hci_event_pckt --> evt_le_meta_event --> le_advertising_info with a 31-byte advertising/scan response payload (and the empirical result that BlueNRG-MS only ever passes 1 advertisement/scan response at a time even though the byte for #of messages implies that there could be more, there never is) all of this requires a receive buffer of at least 43+3 bytes. So I will bump up the max Rx buf size accordingly and see how many years I can last before I make another embarrassing post for help ... or maybe I will still be able find this one and mercifully be reminded of where to look :-0

2019-3-4 08:03:16 评论举报周丽