51uwb.cn

标题: 单标签与多基站通信实时性的问题 [打印本页]

作者: chenziqiang 时间: 2020-9-22 17:37
标题: 单标签与多基站通信实时性的问题

通过阅读代码，我发现代码里某个时刻，一个标签与多个基站通信测距是这样的（比如有1个标签， 3个基站，分别是基站0、1、2）：

标签先与基站0通信，经过计算tx_poll_msg, rx_poll_msg, tx_resp_msg, rx_resp_msg, tx_final_msg, rx_final_msg的时间，算出标签与基站0的距离，这个通信过程中（如果信号良好的话），只有标签和基站0的距离先计算完毕后（未计算完毕则不会与其他基站通信，在这个过程中，其他基站是不会对rx_poll_msg，rx_final_msg 信息处理的），之后才会开始计算标签与下一个基站的距离，即两者重新开始tx_poll_msg, rx_poll_msg, tx_resp_msg, rx_resp_msg, tx_final_msg, rx_final_msg这个过程，同样，计算两者的距离后，才会开始计算与下下个基站的距离，如此循环往复。

问题1：这种通信机制，会不会降低实时性呢？我对代码的分析对吗？

之后又看了一篇核心期刊论文，作者也是用的多基站，他的单标签与多基站的时序测距图是下面这个（最下面的图）：

他不是先计算完一个标签与多个基站的距离后，才开始计算与下一个基站的距离，比如说，标签与基站1通信的过程中（基站1收到rx_final_msg之前），其他基站也会和标签进行通信（比如标签收到了应答1，应答2，应答3，应答4共4个信息）。
问题2：咱们开源出的51uwb和这个期刊的作者的算法比，哪种通信机制实时性更强呢，还是差不多呢？

作者: dragon_L 时间: 2020-9-23 09:13
感觉这两种实时性应该差不多吧

作者: tracy 时间: 2020-9-23 09:52
我认为期刊作者这个算法不靠谱，只存在理论上的可能，程序很难实现；并且每次测距的周期中，飞行时间占用的时间比例很小，主要时间在硬件接收发送处理的过程中，所以期刊这个算法并不能提升实时性

作者: 蓝点无限 时间: 2020-9-23 10:06
它这个算法，标签发送一个信号后，需要等待多个基站回复，使能接收是uwb 最费电的状态。
还有一个缺陷，你要考虑4个基站的延时问题，不同基站之间回复数据不能冲突，时间太短冲突了，时间太长标签太费电。
还有，再次，如果标签和100个基站测距，刊物算法调节起来太过于麻烦了。

所以我的做法就是标签单端去call 基站的地址，后期可扩展性比较好。

刊物的算法是官方手册描述的算法，也是大多数网上其它商家提供的算法。

作者: 714162838 时间: 2022-1-11 13:35
如果标签运动的速度太快了，可以用作者的那个算法

作者: HolyDeal 时间: 2022-2-22 15:24
感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢

作者: wennnnie 时间: 2022-3-16 17:35
感谢大佬解答

作者: linchenmm 时间: 2022-5-16 22:40
uwb手册里面有这个图，但是功耗问题比较致命，对于标签来讲

作者: tansf 时间: 2022-8-8 03:10
感谢解答，这个也一直困扰我。

作者: ryanyooo 时间: 2022-8-15 09:34

714162838 发表于 2022-1-11 13:35
如果标签运动的速度太快了，可以用作者的那个算法

请教一下那是不是这种方法会更适合标签运动跟踪

作者: anzijie 时间: 2023-2-3 16:23

蓝点无限发表于 2020-9-23 10:06
它这个算法，标签发送一个信号后，需要等待多个基站回复，使能接收是uwb 最费电的状态。
还有一个缺陷，你 ...

标签一直广播call基站，会不会费电也比较大呢

作者: Ring_Ash 时间: 2023-3-20 15:08
在自己做测距离的话，肯定一发一回实时性更强，如果考虑到实时性的问题，为什么不单独拿一个命令来做对特定标签的测距呢？
期刊中的算法的确变得多个精确，但是考虑到单片机线程处理能力的话，还是会有很大误差的。

欢迎光临 51uwb.cn (http://51uwb.cn/)