你好
我的申请有两个580，一个主从机
我希望两者有时间同步，时间精度是0.01s，最好是0.001s。
关键词:
设备:
⚠️
你好。。谢谢你来到论坛。令人兴奋的消息！我们现在正在迁移到新的论坛平台，该平台将提供更好的功能，并包含在主对话网站中。所有员额和帐户都已迁移。我们现在只接受新论坛的流量-请在//www.wsdof.com/support. 我们将在未来几天内修复bug/优化搜索和标记。
你好。。谢谢你来到论坛。令人兴奋的消息！我们现在正在迁移到新的论坛平台，该平台将提供更好的功能，并包含在主对话网站中。所有员额和帐户都已迁移。我们现在只接受新论坛的流量-请在//www.wsdof.com/support. 我们将在未来几天内修复bug/优化搜索和标记。
你好
假设同步要求仅适用于连接状态，您应该能够依赖连接事件结束的时间（此事件可以在rwble.c中检测到-在该文件中查找BLE_EVT_END）。
/ MHv
谢谢MT_dialog,
这几天我研究了你的建议，我想主设备和从设备的BLE_EVT_端同步发生，我可以在BLE_EVT_端从两侧发生后立即获得时间，然后我可以同步时间。
而BLE_EVT_END发生的如此频繁，我从双方找不到相应的事件，如何解决这个问题?
谢谢。
BLE主设备和从设备上的BLE_EVT_结束事件应尽可能接近同步。如果要限制同步发生的时间，可以实现写入的GATT特性，然后在以下事件结束时驱动逻辑进行同步。您可以在记录事件后立即在rwble.c中添加同步代码（此行记录事件：arch_rwble_last_event=BLE_EVT_END；-请注意，这一行在rwble.c中会出现两次。实际执行哪一行取决于您的电源优化设置）。在中央设备上的事件触发和外围设备上的事件触发之间可能存在固定的时间延迟，但它将是小的、恒定的，因此可以进行补偿。
使用BLE_EVT_END的优点之一是您将有大量的时间来管理同步算法。在下一次连接事件之前，不需要处理高优先级的irq。
你可以使用函数uint32_t lld_evt_time_get(void)来获取当前时间，每次增加625us。如果你需要更好的计时，你将不得不禁用睡眠和使用systick定时器，它可以提供低至1us的精度。
请让我们知道，如果你设法实施建议的解决方案。我想这个同步方案将在测距/距离应用中与超音结合起来会非常强大。适当地执行，您可能会得到英寸甚至厘米的类型精度。
/ MHv
/ MHv
亲爱的MT_dialog,
非常感谢你的快速回复。
我的问题集中在如何从主设备和从设备“识别”同一连接的相应BLE_EVT_端，因为事件一个接一个地发生得非常快，我无法区分不同的BLE_EVT_端事件。
该应用是远距离应用，但不是超声波测距。
0.01s的时间同步精度可以满足我的应用要求，更好的同步是首选，因为我不需要由于时间漂移而重置同步，以供短时间使用，我将实施建议的解决方案，但现在我重点关注如何从两侧“识别”对应的BLE_EVT_端。
再次感谢。
写入特征并知道连接间隔将允许您标记连接。数据的传输将在接下来的连接事件中发生，服务器端的接收也将发生(同样，可能会有一个偏移量，但这个偏移量应该是常量)。当数据被传输时，客户端将收到一个确认，服务器将收到一个数据已经到达的指示。
/ MHv
您好！
我的问题是两个580主从时间同步的问题,如何才能确定主从的BLE_EVT_END为相对应的事件呢?因为BLE_EVT_END是在不停快速地重复出现,我不知道如何确定主从对应的事件。
只有确定了主从相对应的BLE_EVT_END事件后才可以在事件发生后取得时间以同步。
谢谢！
亲爱的MHv_Dialog,
非常感谢你的回答。
坦率地说，我是这个领域的新手，虽然我觉得你的回答可能是对的，但经过很多研究，我还是不知道该怎么做。
1.确认和指示是什么?BLE_EVT_END吗?或其他事件吗?
2.我仍然不知道如何标记连接，我想应该有一些不同的东西来区分它。
希望你不要对我的问题不耐烦。
你好,本杰明,
首先，我想说的是，你们要做的事情并不简单。
但这里是我将如何尝试实现它的核心。首先，在中央和外围设备上，使用app_on_connection事件重置全局计数器。然后，在rwble.c中，找到引用BLE_EVT_END的两个位置（此事件有两个实现。运行哪一个取决于您对“使用电力优化”的使用）。两种实现都有这样一行：
arch\u rwble\u last\u事件=BLE\u EVT\u结束；
在这行之后，在中央和外围设备上，您可以增加在app_on_connection事件中重置的全局计数器，如上所述。两个计数器，一个在中央/主服务器上，一个在外设/从服务器上，将同步运行，因为双方的BLE事件在“几乎完全”相同的时间(微秒间隔)结束——只要你不开始实现从服务器延迟。计数器将是你的粗糙时间。这将给你一个同步的主服务器和从服务器，但是粒度取决于连接间隔(最小7.5ms)。要实现更细的粒度，您可以基于SysTick计时器实现一个细的计时器(有关详细信息，请参阅参考手册)。这个计时器应该在每个BLE_EVT_END重置，并允许您将粒度降低到几微秒。请注意SysTick计时器只在设备处于清醒状态时工作，因此fine计时器仅在您处于清醒状态时有效。
我希望这对你有所帮助。让我们都知道结果如何。
/米凯尔
你好再次,
我刚刚实现了上面描述的概念，结果很有希望。我使用无代码项目作为起点，并改变rwble.c来切换BLE_EVT_END上的GPIO高。然后将这个修改过的codelless hexfile加载到两个开发工具包中，并通过AT命令在它们之间建立连接(请参阅codelless文档)。我使用一个逻辑分析仪来监测两个gpio，我看到他们被一个3us偏移与偏移+/- 500ns分开。在使用声音的测距应用中，500ns相当于声音传播不到0.2mm。
有时从机会错过主机的传输（这是RF的“优点”），因此您需要在事件之间对计时器进行一些推算，以过滤掉这些实例。但它们应该很容易被发现。
/ MHv
嗨，米凯尔，
我正在测试你给我的方法，总的来说，这是一个很好的方法，可以满足我的需求。我计划有更多的测试，因为有问题，看到你有更多的信息在这里，我把我的测试结果放在这里。
我遇到的问题是，大约有1%的情况下BLE_EVT_END不是同步发生的，无论是从主端还是从药膏端，在最严重的情况下，异步是0.5ms，而其他99%的情况下，同步非常好。
对于我的应用程序，0.5ms异步是可以接受的，实际上，如果我愿意，我可以找到异步。
我正在进行更多的测试，以确定这是真正的异步化还是由于其他原因。
你提到“从机将错过从机的传输”，你的意思是BLE_EVT_END不会成对发生吗?我很担心这个，但是acc。在我的测试中，这从未发生过。如果这在理论上可以发生，或者像你发现的那样确实发生了，我可以设法避免它的影响。
再次谢谢你，迈克尔。
你好,本杰明,
很高兴听到你已经看到了结果。在RF的世界中，您偶尔会遇到其他流量阻止的频道，这导致“Miissing”连接事件。奴隶可能会错过主人的TX，并试图将其接收器保持一点时间。从奴隶不考虑才能结束，直到它超时，这导致ble_evt_end从奴隶的角度来看触发一点。事件仍然发生 - 但你实际上并不与主人同步。这很可能是你观察到的。关于右边的0.5ms。
/ MHv
嗨mhv_dialog，
非常感谢你的快速回复。
仍然对于“从机将错过从机的传输”，它听起来有时可能错过的内容，而事件(BLE_EVT_END
)永远不会错过(虽然偶尔可能会有一些延迟)，换句话说，BLE_EVT_END总是成对发生在主机和从端。
这是非常重要的，如果我假设事件成对发生，而有时在单方(主机或从机)有丢失的事件，这可能是大问题。
我需要确认一下。
如果在理论上，不会有任何遗漏的事件或双方的遗漏，我就放心了。
或者在理论上，在单方可能会有缺失的事件，我需要在我的函数中考虑这个。
谢谢。
我可以确定，双方的事件数量总是相同的。slave可能不会从中央“听到”消息，但事件仍然会结束——尽管时间会错过大约半毫秒的时间。换句话说，在时间方面会有一些异常值，但主端事件计数总是与从端事件计数相匹配。在您的例子中，1ms的精度已经足够好了，您真的不需要过滤任何内容。
/ MHv
嗨MHv_Dialog,
我将使用函数uint32_t lld_evt_time_get（void）获取您建议的当前时间，我发现能够重置此计时器对我来说非常方便，是否有任何功能可供我执行此操作？
谢谢。
你好,本杰明,
不幸的是，没有这样的功能。
/ MHv
嗨MHv_Dialog团队,
在使用上述方法时，我遇到了一个新的问题。
我使用“app_connect_confirm”而不是“app_on_connection”(我的SDK是3。我在SDK5中没有例子。x虽然我想使用它)重置一个全局计数器。
在“arch_rwble_last_event = BLE_EVT_END”之后，我按照你的建议在中央和外围增加全局计数器，这工作得很好，直到我发现新的问题。
问题如下：
从机和主机连接后的一段时间，短到几分钟，长到大约20分钟，在从机端，在调用“app\u disconnect\u func”后，从机无法从主机接收信息，但可以在两侧执行“arch\u rwble\u last\u event=BLE\u EVT\u END”，从机仍保持先前的速度，但在主机端，速度是从机速度的15倍。
我的分析如下:
连接中断，因为从设备无法接收来自主设备的信息，但为什么在两侧，设备都可以执行“arch\U rwble\U last\U事件=BLE\U EVT\U END”？
你能帮我做以下几件事吗？
在从端调用"app_disconnect_func"的可能原因是什么?我认为这两个设备应该没有糟糕的连接环境。
很明显时间同步是不可能的，希望你能帮我解决这个问题。
谢谢
嗨BenjaminDu,
是的，如果设备通过app_disconnect_func，那么连接断开了，BLE_EVT_END是一个状态，当设备在发布广告时，当设备连接时，它表示BLE活动的结束周期。所以你的设备失去了连接，它继续广告，所以你将从广告事件获得BLE_END_EVT。关于的断开,断开的发生有许多原因,可以初始化从中央或断开外围本身,可能松散连接的设备如果外围出于某种原因没有找到主人指定的连接上的间隔,或者由于某种原因，当连接间隔时间到达时，从服务器的主服务器发送或接收延迟。首先可以在app_disconnect_func()中检查设备断开时的原因，以确定580报告的断开原因。
由于MT_dialog
嗨MT_dialog团队,
正如前面讨论的,
BLE_EVT_END总是成对发生在主机和从端
并且有了计数器，事件发生后，时间可以同步。
但是如果其中一个设备繁忙(例如:如果长时间或频繁定时器中断)，计数器在两边的显示是不同的。
1.如果BLE_EVT_END总是在主机和从端成对发生，这怎么可能发生
2.还有其他保持时间同步的方法吗？
非常感谢
便雅悯
嗨BenjaminDu,
由于MT_dialog