作者： 孙浩

先提出自我批评：相对上周，本周在任务没有明显的涨幅。 0415 1.服务器界面电量值上传验证成功。 2.服务器界面新加中继接口：6666 同时系统启动初始化成功。 3.客户端中的语音接受中CHANNEL_CONFIGURATION_MONO停用 修改为CHANNEL_OUT_MONO。验证成功。 0416 服务器（调整之前轿厢位于始发站与迂回战时关闭接近报警的逻辑） 客户端 debug--->采用断点逐步调试+TCP助手 0417-0418 1.按照工作流程 检查内部逻辑，找出隐藏的BUG并debug掉，与VR工程探讨针对运行时轿厢会出现前后漂移情况，提出利用纬度值进行约束（因手机GPS经度达不到10米，所以在提出在得到数据值后将值*1000进行放大，进行约束掉跳变点） 2.优化界面电量显示与现实中逻辑，调整设备在线与不在线电量显示逻辑。 0419 1.（与vr方面 VR问题） 今天谈到一个问题，VR初始化问题， 怎们程序启动可以准确定位缆车在线路上的位置。即VR启动瞬间后怎么刷新缆车的编号排列， 2.与小白师兄交谈： 针对音频这块 进行交流 本周也主要做了这个工作，结果差强人意，C#没有提供开源的音频文件的解码工具，采用soundplay（）类只支持wmv格式且只能本地播放。NAudio也实现不了音频文件解码工作。C#做音频的线恐暂时停止。好在与小白师兄交流，谈到，C#短时间无法改播放组件的开源码，就换个“线”，将音频和广播抽离转移到java中。C#调用命令行执行音频部分。约定明后两天找时间再聊。 0420 (与小白师兄) 提出采用bili 或者快手等直播平台的音视频推流到服务器，在拉流到客户端思路，采用服务器启命令行---->FFMPEg进行音频 广播解码工作---->推流到服务器（RTMP ）----->安卓拉流播放。方法比较开源,learning..... 0421 （与小白师兄-下午) 音频选择采用RTMP服务器，利用nginx启动一个进程，设置默认的端口号进行通信端口，C# 获取参数 送将想要播放的音频文件送FFMPEG 解码推流，安卓端在进行拉流播放。此调整不再进行音频播放的编码，只需要点击按钮后使得C#可以调用cmd命令行，将推流的命令行写死。暂停播放或者停止播放则杀死进程。弊端是：可能人为的选择不了本地文件的地理位置。没有了代码支撑，需要废弃原来所做的音频本地播放的工作。 本周总结：在实验室情况下提高系统稳定性，消除一些隐藏bug。 反思：C#在音文件的解码和上传流没有进展。这也是导致了0421记录。 下周计划：利用0421记录要点，完成音频文件的推流拉流播放。 ...

0405-0408 1.将原来数据、语音两套系统合二为一 进行逻辑调整。 2.做了音频文件选择及选用com组件中windows media player类进行播放测试功能。（与广播独立） 目前功能：多种音频文件选择和本地播放，暂停播放及恢复播放，自动下一首播放以及循环播放 客户端： 0409 1.学习客户端调用系统电量状态，进行发包测试 2.VR接口第二版说明书 0410 1.与VR进行交谈，约定0411带实验室看系统流程以及数据打包和解析 2.交谈过程中，告知VR方需添加什么界面 可见“新需求20190410(1).docx” 3.系统将客户端来的数据整合打包转发VR一份，像接近，坠落，姿态报警等信息，由socket进行异常信息传输。 4.关于语音方面，为了避免监控系统的负荷以及健康性，暂定通话以及语音由VR直接与客户端进行通信，不在利用系统进行中转和判断。 5.将姿态角的计算放到客户端来做，减轻服务器压力。 6.改变打包规则，新加三个float型状态，一个int型状态，数据包大小变为65字节。 0411 1.于501A与杜全工程师对数据交互进一步交流，目前需要确定VR系统也作为一个客户端，监控系统收到数据，整理后转发给VR系统。 2.根据之前数据做一份满足现在字节要求的数据，交付杜全工程师进行验证数据是否可用，以及VR系统验证将数据拆分是否可行。 3.将姿态预警放到客户端来做，缓解服务器压力，这样在服务器管理者模式中添加不了姿态阈值的判断。 0412 1.debug：电量传递过程中，context参数从主界面获取不到，将DEVICEDATA中构造函数修改 传递context值获取主界面上的电量值。 0414 1.修改项目计划书 确定vr任务和性能指标。 ...