含光左卫的工作笔记集

FFT幅度仍然不大对，主要目的是为了找到典型的正转正拉，正转反拉频谱。最终在附录A中找到了两组典型的正转反拉波形。为接下来的工作做数据筛选。

虽然RC反馈环路的移相功能是其中的一个重要方面，但它不仅仅是为了移相。它还涉及滤波、增益控制、动态响应优化和稳定性增强等多个方面。在实际应用中，RC反馈环路的设计需要综合考虑这些因素，以确保系统的性能达到最佳状态。

同事已经发现的信息是当Boost升压电路占空比为50%时会有更大概率失稳。我把对应两种电路参数LLC的增益打印了一下，结果是这样的：此时，如果系统的电压失稳是由于前后级频点形成整数倍，构成拍频关系，那么会有如下可能：1.LLC回路，黄色曲线发生失稳的位置，频点更低，回路电流更小，绿色曲线是另一条,频点更高，回路电路更大。

从响应速度快慢的角度考虑，恒流环的响应速度比电压环要慢很多，所以在短路时，看到的频率变化是：先下降，然后频率开始提升。这说明恒压环先开始动作，恒压环动作后开关频率会向最低频率下降，所以为了保证短路时频率拉升的足够快，最低开关频率的设定，一定不能太低，否则要穿越谐振频率，电流会更大。当CS电压高于0.8V后。使开关频率提升的更快，此时电源会处于打嗝重启的状态。为了避免高于1.6V IC锁机，我们使用了最快响应速度的TVS钳位VCS上的电压，只能让它在1.6V以下，不能高于1.6V，否则锁机，客户又不接受了。

与开关电源功率变压器相关的标准搜集。包含：TC418 全国小型电力变压器、电抗器、电源装置及类似产品标准化技术委员会 IEC/TC96，和TC89 全国磁性元件与铁氧体材料标准化技术委员会 IEC/TC51的标准摘要。

铁心的磁通量上限，导致了变压器为了维持初级和次级线圈的电压平衡，匝数比N增大，工作频率F必须减小。匝数比变小，工作频率必须增大。

上面是一个典型的LLC电路。注意Lm是漏感，据说在计算谐振频率时无需关心。然后，作为DCDC电源，它通过调整谐振频率，来改变输出的电流。负载越大，频率越低，输出电流越大。

在代码维护时，你会有意识使用diff编辑器吗？发现这样做的好处很多：1.你能非常明显地看到代码基线。2.你能实时看到高亮显示的本轮已修改的代码，更难出现遗漏。

去年因为要分析示波器波形，下载过它的MAUI Studio。它的免费版需要逐年注册。注册是免费的。示波器从业人员和工程技术人员可以看看示波器的第一梯队的设计和功能项点是怎样的。其他示波器，和工程中自己生成的.csv文件经过一些非常简单的自制工具就可以导入这个分析，呈现工具。我的csdn下载项里似乎上传过部分用python写的转换工具。我应该还处理micsig示波器=>lecroy格式的示波器波性文件的单向转换。我的注册到期了，注册完毕我把它运行起来的界面再截几张图过来，这是桌面很好用的一个采样数据分析工

VC++ stdafx, pch.h的一个可能低级错误。。。

速度积分错误的排错过程。

可以将任何json文件转入redis供跨进程同步更新。包含linux命令行的处理 argv[]缺省参数的处理。redis转换时对key做了适合redis语法的处理。

工作中，我们有时需要测试web post功能是否正常。这类测试，客户端的请求很容易实现，比如portman，比如非常简单的命令行curl语法：curl -X POST http://127.0.0.1:5000/post-endpoint/ -F "warning_image=@/path/to/your/file"客户端的请求测试，我没有找到好的测试工具。现在，我一般会使用flask直接在嵌入式平台上搭建测试环境：

注意，与拉流推流花屏，绿屏相关的问题，本质只有一个——就是缓冲区的点阵数量不对。出现问题时，纠错的第一步始终是打印frame缓冲区，看看那个尺寸与你的预估是否相同。width*height*1.5的，一定是YUV型数据width*height*3的，一定是RGB数据。比理论数据多一个尾巴的，一定是因为h264或者h265编解码对齐，产生的一些数据：比如：1920*1080在编解码之前需要对齐到1920*1088。。。。对于编码器而言，这个限制条件仍然存在，在进入硬件编码器之前，你需要手工

YUV420原始图像和.h264编码 .h265编码的压缩率直观感受。各种编码和图片查看程序。

起升电机电流原始数据识读，及转差率估算过程的工程实现。

一个发现：电机上下行电流差与负载正比——从理论模型推导，提出假说，实验数据整理、验证，进行曲线拟合，数据点，拟合曲线与原始理论模型比对的全过程。

