51uwb.cn

标题: DWM1000 收发数据总是超时 [打印本页]

作者: gi7878 时间: 2020-7-13 18:07
标题: DWM1000 收发数据总是超时
最近刚用uwb模块开始做项目，遇到了问题，不知道是不是官方的bug，也是用官方的api例程， A标签往B基站发送poll包， B基站可以接收到poll包，但是延迟发送respone包的时候，api函数总是返回dwt_error,供应商告诉我，不要用hal库，也不要用st以外的板子，换了stm32f103(标准库)和stm32f429(hal库)，发现还是不行，厂商说不要去修改那些时间延迟，个人感觉，每一次spi通信时间都是us级别，按理来说不加大延迟，一定会是失败的，不知道是不是这个原因，我的SPI的速率都是16m，是否要调整成和官方说的要20m以上，按供应商说的，把respone包调整为马上发送，但是 A标签收不到respone包，接收总是超时，对应的 A标签接收respone包的延迟是否要大于 B基站从接收poll包到发送respone的时间，我看蓝点大佬的视频，延迟都是ms级别。

作者: 蓝点无限 时间: 2020-7-13 19:46
你用的是官方源码吗？
不应该有这么大延迟的，我们测距一次，三四条信息下来2ms左右。

作者: gi7878 时间: 2020-7-13 21:03

蓝点无限发表于 2020-7-13 19:46
你用的是官方源码吗？
不应该有这么大延迟的，我们测距一次，三四条信息下来2ms左右。

你们填写那几个延迟参数都是多少啊，用的是官方API，模块初始化都没问题，就是交互的时候出问题了。尤其是收到poll包，发送respone的时候，一直都是发送失败，官方说法就是超过规定的延迟时间了，如果设置马上发送，标签这里就收不到回包，提示超时

作者: 蓝点无限 时间: 2020-7-14 08:47

gi7878 发表于 2020-7-13 21:03
你们填写那几个延迟参数都是多少啊，用的是官方API，模块初始化都没问题，就是交互的时候出问题了。尤其 ...

dwt_setrxtimeout(0);
dwt_rxenable(0);

复制代码

可能你timeout设置调小了。这样就不会超时了

作者: haonan1211 时间: 2020-7-14 08:57
我是延时发送一直发送失败，不知道楼主解决了吗

作者: gi7878 时间: 2020-7-14 09:20

蓝点无限发表于 2020-7-14 08:47
可能你timeout设置调小了。这样就不会超时了

我看标签这边dwt_setrxtimeout(2700),如果写成0，不是时间更短了吗，还是我理解有问题

作者: gi7878 时间: 2020-7-14 09:21

haonan1211 发表于 2020-7-14 08:57
我是延时发送一直发送失败，不知道楼主解决了吗

没呀，还在不断的调试中

作者: gi7878 时间: 2020-7-14 09:22

gi7878 发表于 2020-7-14 09:20
我看标签这边dwt_setrxtimeout(2700),如果写成0，不是时间更短了吗，还是我理解有问题

Poll接收没问题，发送respone包的时候ret = dwt_starttx(DWT_START_TX_DELAYED | DWT_RESPONSE_EXPECTED); 这里ret一直是error

作者: gi7878 时间: 2020-7-14 09:25

蓝点无限发表于 2020-7-14 08:47
可能你timeout设置调小了。这样就不会超时了

而且我还很容已出现一个问题就是，system_status有时候会报SYS_STATUS_CLKPLL_LL

作者: 蓝点无限 时间: 2020-7-14 10:00

haonan1211 发表于 2020-7-14 08:57
我是延时发送一直发送失败，不知道楼主解决了吗

延时时间太短了，导致配置tx发送命令的时候，延时已经过去。导致tx fifo 发不出去了。
问题这么多，赶快换我们的代码吧

作者: gi7878 时间: 2020-7-14 11:23

蓝点无限发表于 2020-7-14 10:00
延时时间太短了，导致配置tx发送命令的时候，延时已经过去。导致tx fifo 发不出去了。
问题这么多，赶快 ...

