折腾了两天，现在终于从坑里爬出来了，留个笔记。
众所周知，ffmpeg是个非常牛B lity的东西，很多需要拉流或者推流的时候，这都是不二选择。并且这货还有其他很多功能，比如剥离视频中的图像与音轨，比如转换视频、音频的格式。当下一个正在进行中的项目，需要通过ONVIF协议，把机器人的摄像头H.265画面回传到控制中心，这就有了这次掉坑里的经历。
注意，重点来了： ffmpeg 有个 rtsp_transport 参数，通过设定这个参数值为 tcp ，使得ffmpeg强制使用tcp协议传输RTSP流（RTSP流模式使用UDP方式传输）。
错误示范：
ffmpeg -rtsp_transport tcp -i rtsp://camera-ip-address/channel/stream?param=value&other=something -f rtsp rtsp://media-server/app/stream_id?token=xxx
如果这样来跑ffmpeg，这货死活就是要走UDP。而数据中心的WAF刚好又关闭了所有的UDP端口......郁闷的我都想提流程申请开通UDP了。

GOOGLE翻了N多文章，发现了一个细节，stackoverflow上很多高分回答中，rtsp_transport这个参数的位置都在后面。如下正确示范：
ffmpeg -i rtsp://camera-ip/channel/stream?param=value -f rtsp -rtsp_transport tcp rtsp://media-server/app/stream-id?token=xxx

............刚吃完饭的我，顺手就抄个作业，MMP，世界真美好。ffmpeg现在终于老老实实的用TCP传输了。今天可以按时睡觉。

最近才知道一个让我哭笑不得的事情：在广东人眼中，广东以外的省，统统都是北方......
某个在广东的前同事最近向我咨询，如何改进GPS/北斗定位设备的数据质量，如何提高超载监控设备的数据精准度。顺便palapala吐槽了一堆市面上现有的某两大知名品牌车载终端的数据质量（我啥都没说，懂的都懂）。
拉了个网络会议，邀请了某通的算法工程师，大致了解了一下情况：
1、目前国五和国六排放的工程车，终端数据都要遵循JT808国标
2、定位数据偶尔发生漂移，少则几百米，多则几十公里
3、车子的承重数据波形图，瞬时漂移多达1000KG以上，距离90%的精确要求相差甚远

分析了问题的原因：
1、安装的时候，既为了省事，也为了防破坏，GPS天线都是跟终端用扎带捆绑在一起，塞到副驾驶位的工具箱里面。这样就导致了GPS接收数据的不稳定性。查看了轨迹图，漂移较严重的时候，大多在周边有高楼的情况下。某些特殊位置（地图上没有名字的区域），信号失真，这个应该是安全考虑，附近区域做了特殊防护措施。
2、承重数据，当前的算法居然是利用JT808的手刹信号作为标定点...让我哭笑不得。司机的驾驶习惯、终端的数据延迟等因素，都会导致手刹信号不可靠。还有一些特殊场景：诸如修路的时候，搅拌车边走边卸料，这就不可能去拉手刹。

解决办法：
1、把天线外露，放置到驾驶楼的顶部
2、采用卡尔曼滤波算法，核心思想：预测+估值，计算出合理的数值区间，让波动收敛在可控范围内。

改进意见是提了，但愿这个问题尽快得到解决。

ARM漫天飞的年代，没必要还在坚守古老的C89了。谭浩强教授的C语言教程都升级多少个版本了，嵌入式行业还在抱着古董级的东西不放......上一篇文章，贴了AHT20传感器的示例，所以干脆一不做二不休，顺便把最近写的INA226传感器的Python版代码也公布了。

说明一下：

1. INA226不贵，某宝上随便搜搜就知道，是德州仪器的
2. 这个SOC是I2C协议，兼容SMBUS，所以可以直接用Python的smbus2组件
3. 如果你怕Python工作不稳定，那么我告诉你：你想多了，我这里在工业环境下照样好好的。实在不放心，那就systemd托管起来

不废话，上图：

嵌入式开发，动不动就是C，千篇一律的C，甚至好多都特么的还是古老的ANSI89版的标准。
大学里的C语言基础教程都升级了，这嵌入式行业就这么不思进取么？
看看奥松官方的DEMO，还是用的GPIO作为示例，我也是醉了。
最近的项目刚好用到了这款传感器，都啥年代了，ARM遍地都是......所以决定，在条件允许的前提下，抛弃古老的C语言，尝试着用Python3.x来实现一下传感器数据的读取。
话不多说，上图（要抄作业的自己照着图敲一遍，别老想着Ctrl+C & Ctrl+V，这样不会有进步的）

        搬砖佬现在从事IOT行业，已经荒废了N年的数据结构基础，差不多都还给大学老师了。最近做的一个项目，让我重新拾起荒废的技能开战...
        项目中有一个需求：识别摄像头画面中的工程车，并获取车牌号。首先就想到了OpenCV，后来去工地现场考察，发现.......又特么的是现实很骨感的问题。工程车基本上都脏得要死，识别率简直低的不要不要的。于是变更了设计方案，使用超高频射频天线阵列，去感知附近的RFID标签。
那啥是RFID呢？我简单解释一下，超市里扣在毛巾袜子上的那个耳朵就是RFID标签的一种。当你没付钱就企图跑路时，超市门口的射频天线会滴滴滴，于是保安就过来抓小偷了。

好了，回到正题。RFID标签分为三个存储区块，分别是：

1. EPC：超时里的物品条码，通常就是写在这个区段内。长度为14个字节（某些类型的标签只能用12个字节）。
2. TID：标签的厂家ID，基本上都是只读的。这个区段一般是用来识别标签类型的，所以不可更改。
3. USER：可以用来保存用户自定义的数据，长度不固定。欧标的可以写入192个bit，也就是24个字节。

这里有一个问题，USER区段虽然很美丽，并不是所有标签都有...所以，把ECP段的12个字节利用起来才是王道！
车牌号分为几个部分：

1. 省份字头
2. 首字母
3. 号码
4. 后缀

举两个栗子：湘UD12345，字头是“湘”，首字母“U”，号码“D12345”，没有后缀；湘U1234挂，字头“湘”，首字母“U”，号码“1234”，后缀“挂”。

全国每个身份一个字头，加上“使领”这两个特殊字头（工程车可以忽略不考虑特殊字头），后缀有这几种情况：“挂学警港澳使领”，工程车同样可以忽略这些情况。归纳一下，号牌可能出现的数量组合有：34263636363636*36种。MMP，12个字节不够用啊（光一个汉字就要吃掉4个byte，UTF8模式下，单个字符最多可能占用4个byte，一般是3个byte）。

换个思路吧，不然又无解了。大学时候的计算机文化基础课程，2进制8进制10进制16进制的换算...我特么的撸个34进制，36进制好不好？答案是非常好。此题有解！这样子一来，车牌号可以压缩到28个bit来表示，也是就说4个字节就可以搞定。

强迫症在这个时候又开始发作，12个字节，还剩那么多怎么办？别浪费。于是就开始作死，加上4个bit的随机数，加上4个byte的时间戳，还剩2个byte用来保存crc16，简直就是完美。这样又把以前动态密文的设计思想给带进来了。

贴一段解算编码算法的Python实例代码：（从解算代码可以反推编码算法，我不喜欢留邮箱一族，也不喜欢只要源码光抄作业的人）

在算法的加持下，12个字节可以记录完整的车牌号，同时还可以记录制卡时间，还可以防伪，完美的不要不要的。