拥有UWB标签的文章

DW1000的SPI速率

经过好几个平迁移DW1000的折磨,总结一下。一、速率对DW1000的影响主要有两个:1、MCU的运行速率;从STM32、nrf、gm技术、sifli等MCU,总结经验是,MCU的运行主频只要高于48MHZ,少打印串口log,以及少用memcpy等耗时操作,对dw1000的操作是不会存在性能瓶颈的。2、SPI通信速率;SPI速率主要是SPI主频,官方代码中port_set_dw1000_slowr
阅读全文

UWB主从站选举机制

  • 呱牛
  • 3814
  • UWB
主站的逻辑:决定标签测距的时间槽位信息;决定多个站测距过程中回复A包的时序;从站的逻辑:根据从站的内部序号,决定测距过程中回复A包的时序;方案:一、开机上电同步主站tick,并收集基站列表:1. 开机上电后,即发上线通知, 只有主站回复自己的tick;2. 如果超时20ms 没有收到主站回复的SYNC,则决定自己就是主站;3. 收到主站回复的SYNC ,以及包括主站的tick,则同步tick,计算
阅读全文

UWB爬坑笔记之基于时间槽的测距实现

1、基站配置进入升级模式2、基站通过串口接收ota数据,然后通过UWB广播消息发送给标签,然后标签升级;标签和基站之间的应答
阅读全文

UWB定位产品开发爬坑记录-4

吞吐量要解决的几个问题:1、标签时隙管理;一种方式:基站主导,官方的TREK1000代码有类似的逻辑;一个标签,比方每2s发送一次P帧,2、多基站测距;A站、B站、C站回复A帧的时间不同,需要做延时发送;具体延时多久,也需要同标签做好时间窗口同步;
阅读全文

UWB定位产品开发爬坑记录-3

DW1000跟MCU之间是通过SPI读写完成数据交互,如果SPI数据读写有延迟,对基站吞吐量的影响是很大的,最近一次,分析标签完成一次测距时间太长的问题,就找到了SPI读写过程中的问题,当然也有选用MCU自身主频低的因素在里面;
阅读全文

UWB定位产品开发爬坑记录-2

近期的几个问题着实让人头疼,过程也是相当坎坷;1、丢包率硬件的稳定性,软件一样的逻辑,丢包率居高不下,一直在40%以上;还好硬件同事不甩锅,发现硬件PA的问题,重新修改了一版硬件后,确实丢包率下来了好多,还是需要有一般靠谱的伙伴;当然软件这块也做了好多修改,丢包重试;sniffer模式的实现;2、功耗;功耗仪上测试了好几版,抓波形,分析工作时长;分析竞品的工作时长,找到功耗消耗长的原因:第一个:T
阅读全文

UWB定位产品开发爬坑记录

只能说从开始做这个产品就一直在坑里,DW1000寄存器多且不那么好理解,摸了快一年了,寄存器的配置还是一知半解。
阅读全文

UWB发送接收调测记录之超时时间

最近调测UWB的收发,比较困扰的是DW1000是半双工通信方式,也就是要么在RX,要么在TX,那么标签和基站如何协同工作呢,比方标签发包的时候,基站一定要在RX才能收到包,否则发包就会失败,这个协同如何来做呢?其实官方给的例子有一个demo,一个是能说明这个协同的,但是其中的延时,是如何配置的?这也是困扰我好久的问题!
阅读全文

BpHero-UWB上位机源码修改过程记录

BpHero-UWB上位机是从DECARANGERTLS PC 端源码修改来的,蓝点开放出来的代码,最基本的几个需求发现不能满足,比方:基站ID修改为非0,1,2,自定义为其他的基站ID,程序就奔溃了; --出现这个问题的主要原因是基站ID作为了数组的下标会用,一大就越界了,所以需要一个基站ID和下标值得映射关系: class GraphicsWidget : pu
阅读全文

UWB定位产品不可忽视的MAC层实现

从开源的代码以及DW1000提供的代码,均没有很好的MAC层控制实现,对于定位模块的产品化来说,这是缺少关键的一层,只实现了功能,绝不能算是产品;MAC:MAC协议全称Media Access Control(媒体访问控制子层),该协议位于OSI七层协议中数据链路层的下半部分,主要负责控制与连接物理层的物理介质。DW1000的官方文档明确提出了DW1000的收发器模块并没有实现MAC层,但对MAC
阅读全文
首页 12 末页 共 14 条记录