延迟我也调整过到ms级别以上但是还是失败，不过每次过17s,就会提示发送成功

作者: 蓝点无限 时间: 2020-7-14 15:46

gi7878 发表于 2020-7-14 11:23
延迟我也调整过到ms级别以上但是还是失败，不过每次过17s,就会提示发送成功

17s 这么长，那肯定是下一轮了吧，好好检查code吧

作者: gi7878 时间: 2020-7-14 16:58

蓝点无限发表于 2020-7-14 15:46
17s 这么长，那肯定是下一轮了吧，好好检查code吧

参考蓝点哥的，标签这边用的延迟已经没问题了#if 0
            /* Compute final message transmission time. See NOTE 10 below. */
            final_tx_time = (resp_rx_ts + (RESP_RX_TO_FINAL_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
            dwt_setdelayedtrxtime(final_tx_time);

            /* Final TX timestamp is the transmission time we programmed plus the TX antenna delay. */
            final_tx_ts = (((uint64)(final_tx_time & 0xFFFFFFFEUL)) << 8) + TX_ANT_DLY;
#else
final_tx_time = dwt_readsystimestamphi32()+ 0x17cdc00/10;
            dwt_setdelayedtrxtime(final_tx_time);
            final_tx_ts = (((uint64)(final_tx_time & 0xFFFFFFFEUL)) << 8);
#endif

不过基站这边就对接收final超时了，而且基站也是用ret = dwt_starttx(DWT_START_TX_IMMEDIATE | DWT_RESPONSE_EXPECTED);发送respone包，如果标签也是用ret = dwt_starttx(DWT_START_TX_IMMEDIATE );发送final包，交互正常实现，但是距离测出来都是不准的。感觉理目标就差一点点了。就是不知道基站这边到底哪里出问题了，基站用的F429的hal库

作者: 蓝点无限 时间: 2020-7-15 10:09

gi7878 发表于 2020-7-14 16:58
参考蓝点哥的，标签这边用的延迟已经没问题了#if 0
/* Compute final message transmis ...

和stm32 hal 库没有关系的，我们的开源框架就是用的hal库
肯定是uwb 的逻辑上有问题，你再好好查下代码吧

作者: gi7878 时间: 2020-7-15 10:25

蓝点无限发表于 2020-7-15 10:09
和stm32 hal 库没有关系的，我们的开源框架就是用的hal库
肯定是uwb 的逻辑上有问题，你再好好查下代码 ...

好的谢谢蓝点哥，昨晚查官方论坛，还是那几个参数设置的问题，这里有个疑问就是，DWM1000里的uus是微秒的意思吗，还是指的是皮秒，官网的说法都是微秒

作者: gi7878 时间: 2020-7-15 14:24

蓝点无限发表于 2020-7-15 10:09
和stm32 hal 库没有关系的，我们的开源框架就是用的hal库
肯定是uwb 的逻辑上有问题，你再好好查下代码 ...

发现问了，dwt_initialise(DWT_LOADUCODE)，这里原来填的是DWT_LOADNONE，所以导致没有装载LDE算法，现在基站解决了，就剩下TX端，TX端，这里接收到respose包后，get_tx_timestamp_u64()得到为0，测试了一下，如果一直发送poll，这个get_tx_timestamp_u64是会变化的，现在还没找到原因为什么是0

作者: gi7878 时间: 2020-7-15 16:38

蓝点无限发表于 2020-7-15 10:09
和stm32 hal 库没有关系的，我们的开源框架就是用的hal库
肯定是uwb 的逻辑上有问题，你再好好查下代码 ...

调试成功了，很艰难

作者: 蓝点无限 时间: 2020-7-15 20:06

gi7878 发表于 2020-7-15 16:38
调试成功了，很艰难

最后什么问题？

作者: gi7878 时间: 2020-7-16 00:02

蓝点无限发表于 2020-7-15 20:06
最后什么问题？

换了一个备用模块就好了，主板还是用TI CC2640驱动起来的

作者: 蓝点无限 时间: 2020-7-16 10:09

gi7878 发表于 2020-7-16 00:02
换了一个备用模块就好了，主板还是用TI CC2640驱动起来的

你们的主控是CC2640？
我之前也想搞uwb+zigbee 双频，后面没有时间搞

作者: haonan1211 时间: 2020-7-16 14:58

蓝点无限发表于 2020-7-14 10:00
延时时间太短了，导致配置tx发送命令的时候，延时已经过去。导致tx fifo 发不出去了。
问题这么多，赶快 ...

分享一下多标签代码吧

作者: haonan1211 时间: 2020-7-16 14:59

gi7878 发表于 2020-7-14 09:21
没呀，还在不断的调试中

用的什么芯片呢

作者: gi7878 时间: 2020-7-16 16:24

蓝点无限发表于 2020-7-16 10:09
你们的主控是CC2640？
我之前也想搞uwb+zigbee 双频，后面没有时间搞

不是，之前想用TI AOA定位做定位方案，但是有点不太行，就放弃了，开发板买来好几个，不能浪费了，就拿CC2640作为测试主板在实验，哈哈哈，不过我觉得AOA角度定位和TOF结合起来效果可以达到更好，但是我看DWM1000没有相关AOA计算方式。

作者: gi7878 时间: 2020-7-16 16:25

haonan1211 发表于 2020-7-16 14:58
分享一下多标签代码吧

还没做多标签测试，但是从观察的角度来说，很多人暴露了这个问题，后面考虑采用分时测量来试试。

作者: wo4fisher 时间: 2020-10-20 22:26

haonan1211 发表于 2020-7-14 08:57
我是延时发送一直发送失败，不知道楼主解决了吗

问一下你的问题解决了吗

作者: wo4fisher 时间: 2020-10-20 22:31

gi7878 发表于 2020-7-15 16:38
调试成功了，很艰难

我现在遇到的问题和你的类似，之前用STM32F103是正常的，使用HAL库。现在用了STM32G030就出现你说的这些问题，能不能给一些解决思路，换了多个板子和模块都是这样，怀疑还是stm32和DWM1000（硬件SPI，查询方式）速度匹配、延时参数的问题。
能不能分享一下调试经验。
使用官方twr测距例程。

作者: 时间复检 时间: 2020-10-26 10:53
楼主是不是中途加入串口输出了，我之前加入串口输出后也遇到这个问题

作者: almeidals 时间: 2020-11-10 22:55

gi7878 发表于 2020-7-14 09:25
而且我还很容已出现一个问题就是，system_status有时候会报SYS_STATUS_CLKPLL_LL

CLKPLL_LL 的这个问题我也遇到了！我的模组还是 Qorvo 原厂寄来的，问 FAE 总说我电源有问题，但是我电源很简单啊，都是电池经 LDO 转来的，而且同样的外围电路，我换过一个 pin2pin 的大功率版本的模组，这位读到就是 0 了。一筹莫展啊，你这边对这个问题有什么进展么？

作者: bran 时间: 2021-1-14 19:49

gi7878 发表于 2020-7-16 16:24
不是，之前想用TI AOA定位做定位方案，但是有点不太行，就放弃了，开发板买来好几个，不能浪费了，就拿CC ...

zigbee用来做AOA角度定位精度高吗？角度偏差有多少呢？

作者: gi7878 时间: 2021-5-12 00:11

bran 发表于 2021-1-14 19:49
zigbee用来做AOA角度定位精度高吗？角度偏差有多少呢？

没用过zigbee 只知道蓝牙的AOA

作者: gi7878 时间: 2021-5-12 00:11

wo4fisher 发表于 2020-10-20 22:31
我现在遇到的问题和你的类似，之前用STM32F103是正常的，使用HAL库。现在用了STM32G030就出现你说的这些 ...

只能去加大延迟

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