你好，
我们使用的是SDK 5.0.4的最后一个版本，我们创建了一个自定义配置文件，其中包含两个特征的特征，属性使用示例项目“ble_app_peripheral”。定期我们从外部传感器接收数据，我们使用通知更新数据库中的相应特性。除了确认之外，一切都正常工作。当我们逐个将通知发送到这两个特征时，我们仅对最后一个通知收到确认。在移动应用程序上，数据将正确更新。在收到前一封通知的确认时，是否有义务传输每个新通知？有没有办法跳过这段等待，但是要有所有期望的确认？
非常感谢您的答案。
设备：
嗨舞厅，
由于您发送了两个通知，因此您应该接收的确认器应该也是如此，每个句柄都是一个，每个句柄（一个用于您发送的不同特征的通知一个）。在确认前一个之后发送下一个通知，但它的最安全方法是没有强制发送，这是一个有限的通知，即设备可以缓冲，如果该缓冲区填满，则在某些时候发送通知这些消息将存储在您的堆中，如果您继续发送通知（在存储在堆上的通知之外，则不会向您的中央发送适当的值），因此您的堆最终将填充和平台。重置将断言。因此，发送通知的最安全方法是等待确认以避免结合。
谢谢mt_dialog.
你好mt_dialog，
谢谢你的答案，但试验显示有点不同的行为。确认的数量（成功与否）始终等于通知的数量。问题是，当我们有两个或多个具有属性“通知”的特征时，我们向这些特征发送两个或多个通知（一个逐个），所有接收的确认都是用于最后一个通知的特征。在这种情况下，我们的逻辑是收到每个特征的通知，可以写入/通知新数据将无法正常工作。
顺便说一下，DSP项目中的对话框中使用的通知方法也不适用于我们的案例。等待每一个确认不是最好的解决方案，因为保持下一个
通知并降低连接的吞吐量。
嗨舞厅，
我不确定我很匹配，当你一个接一个地说出一个通知你第一次等待确认消息custs1_val_ntf_cfm后，然后你向下一个特征发送下一个。即使您向相同的特征发送两个通知，您也应该再次采取两次确认（FW应响应两个Custs1_Val_ntf_cfm消息）。您还可以使用像Ble_App_Peripheral（）这样的某些Finamer的简单项目测试这一点，您可以使用按钮特性并通过第二个定时器发送通知并捕获不同特性的确认（如下所示），您可以添加ARCH_SET_PXACT_GPIO（）函数通过SMART SPIPPET电源分析器工具，函数应该强制工具指示用垂直红线完成通知，所以你应该在每次推动后得到两个线。
案例custs1_val_ntf_cfm：
{
struct musts1_val_ntf_cfm const * msg_param =（struct custs1_val_ntf_cfm const *）（param）;
交换机（msg_param->句柄）
{
案例cust1_dx_adc_val_1_val：
ARCH_SET_PXACT_GPIO（）;
休息;
案例cust1_dx_button_state_val：
ARCH_SET_PXACT_GPIO（）;
休息;
案例cust1_dx_long_value_val：
休息;
默认：
休息;
}
} 休息;
谢谢mt_dialog.
你好mt_dialog，
可能是我的解释不正确。对不起。一个逐个意味着我们向第一个特征发送第一通知并立即进行第二个特征的第二个通知，没有等待第一个确认期望，后来将接收这两个通知的2个单独的确认。是的，我们收到了这两个确认，而是始终用句柄进行第二个/最后一个通知的特征。那就是问题所在。
嗨舞厅，
正如我所提到的那样，即使你将获得两个确认你发送的通知，如果检查Custs1_val_ntf_req_handler（）函数的Custs1_val_ntf_req的处理程序，您将看到如果通知已成功分配和放入缓冲区有一个custs1_val_ntf_cfm，被分配并发送到应用程序，因此如果您发送两个通知，则将有两个Custs1_Val_ntf_cfm，一个用于您更新的每个特征。如果您在应用程序中没有看到，当您获取Custs1_Val_ntf_cfm时，您可以检查通知是否从上面粘贴的开关盒中获取通知的特征？您是否尝试在像Ble_App_Peripheral这样的简单示例上复制您的问题？我可以想到的唯一原因如果您遇到类似的东西是您正在更新相同的特征，则Custs1_Val_ntf_Req的句柄成员在两个通知中都是相同的。
谢谢mt_dialog.
嗨mt_dialog，
这是我们的预期行为，但结果是不同的。再次始终返回的确认是为了上次通知的特征。对于测试，我们完全使用项目“ble_peripheral”，具有两个不同的特征，具有“notify”属性。根据我们，问题在于包含NTF_Handle / Ind_Handle的变量“custs1_env”。你怎么看？我们对吗？
嗨舞厅，
我不知道如何发生这种情况，就像我提到的一样，Custs1_val_ntf_req由custs1_val_ntf_req_handler（）函数处理，如果检查这个函数它将在中央发送通知，它还将分配和发送（如果消息不发送消息成功）CUSTS1_VAL_NTF_CFM，所以对于每个CUSTS1_VAL_NTF_REQ消息，CUSTS1_VAL_NTF_CFM是发送的（如果发生成功消息，CUTTS1_VAL_NTF_CFM将由GATTC_CMP_EVT_HANDLER（）发送）））。在Custs1_val_ntf_req_handler（）中发生消息的分配时，Custs1_val_ntf_cfm填充了已更新的句柄cfm-> handle = param->句柄（您已从custs1_val_ntf_req传递的句柄，此值也将更新custs1_env。ntf_enable in order to be send from the GATTC_CMP_EVT handler), so the message CUSTS1_VAL_NTF_CFM that you will receive will have as handle parameter the characteristic that you have just updated and send a notification, so if you send two CUSTS1_VAL_NTF_REQ you will receive two CUSTS1_VAL_NTF_CFM and the handle of the message retruned will be the updated characteristic. Thats why in the confirmation handler that i ve indicated above (the switch case) i am checking the handle for every CUSTS1_VAL_NTF_CFM i get. I dont see how the custs1_env and the ntf_handle/ind_handle has anything to do with it. Since those members are populated in the custs1_val_ntf_req_handler() in the case of a succesful notification send and used later on to send the confirmation message. If you paste a code about how i can replicate this, for example, in order to check, i used the ble_app_peripheral and applied the following mods.
在ADC的同一计时器处理程序上发送第二个通知（第一个通知的KE_MSG_SEND（MSG）的粘贴）：
/ *第二通知* /
struct susts1_val_ntf_req * req_2 = ke_msg_alloc_dyn（custs1_val_ntf_req，
task_custs1，
task_app，
custs1_val_ntf_req，
def_cust1_button_state_char_len）;
//待采样的ADC值
静态uint16_t sample_2;
sample_2 =（Sample_2 <= 0xFFFF）？（Sample_2 + 1）：0;
req_2-> conhdl = app_env-> conhdl;
req_2-> handle = cust1_idx_button_state_val;
req_2-> length = def_cust1_button_state_char_len;
memcpy（req_2->值，＆sample_2，def_cust1_button_state_char_len）;
ke_msg_send（req_2）;
在user_catch_rest_hndl（）中，在user_peripheral.c文件中我放置了cust1_idx_adc_val_1_val和cust1_dx_button_state_val下的ARCH_SET_PXACT_GPIO（），以便从两个更新中捕获确认，即使您没有Pro套件使用电源分布器，如果您放置断点两个案例应该在另一个之后发生。
谢谢mt_dialog.
你好mt_dialog，
谢谢你的详细答案。这是例子。您是否计算了每个特征的确认数量（例如，2通知，1确认第一个特征和第二个确认）？只有在第二次确认延迟时，只有在您的解释中，所有内容都将正常工作。请参阅函数custs1_val_ntf_req_handler（）中的代码。通过gatt发送指示 - custs1_env.ntf_handle = param->手柄;通过第二个通知，变量CUSTS1_ENV.NTF_HANDLE将包含第二个特征的句柄。由于第一次确认将由函数GattC_CMP_EVT_Handler（）发送第二个通知，因此所有确认都将使用最后保存的句柄（第二通知的句柄 - CFM->句柄= custs1_env.ntf_handle;）为什么，在Custs1_env.ntf_hadle的定义是写的，这是最后一个句柄。
最后，在这种情况下，副作用是所有确认都是为了令人不快的最后通知特征。
嗨舞厅，
对不起，很好地看起来很有用什么是有效的，我可以看到你所提到的事情正在发生，这是因为这两个ults1_val_ntf_req将运行，两个prf_server_send_event（）将执行，但是custs1_env.ntf_handle = param- >句柄只会保持第二个句柄（使用断点显然是发出延迟，我想这就是为什么我可以在断开断开之前获得两个指示的原因，就我所能告诉我，我也用SDK检查了。团队无法围绕这一点，因为它的目前的SDK（Gattc_cmp_evt消息的执行情况，指示缓冲区中通知的成功放置不包括通知发送的特征的句柄，因此可以填充该信息通过自定义配置文件的情况或应用程序本身的情况下通过配置文件任务，但您可以假设第一个通知已将其放入缓冲区中以便发送。完整和推动额外的通知主要是为了保持缓冲区，以免溢出，但显然还有额外的用法。
如果您想这样做，您可以尝试更改Custs1_env结构以及Handlers1_val_ntf_req_handler（）以及保留类似缓冲区的缓冲区，以便跟踪您正在进行确认的特征。执行是串行的，这意味着无论是什么特征都已首先通知您将获得确认。
谢谢mt_dialog.
谢谢mt_dialog。
最后，我们找到了真相。我希望我的问题的答案对本论坛中的所有成员有用。我的建议是对话框半导体，包括在文档UM-B雷竞技电竞平台-050_DA1458x_software_developer's_guide_1v1.pdf中包含此特定情况，因为所有示例项目都有两个或多个具有属性“通知或指示”的特征。
祝你今天过得愉快。
嗨舞厅，
我已经向SDK团队发出了一张机票，以改善SDK的未来版本的处理，如果您发现上述任何答案有用，请将其标记为已接受。
谢谢mt_dialog.