|
通过阅读代码,我发现代码里 某个时刻, 一个标签与多个基站通信测距是 这样的(比如有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和这个期刊的作者的算法比, 哪种通信机制实时性更强呢,还是差不多呢?
|
-
捕获.JPG
(70.42 KB, 下载次数: 4248)
多基站测距时序图
|