Day7:一款无线抢答系统的设计思路
Day7:一款无线抢答系统的设计思路
Aciano主要探讨了有关设计一款无线抢答器的基本思路,通过不同的通讯方式之间比较出适合本作品的最优方案。实现过程请见:Day8:一个无线抢答系统的实现过程。
基本思路
这套系统分为三个端,分别为主持人App端、主持人掌控板端与选手端。
其中主持人App端负责发出正确选项、开始抢答、下一题等指令。
主持人掌控板端负责将主持人App端发出的消息转发给下方的选手端。
选手端负责判断选手的抢答与否,并自动给分。
通讯方式
前面谈到,主持人App端需要发送指令给主持人App端并转发给选手端,其中的通讯方式我们有以下几种方案:
方案一
所有平台端联网,使用WiFi+MQTT方案:
优点
1.连接方便,无需主持人掌控板端转发消息;
2.无需其他模块,使用板载WiFi即可;
3.可连接平台端数量多;
缺点
1.不稳定,延迟受网速影响,无法做到同步抢答;
2.需要网络支持,环境受限;
3.WiFi距离有限;
总结
此方案虽然行得通,但是不稳定性太高,容易出现错误,pass.
方案二
所有平台端使用掌控板蓝牙:
手机作为客户端只能连接一个蓝牙服务端,而选手端肯定不止一个,pass.
方案三
所有平台端使用LoRa通讯:
理论可行,但是LoRa无法与手机App通讯,pass.
方案四
使用Bluetooth+LoRa进行通讯:
主持人App端与主持人掌控板端之间使用蓝牙通讯;
主持人掌控板端接收到手机App端通过蓝牙发送来的消息后,通过LoRa发送给下方的选手端;
选手端之间的抢答判断也通过LoRa实现通讯,最后发送回主持人掌控板端进行汇总。
总结
综上所述,方案四是最优的方案,我们选择方案四作为通讯方案,主持人掌控板端使用蓝牙与LoRa模块,选手端也使用LoRa模块。
思维导图
简略画了个思维导图,凑合着看看吧:
实现过程
随堂笔记
TCP 稳定传输 常见于网站 确保不能丢包
UDP 不稳定传输 常见于视频通话 丢包无所谓
心跳机制 每隔一分钟发送一个数据包,确保对方存活