单标签与多基站通信实时性的问题

chenziqiang

通过阅读代码，我发现代码里 某个时刻， 一个标签与多个基站通信测距是 这样的（比如有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

感觉这两种实时性应该差不多吧

tracy

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

蓝点无限

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

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

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

714162838

如果标签运动的速度太快了，可以用作者的那个算法

HolyDeal

感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢感谢

wennnnie

感谢大佬解答

linchenmm

uwb手册里面有这个图，但是功耗问题比较致命，对于标签来讲

tansf

感谢解答，这个也一直困扰我。

ryanyooo

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

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