到目前为止,我们已经开发了基于 Socket PHY 的双向通信收发机。不过目前的Socket PHY不能直接用Pluto SDR来替代,因为Pluto SDR发送/接收的是物理层基带信号,我们需要进行物理层的基带信号处理,而目前Socket PHY简化了了物理层信号处理过程而是直接收发数据包。
在实验1与实验2中,同学们已经开发了物理层信号处理的模块,包括发送机与接收机的信号处理。在实验3中,同学们已经开了链路层协议,实现了可靠图片传输。本次大项目就是将前述实验的开发成果进行集成,完成物理层、链路层、应用层的开发,并实现一个完整的实时无线通信系统,支持图片的可靠传输。
为了降低难度,大项目有两种提交方式:a) 物理层采用Pluto SDR硬件;b) 物理层依然采用Socket PHY,不过Socket传输的是基带信号。前者能拿到大项目全部的分数,后者只能拿到大项目全部分数的80%。对于这两种方式,项目都会提供一个框架代码,同学们只需要在框架代码中实现相应函数即可。
这两种方式都需要进行基带信号处理,区别就在于修改的Socket PHY会直接传输一个信号块,包括一个帧的全部基带信号与帧前面有随机添加的噪声。对于Pluto PHY,每次获取的一个信号块不一定保证包括一个完整的数据帧。此外,对于前者,在Pluto SDR实现实时系统有很多挑战,需要注意优化代码的性能,使得接收模块的处理足够快,否则会发生丢包。
tx_queue
,然后完成OfdmTx类的 put()
和 process()
。提交你实现的程序。(10%)tx_sample_queue_watcher_thread
以从 tx_queue
中获取样本,并使用PlutoSDR进行传输。提交你实现的程序。(5%)socket
发送机和 pluto
发送机之间的区别是什么?(5%)process()
函数tx_sample_queue_watcher_thread
的设计类似于 tx_packet_queue_watcher_thread
sdr_tx.tx(samples)
rx_sample_queue_watcher_thread
以从pluto获取缓冲区并将其放入 rx_sample_queue
中。提交你设计的程序。(10%)rx_sample_queue
获取缓冲区。检测缓冲区中的前导码并解调接收的样本。将解调的数据包放入 rx_packet_queue
,然后完成OfdmRx类的 process()
。提交你设计的程序。(15%)socket
接收机和 pluto
接收机之间的区别是什么?(5%)rx_sample_queue
和 rx_packet_queue
的作用?(5%)rx_sample_queue
或 rx_packet_queue
没有及时处理,会发生什么?(5%)samples=sdr_tx.rx()
。rx_sample_queue_watcher_thread
的设计类似于 rx_packet_queue_watcher_thread
。rx_buffer_size
的值,以帮助调试 process()
。time
库来测量 process()
中每个部分的时间消耗,并优化较慢的部分以提高处理速度。-t
选项可以相应修改。(py37)$ python test_nodeB.py -p pluto -l double # run first (py37)$ python test_nodeA.py -p pluto -l double
上述Pluto PHY需要和Pluto硬件交互,存在一定的难度。另一个选项是通过修改的Socket PHY进行交互。与Lab 3的Socket PHY不同(传递的是frame),Project使用的Socket PHY传递的是baseband samples。你需要从baseband samples中解码出frame,然后才能进行packet-level的处理。此外,为了能够集成帧同步的功能,我们的框架代码会在baseband samples前增加一段随机长度的噪声,但是可以保证每次接收到的信号包括一个完整的frame。存在随机长度的噪声,意味着需要实现帧同步,找到帧开始位置。
要求同上
要求同上
要求同上
要求同上