Автобусное табло, неведомый протокол по RS485
 

Знатоки, кто сталкивался с таким вот протоколом, который опишу ниже. Сильно не пинайте, я прикладник, такое вижу впервые, документация проприетарная и её не дают.

Есть автомобильное табло на автобус Luminator TwinVision Smart Series и к нему пульт OCU. Я подключился между пультом и знаком, могу видеть данные на ПК через Rs485 конвертер. Скорость 115200, настройки порта 8N1. И вижу я к примеру, вот такое:

Команда, видимо, очистки строки:

40 50 00 08 00 84 24 00 00 30 11

Команда отправки строки текста RED ROUTE 10

40 05 00 38 00 82 00 00 00 24 14 FF FF 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 52 45 44 20 52 4F 55 54 45 20 31 30 20 20 20 20 20 20 20 20 20 20 30 11


Несложно было догадаться, что 0x40 это заголовок, второй байт это CRC (0x100 минус сумма), 0x38 вроде как получатель(?), 0x82 тип команды, 0x24 тип строки, 0x14 начало строки, два байта 0xFF это типа маска NN (номера маршрута), далее простая тексотвая строка, а 0x30 и 0x11 - конец. Расположение контрольной суммы в начале - это уже фантастика для меня, ну ладно.

Однако если попытаться с ПК отправить такую же команду в обход пульта, знак ругается строкой 40 04 00 08 00 F3 01 00 00, которую он повторяет на любую посылку количеством over 100 раз(!) без какой-либо реакции.

Вопросов два.

1. Что за протокол такой чудной, где CRC в начале? Может кто узнал? Почему в конце зачастую 30 11, но иногда нет?

2. Что за ответ такой от табло, чего он от меня хочет таким многочисленным повтором? Это типа хендшейк что ли?

Этот протокол испрользуется в промышленных контроллераз для связи с датчиками. Он позволяет связывать несколько усттройств по одной шине. Можете не изобретать велосипед, описание есть в И-нете.

Николай_С, замечательно, а как называется спецификация?

Похоже, что-то на аппаратном уровне. Неплохо бы запоминающим осциллоскопом посмотреть разницу непосредственно по RS485. Может, конвертер чудит - например, передача инвертируется tehno015

Abell, да, по уровням там чёрте что может быть запросто. Но!
Ответ от табло - осмысленный, в том же формате, с валидным CRC. А значит, он явно что-то просит в этом протоколе, назовём его так. У меня идей нет, я такое впервые вижу, так что вся надежда, если тут кто-то припомнит похожие реализации.

я имел в виду, что конвертер может отправлять неправильные данные, на которые и ругается табло.
Кстати, насчет ругается. Вы наблюдаете линию rs485, а она двунаправленная. Что, если некоторые байты в команде - ответ, а не команда пульта? Есть возможность открыть пульт и посмотреть отдельно, что он передает, а что - принимает? tehno015

На это я Николаю С ответил. CRC в 95% совпадает, а где вплетается ответ - оно видно и легко исключаемо. Скажем так, да, это всегда проблема, но здесь удалось увидеть и убедиться в единообразии формата.

Формата, где CRC идёт вторым байтом. Ну вот что это за причуда? Я не нашел ни в одной стандартной спецификации такого :-(

"а зачем нам стандартная спецификация? не, нам стандартная спецификация не нужна!" - сказали разработчики этого девайса, придумали свою и ни с кем не поделились, "Ы!" - чтоб никто не догадался и искал тайный смысл, а его нет tehno013
На электрониксе, где Вы этот же вопрос задавали, посмотрите темы и сообщения, сколько "разработчиков" озабочены в первую очередь задачей - защитить свое устройство от вскрытия и копирования, пусть даже в ущерб функционалу - так и здесь :fase:

Да так и называется. Спросите у Вики, узнаете много интересного.
И еще:
В самом конце перечислены основные протоколы с их описанием.

вы RS485, что ли, мне сватаете? так я ж в нем и читаю уже. Эх, а я надеялся :-)

Оно понятно. Надежда, что кто-то подобное встречал.

Скажем так, можно даже сократить вопрос до одного, абстрагировавшись от формата.

Кто встречал такую реализацию, когда слейв спамит канал каким-то запросом в ответ на любую посылку? Что именно делают таким образом? Хендшейк?

исходя из вышесказанного тезиса - никто, кроме разработчиков tehno013
Вы разберитесь на месте, где прием и где передача - с этой стороны монитора плохо видно. Может, пульт запрашивает квитирование после каждого байта. Или двух. А табло, пытаясь выдать квитанцию на команду с компьютера, упирается в занятую линию.
И когда отправляете команды с компьютера - пульт остается на линии или уже отключен (а вдруг)? tehno015

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

Но допустим квитирование. Проверяем. Я отправляю всего один байт 0x00 и молчу, табло начинает мне слать 100 квитанций. Занятой линии, получается, нет. Значит, это хендшейк "вы кто?". Я верно рассуждаю? Бывает такое в стандартных протоколах? Но как я это прерву, он же бомбардирует порт добрых 5-7 секунд.

А я знаю? Оно мне надо? tehno015 Не забывайте, что стандарт rs485, кроме двунаправленности, предусматривает еще и работу нескольких устройств на линии, а это уже сеть, и значит - адресация. И скорее всего, процедура инициализации сети, где покорные рабы по команде хозяина должны назвать свои имена и адреса. Вполне возможно, что на любой чих по проводам изнывающее от одиночества табло начинает судорожно слать посылки типа "я здесь, мой адрес такой-то, готов к контакту, как слышно-прием, ответь мне, ОТВЕТЬ МНЕ! кто-нибудь!" - а в ответ тишина :fase:

)) посмеялся, принял к сведению, будем копать :ku-y: