數據錯誤檢查

Question

我有一個奇怪的問題。我的一位朋友認爲，在使用聲音的計算機之間進行串行端口通信會很有趣。基本上，計算機發出一系列嘟嘟聲來發送數據，並通過麥克風收聽嗶嗶聲以接收數據。總之，世界上最煩人的串口。我已經掌握了所有的基礎知識。我可以過濾掉只有一個頻率的聲音，並且我已經將數據從一臺電腦發送到另一臺。雖然傳輸沒有錯誤，只受很大的噪聲影響，但仍存在一些問題。我的問題是，有哪些好的方法來檢查數據是否有錯誤，更重要的是，從這些錯誤中恢復。

我的串行通信是非常標準的，一旦你超越了它使用聲波的事實。我在每個幀中使用一個起始位，8個數據位和一個停止位。我已經考慮了循環冗餘校驗，並且計劃將這個考慮在我的錯誤檢查中，但是CRC沒有考慮到一些更隱蔽的問題。例如，考慮發送兩個字節的數據。你發送第一個，並且它正確接收，但是在第一個字節的停止位和下一個的開始位之後，一本大書落在地板上，接收器將其解釋爲開始位，現在是真正的起始位作爲數據的一部分被讀取，並且接收器可能正在讀取垃圾數據以獲得許多字節。最終，數據暫停會讓事情回到正軌。

雖然這並不是最糟糕的。比特也可以被丟棄，並且我能想到的大多數錯誤檢查方案都依賴於接收一定數量的字節。當接收器持續等待可能不會出現的字節時會發生什麼？

所以，你可以看到這個問題的複雜性。如果你可以指導我使用任何資源，或只是給我一些提示，我將不勝感激你的幫助。

Answer 1

CRC只是解決方案的一部分。你可以檢查不好的數據，但你必須做一些事情。發射機必須重新發送數據，需要告知這麼做。協議。

起點是你將數據分成數據包。常見的方法是指示數據包開始的開始字節，後跟數據包號碼，後跟指示數據包長度的長度字節。隨後是數據字節和CRC。接收器發回ACK或NAK以指示成功。

這解決了幾個問題：

• 你不關心一個糟糕的開局位了，你需要恢復暫停是永遠存在的
• 當您收到的第一位，或者你啓動一個定時器在收到整個數據包之前定時器到期時宣佈失敗
• 數據包號碼可幫助您從錯誤的ACK/NAK返回中恢復。發送器超時並重新發送數據包，您可以檢測到重複數據。

RFC 916詳細描述了這樣的協議。我從來沒有聽說過任何人實際執行它（除了我）。工作得很好。