你好，
我们使用了SDK 5.0.4的最新版本，并使用示例项目“ble_app_peripheral”创建了一个带有两个特性的自定义概要文件。我们定期从外部传感器接收数据，并使用通知更新数据库中相应的特征。除了确认外，其他都工作正常。当我们逐个发送这两个特征的通知时，我们只会收到最后一个通知的确认。在移动应用程序上，数据被正确更新。收到前一份通知书的确认后，是否必须传送每一份新通知书?有什么办法可以跳过等待，而得到所有期待的确认吗?
提前感谢你的回答。
设备:
嗨舞厅，
因为发送两个通知，所以应该收到的确认也应该是两个，每个句柄对应一个确认(每个发送的不同特征的通知对应一个确认)。不是义务后发送下一个通知确认前一个,但它的最安全的方法,有一个有限的设备可以缓冲的通知,如果缓冲区填满,你继续发送通知在某种程度上这些信息将存储在堆,如果你继续发送通知(除了存储在堆上的通知不会向中央发送正确的值)，你的堆最终也会填满，平台重置将断言。因此，发送通知的最安全方式是等待确认，以避免连接。
由于MT_dialog
你好MT_dialog,
谢谢你的答案，但试验显示有点不同的行为。确认的数量（成功与否）始终等于通知的数量。问题是，当我们有两个或多个具有属性“通知”的特征时，我们向这些特征发送两个或多个通知（一个逐个），所有接收的确认都是用于最后一个通知的特征。在这种情况下，我们的逻辑是收到每个特征的通知，可以写入/通知新数据将无法正常工作。
顺便说一下，DSP项目中的对话框中使用的通知方法也不适用于我们的案例。等待每一个确认不是最好的解决方案，因为保持下一个
通知并降低连接的吞吐量。
嗨舞厅，
我不确定我完全理解这种情况，当你说一个接一个，我想在你发送一个通知之后，你首先等待确认消息CUSTS1_VAL_NTF_CFM，然后你发送下一个相同的特征。即使你发送了两个通知给相同的特征，你也应该再次接受两个确认(fw应该用两个CUSTS1_VAL_NTF_CFM消息响应)。您还可以使用一个简单的项目来测试这一点，使用一些基础设施，如ble_app_peripheral()，您可以使用按钮特征，并通过第二个计时器发送通知，并捕捉不同特征的两个确认(如下所示)，您可以添加arch_set_pxact_gpio()函数，并通过Smart Snippets功率分析器工具观察它，该函数应该强制工具用一条垂直的红线表示通知的完成，因此您应该在每次推送后得到其中的两行。
案例custs1_val_ntf_cfm：
｛
Struct custs1_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_IDX_BUTTON_STATE_VAL:
arch_set_pxact_gpio ();
打破;
案例CUST1_IDX_LONG_VALUE_VAL:
打破;
默认值:
打破;
｝
}打破;
由于MT_dialog
你好MT_dialog,
也许我的解释是不正确的。对不起。一个接一个意味着我们发送第一个特征的第一个通知，并立即发送第二个特征的第二个通知，而不等待第一个确认，期望稍后将收到这两个通知的两个单独的确认。是的，我们收到了这两份确认，但总是有处理第二个/最后一个通知的特征。这就是问题所在。
嗨舞厅，
正如我所提到的那样，即使你将获得两个确认你发送的通知，如果检查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,
这是我们所期望的行为，但结果却不同。同样的ALWAYS，返回的确认是针对最后一个通知的特征。对于测试，我们使用项目“ble_peripheral”，带有两个不同的属性“Notify”。根据我们的说法，问题是在变量“custs1_env”中，它包含ntf_handle/ind_handle。你觉得呢?我们对吧?
嗨舞厅，
我不知道它是如何发生的,就像我前面提到的CUSTS1_VAL_NTF_REQ处理custs1_val_ntf_req_handler()函数,这个函数如果你检查它会发送通知中央,它还将分配和发送(如果消息没有发送成功)CUSTS1_VAL_NTF_CFM,因此，对于每个CUSTS1_VAL_NTF_REQ消息，将发送一个CUSTS1_VAL_NTF_CFM(如果消息成功，CUSTS1_VAL_NTF_CFM将由gattc_cmp_evt_handler()发送)。在发生消息分配的custs1_val_ntf_req_handler()中，结构custs1_val_ntf_cfm中填充了更新后的句柄cfm->句柄= param->句柄(从CUSTS1_VAL_NTF_REQ中传递的句柄，此值也将更新custs1_env。ntf_enable以便从GATTC_CMP_EVT处理程序发送)，因此您将接收到的消息CUSTS1_VAL_NTF_CFM将具有您刚刚更新的特征作为处理参数，并发送一个通知，因此，如果发送两个CUSTS1_VAL_NTF_REQ，您将收到两个CUSTS1_VAL_NTF_CFM，并且返回的消息句柄将是更新后的特征。这就是为什么在我上面指出的确认处理程序(开关情况)中，我检查每个CUSTS1_VAL_NTF_CFM的句柄。我不知道custs1_env和ntf_handle/ind_handle与它有什么关系。因为在成功发送通知的情况下，这些成员将被填充到custs1_val_ntf_req_handler()中，稍后将用于发送确认消息。如果你粘贴一个代码关于我如何可以复制这个，例如，为了检查，我使用了ble_app_peripheral和应用以下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 - >处理= 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_peripherals.c文件我放在一个arch_set_pxact_gpio () CUST1_IDX_ADC_VAL_1_VAL下CUST1_IDX_BUTTON_STATE_VAL为了赶上确认从更新,即使你没有专业工具使用分析器,如果您放置了一个断点，这两种情况都应该依次发生。
由于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结构以及处理程序custs1_val_ntf_req_handler()和保持类似的缓冲区为你发送的通知为了跟踪的特点你正在等待确认。执行是串行的，这意味着无论哪个特征首先得到通知，您都将得到确认。
由于MT_dialog
谢谢MT_dialog。
最后，我们找到了真相。我希望我的问题的答案对本论坛中的所有成员有用。我的建议是对话框半导体，包括在文档UM-B雷竞技电竞平台-050_DA1458x_software_developer's_guide_1v1.pdf中包含此特定情况，因为所有示例项目都有两个或多个具有属性“通知或指示”的特征。
祝你过得愉快。
嗨舞厅，
我已经向SDK团队发出了一张机票，以改善SDK的未来版本的处理，如果您发现上述任何答案有用，请将其标记为已接受。
由于MT_dialog