Пишу программу для работы дежурного персонала (не квалифицированного) с DX500. Предполагается выполнение ограниченных установок: закрыть/открыть порт, выдать/снять генератор ...
Столкнулся с проблемой - не могу найти описание протокола обмена между DX500 и терминалом.
Буду очень благодарен кто пришлет описание или подскажет где найти протокол.

P.S. В фирму звонить бесполезно.

KVN234 пишет

P.S. В фирму звонить бесполезно. [/i]

Более того скажу, что на самой фирме это знают единицы. Так что не стоит даже и пытаться

Здесь всё просто НЕТ никакого протокола, общение станции с терминалкой происходит путём соединения ПК с портом RS232(COM). А если почитать MSDN, то станет понятно что работа с COM портом осуществляется точно так же как и при работе с обычным файлом.

Все-таки кто-нибудь пытался разгадать протокол обмена? Я пытался при помощи wireshark, при подключении по TCP/IP, но к сожалению, пока ничего не получается...

Перехватывал сообщения с СОМ порта при помощи программы PORTMON, терминалку тоже хотелось написать свою, но отвлекли. Давайте сообща решим проблему! Правда пишу (громко сказано, скорее корябую) на Делфи.

А стандартный конфигуратор DX500 от информтехники не подходит? В свое время с помощью этой проги быстро освоил станцию(на курсы не направляют). Простые операции(кроме вкл генератор) можно легко сделать.

Смотрите аккуратно с Конфигуратором, он умеет гораздо меньше чем хотелось и удобен только для ознакомления и и понимания структуры станции. Терминалка дает полную свободу действий, главное чтоб было понимание того чтог творишь...

Согласен, многие таблицы(sys, EDSS1n и др) в новых версиях ПО им вообще сконфигурировать нельзя. Только простейшие операции типа: ввести в сервис, присвоить списочный номер.

вот что удалось раскопать за пару дней:
первые 5 байт = 01 (начало сообщения)
последние 4 или 5 байт = 02 (конец сообщения)
6 ой байт - количество символов в сообщении
7 ой байт -? у меня либо 00, 01, или 02
8 ой байт - всегда 01
9 и 10 ый байт - видимо счетчики т.к наблюдается их увеличение но закономерность не совсем понятна.

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

Диалог сопровождается сообщениями, и подтверждениями.
.
Подозреваю что аналог х.25 на 2 уровне обязан присутствовать, на 3 уровне - чистая специфика

Подтверждения идут на 3 уровне, в них подтверждаются значения счетчиков, как я понял 8 байт счетчик передачи, 9 байт счетчик приема.

Всем спасибо!! Разобрался ))

Если у кого есть необходимость, готов выполнить заказ на разработку ПО для управления, сбора информации, мониторинга в том числе по SNMP станции DX-500. Предложения по мылу snus@inbox.ru

Если у кого есть необходимость, готов выполнить заказ на разработку ПО для управления, сбора информации, мониторинга в том числе по SNMP станции DX-500. Предложения по мылу
ню-ню... по SNMP... а мужики то не знают! корячатся со своими RS232, сервера СМА ставят, по модемам подключаются, а там то оказывается надо только SNMP включить и станцию опросить :)

:) Все верно вы говорите. В данном вопросе SNMP выполняется в виде шлюза и подключается к тому же RS-232, сообщения для посылки Trap можно использовать сообщения выдаваемые для СМА, тут никаких проблем. Этот функционал я уже реализовал на своей станции. Настроил Zabbix и сижу наблюдаю. А за одно, чтобы порт рационально использовать, сделал возможным сохранение тарификационных данных через этот же шлюз. Будет время, еще и терминалку встрою, чтобы люди с "компактами" не чувствовали себя ущербными.

В данном вопросе SNMP выполняется в виде шлюза и подключается к тому же RS-232,
Как это ФИЗИЧЕСКИ реализовано?
ПК? - ну это неинтересно. сами наверное понимаете почему.

Ну это в любом случае будет ПК, даже если его убрать в корпус от модема. И я не вижу проблем с использованием ПК, это нормальное решение. Если разрабатывать решение на микроконтроллере, нужно будет решить ряд сложных проблем, к примеру многопоточность. Опыт подобных решений есть, разработка может занять не один год.
И потом на ПК может интергироваться графическая система управления, как альтернатива терминалке, плюс сбор тарификационных данных. Без ПК тут не обойтись.