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

请注意，今天我已经更改了这个问题的标题，因为它可能看起来像我在询问社区广告数据或扫描响应的最大长度是多少。为了清楚起见，我知道它总共有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?

多么尴尬 - 我甚至不能删除这篇文章（只对帖子发表评论）： - /
无论如何，当我最初移植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