Day7:一款无线抢答系统的设计思路
基本思路
這套系統分為三個端,分別為主持人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模塊。
思維導圖
簡略畫了個思維導圖,湊合著看看吧:
 
實現過程
見Day8:一個無線搶答系統的實現過程
隨堂筆記
TCP 穩定傳輸 常見于網站 確保不能丟包
UDP 不穩定傳輸 常見于視頻通話 丟包無所謂
心跳機制 每隔一分鐘發送一個數據包,確保對方存活
總結
以上是生活随笔為你收集整理的Day7:一款无线抢答系统的设计思路的全部內容,希望文章能夠幫你解決所遇到的問題。
                            
                        - 上一篇: rhino java api demo_
 - 下一篇: 工具收集 - 重命名工具 ReNamer