Проверка ошибок данных - PullRequest
0 голосов
/ 10 января 2012

У меня немного странный вопрос.Мой друг и я подумали, что было бы забавно создавать последовательный порт для связи между компьютерами с использованием звука.Как правило, компьютеры посылают серию звуковых сигналов для отправки данных и прослушивают звуковые сигналы через микрофон для получения данных.Одним словом, самый раздражающий последовательный порт в мире.У меня все основы проработаны.Я могу отфильтровать звуки только одной частоты, и я отправил данные с одного компьютера на другой.Несмотря на то, что передача не содержит ошибок, на нее влияют только очень громкие звуки, некоторые проблемы все еще существуют.Мой вопрос заключается в том, каковы хорошие способы проверки данных на наличие ошибок и, что более важно, восстановления после этих ошибок.

Моя последовательная связь очень стандартна, как только вы преодолеете тот факт, что она использует звуковые волны.Я использую один стартовый бит, 8 бит данных и один стоповый бит в каждом кадре.Я уже рассмотрел циклические проверки избыточности и планирую учесть это в своей проверке ошибок, но CRC не учитывают некоторые из более коварных проблем.Например, рассмотрим отправку двух байтов данных.Вы отправляете первый, и он получен правильно, но сразу после стоп-бита первого байта и стартового бита следующего на пол падает большая книга, которую получатель интерпретирует как стартовый бит, теперьИстинный стартовый бит читается как часть данных, и получатель может считывать ненужные данные на многие байты.В конце концов, пауза в данных может вернуть все в нужное русло.

Хотя это еще не самое худшее.Биты также могут быть отброшены, и большинство схем проверки ошибок, о которых я могу думать, полагаются на получение определенного количества байтов.Что происходит, когда получатель продолжает ждать байтов, которые могут не прийти?

Итак, вы можете увидеть сложность этого вопроса.Если вы можете направить меня к любым ресурсам или просто дать мне несколько советов, я был бы очень признателен за вашу помощь.

1 Ответ

2 голосов
/ 10 января 2012

CRC - это только часть решения.Вы можете проверить плохие данные, но тогда вам нужно что-то с этим делать.Передатчик должен повторно отправить данные, ему нужно сказать, чтобы сделать это.Протокол.

Отправной точкой является разделение данных на пакеты.Обычный подход - это начальный байт, который указывает начало пакета, за которым следует номер пакета, за которым следует байт длины, который указывает длину пакета.Далее следуют байты данных и CRC.Получатель отправляет ACK или NAK обратно, чтобы указать успех.

Это решает несколько проблем:

  • вам больше не нужен бит с ошибкой начала, паузу, которую нужно восстановитьвсегда там
  • вы запускаете таймер при получении первого бита или байта, объявляете ошибку, когда истекает время таймера до получения всего пакета
  • номер пакета помогает вам восстановиться после сбоя ACK /НАК возвращается.Передатчик истекает и отправляет пакет, вы можете обнаружить дубликат

RFC 916 описывает такой протокол в деталях.Я никогда не слышал о том, чтобы кто-то на самом деле его реализовывал (кроме меня).Работает довольно хорошо.

...