你好,
我的应用程序有两个580,主人和奴隶我希望两者有时间同步,时间精度为0.01s,更好为0.001秒。
假设同步要求仅适用于连接状态,您应该能够依赖连接事件结束的定时(此事件可以在RWBE.C中检测到该文件中的BLE_EVT_END)。
/ mhv.
谢谢mt_dialog,
我现在研究了你的建议,我想主机和从属BLE_EVT_END发生同步,我可以在BLE_EVT_END发生在两侧后立即获得时间,然后我可以让时间同步。而BLE_EVT_END发生的如此频繁,我从双方找不到相应的事件,如何解决这个问题?
非常感谢。
BLE Master和Slave上的BLE_EVT_END事件应尽可能接近同步。如果要限制同步何时进行,则可以实现写入的GATT字符,然后将逻辑驱动到以下事件结束时驱动逻辑以同步。您可以在录制事件后立即在Rwble.c中添加同步码(此行记录事件:ARCH_RWBLE_LAST_EVENT = BLE_EVT_END; - 请注意,您将在RWBE.C中找到此行两次。它们实际上是哪一个执行取决于您的电源优化设置)。在中央的事件和外围设备上触发的事件触发之间可能存在固定的时间延迟,但它将是小的,常数,因此可以得到补偿。
使用BLE_EVT_END的优点之一是您将有大量的时间来管理同步算法。在下一次连接事件之前,不需要处理高优先级的irq。
你可以使用函数uint32_t lld_evt_time_get(void)来获取当前时间,每次增加625us。如果你需要更好的计时,你将不得不禁用睡眠和使用systick定时器,它可以提供低至1us的精度。
请让我们知道,如果你设法实施建议的解决方案。我想这个同步方案将在测距/距离应用中与超音结合起来会非常强大。适当地执行,您可能会得到英寸甚至厘米的类型精度。
亲爱的MT_dialog,
非常感谢您的快速反应。
我的问题中心周围如何“识别”相应的BLE_EVT_END与主站和从站相同的连接,因为该事件陆续到另一个非常快,我无法区分不同的BLE_EVT_END事件。
应用程序是距离应用,但不是超声测距。0.01s时间同步精度可以满足我的应用要求,更好的同步,因为我不需要由于时间漂移来重置同步,我将实施建议的解决方案,但现在我专注于如何“识别'来自双方的相应ble_evt_end。
再次感谢。
写入特征并了解连接间隔应允许您标记连接。数据传输将在以下连接事件上发生,因此在服务器端接收(再次,可能存在偏移量,但此偏移量应为常数)。客户端将在传输数据时收到确认,服务器将接收数据已到达的指示。
您好!我的问题是两个580主从时间同步的问题,如何才能确定主从的BLE_EVT_END为相对应的事件呢?因为BLE_EVT_END是在不停快速地重复出现,我不知道如何确定主从对应的事件。只只了主从相对应的ble_evt_end事件后才可在事件发生中的事件中。谢谢!
亲爱的MHv_Dialog,非常感谢你的回答。坦率地说,我是这个领域的新手,虽然我觉得你的回答可能是对的,但经过很多研究,我还是不知道该怎么做。
1.什么是确认和指示?ble_evt_end?或其他事件?2.我仍然不知道如何标记连接,我想应该有一些不同的东西来区分它。
希望你对我的问题不耐烦。
你好,本杰明,
让我开始说你已经开始做的事情并不简单:o)
但这是我如何尝试实现它的核心。首先,在中央和外设都使用App_On_Connection事件来重置全局计数器。然后,在Rwble.c中,找到引用BLE_EVT_END的两个位置(此事件有两种实现。哪一个运行取决于您使用“USE_POWER_OPTIMIZATIONS”)。两个实现都有这样的线:
ARCH_RWBLE_LAST_EVENT = BLE_EVT_END;
在这行之后,在中央和外围设备上,您可以增加在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的“美”),因此您需要在事件之间进行一些死亡时间来过滤掉这些实例。但它们应该很容易被发现。
嗨mikael,
我测试了你给我的方法,一般来说,这是一个很好的方法,可以满足我的需求。我计划在有问题上有更多的测试,看到你有更多的信息在这里,我首先把我的测试结果放在这里。我遇到的问题是大约有1%的情况下,BLE_EVT_END不会同步,无论是来自主侧还是从抛售侧同步,在最严重的情况下,异步为0.5ms,而其他99%的情况下,同步非常好。对于我的应用,实际上,0.5ms的异步是可接受的,如果我想要,我可以找到仿咽部。我正在进行更多的测试,以了解它是否是真实的异步,否则它是由于其他原因。
你提到“从机将错过从机的传输”,你的意思是BLE_EVT_END不会成对发生吗?我很担心这个,但是acc。在我的测试中,这从未发生过。如果这在理论上可以发生,或者像你发现的那样确实发生了,我可以设法避免它的影响。
再次谢谢你,迈克尔。
很高兴听到你已经看到了结果。在RF的世界中,您偶尔会遇到其他流量阻止的频道,这导致“Miissing”连接事件。奴隶可能会错过主人的TX,并试图将其接收器保持一点时间。从奴隶不考虑才能结束,直到它超时,这导致ble_evt_end从奴隶的角度来看触发一点。事件仍然发生 - 但你实际上并不与主人同步。这很可能是你观察到的。关于右边的0.5ms。
嗨mhv_dialog,
非常感谢您的快速反应。仍然对于“从奴隶会错过主人的传输”,它听起来可能会错过的内容有时候,而事件(ble_evt_end)永远不会错过(虽然偶尔可能会有一些延迟),换句话说,BLE_EVT_END总是成对发生在主机和从端。
这是非常重要的,如果我假设事件成对发生,而有时在单方(主机或从机)有丢失的事件,这可能是大问题。
我需要确认。如果在理论上,双方都不会有任何遗失的事件或错过,我会放心。或者在理论上,在单方可能会有缺失的事件,我需要在我的函数中考虑这个。
谢谢。
我可以确认两侧总会有相同数量的事件。从中央奴隶可能不会“听到”,但事件仍然会结束 - 尽管时机会错过一半的东西。换句话说,将有一些异常值与时序一样,但主侧的事件计数将始终匹配从设备的。在您的情况下,其中1ms精度足够好,您真的不必过滤掉。
嗨MHv_Dialog,
我将使用uint32_t lld_evt_time_get(void)获取当前时间,因为您推荐,我发现我能够重置这个计时器将非常方便,有没有任何功能可供我这样做?
不幸的是,没有这种功能。
嗨mhv_dialog团队,
在使用上述方法时,我遇到了一个新的问题。我使用“app_connect_confirm”而不是“app_on_connection”(我的SDK是3。我在SDK5中没有例子。x虽然我想使用它)重置一个全局计数器。在“arch_rwble_last_event = BLE_EVT_END”之后,我按照你的建议在中央和外围增加全局计数器,这工作得很好,直到我发现新的问题。
问题如下:有一段时间后,从奴隶和掌握后,短到几分钟,更长的是20分钟,在奴隶侧,在呼叫“app_disconnect_func”的时候,从机无法从主站接到信息,但“arch_rwble_last_event =”app_rwble_last_event =BLE_EVT_END“可以在两侧令人作呕,从站仍然处于先前的速度,但在主侧,速度是从速度的15倍。
我的分析如下:Connect坏了,因为从机无法接收来自主机的信息,但为什么在两侧,设备都可以执行“Arch_rwble_last_event = ble_evt_end”?
你能帮我解决以下问题吗?什么可能的reson为什么“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.任何其他方式保持时间同步吗?
非常感谢本杰明
你好,
假设同步要求仅适用于连接状态,您应该能够依赖连接事件结束的定时(此事件可以在RWBE.C中检测到该文件中的BLE_EVT_END)。
/ mhv.
谢谢mt_dialog,
我现在研究了你的建议,我想主机和从属BLE_EVT_END发生同步,我可以在BLE_EVT_END发生在两侧后立即获得时间,然后我可以让时间同步。
而BLE_EVT_END发生的如此频繁,我从双方找不到相应的事件,如何解决这个问题?
非常感谢。
BLE Master和Slave上的BLE_EVT_END事件应尽可能接近同步。如果要限制同步何时进行,则可以实现写入的GATT字符,然后将逻辑驱动到以下事件结束时驱动逻辑以同步。您可以在录制事件后立即在Rwble.c中添加同步码(此行记录事件:ARCH_RWBLE_LAST_EVENT = BLE_EVT_END; - 请注意,您将在RWBE.C中找到此行两次。它们实际上是哪一个执行取决于您的电源优化设置)。在中央的事件和外围设备上触发的事件触发之间可能存在固定的时间延迟,但它将是小的,常数,因此可以得到补偿。
使用BLE_EVT_END的优点之一是您将有大量的时间来管理同步算法。在下一次连接事件之前,不需要处理高优先级的irq。
你可以使用函数uint32_t lld_evt_time_get(void)来获取当前时间,每次增加625us。如果你需要更好的计时,你将不得不禁用睡眠和使用systick定时器,它可以提供低至1us的精度。
请让我们知道,如果你设法实施建议的解决方案。我想这个同步方案将在测距/距离应用中与超音结合起来会非常强大。适当地执行,您可能会得到英寸甚至厘米的类型精度。
/ mhv.
/ mhv.
亲爱的MT_dialog,
非常感谢您的快速反应。
我的问题中心周围如何“识别”相应的BLE_EVT_END与主站和从站相同的连接,因为该事件陆续到另一个非常快,我无法区分不同的BLE_EVT_END事件。
应用程序是距离应用,但不是超声测距。
0.01s时间同步精度可以满足我的应用要求,更好的同步,因为我不需要由于时间漂移来重置同步,我将实施建议的解决方案,但现在我专注于如何“识别'来自双方的相应ble_evt_end。
再次感谢。
写入特征并了解连接间隔应允许您标记连接。数据传输将在以下连接事件上发生,因此在服务器端接收(再次,可能存在偏移量,但此偏移量应为常数)。客户端将在传输数据时收到确认,服务器将接收数据已到达的指示。
/ mhv.
您好!
我的问题是两个580主从时间同步的问题,如何才能确定主从的BLE_EVT_END为相对应的事件呢?因为BLE_EVT_END是在不停快速地重复出现,我不知道如何确定主从对应的事件。
只只了主从相对应的ble_evt_end事件后才可在事件发生中的事件中。
谢谢!
亲爱的MHv_Dialog,
非常感谢你的回答。
坦率地说,我是这个领域的新手,虽然我觉得你的回答可能是对的,但经过很多研究,我还是不知道该怎么做。
1.什么是确认和指示?ble_evt_end?或其他事件?
2.我仍然不知道如何标记连接,我想应该有一些不同的东西来区分它。
希望你对我的问题不耐烦。
你好,本杰明,
让我开始说你已经开始做的事情并不简单:o)
但这是我如何尝试实现它的核心。首先,在中央和外设都使用App_On_Connection事件来重置全局计数器。然后,在Rwble.c中,找到引用BLE_EVT_END的两个位置(此事件有两种实现。哪一个运行取决于您使用“USE_POWER_OPTIMIZATIONS”)。两个实现都有这样的线:
ARCH_RWBLE_LAST_EVENT = BLE_EVT_END;
在这行之后,在中央和外围设备上,您可以增加在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.
嗨mikael,
我测试了你给我的方法,一般来说,这是一个很好的方法,可以满足我的需求。我计划在有问题上有更多的测试,看到你有更多的信息在这里,我首先把我的测试结果放在这里。
我遇到的问题是大约有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总是成对发生在主机和从端。
这是非常重要的,如果我假设事件成对发生,而有时在单方(主机或从机)有丢失的事件,这可能是大问题。
我需要确认。
如果在理论上,双方都不会有任何遗失的事件或错过,我会放心。
或者在理论上,在单方可能会有缺失的事件,我需要在我的函数中考虑这个。
谢谢。
我可以确认两侧总会有相同数量的事件。从中央奴隶可能不会“听到”,但事件仍然会结束 - 尽管时机会错过一半的东西。换句话说,将有一些异常值与时序一样,但主侧的事件计数将始终匹配从设备的。在您的情况下,其中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_disconnect_func”的时候,从机无法从主站接到信息,但“arch_rwble_last_event =”app_rwble_last_event =BLE_EVT_END“可以在两侧令人作呕,从站仍然处于先前的速度,但在主侧,速度是从速度的15倍。
我的分析如下:
Connect坏了,因为从机无法接收来自主机的信息,但为什么在两侧,设备都可以执行“Arch_rwble_last_event = ble_evt_end”?
你能帮我解决以下问题吗?
什么可能的reson为什么“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