你好,
我们使用了SDK 5.0.4的最新版本，并使用示例项目“ble_app_peripheral”创建了一个带有两个特性的自定义概要文件。我们定期从外部传感器接收数据，并使用通知更新数据库中相应的特征。除了确认外，其他都工作正常。当我们逐个发送这两个特征的通知时，我们只会收到最后一个通知的确认。在移动应用程序上，数据被正确更新。收到前一份通知书的确认后，是否必须传送每一份新通知书?有什么办法可以跳过等待，而得到所有期待的确认吗?
提前感谢你的回答。
设备:
嗨AngelT,
由于您发送了两个通知，因此您应该接收的确认器应该也是如此，每个句柄都是一个，每个句柄（一个用于您发送的不同特征的通知一个）。在确认前一个之后发送下一个通知，但它的最安全方法是没有强制发送，这是一个有限的通知，即设备可以缓冲，如果该缓冲区填满，则在某些时候发送通知这些消息将存储在您的堆中，如果您继续发送通知（在存储在堆上的通知之外，则不会向您的中央发送适当的值），因此您的堆最终将填充和平台。重置将断言。因此，发送通知的最安全方法是等待确认以避免结合。
谢谢mt_dialog.
你好MT_dialog,
谢谢你的回答，但我们的测试显示了一些不同的行为。确认的数量(成功或不成功)总是等于通知的数量。问题是，当我们有两个或多个带有属性“Notify”的特征时，我们向这些特征发送两个或多个通知(一个接一个)，所有收到的确认都是针对最后一个通知的特征。在这种情况下，我们的逻辑是否接收到每个特征的通知，是否可以写入/通知新数据，将不起作用。
顺便说一下，DSPS项目中Dialog所使用的通知方法在我们的例子中也不适用。等待每一次确认并不是最好的办法，因为保持下一个
通知并降低连接的吞吐量。
嗨AngelT,
我不确定我很匹配，当你一个接一个地说出一个通知你第一次等待确认消息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_IDX_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,
可能是我的解释不正确。对不起。一个逐个意味着我们向第一个特征发送第一通知并立即进行第二个特征的第二个通知，没有等待第一个确认期望，后来将接收这两个通知的2个单独的确认。是的，我们收到了这两个确认，而是始终用句柄进行第二个/最后一个通知的特征。那就是问题所在。
嗨AngelT,
正如我所提到的，即使是这样，如果检查CUSTS1_VAL_NTF_REQ的处理程序，也就是custs1_val_ntf_req_handler()函数，您也将获得对已发送的通知的两个确认，您将看到,如果通知成功分配和放置在缓冲区有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”。你怎么看？我们对吗？
嗨AngelT,
我不知道它是如何发生的,就像我前面提到的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 custs1_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 - > = 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个第一个特征的确认，1个第二个特征的确认)?只有第二次确认延迟，才会像你说的那样正常工作。参见custs1_val_ntf_req_handler()函数中的代码。通过GATT - custs1_env发送指示。ntf_handle =参数- >处理;。第二个通知是变量custs1_env。Ntf_handle将包含第二个特征的句柄。因为FIRST确认将在SECOND通知之后由gattc_cmp_evt_handler()函数发送，所以所有的确认将使用最后保存的句柄(第二个通知的句柄- cfm->handle = custs1_env.ntf_handle;)根据为什么，在custs1_env的定义中。ntf_hadle is written that this is the LAST handle.
最后，这种情况下的副作用是，所有的确认都是针对最后一个通知的特性，这非常令人不快。
嗨AngelT,
抱歉长post显然你所提到的是有效的，我可以看到你所提到的正在发生，这是因为CUSTS1_VAL_NTF_REQ将运行，两个prf_server_send_event()将执行，但custs1_env。ntf_handle =参数- >处理将只保留第二处理(使用断点显然是发布延迟,我想这就是为什么我可以得到两个信号断开前发生),据我所知,我也已经与SDK团队检查没有解决这个问题的办法,以来的当前实现SDK (GATTC_CMP_EVT消息表明succesfull放置缓冲多恩不包括通知的通知发送的特点的处理通过填充的信息概要任务的自定义概要或由应用程序本身),但是您可以假设第一个通知已经被放置到缓冲区中以便发送。完整和推送额外的通知主要是为了保持缓冲区以防止溢出，但显然也有额外的用途。
如果你想做,你可以试着改变custs1_env结构以及处理程序custs1_val_ntf_req_handler()和保持类似的缓冲区为你发送的通知为了跟踪的特点你正在等待确认。执行是串行的，这意味着无论哪个特征首先得到通知，您都将得到确认。
谢谢mt_dialog.
谢谢MT_dialog。
我们终于找到了真相。我希望我的问题的答案对这个论坛的所有成员都有用。我的建议是Dialog Semicondu雷竞技电竞平台ctor在文档UM-B-050_DA1458x_Software_Developer's_Guide_1v1.pdf中包含这个具体的案例，因为所有的示例项目都具有两个或两个以上的属性“通知或指示”。
祝你今天过得愉快。
嗨AngelT,
我已经给SDK团队开了一张票，以便在未来的SDK版本中改进处理，如果您发现上述答案有帮助，请标记为接受。
谢谢mt_dialog.