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

使用FFMPEG提供的编解码接口，实现的aac编码和解码程序！

广播的业务还是挺好实现的，作为练手项目绝对不错，主要涉及到几个点：1、音频数据采集；2、音频数据编码；3、媒体流组包发送；4、UDP Socket服务器、客户端实现；5、音频抖动缓冲区，及播放器实现；

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

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

工作的意义？ 一个有院子的房子？一个接地气的家？一个举家搬迁计划？我们到底想要什么样的生活？我们到底想要如何过每一天？禅宗说，万事皆空，不报执念，不认对错，对外界任何事物不要产生二元对立的念头，才能真正做到出世，可出世又为了什么呢，却又不得而知；律法、信仰，将心安放在哪里最合适？心安自有归处；人说四十知天命，认命，可能是当下，对自己最好的接纳。

使用ffmpeg实现一个播放器？是不是没什么新意，不过一直使用ffmpeg程序，还没有用ffmpeg代码接口实现播放器，并且还需要使用linux的alsa接口播放出声音，所以做出来还是觉得有点意思；

LINUX外接TM1650键盘，由于TM1650不是一个标准的I2C接口，只能通过操作GPIO方式模拟I2C通信；问题1:通过linux的文件读写gpio方式，支持us级别的控制；几个报错处理：1、开始通过文件方式操作export文件，发现总是失败；[failed]gpio_export path:/sys/class/gpio/gpio145open error: Permission deni

接上篇：单路通话，Freeswitch录制视频CPU高的原因，主要是开启media_bug通道会涉及一次H264解码、两次H264编码，所以CPU高；解决思路就是：由于录制是使用rtsp/rtmp转发流的方式，可以直接将源端发送过来的H264码流转发给rtsp/rtmp服务器，这样就减少了Freeswitch端的解码和编码过程；上篇已经减少了一次转发给b_leg时的编码，确实CPU负载就降下来了，

早上翻看沈复的《浮生六记》，恰好翻到第三篇坎坷记愁，虽是古文，读起来还不是很费劲，读到芸客死他乡，于临终前的那段话，看得我是唏嘘不已，不禁感同身受起来；恰逢其父去世，而其亲弟唯利是图，兄弟失和，又让其有退隐皈依的念头，朋友诘问：“家庭若此，固堪动忿，但足下父死而母尚存，妻丧而子未立，乃竟飘然出世，于心安乎。”，听之，却也无可奈何。