Протокол передачи данных по одному проводу Опции

[Слесарь]

Здравствуйте!
Я сделал эл. схему и создал протокол передачи данных по одному проводу. По типу протокола 1-wire. Напряжение питания устройств на шине 15V. Высокий уровень> 10V. Низкий уровень < 5V. Расстояние между устройствами, ведущим и ведомым, несколько метров. Больше месяца намеренно не делаю никакого контроля достоверности информации передаваемой по шине, получил такую статистику: в среднем, раз в час происходит сбой достоверности преданных данных, почемут, особенно в ночное время.
Данные в размере двух байт, передаются от ведущего к ведомому (двубайтная последовательность, адрес и команда) с частотой двух посылов в секунду. Ведомый принимает два байта и немедленно отвечает ведущему одним байтом, отвечает продолжая передачу ведущего. Тактовая частота последовательности передаваемых бит - 100 Гц.
Нормальная ли это статистика ошибок для однопроводной шины по типу 1-wire? Грубо говоря, провод висит в воздухе и не будет экранирован.
Планирую как-то ввести контроль достоверности, на стороне ведомого, для переданных мастером адреса ведомого устройства на шине и команды. На стороне мастера сделать проверку достоверности ответа ведомого.
Если у кого-нить есть опыт, подскажите, как лучше в данной схеме реализовать контроль? Может просто ведущему дважды посылать запрос и сравнивать два ответа ведомого? Ведомому сравнивать два запроса ведущего? Как говорится, молния не попадает дважды в одно место.

[kovigor]

Нормальная ли это статистика ошибок для однопроводной шины по типу 1-wire? Грубо говоря, провод висит в воздухе и не будет экранирован.
Если у кого-нить есть опыт, подскажите, как лучше в данной схеме реализовать контроль?

Как минимум нужно использовать контроль четности, а лучше - CRC8, как это сделано в тех же DS18B20. Еще можно для повышения помехоустойчивости увеличить ток в линии.

[Слесарь]

Как минимум нужно использовать контроль четности, а лучше - CRC8, как это сделано в тех же DS18B20. Еще можно для повышения помехоустойчивости увеличить ток в линии.

Для контроля четности читать собственно нечего. Мастер передает байт идентификатор устройства и следом за ним байт команду. Суммировать эти два значения и сравнивать с третим байтом четности?

В данный момент сделал двойную передачу мастером ID устройства и команду, если дважды ведомый принимает одинаковую команду, команда принимается ведомым. Если ведомый принял команду, то продолжает принятую от мастера последовательность двух байт, ответным байтом равным значению байта команды мастера. Мастер получив такой ответ от ведомого, фиксирует, что команда успешно принята ведомым. Что-то мне подсказывает, что данный способ надежней простого контроля четности.

Как сделано в DS18B20 изучаю.

[kovigor]

Суммировать эти два значения и сравнивать с третим байтом четности?

Нет, снабдить каждый байт своим битом четности, как это сделано в UART. Бит четности, кодирование по Хеммингу, CRC8 - обязательно должен быть механизм контроля корректности посылок.

Что-то мне подсказывает, что данный способ надежней простого контроля четности.

Сложно, надумано и ненадежно. Почитайте у того же Тутевича про помехоустойчивое кодирование. Или хотя бы про код Хемминга у Калабекова. Это ведь не зря все придумали и обосновали:


http://lord-n.narod.ru/walla.html

[Слесарь]

Я думал все эти биты четности для уменьшения количества передаваемых контролируемых бит. Выше скорость передачи.
А если скорость передачи не принципиальна, что может быть надежней повторения передачи и сравнения двух, а то и трех, переданных данных.

[kovigor]

А если скорость передачи не принципиальна, что может быть надежней повторения передачи и сравнения двух, а то и трех, переданных данных.

А если из-за обрыва или КЗ на линии вы трижды получите вполне допустимые посылки вида "0xff" или "0x00", что вы станете делать ? А если вход чувствительного приемника повиснет в воздухе, и вы постоянно будете получать "0x55" или "0xAA", тоже формально вполне допустимые ?

[stells]

А если...

прямой код и инверсный

[Слесарь]

А если из-за обрыва или КЗ на линии вы трижды получите вполне допустимые посылки вида "0xff" или "0x00", что вы станете делать ?

Перед посылкой вида - идентификатор+команда, мастер закорачивает линию для сброса в течении 100 мксек. Ведомый зарегистрировав событие сброса, начинает прием данных вида - идентификатор+команда. Проверяет идентификатор (сравнивает со своим) и запоминает переданную за идентификатором команду. Снова ожидает событие сброса и повторения посылки вида - идентификатор+команда.
Если дважды ведомый принял одинаковую команду, значит команда верна. Ведомый выполняет эту команду и отчитывается мастеру посылая ответный байт, код выполненной команды.

Разве что-либо может быть надежней?

Тактирует шину мастер(ведущий), ведомый передает данные по тактам ведущего, как и DS18B20

[kovigor]

прямой код и инверсный

И кому это, простите, надо ? Теория помехоустойчивого кодирования давно разработана, подробнейшим образом расписана в литературе. Так нет же, надо изобретать велосипед, просто потому, что лень почитать книжку. Так ?

Перед посылкой вида - идентификатор+команда, мастер закорачивает линию для сброса в течении 100 мксек. Ведомый зарегистрировав событие сброса, начинает прием данных вида - идентификатор+команда. Проверяет идентификатор (сравнивает со своим) и запоминает переданную за идентификатором команду. Снова ожидает событие сброса и повторения посылки вида - идентификатор+команда.
Если дважды ведомый принял одинаковую команду, значит команда верна. Ведомый выполняет эту команду и отчитывается мастеру посылая ответный байт, код выполненной команды.

Разве что-либо может быть надежней?

Тактирует шину мастер(ведущий), ведомый передает данные по тактам ведущего, как и DS18B20

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

[stells]

Так нет же, надо изобретать велосипед...

дублирование и резервирование изобрели до нас

[kovigor]

дублирование и резервирование изобрели до нас

Не будем продолжать этот бессмысленный спор. Я стою на том, что изобретать новые способы помехоустойчивой передачи данных, не изучив того, что разработано до вас (не изучив из-за простого нежелания изучить), по меньшей мере не совсем разумно ...

[Слесарь]

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

[kovigor]

Мне просто непонятно, чем плохо дублирование, кроме как уменьшением пропускной способности?

У меня нет времени детально продумывать описанный вами протокол. Лично мне видятся как минимум связанные с повторениями проблемы распознавания границ посылок - можно запутаться, что и к чему относится. Еще раз. Ничего изучать не надо. Просто настройте ваш МК на работу с битом четности, и все. На проходящие контроль четности посылки отбрасывайте. Проще едва ли можно придумать ...

[Слесарь]

Но насколько мне известно при контроле четности обнаруживается лишь какой-то процент ошибок или я что-то не понимаю. Двойная ошибка в байте ведь может пройти контроль четности?

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

[kovigor]

Но насколько мне известно при контроле четности обнаруживается лишь какой-то процент ошибок или я что-то не понимаю. Двойная ошибка в байте ведь может пройти контроль четности?

Да, двойные ошибки так не обнаружишь, но ведь и ваша схема неидеальна. В обоих байтах нарушится первый разряд. Что тогда ? Или из-за обрыва вы примете одни нули или одни единички ? Вы попробуйте, вполне возможно вам контроля четности и хватит. А еще очень советую увеличить передаваемый в линию ток ...