IEPE传感器可以视作电压源，自身被恒流源驱动，然后输出电压，一般是+-5V实际在输出至采集器AI时，会在电路中添加一个1uF的电容。AI是一个交流电压信号，被一个高内阻的采集电路采集，输出上面的值。问题是1uF电容在低频时阻抗会变大，这其实构成了一个高通滤波，容抗在10Hz下的是：1/(2*pi*f*c) = 16K，查阅过采集器内阻是1M欧，此时因为C分压引起的采集值变化是：5*arctg(16/1000) = 1.6%,所以24%的衰减不可能是因为它。

GearBox的频谱图，原作者不知道是从哪里拷贝来的，待会儿确认一下。齿轮啮合频率GMF等于齿数乘以齿轮转速频率：★齿轮啮合频率两边有边频，间距为1X（这是由冲击响应本身的信号特征决定的，参见下面的实验，这里的1x单位应该是转频，在上面的图中可以看出）★随着齿轮故障发展，边频越来越丰富，幅值增加（频谱边频丰富很难理解，因为冲击力会随着磨损逐渐变得圆滑，这个需要做实验）★可用倒频谱作进一步分析1.★齿轮啮合频率等于齿数乘以齿轮转频★啮合频率两边存在边频，间距为1×。

转速6.4转时,此时150Hz转速大概是24x。此时的200Hz处的频点，大概是30x，30x频这里似乎是另一个振动源。它的边频谱线特征与150Hz的不在一个体系。24x倍频的谱线特征在时域，相对24x转频是一种比较平缓的单周期正弦效果，所以，推测是一种偏心效应。是轴心没有对齐导致的。30x高频部分，这种类似的偏心趋势在蔓延，这是另一根轴。所以，那个频点的时域幅度调制大概率是由这根低速轴传递过去的。

此时可以使用nmap工具，进行网段扫描：256个地址的子网10秒就能扫描一轮。关掉设备，打开设备，diff，基本就可以定位所要找到目标设备的IP。

YUV解码时可能出现的常见故障及解决

加速度信号积分的一个可能错误，及演示。这是振动分析的必修课。

加速度信号采集过程中，因为电源Rising Time以及后续电流源初始化导致的无效数据，及其消除。

创建外围线程的目的只是因为使用的Pymodbus的串口服务是个阻塞函数。在修改寄存器值时需要修改的对象是最原始的hr_block。它有两个关联参数：启动pymodbus是需要添加：broadcast_enable = true，使得对原始缓冲区中寄存器的修改会传递给所有的用户。创建ServerStore是，使用：Single=True，表示所有的客户端共享同一个缓冲区。pyModbus在2=>3的过程中语法大变，上面的版本基于pymodbus==2.5.3上面包含了大小端转换，但是最终没有用上

文件系统制作时，查询需要添加的额外安装包

python opencv gstreamer rtsp实时推流的尝试，延迟小于500ms

视频YUV格式转为RGB点阵的python实现。

使用systemctl构建开机脚本的编制、调试、注意事项。

查看系统自带的.264硬编码器是否已经生效的判断标准。

视频转换过程中的一些低级错误的由来，以及针对性的处理策略，程序框架和示例代码。

介绍了rtsp流媒体服务器的一种实现方式；通过mediamtx，它可以很容易地很python环境集成。这个流媒体服务器提供rtsp, rtmp等多种媒体流发布。

Windows下面的multiprocessing库根本没有shardmemory这个子项，它被放置在别的地方。Python没有足够的能力把所有的天堑填平。。。分歧是必然的，同步，和谐有，更可能没有。一些思维僵化的人无法在舒适圈外有效拓展认知。今天一清早被朋友数落了一句：你是错把风口当本事。。。这个地方我卡了大概三个小时，老顽固们大部分工作时间，都耗在卡顿上。不是不行，脑袋跟不上时代。

对于以嵌入式应用为代表的物联网项目，很多工作需要数据推送来调试后面的业务逻辑。如果完全依赖硬件环境调试，会非常麻烦，而且，对于大中专院校的学生，还有一些其他数据部署会推迟的项目，先行构建一个好用的测试桩是必要的。

西交大轴承振动数据如果要在自己的振动解析程序中进行处理，需要能够把振动数据逐帧压入分析程序，这里是一份具备完整功能的python源码，它会检索多个通道数据最终统一采样率后压入一个.bin的数据文件。

面临发布节点的最终看家本领 - UncleZZ's Remedy系列第一则：进程看护工具（源码和测试例）

linux 命令行gdb调试内存泄露相关最小知识集合

采样率不足，引发的频谱混叠效应的实验，结论：混叠后的频率是 信号频率除以采样频率后的余数

信号采集过程中的两个关键技术指标的解析

在老旧电脑上实现无线投屏功能——通过MiraCast. 音视频从书房传递到10米左右的客厅。