19年KCSA卖过这东西，500km距离的图传。1.2m抛物面天线，4Mbps速率，软件ldpc编解码。
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
这个能跑到20M符号率，40M采样率。现在的电脑可能可以跑60M以上。
dvb的交织器不是为了打散连续的0和1，是为了打散内层的ldpc的块错误，让外层的bch码能够顺利纠错
6
AD936X gnuradio SDR实现QPSK视频传输
研究了好一段时间的gnuradio，终于弄了一个大的项目出来， 用两个AD936X结构的SDR实现了视频实时传输，话不多说，直接上效果：
PXL_20251109_144434385.mp4 点击下载
两个plutosdr架构的SDR，两台电脑，一个发射一个接收，发射端电脑读取ts流文件，打上tag，计算CRC32、加上访问协议头，然后映射为QPSK的符号，转化成IQ数据给plutosdr，发射出去
接收端是另外一个电脑，从SDR读取IQ数据，进行相位时钟同步（Gardner算法），线性均衡（CMA算法）、Costas解调、映射符号，解析访问协议头、组装成8bit字节、检查CRC32、得到ts流视频数据发送给UDP端口
然后再用VLC视频软件打开udp流，打开udp://@127.0.0.1:2345 这个地址，就能播放出视频
需要注意的是TS流，这个是一种视频流的文件，里面的编码可以是H264或者H265，这个文件奇特的地方是，它像蚯蚓一样，你把他切断成N份，每一份都可以播放的，甚至里面的数据出了一些错也能播放，这种流文件的设计就是给无线视频传输用的
以上的内容，可以作为通信原理的大作业了，这个实验还是比较复杂的，细节很多，甚至我怀疑很多研究生阶段也不一定能够搞成功。
这里就直接造福大家了，代码文件开源，适合于gnuradio3.11最新版本（网上一堆不兼容3.11版本的流图），windows环境可用！：
发送部分
接收部分
转换mp4文件为ts流的命令
测试的ts文件是720x480的分辨率，600k的码率，因为没有进行FEC纠错，播放时容易有马赛克，有点像以前播放VCD碟片
测试的plutosdr一个是原版的，
一个是以太网版的，
原版的使用usb iio传输采样率不能大于2.8M，否者星座图会乱掉，以太网版的没问题，听说把原版的改成usb otg接以太网转换器可以大于20M，我个人尝试过把原版的plutosdr换成hackrf，传输文本文件也是没问题的，采样率能大于2.8M到20M，但是误码较多，还是两个plutosdr最好，两个plutosdr都没有PA，居然能够传输20米，甚至拿到另外一个房间都能正常接收，甚至感觉要好于wifi
电脑的算力是E52640和i5，发射端I5平板、接收端E5服务器，测试CPU占用来看，并不多，消耗算力很小，我尝试过树莓派的Ubuntu环境运行发射也没有问题
后续还会研究通过FPGA的方式来进行调制和解调，这样码率能够更高，延时更低，这样可以更靠近一步终极目标——无人机低延时图传
[ 修改于11个月22天前 - 2025/11/12 21:31:23 ]
另外目前我在前期的调试实验中，发现用这套代码传输文本文件正常，发射端选择下面这样的txt文件，接收端也能正常接收下来
但是换成TS流文件就容易出错，导致视频大量马赛克，一直奇怪为什么会这样，最近我用二进制编辑工具打开ts流文件，才恍然大悟
TS流的文件，里面有大量的FFFFFF这样全1的数据，对于QPSK传输系统来说，最忌讳的就是传输全0全1的数据，因为这样的数据没有符号跳变，很容易导致时钟无法同步，大家可以试试用这套代码传输一个全部是0xff的文件，会发现星座图无法产生
这里就要说到DVB数字电视之类的协议里面的交织（interleaving）和加扰（Scramble）了，这两个过程的目的是把输入的数据打乱，避免出现这种大段的全1全0，显然我们上面的项目是没有做交织和加扰的。
在gnuradio中，有现成的交织和加扰模块可以用
后续在这个项目上加上交织和加扰，这样就能进一步提升传输的质量了
3
后续在FPGA硬件上实现，可能会采用导频码的方式做同步和均衡，参考B站东枫科技实现的流程
从这个流程图来看，直接用帧头滤波就可以实现载波同步，再使用导频码实现均衡，应该能够比Gardner同步和盲均衡延时更低
引用
评论
另外目前我在前期的调试实验中，发现用这套代码传输文本文件正常，发射端选择下面这样的txt文件，接收端也能正常接收下来
但是换成TS流文件就容易出错，导致视频大量马赛克，一直奇怪为什么会这样，最近我用二进制编辑工具打开ts流文件，才恍然大悟
TS流的文件，里面有大量的FFFFFF这样全1的数据，对于QPSK传输系统来说，最忌讳的就是传输全0全1的数据，因为这样的数据没有符号跳变，很容易导致时钟无法同步，大家可以试试用这套代码传输一个全部是0xff的文件，会发现星座图无法产生
这里就要说到DVB数字电视之类的协议里面的交织（interleaving）和加扰（Scramble）了，这两个过程的目的是把输入的数据打乱，避免出现这种大段的全1全0，显然我们上面的项目是没有做交织和加扰的。
在gnuradio中，有现成的交织和加扰模块可以用
后续在这个项目上加上交织和加扰，这样就能进一步提升传输的质量了
引用
评论
3
19年KCSA卖过这东西，500km距离的图传。1.2m抛物面天线，4Mbps速率，软件ldpc编解码。
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
这个能跑到20M符号率，40M采样率。现在的电脑可能可以跑60M以上。
dvb的交织器不是为了打散连续的0和1，是为了打散内层的ldpc的块错误，让外层的bch码能够顺利纠错
引用
评论
6
长期连续FF会导致失同步，或者在切去直流的通信系统里造成基线飘移（baseline wandering）。解决方法是编码/扰码，
如曼彻斯特编码，8B/10B，或者PRBS扰码/自扰码。你的系统里可以考虑加入这些环节。
至于交织的作用，战猴是对的。交织的主要目的是打散error，让burst error散开，这样error会更接近（更像）随机的正态分布白噪音导致的随机误码。这样的误码分布对纠错算法的纠后BER提升有利。
引用
评论
3
引用
评论(1)
3
请问贴主的项目有落地吗？单载波QPSK的多径抗干扰能力差，感觉这个只能做近距离的VTX，如果要距离拉大，是不是还得OFDM？如果按这套来做，是不是到了1080P60Hz，7010的PL侧资源就到头了
引用
评论
请问贴主的项目有落地吗？单载波QPSK的多径抗干扰能力差，感觉这个只能做近距离的VTX，如果要距离拉大，是不是还得OFDM？如果按这套来做，是不是到了1080P60Hz，7010的PL侧资源就到头了
看你配什么天线。制高点远距离无遮挡，配定向高增益天线或者相控阵波束成形，多径相对影响小很多。
如果是两边都用全向或者接近全向的天线，都在地面高速移动，多径会非常显著。
带宽做大了，带内响应基本上做不平，宽带必加均衡器。均衡器阶数做高了一是难以收敛，二是资源开销跟fft做ofdm解调也差不多了。
ofdm对同步精度、相位噪声极为敏感，远比单载波要求高，这就是wifi图传与专业cofdm图传的区别。ofdm参数和fec纠错码影响并没有想象的那么大，也就是说跟用什么协议关系不大。
引用
评论
引用
评论
引用
评论
请问贴主的项目有落地吗？单载波QPSK的多径抗干扰能力差，感觉这个只能做近距离的VTX，如果要距离拉大，是不是还得OFDM？如果按这套来做，是不是到了1080P60Hz，7010的PL侧资源就到头了
这个项目是研究性质的，qpsk单载波广泛运用在卫星通信上，没有必要怀疑它的距离。
而且用qpsk单载波能最大程度简化发射端的设计，结合现在山寨plutosdr价格越来越低，配合上合适的压缩算法，是可以做到自定调制方式自定义协议的数字图传的。
我现在在做把发射端的grc图转换为C算法的工作，再加上用国产GaN做PA，发射功率弄到10W，能够实现俄罗斯柳叶刀无人机那等级的图传了
引用
评论
1
有人开源了一个紧凑的ad936x的图传设计，有mipi-csi接口，可以接摄像头。
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
看里面的命名，作者是想做OFDM图传的，但是软件未完成，很多人都做出了类似的硬件，但是软件开发还是太难了，哈哈。
建议还是先从单载波QPSK做起，另外zynq7020编码出H264还是太难了，估计做了baseline就没空间做OFDM了，而且编码这一块行业壁垒很大，就没有什么开源数字硬件实现
引用
评论(1)
这个项目是研究性质的，qpsk单载波广泛运用在卫星通信上，没有必要怀疑它的距离。而且用qpsk单载波能最大程度简化发射端的设计，结合现在山寨plutosdr价格越来越低，配合上合适的压缩算法，是可以做...
卫星链路几何稳定很多，不太会出现低空图传的地反射、多径、遮挡、机动、频偏、短时深衰落这些问题。我这里也在自己手搓，打算试试QPSK加上SCFDE和FEC，相当于小ofdm了，后面再试试完整的。
GNU转成C是为了用vivado上板吗？这里FIFO、FFT这些都有现成模块，但边界条件、协议、握手，还有测试验证的一堆testbench都得自己搞。
pa这里我打算问问厂家看看怎么调，氮化镓模拟图传用的多，数字的还不太清楚。
引用
评论
引用
评论
3