1、从pcb板来看，丝印层的字体设计得太小了，在pcb板上显示不清楚，这个可以参考pcb板厂家的书籍来调整text字体的长宽。电阻和电容的pcb丝印没有显示出来，这个要问下pcb厂家是怎回事。
2、串口的tx、rx、gnd引脚在pcb板上的顺序跟实际的母头不一致，把pcb上的母头设置为在bottom layer就可以了。
3、4G模块的ldo电源R155、R156电阻阻值刚好反了，R155电阻应该为68K，R156电阻应该为30K。应该给4G模块的电源部分增加一个led指示灯。
4、在测试mbus接口的时候发现用于建立比较基准的R316电阻有虚焊，导致偶然能通信成功，再测试的时候又不能通信成功。 5、在测试表具的时候发现基于PIC16F690单片机开发的6字轮大表通信不成功，有收到部分的数据，而其他的表具测试都是正常的，用示波器测试，抓取波形如下： 这里有三条波形，第一条为基于LPC1111芯片开发的直读表，可以看到在光电AD采样阶段电流很平稳，大概32ms后开始通信，在通信阶段先发送了3个连续的0xFE；第二条波形是基于PIC16F690单片机开发的6字轮表具，可以看到在AD采样阶段和通信之前有明显的5个凹坑，表明在AD采样阶段从总线吸取的电流较大，大概在55ms后开始通信，发出连续的4个0xFE；第三个波形是基于第二个波形的在串口rx引脚上抓取的波形，可以看到在AD采样阶段就引起的RX引脚上电压的变化，让串口认为总线上有数据返回了，并开始了数据的接收，但这时候的数据根本就是不正确的，串口识别出来的都是些随机的乱码，然后串口继续识别直到能识别出正确的数据为止，这时从打印输出就可以看到串口能接收的一些数据，有些数据是正确的，有些时错误的数据，但整个数据帧是错误的。类似于下图所示（我看到其它厂家的集抄设备也有类似的错误）。 这种错误我在测试的时候是由于大表返回的数据格式不对，本来应该是2400波特率，8数据位、1停止位、偶校验，但返回的波形如下：     从图片中可以看到前三条波形是串口rx引脚识别出来的波形，第三条是正确的波形，前面是3个连续的0xfe，紧接着是0x68；后面3条波形是电流调制的波形，基本一致。 6、短路保护电路 之前一直没有通过示波器抓取波形，这次通过示波器仔细分析了短路电路的工作。 可以看到在短路发生的时候，在R209上有△y=3v的电压，N型mos管的GS间电压由△y=6.75v变为0V从而起到短路保护作用，短路响应时间从波形上看大概为20ms。        2018.11.18日在S3CDV2.1版本调试中，由于要多接水表，因此将18V电压降到13V，在调试短路保护的时候发现直接将Mbus总线短路，短路保护灯也不亮，短路保护没有起作用，这时测试mos管GS间电压只有不到5V，而R209电阻上电压只有不到1.2v的电压；经过分析估计是mos管没有完全打开，因此将R205电阻有15K换为30K，将R208电阻由20K换为10K，通过R205和R208的分压使得mos管GS间电压大概为9V左右，这样短路保护就能正常工作了。 7、lora模块的数据接收         目前lora模块的数据接收是采用查询的方式，后续可以考虑采用中断的方式来实现数据的接收，这就要求在硬件上选择一个有中断功能的硬件跟lora模块的DIO0引脚相连接。 8、bsp250 MOS管没有完全关断的问题         有两个cp2102芯片，通过npn三极管和bsp250 p沟道mos管来控制cp2102的5v输入电压，发现在关闭mos管开关的时候，mos管的d级任然有1.5v左右的电压，通过电路研究发现cp2102的vbus上连接有1uf和0.1uf两个电容，在mos管截断后两个电容上的电荷没有释放完，去掉这两个电容，mos管d级电压基本可以拉到0。 9、在进行Mbus总线读水表的时候主机会复位         有时在进行MBus总线抄读水表的时候主机会复位，经过分析是核心板的3.3v电压被tps61175启动瞬间拉低了；通过将tps61175的输入输出电容改为1000uf/10v的电容就可以了，这种情况在之前的版本中也遇到过。 10、再次分析进行Mbus总线读水表的时候主机复位         再次对Mbus总线读水表的时候主机偶尔复位问题进行分析，发现给sim7600ce提供电流的线性稳压芯片mic29152的最大输出电流为1.5A，而sim7600在发送的时候峰值电流可达到2A，因此选择mic29302来代替mic29152，mic29302最大输出电流可达3A。 11、在同时打开4G模块、lora模块、Mbus总线后核心板复位的最终分析         在整个主机全部模块打开的情况下，进行Mbus总线读取水量的时候核心板偶尔会复位，最初一直怀疑是电源的输入电流不足，做了几个方面的修改测试：1、将3.3v LDO芯片LM317的输入和输出端电容都换为大的电容，但问题还是存在；2、将DC-DC升压芯片61175的输入输出电容也换为大的电容，问题依然存在；3、将4G模块的LDO芯片mic29152替换为mic29302，问题依然存在；4、将电源适配器由5V3A替换为5V5A，问题依然存在；5、怀疑是软件问题，导致复位，但在linux里面应用程序是作为一个进程运行的，有自己独立的程序空间，及时软件有bug，也是自己这个进程出问题，不会导致系统复位；6、最后怀疑有可能是给核心板供电的LDO lm317电流输出能力不够，这个在以前也遇到过，最初用的是s812c33只有几十毫安的电流输出能力，后来换为lm317有1.5a的电流输出能力觉得应该没有问题了；这次又出现核心板复位的情况，因此将lm317换为了mic29302，将电流输出能力提高到了3a，这个改进后，一直测试都没有发现核心板复位的情况。 12、9月22~23日期间测试了带载能力         最初Mbus总线设计是通过两个tps61175将5v输入分别升压到30V和18V，反馈电阻R1、R2一组为304、133；另一组为304、203；在一个通道的总线上挂载了大约40只表的时候就发现接收Mbus总线数据的串口不停的收到错误的数据，导致Mbus线程一直在接收数据，不能处理后续的数据；这时，用示波器抓取总线上的波形发现总线上有很大的纹波，这些纹波就是干扰数据。分析纹波产生的原因，估计是tps61175的输出功率不足造成的。后面将tps61175的输出分别调为25v和13v，这时候带载能力有显著提升，反馈电阻R1、R2一组为394、203；另一组为104、103；每个通道分别挂载50只表的时候都能正常抄回数据，由于没有多余的表具就没能再增加负载了。 只接一只表时候的波形   接50只表时候的波形  接50只表时候的波形 展开    S3CDV2.0主机实物图