[=AK= 12]

Не в начале, а в конце, иначе как слейвы узнают, что пакет пришел?

Ага, забыл я уже Модбас...

 

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

[_Pasha 0]

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

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

А мы него опираемся как на длину посылки... а если он принят неверно и фактическая длина меньше ожидаемой? Что дальше? Таймауты вводить? Бардак получается.

[=AK= 12]

а если он принят неверно и фактическая длина меньше ожидаемой? Что дальше?

 

Элементарно. Ждем очередного байта. Если байт не придет, то затянувшаяся пауза сбросит все, что было принято ранее.

 

Если длина больше ожидаемой, то заканчиваем прием посереди пакета, проверяем CRC и выбрасываем принятое.

[_Pasha 0]

Элементарно. Ждем очередного байта. Если байт не придет, то затянувшаяся пауза сбросит все, что было принято ранее.

Вот. И я о том же. Т.е. по-любому появляется понятие тайм-аута и необходимость в нём. Так нафига же (согласно принципу Оккама) оставлять в живых еще одну - теперь уже совершенно лишнюю и ущербную,- сущность длины пакета? Если тайм-аут не только выполняет роль маркера конца пакета, но и не является ни частью содержимого, ни каким-либо управляющим кодом, следовательно - не подвержен влиянию ошибок в той мере, в какой подвержена информационная часть.

Изменено 18 октября, 2012 пользователем _Pasha

[=AK= 12]

по-любому появляется понятие тайм-аута и необходимость в нём.

А я начал с того, что пауза в начале пакета нужна, стало быть, и тайм-аут нужен.

 

Так нафига же (согласно принципу Оккама) оставлять в живых еще одну - теперь уже совершенно лишнюю и ущербную,- сущность длины пакета?

Потому что:

- Пакет будет передан быстрее (вместо паузы T35 в конце - один дополнительный байт, выигрыш по времени 2.5 байт-интервала)

- Появится возможность отличать начало пакета от конца, вследствие этого мусор, принятый в промежутках между пакетами, может быть гарантированно выброшен (для этого надо сделать так, чтобы по окончании приема пакета запрещалось принимать новые байты до тех пор, пока не появится пауза T35). В результате вероятность ложного приема при большом уровне помех (когда при отпущенной линии на вход все время прет мусор) уменьшится, имхо. Сейчас Модбас не отличает начало пакета от конца, поэтому такой мусор будет парсить как "реальный" пакет.

[_Pasha 0]

А я начал с того...

Сейчас Модбас не отличает начало пакета от конца, поэтому такой мусор будет парсить как "реальный" пакет.

1. Так, с налету объяснить у меня не получилось. Продолжение следует...

2. А здесь Вы приводите случай, которого быть не должно, потому что для отсева мусора служат паритет и Т15.

[=AK= 12]

1. Так, с налету объяснить у меня не получилось. Продолжение следует...

Ага. Не догадался, что кто-то не воспримет довольно ясный текст "в принципе пауза в конце не обязательна, в отличие от паузы в начале".

 

2. А здесь Вы приводите случай, которого быть не должно, потому что для отсева мусора служат паритет и Т15.

Паритет еще больше удлиняет пакет. А Т15 скорей всего не будет работать, если на входе плотный белый шум.

[_Pasha 0]

Ага. Не догадался, что кто-то не воспримет

 

Паритет еще больше удлиняет пакет. А Т15 скорей всего не будет работать, если на входе плотный белый шум.

1. Сейчас - беспредметный спор получается. Позже.

2. Плотный белый шум на входе - это значит, что физический уровень (OSI) у нас не работает, поскольку к "физике" относится не только электрический интерфейс, но и соответствующие этому интерфейсу методы - помехоустойчивое кодирование, контроль четности, 2B1Q, что там еще на ум приходит...

 

А если в данном случае:

работают совместно отбраковка получаемых данных контролем четности (т.е. таймер при приеме не сбрасывается, т.к. байт не считается принятым) - и Т15.

Тут правильно говорили про то, что радиоканал без ШП, а также без FSK - это бред. Это не "физика". Приведите навскидку реальное условие, когда шум настолько плотный, что "нивазможна" и при этом физика остается RS485+UART. У меня фантазии не хватает что-нить подобное представить.

[Ruslan1 17]

Ребята, вы вообще что изобретаете?

Если протокол с определением пакета по межпакетному интервалу- берите MADBUS-RTU.

Если протокол с определением пакета по спецсимволам- берите MODBUS-ASCII.

:)

 

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

Лично мое мнение:

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

[=AK= 12]

радиоканал без ШП, а также без FSK - это бред.

Почему же, вполне представляю себе радиоканал с ASK и АРУ, у котрой постоянная времени равна нескольким байт-интервалам. При этом сигнал на входе UART-а будет мало чем отличаться от канала с FSK.

 

Приведите навскидку реальное условие, когда шум настолько плотный, что "нивазможна"

Дык, это радиоканал и есть. Хоть бы и с FSK. Один черт, FSK или ASK, когда передатчики молчат, то на выходе приемника прет белый шум.

 

Соответственно, то, что будет хорошо работать для радиоканала, отлично сгодится и для RS485. Обратное вообще говоря не верно.

[_Pasha 0]

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

Придумывать протокол "по дороге" во время разработки системы и относиться к этому как к одной из многих задач в проекте- это верх наивности.

Не согласен.

Всё от задачи зависит. И степень нестандартности тоже.

 

Дык, это радиоканал и есть.

Значит, спор ни о чём. Всё, о чем Вы говорили - физический уровень, отличный от 485-го, там по идее должен быть корреляционный прием преамбулы и после этого - запись данных. Если помните, POCSAG, например - там емнип длиннющая прембула имелась. Но 0xF0 повторенные больше 2-х раз - самое оно, компромисс.

[Сергей Борщ 129]

там по идее должен быть корреляционный прием преамбулы

У меня в радиоканале сообщения без преамбулы (не считая битовой синхронизации). Протокол свой. Надежность связи - получше, чем у конкурентов, длительность посылки - меньше. Специально для =AK=: конкуренты из России, Латвии, Израиля, Канады. У них преамбула есть ;)

[_Pasha 0]

У меня в радиоканале сообщения без преамбулы (не считая битовой синхронизации)

Интересно! Но недопонял - про битовую синхронизацию.

[demiurg_spb 0]

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

Как это сделать на ПК при наличии автоматических конвертеров USB-RS485 типа ftdi и им подобным? Я вот об этом задумался и что-то сразу в голове ответа не нашел... Если не найти ответа на этот вопрос то становится очевидным, что именно для modbus-rtu растяжки могут дать положительный эффект...

[_Pasha 0]

Серьёзно, чем в wake 0xC0 якобы лучше чем 0xF0 ?