佚段的毕设

佚段的毕设

动态二维码的数据传输设计研究

将信息转换为连续的QR码图像组(下文简称动态QR码)，接收端扫描动态QR码以实现1-2Mbps的近距离(3米内)数据传输，这是一种以光通路为传输介质的单向传输方式。该传输系统可满足低数据量的多设备传输需求，可应用于大型集会，博物馆等人流密集场所，用于解决网络拥塞情况下的低数据量传输问题。

设计进度
目前可以实现文件的传输，但是传输速率较慢27Kb/s，继续寻找提升数据速率的方法。
大量时间花在了调试和module的学习中–本文只展示研究结果和答题思路
目前使用的module
pyzbar，math，qrcode，pilllow，cv2，numpy，os

QR1.0设计方案一（传图片的具体数据）

    以图片视角切入，读取图片的RGB原始数据，图片的矩阵的格式转化为字符串格式进行传输，
这样的转化使原始数据量翻18倍左右，因为存在很多的无效数据，传输效率大打折扣。
0_0[[255, 255, 255], [255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255],[255, 255, 255]],这样的传输方式很占资源，一张二维码最多只能传10*10像素的图片，且需要大量的字符串操作才
能保证数据的正确还原。       

QR2.0设计方案二（传文件数据，二进制文件形式）

    如果以字符传输，那二进制格式下转字符串传输数据，解码端就存在着解出/0（字符串停止符号）
导致无法正确传输，现在的解决方案是以16进制格式去传输数据（但是字符串格式下一个8位数据(1字
节数据)是用了2个字节是传输的）

QR3.0设计方案三（base64编码处理）

   用两个二进制数来存一个八位还是浪费了二维码的传输能力，采用 base64 编码进一步降低数
量；原始数据的3个字节转化为4个字节。原始数据取六位然后在数据前添加00，构成新的可以用
字符表示的8位数据。基本原理如下图所示：

QR4.0设计方案四（0.23.1以上的Zbar更新的pyzbar原数据传输验证）暂时失败

二进制数据不会在解码端转换为字节符号，但是无法正确的恢复出原始数据。
一个猜想是可能生成二维码时数据有变化

QR5.0设计方案五 结合喷泉码的研究

QR6.0设计方案六 实际系统设计

1、扫描时间内处理就不需要加上解码识别的时间了，在同一个范围内就行。
有效性的参数设计：扫描帧数和有效帧数的比值

2、在输出帧数相同保持不变时，设计系统的接收应该只会收到接收端的帧率影响

3、接收端帧率与接收效率的关系图

4、存储内容大小与传输速率的影响

5、设计因素：摄像头频率，分辨率，实验光线环境，屏幕帧率

6、处理速度与采集到的图像的像素多少有关

7、识别率与图片存的数据量有关，与屏幕和摄像头的帧率，分辨率都有关系