| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Father
Junior member
Зарегистрирован: 23.10.2004
Сообщения: 4
|
 Добавлено: Сб Окт 23, 2004 12:05 pm Заголовок сообщения: Модемы IDC-5614BXL/VR принимают "мусор" с линии |
 |
|
Здравствуйте! Два модема IDC-5614BXL/VR применяются для связи по коммутируемой телефонной линии с удаленным измерительным оборудованием. Скорость обмена- 2400, модуляция v.22bis
Связь устанавливается без проблем, но после установки связи один из модемов (любой из них случайным образом) начинает принимать по телефонной линии "мусор" - на RS232 модемов с помощью терминала регистрируются хаотичные последовательности символов, индикатор RD на лицевой панели непрерывно мигает. При этом гарантированно ни одно из подключенных к модемам устройств данные не передает.
Регулировка регистром S91 уровня выходного сигнала у обоих модемов видимого результата не дает, также как заземление экрана линии (кабель КММ-4, 200 метров до распред. розетки). Ретрейнов во время соединения нет.
Пожалуйста, посоветуйте как обойти данную проблему. Заранее благодарен.
Рабочий профиль модемов:
B1 E0 L2 M1 N1(0) P Q1 V1 W1 X4 Y0 &C0 &D0 &G0 &J0 &K0 &Q6 &R1 &S0 &T5 &X0 &Y0
S00:008 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:090 S08:002 S09:006
S10:014 S11:095 S12:050 S13:000 S17:072 S18:000 S25:005 S26:001 S36:007 S37:006
S38:020 S46:138 S48:007 S91:009 S92:009 S95:000
И еще один вопрос. Оборудование, подключаемое к модему, имеет достаточно сложный протокол обмена данными и таймаут на прием символов порядка 0,3 с. Есть ли средства управления потоком данных, выдаваемых модемом в порт? Можно ли с гарантировать соблюдение данного условия? |
|
| Вернуться к началу |
|
 |
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Окт 23, 2004 3:24 pm Заголовок сообщения: |
|
|
Последовательность действий такая:
1. Подключить вместо целевых устройств компьютеры, запустить терминальные программы и настроить их на такую же скорость передачи и формат символа, которые будут в целевых устройствах (например, 2400 бит/с, 8 бит в символе, без контроля чётности, 1 стоп-бит).
2. Выдать обеим модемам команды:
at *nc22 w2 \v1 s95=3 &w &w1
OK
Это сбросит модемы в "исходное" (т.е. заводское) состояние.
3. Теперь можно попробовать установить соединение. Для этого одному модему выдаётся команда:
atdp номер
а другому:
at s0=1
OK
(включается режим автоответа). Проконтролировать, что соединение устанавливается, убедиться в наличии протокола коррекции ошибок, попробовать передать/принять файл (т.е. убедиться в том, что есть устойчивая и надёжная связь). При необходимости - подстроить модемы (в т.ч. и с нашей помощью, показав статистику).
4. Добавляете установки, необходимые для работы целевых устройств (dumb-режим, игнорирование DTR, управление потоком и т.п.). Процедура такая (пример):
atz
OK
at s15.7=1
OK
at &w
OK
В промежутке между первой командой (atz) и последней (at &w) можно выполнить любое количество команд, которое потребуется для настройки всех нужных параметров.
Обратите внимание, что настройка порта в терминальной программе должна совпадать с настройками в целевой системе.
Если Вы подозреваете, что "мусор" появляется из-за отсутствия протокола коррекции ошибок, заставьте модем соединяться только с протоколом коррекции (например, командой at\n2).
Вот, пожалуй, и всё.
| Цитата: |
И еще один вопрос. Оборудование, подключаемое к модему, имеет достаточно сложный протокол обмена данными и таймаут на прием символов порядка 0,3 с. Есть ли средства управления потоком данных, выдаваемых модемом в порт? Можно ли с гарантировать соблюдение данного условия?
|
Управление потоком данных, естественно, используется (посмотрите описание команды &Kn). Но кажется, Вы на самом деле ищете ответ на другой вопрос, а именно: "Можно ли гарантировать, что символ, переданный целевым устройством номер 1, появится на входе устройства номер 2 не позднее, чем через 300 мс?". Ответ на этот вопрос отрицательный. При использовании протокола коррекции ошибок при возникновении помехи в канале и разрушении информации в кадре данных модему придётся повторно послать этот кадр. Время, затраченное на исправление ошибки, может быть больше 300 мс.
Если отказаться от протокола коррекции ошибок, то символ гарантированно появится на другом конце линии за 300 мс. Однако, в этом случае нет гарантии, что это будет тот же самый символ (он может исказиться в процессе передачи). И более того, может появиться "пачка" случайных символов (результат демодуляции искажённого сигнала).
Лучше всего, конечно, изменить протокол общения с целевым устройством таким образом, чтобы он допускал более длительные задержки. Если же это невозможно, то придётся подбирать скорость передачи в линии таким образом, чтобы задержки были минимальны (при большей скорости обмена и использовании, например, протокола V.32bis или V.34 задержки могут оказаться меньше). И молиться о том, чтобы сеанс связи с устройством прошёл удачно. Другого не дано.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Father
Junior member
Зарегистрирован: 23.10.2004
Сообщения: 4
|
| Добавлено: Пн Окт 25, 2004 11:02 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | Последовательность действий такая:
Если Вы подозреваете, что "мусор" появляется из-за отсутствия протокола коррекции ошибок, заставьте модем соединяться только с протоколом коррекции (например, командой at\n2).
|
Видимо, причина на самом деле в отсутствии корекции ошибок. При разрешении MNP или V.42 "шум" исчезает.
| Цитата: |
Но кажется, Вы на самом деле ищете ответ на другой вопрос, а именно: "Можно ли гарантировать, что символ, переданный целевым устройством номер 1, появится на входе устройства номер 2 не позднее, чем через 300 мс?"
|
Не совсем. Имеется в виду, что интервал между байтами, выдаваемыми удаленным модемом в порт в рамках одной посылки, переданной ПК через локальный модем, не превысит этого значения. При этом длина посылки существенно меньше кадров протоколов коррекции и составляет 15-20 байт.
| Цитата: |
Лучше всего, конечно, изменить протокол общения с целевым устройством таким образом, чтобы он допускал более длительные задержки. Если же это невозможно, то придётся подбирать скорость передачи в линии таким образом, чтобы задержки были минимальны (при большей скорости обмена и использовании, например, протокола V.32bis или V.34 задержки могут оказаться меньше). И молиться о том, чтобы сеанс связи с устройством прошёл удачно. Другого не дано. |
А возможно ли применение модуляции V.32bis или V.34, если устройство и модем работают только на скорости 2400 ? Настройка модема с помощью команды at +ms=... эффекта не дала- соединение по-прежнему идет на модуляции v.22bis. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пн Окт 25, 2004 11:58 am Заголовок сообщения: |
|
|
| Цитата: |
Имеется в виду, что интервал между байтами, выдаваемыми удаленным модемом в порт в рамках одной посылки, переданной ПК через локальный модем, не превысит этого значения. При этом длина посылки существенно меньше кадров протоколов коррекции и составляет 15-20 байт.
|
Весьма велика вероятность того, что все байты "посылки" попадут в один кадр данных и соответственно, будут выданы в удалённое устройство с максимальной скоростью (при установке порта в 2400 бит/с, 8 бит в символе, без контроля чётности и 1 стоп-бит данные будут выдаваться со скоростью 240 байт/с, и промежуток между получением двух "соседних" байт данных составит чуть более 4 мс).
Однако, гарантировать попадание всей посылки в один кадр нельзя. Соответственно, более длительные (чем 4.2 мс) задержки между байтами одной посылки возможны, хотя и маловероятны.
| Цитата: |
А возможно ли применение модуляции V.32bis или V.34, если устройство и модем работают только на скорости 2400 ?
|
Начиная с версии 2.20, невозможны. Вот цитата из whatsnew к этой версии:
| Код: |
3. Скорость в линии (DCE) будет автоматически ограничиваться при ограни-
чении скорости порта DTE:
Скорость DTE Макс. скорость DCE Протокол
---------------------------------------------
300 300 V.21
1200 1200 V.22bis
2400 2400 V.22bis
4800 4800 V.32bis
9600 9600 V.32bis
19200 19200 V.34bis
38400 37333 V.90
57600 и выше н е т о г р а н и ч е н и й
|
Так что придётся либо довольствоваться тем, что есть, либо пользоваться более старой версией микропрограммы.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Father
Junior member
Зарегистрирован: 23.10.2004
Сообщения: 4
|
| Добавлено: Чт Окт 28, 2004 2:29 pm Заголовок сообщения: |
|
|
| Цитата: |
Весьма велика вероятность того, что все байты "посылки" попадут в один кадр данных и соответственно, будут выданы в удалённое устройство с максимальной скоростью (при установке порта в 2400 бит/с, 8 бит в символе, без контроля чётности и 1 стоп-бит данные будут выдаваться со скоростью 240 байт/с, и промежуток между получением двух "соседних" байт данных составит чуть более 4 мс).
Однако, гарантировать попадание всей посылки в один кадр нельзя. Соответственно, более длительные (чем 4.2 мс) задержки между байтами одной посылки возможны, хотя и маловероятны.
|
Большое спасибо за помощь!
Что касается потока символов, выдаваемых в порт, то у модемов здесь все в порядке- задержка между стоп-битом предыдущего и старт-битом последующего символа составляет единицы мкс.
Правда, пришлось перенастраивать таймауты в ПО, работающем с устройствами, поскольку работа идет только на модуляции v22.bis |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Чт Окт 28, 2004 4:41 pm Заголовок сообщения: |
|
|
Самое главное то, что всё работает 
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Father
Junior member
Зарегистрирован: 23.10.2004
Сообщения: 4
|
| Добавлено: Пт Окт 29, 2004 3:14 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Самое главное то, что всё работает |
Увы, это не совсем так.  Примерно в 50% случаях удаленный модем "зависает" в процессе установления соединения. Как правило, это происходит либо в сразу после снятия им трубки, либо в конце процедуры соединения. Разрыв связи локальным модемом не помогает, удаленный модем трубку не кладет. Находится в этом состоянии он может бесконечно долго.
В тех случаях, когда удается инициировать обмен данными, он идет не вполне устойчиво. Статистика одного из таких соединений следующая:
Unimodem Diagnostics/W32, version 1.1.0.1, compiled at Nov 20 2002 22:29:14
(c) 2000 Stanislav V. Mekhanoshin (rampitec@tu.spb.ru, 2:5030/172.9@fidonet)
----------------------------------------------------------------------------
Diag Command Specification rev.: 1.0
Call Setup Result code : Data Answering signal detected
Multi-media mode : Data Only
DTE-DCE interface mode : Async data
TX/RX signal power level, -dBm : 9/24
Estimated noise level, -dBm : 100
TX/RX Negotiation : V.22bis/V.22bis
TX/RX Symbol Rate : 1600/1600
TX/RX Carrier frequency, Hz : 1600/1600
TX data rate (Last/Init) : 2400/2400
RX data rate (Last/Init) : 2400/2400
Temporary carrier loss count : 0
Carrier Rate Re-neg count : 0
Retrains Requested/Granted : 0/0
Protocol/Compression : V.42 LAPM/V.42bis
Error control frame size, bytes: 128
Error control timeouts in TX : 0
Error control NAKs received : 0
Compression dict. size, bytes : 2048
TX/RX flow control : V.24 ckt 106/133 / V.24 ckt 106/133
TX/RX chars sent : 960/5989
TX/RX chars lost (data overrun): 0/0
TX/RX I-Frame count : 113/238
TX/RX I-Frame error count : 0/16
Termination Cause : cct108 turned Off
Пожалуйста посоветуйте, как решить проблему.
Заранее благодарен. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Окт 29, 2004 3:35 pm Заголовок сообщения: |
|
|
В такой ситуации нужно "отделить мух от котлет". Пожалуйста, вернитесь к рекомендациям, данным в самом первом ответе в этой теме. Сбросьте модемы, отрегулируйте соединение и обмен данными в терминалке.
Если модем не реагирует на пропадание несущей, "научите" его реагировать, уменьшая значение регистра S10.
В приведённой Вами статистике довольно высокий процент ошибок на приём:
TX/RX I-Frame count : 113/238
TX/RX I-Frame error count : 0/16
16 / 238 * 100% = 6.72%
Возможно, это было вызвано простоями (т.е. канал был мало загружен). Возможно, что сама линия в очень плохом состоянии, и эти сбои - результат помех. В этом случае может помочь увеличение значения регистра S91 этого (т.е. того, который принимал данные) модема... попробуйте S91=12..15.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
