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

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

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

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

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

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

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

所谓的TDMA,就是根据时隙决定谁来发送什么类型的数据，或者决定由谁来使用该时隙，这里uwb_tdoa_anchor2的实现就是根据slot号决定由谁来进行tdoa测距的业务实现； 这里uwb模块就没有了anchor和tag的概念

好久没写嵌入式代码，最近碰到两个数组越界导致程序行为异常的问题，调了近两天，才找到真正的原因，改到开始怀疑人生，到最后柳暗花明，怎么说呢，事出蹊跷必有因！由于有基线版本，并且基线版本功能是正常的，碰到这种问题，当然先是排除自己的问题（或许是错的，应该先摘除基线版本的问题）！我先把我增加的代码中涉及数组操作的都仔细的滤了一遍，没有发现问题！考虑那就正面刚，先定位问题，所以一通屏蔽代码后，得出的结论是

做一件事情，先有全局视角，拆分出系统的模块，然后根据不同的模块确认出待办顺序，并从全局的角度考虑多个模块的整合，是否需要公共模块，模块之间的依赖关系是什么样的，然后整合后，逐条去解决！做软件，其实这两年的成长是最大的，因为转到架构岗，确实是少了一部分之前在开发岗的一些不好的习惯，比方一上来就是细节，一上来就是某个功能点如何实现，现在接触一个事物，或者一个项目，首先考虑的是项目的整体框架，先搭骨架，