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

Однако, очень часто дело обстоит совершенно иначе, и через некоторое время после покупки многих ждет разочарование: заявленные на сайте характеристики оказались не соответствующими действительности; поверхностный обзор в Интернете не выявил ни единой ошибки, несмотря на обильное наличие оных в реальных условиях; редакция журнала, присвоившая свой "выбор" изделию, хоть и обмолвилась, что для преодоления ограничения скорости 31200 бит/с необходимо "редактирование драйвера", на деле ничем не может помочь в решении этой проблемы. К кому же обратиться пользователю? Где все те, кто громко призывал его к покупке, и кто теперь не хочет или, что более вероятно, не может ему помочь с конкретными возникшими проблемами? Как может пользователь в такой ситуации не считать себя "пострадавшим"?

Глоссарий

Текст данного FAQ насыщен техническими терминами, которые начинающим бывают не всегда понятны. Разбор и объяснение займут гораздо больший по объёму документ. Для лучшего понимания терминов советуем ознакомиться со следующей ссылкой:

http://www.flashcom.ru/html/modems/termhs.shtml

1. Вопpосы по пpиобpетению модемов.

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

Согласно правилам торговли такое оборудование продавать нельзя. Поэтому, если организация, продавшая Вам модем, отказывается сделать возврат денег (в том случае, если модем Вас категорически не устроил в первые же дни после покупки), Вы можете обратиться Госторгинспекцию по факту торговли контрафактным товаром без российского Сертификата соответствия. Можно обратиться и в милицию (отдел по борьбе с экономическими преступлениями): в этом случае произошедшее с Вами дает основания для заведения уголовного дела против продавца по факту мошенничества. Естественно, не обязательно сразу бросаться применять сии строгие меры.

Q1.3. Могут ли эти модемы продаваться без документации и сопутствующего firmware в так называемом OEM виде?

OEM поставки предназначены для крупных производителей компьютеров. Если они и комплектуются сопутствующим программным обеспечением и документацией, то только одним на целую партию. Соответственно и стоимость конечных продуктов получается ниже, чем у Retail. Этим и пользуются отечественные дельцы, стремящиеся получить максимальную прибыль независимо от интересов потребителя. Продавец на такое оборудование либо устанавливает сроки гарантийных обязательств по своему усмотрению, либо вообще отказывается их выполнять. Всё это является прямым обманом покупателя, поэтому избегайте покупок OEM, а в крайнем случае требуйте последние версии драйверов и документацию хотя бы в электронном виде.

Q1.4 Назовите, пожалуйста, официальных представителей в России, занимающихся импортом таких модемов.

Модемы на чипсете Lucent 1646 изготавливаются многими фирмами. Поэтому говорить об официальных представителях всего парка модемов на этом чипсете крайне сложно. В сети русскоязычного интернета Вы можете найти, например, сайт http://www.genius.ru/ В отличие от представительств, например IDC или ZyXEL, никакой деятельности по поддержке пользователей, исправлению ошибок в модемах и улучшению адаптации продуктов данные "представители" не ведут. Ими осуществляются только простейшие рекламно-торговые функции.

Q1.5 Существуют ли альтернативные варианты при выборе модема на чипсете Lucent 1646?

Любое техническое решение имеет альтернативные варианты. Даже в рамках выпускаемых моделей на Lucent 1646 есть модемы разных фирм с разными возможностями и, соответственно, стоимостью. При выборе этих модемов следует обратить особое внимание на наличие/отсутствие разъемов для подключения наушников и микрофона, иначе модем нельзя будет использовать в качестве спикерфона (телефона). Кроме того, наличие специализированного аудиокодека CSP1027 позволяет пользоваться всеми голосовыми функциями и расширяет возможности модема при применении в качестве факса, спикерфона, автоответчика. С другой стороны, при выборе модема на чипсете Lucent 1646 не следует забывать, что наличие одного и того же чипсета порождает у разных модемов одни и те же ошибки, ведь используется одна и та же "базовая" версия драйверов от Lucent 1646. Сравнение с модемами других фирм не входит в задачу этого FAQ, но по числу выявленных ошибок controllerless модемы на Lucent 1646 занимают отнюдь не лучшую позицию.

2. Вопросы относительно аппаратной части модема

Q2.1 Можно ли обеспечить защиту этого модема от внешних пеpенапpяжений, во избежании выхода его из строя?

Поскольку модем выполнен по максимально упрощённой схеме, в нём отсутствуют средства защиты от перегрузок в телефонной сети. Поэтому любое перенапряжение может вывести из строя входные цепи, и не только их.

Q2.2 Модем отказывается набирать номер. Можно ли его отремонтировать путем замены наборного реле?

В модемах на чипсете Lucent 1646 для набора телефонного номера могут использоваться различные схемотехнические решения. Если это механическое наборное реле, то возможна его замена. Если же коммутация осуществляется оптронами, то в случае выхода из строя входных цепей и нарушения гальванической развязки с чипом, сам чип нуждается в замене. Естественно, никто этим заниматься не будет, поскольку затраты на "операцию" соизмеримы со стоимостью модема.

Q2.3 Можно ли улучшить модем путём восстановления симметрирующих цепей?

Прежде чем ответить на этот вопрос, посмотрите на схему включения конденсаторов С1, С2 и С3. Даже беглого взгляда достаточно, для того, чтобы определить их назначение - симметрирование входного сигнала относительно земли модема. Естественно, что в комбинации с дросселями L1 и L2 получается цепочка, неминуемо вносящие искажения в АЧХ и ФЧХ модема. Несмотря на то, что любые реактивные элементы вносят эффект фильтрации, назвать эту цепь фильтром НЧ нельзя. Если же говорить о необходимости фильтра на входе модема, то необходимо вспомнить о том, что любые простейшие фильтры пагубно сказываются на работе эквалайзера (при приёме) и скремблера (при передаче), в задачу которых входят процессы коррекции АЧХ и ФЧХ.

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

Основное пагубное воздействие при отсутствии возможности отключения параллельного телефона заключается в том, что любой телефон имеет собственную ёмкость, а она, в свою очередь, может сильно исказить АЧХ линии с завалом в области высоких частот. Наибольшей ёмкостью, вносящей подобные искажения, обладают дешёвые китайские телефоны-трубки, а также старые телефоны с дисковым набором номера. Проконтролировать вид АЧХ в модемах на чипсете Lucent 1646 нет возможности, поэтому для её запроса придётся на время "вооружиться" модемом, позволяющим это делать, например, IDC-2814 BXL+, практически любым модемом на 33600 или 56000 фирмы U.S.Robotics, ZYXEL Omni 56К. Сразу следует отметить, что искажения АЧХ могут вносить не только телефонные аппараты, но и конденсаторы в розетках, собственная ёмкость и индуктивность линии связи, особенно при большом расстоянии до АТС. Проведите связь с подключенным параллельно телефоном и без него и проанализируйте полученную АЧХ. Если завал амплитуды сигнала в области высоких частот полосы пропускания значителен, то отключайте параллельные телефоны во время проведения связей, если нет, то можно всё оставить как есть, хотя отключение в любом случае должно благоприятно сказываться на качестве.

3. Вопросы настройки модема под конкретную линию

Q3.1 Почему в документации по модему не предусмотрена максимальная скорость 56000, согласно стандартам ITU-T?

Вероятно, разработчики драйверов реально оценили возможности модема и не смогли добиться на нём максимальной скорости, регламентируемой V.90. Более того, в ранних версиях драйверов эта скорость была ограничена на уровне 53333.

Это фирменная ошибка драйверов для Lucent'ов. Попытки избавиться от нее предпринимаются разработчиками начиная с версии драйвера 5.75. Суть этого явления состоит в том, что на этапе хэндшейка модем сначала слишком оптимистично выбирает скорость коннекта, но потом, поняв, что не способен удержаться на этой скорости, делает ретрейн с Fall Back сразу на несколько ступенек вниз. "Любимой" скоростью для Lucent'ов стала именно 37333. Тут, глядишь, и чуть выше чем 33600, а с другой стороны, пользователь зачастую и не подозревает, что его модем работает намного хуже, чем кажется владельцу, поскольку многие программы показывают только первоначально зафиксированную битовую скорость. В драйверах версии 5.75 этот недостаток был устранён, но за счет того, что модем вообще стал отказываться коннектится на V.90 при малейшем подозрении на шумы и импульсные помехи в линии, к тому же в этой версии наиболее сильно проявляется "синдром 31200" (см. п. 3.4) Начиная с версии драйверов 5.92 ,была предпринята попытка поднять планку до 41333, и надо отдать должное, что так и получилось. Но кроме того появилась ещё одна "неудобная" скорость 29333. Осталась и злосчастная 37333. В итоге трудно дать гарантию, что по причине вышеописанного механизма модем будет работать именно на 41333, а не на 37333 или 29333.

В модемах на чипсете Lucent 1646 склонность к ретрейнам объясняется весьма непростым механизмом, и основу этого механизма составляет отсутствие возможности простого запроса пересогласования скоростей. Поэтому при любом изменении помеховой обстановки в линии модем выполняет перетренировку (retrain). Эта процедура занимает достаточно продолжительное время и в конечном итоге неминуемо ведёт к общей потере CPS. Запрещать ретрейны нет смысла. Почему? Посмотрите внимательно документацию и Вы не найдете отдельной команды принудительного запрета ретрейнов для высокоскоростных протоколов. Она просто не предусмотрена. Зато есть команда %En, отвечающая как за включение/отключение ретрейнов, так одновременно и за включение/отключение процедур Fallback/Fall Forward. Запрет не позволит модему адаптироваться к линии при прохождении помех, и он обязательно разорвет связь.

Источник проблемы - печально известный "синдром 31200". Суть явления в двух словах: после первого пересогласования скорости удаленным модемом Lucent 1646 запрещает использование линейной скорости 31200. Если же произошел ретрейн, то модем перестает использовать максимальную скорость модуляции, оставаясь ограниченным опять же скоростью 31200. Скорость 33600 будет исчезать всегда, когда за время сеанса произошло хотя бы одно пересогласование скорости или ретрейн - в статистике об этом будет свидетельствовать ненулевое значение счетчиков Retrain by Local Modem или Retrain by Remote Modem.

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

Метод обхода проблемы: после начала связи необходимо перевести Lucent 1646 в командный режим, +++ в любом терминале, после чего заставить выполнить ретрейн с возвратом в режим данных командой ato1. После этой манипуляции модем уже не забудет ни про линейную скорость 33600, ни про максимальную модуляционную скорость.

В большинстве случаев следствием этой манипуляции является увеличение линейной скорости и эффективной скорости передачи данных, и, что очень важно, даже на тех линиях, где линейные скорости 28800-33600 не достигаются.

Способ не даст прироста эффективной скорости, если линия по своим физическим параметрам не позволяет модемам использовать максимальную скорость модуляции. Однако, чтобы убедиться в этом, необходим модем с полноценной статистикой, в которой можно увидеть, какие модуляционные скорости вообще могут использоваться. В статистике Lucent 1646, выводимой по at#ud, эта цифра слишком часто неверна, и потому не вызывает доверия. А вот если в статистике тех же USR, IDC или ZyXEL мы видим (хотя бы иногда) TX/RX Symbol Rate 3429 символов/с, способ будет полезен. В противном случае пользы не будет, хотя и вреда тоже.

Однако, как и у любого другого способа с латанием дыр, оставленных разработчиками Lucent 1646, возможны негативные эффекты: в том случае, если линия изобилует помехами, вызывающими частые ретрейны, принудительное расширение круга выбираемых модемом скоростей может привести к упоминающемуся ниже (см. п. 4.2) обрыву связи после трех ретрейнов. Если такая ситуация возникает, то использовать способ не стоит.

Q3.5 Как на практике воспользоваться методом перехода в командный режим и обратно при подключении к Интернету в Windows?

Рассмотрим на примере самого тривиального "Удаленного доступа". Открываем эту самую папку нажатием правой кнопки мыши на значке с требуемым подключением выбираем его "Свойства". В открывшемся окошке нажимаем кнопку "Настройка". В следующем открывшемся окне выбираем закладку "Параметры". В "Параметрах" активируем check box "Открыть окно терминала после набора номера". Сохраняем сделанные изменения. Далее все как обычно: запускаем соединение - после установки связи всплывет окно терминала. Теперь, при активном окне, жмем быстро "+++" и пишем латинскими буквами ato1, "Enter". Пишем вслепую, ибо символы не отображаются. Достигнут ли результат, легко узнать, если динамик модема включен - в случае успеха сразу после ввода команды последует ретрейн, а затем появится надпись "connect xxxxx". После этой манипуляции нажимаем кнопку "Продолжить" внизу терминального окна, дожидаемся проверки пароля и наслаждаемся плодами современных технологий.

Как добиться требуемого результата при использовании иных программ дозвона, предлагаем поразмыслить их владельцам.

Сначала следует заметить, что решётчатое кодирование предназначено в первую очередь для компенсации недостаточной помехоустойчивости многопозиционной квадратурно-амплитудной модуляции. Поскольку неподготовленному читателю очень тяжело понять сию научную формулировку, выразим её более просто: если при связи не применять этот специфичный вид свёрточного кодирования, то связь модемов невозможна. Чем выше разрядность такого кодирования, тем выше помехоустойчивость модема. В настоящее время в модемах могут применяться различные типы свёрточного кодирования. Это - 8-ми (только на низкоскоростных протоколах), 16-ти (в простейших модемах), 32-x и 64-х разрядное кодирование. В модемах на чипсете Lucent 1646 на высокоскоростных протоколах может быть применена только 16-ти позиционная схема. Увы, в процессе написания драйверов видимо вкралась ошибка, в результате которой при возникновении импульсных помех на этапе перетренировки модем пытается соединиться без применения свёрточного кодирования и тут же рвёт связь. Пользователь модема не имеет возможности увидеть, как это произошло и грешит на неблагоприятную обстановку. И это, в общем-то, верно, точную же причину можно выяснить, только просмотрев параметры диагностики удалённого модема. Удалённый модем должен уметь выводить данные "Trellis Coded Modulation", где в подобном случае вместо ожидаемых 16S-4D будет стоять NONE. Всплывает эта ошибка нечасто (в противном случае модемы вообще бы не соединялись), а вот предсказать её появление практически невозможно, как нельзя найти и способ устранения : всё зависит только от того, исправят ли разработчики драйверов её в будущем.

Q3.7 Объясните, пожалуйста, как научить модем ловить BUSY, если смена стpаны не помогает?

Обычно в модемах предусмотрена возможность смены страны для адаптации под те стандарты сигналов АТС, которые в этой стране приняты. В модемах на чипсете от Lucent 1646 такая возможность также предусмотрена, причём для FF (256) стран, но реально этот список намного меньше. Для того, чтобы убедиться в этом, войдите в терминал, а затем выполните следующую последовательность команд:

at%t19,0,country_code in HEX (здесь "country_code in HEX" - любое число в шестнадцатеричной системе исчисления в диапазоне от 0 до FF)
Убедитесь, что смена страны произошла: ati9
Посмотрите соответствующее содержание таблицы контроля и отладки параметров по командам at%t22,par# Параметры распознавания занято:

11 - минимальное время сигнала в мсек.

12 - максимальное время сигнала в мсек.

13 - число сигналов, через которое происходит индикация BUSY

14 - минимальное время паузы между сигналами в мсек.

15 - максимальное время паузы между сигналами в мсек.

Если у Вас по ati9 индицируется Russia, то отклики на вышеперечисленные команды будут 00. Не пугайтесь, это включён так называемый алгоритм детектирования, который одинаков что для России, что для Индии, что для Панамы. Просто разработчики считают нашу страну эквивалентной, и, мол, для всех подобных стран сойдёт и стандартный алгоритм.

Из всего сказанного можно сделать вывод - устанавливать страну Россия для правильного распознавания BUSY нет смысла. Если у Вас есть проблемы, то попробуйте поставить одну из 24х стран, приводимых в документации к модемам на чипсете Lucent 1646, предварительно ознакомившись с данными из таблиц. Можно установить значения сигналов и пауз, взгромоздив их в строку инициализации с помощью команды at%t21,par#,param_value.

Q3.8 После набора номера и до начала соединения модем издает странные сигналы, напоминающие гудки АТС - что это?

Это дополнительная служебная сигнализация, т.н. Calling Tones. Используется "по умолчанию" в некоторых странах. Почему разработчики решили, что это нужно в России, неизвестно. Скорее всего, причина в том, что "российские" настройки просто скопированы один к одному из профайла какой-то другой страны. Так или иначе, пользы от этой сигнализации нет, и ее стоит отключить. Это можно сделать или командой at-c0, или регистром s35=0.

Это очередная ошибка в драйвере. Если происходит ретрейн на V.90, результатом которого станет уход на протокол V.34, модем начинает считать, что установлена m1. Если после этого перевести модем в командный режим, и повторить команду atm2, все нормализуется. Однако, при связи с Интернетом с использованием ОС Windows это сделать невозможно. Рекомендуется отнестись к этой ошибке философски. Оптимисты могут рассматривать ее как некий "звуковой индикатор ухода на V.34": раз звук исчез, то это уже не V.90 - может быть, перезвонить и установить соединение заново?

Q3.10 Как избавиться от падения CPS при увеличенной загрузке CPU, например, при переключении задач?

Ваши проблемы связаны с увеличенной загрузкой CPU компьютера, его ОЗУ и синхронизацией PCI шины. Любой неполноценный модем подвержен этим проблемам. Суть сводится к тому, что Windows не является OS реального времени, а вот модему просто необходимо работать в режиме реального для обеспечения не только задач синхронизации при передаче сигнала и выделения тактовой частоты из принимаемого сигнала, но и для обработки блоков данных на канальном уровне (подсчет контрольной суммы принимаемых кадров, реакция на командные кадры удаленного модема и т.п.). Запуск ресурсоёмких задач ведёт к нарушению синхронизации и при этом возможно падение CPS. Производители различных неполноценных модемов всеми силами борются с этим очевидным недостатком, и эта борьба идёт сразу по нескольким направлениям. Тут и совершенствование аппаратной части, тут и совершенствование firmware, тут и выделение приоритета именно модему. Увы, даже весь комплекс мер бывает неспособен обеспечить приемлемое функционирование модема. Наверное, не нужно убеждать пользователя, что запуск LPT сканера с высоким разрешением может не просто снизить CPS у работающего модема, но и вообще явиться причиной разрыва связи.

Есть ещё один интересный момент, который очень часто не учитывают начинающие пользователи. Очень часто слышатся заявления о небывалых значениях CPS, измеренных при приёме пакованных файлов с помощью программ докачки типа ReGet, Net Vampire и.т.п Эти заявления ошибочны по двум причинам. Во-первых, многие из подобного рода программ измеряют не CPS (число символов в секунду), а BPS (число бит в секунду). Ведь не предусмотрены же в этих программах установки модема и аналогичные измерения проводятся и при использовании локальной сети. Во-вторых, увеличение загрузки CPU в Windows'е приводит к искажениям откликов по времени, что проявляется в уменьшении знаменателя в расчетах измеряющих программ, и кажущемуся повышению скорости.

Модемы на чипсете Luсеnt 1646 крайне чувствительны к загрузке CPU. Причём чем ниже быстродействие CPU, тем выше получается его загрузка модемом. Объём ОЗУ, несмотря на относительно небольшой размер блока от драйверов модема, также играет не последнюю роль. Нельзя забывать и про то, что медленный процессор обычно сожительствует с небольшим объёмом оперативной памяти, а на их ресурсы покушаются не только модем, но и другие задачи. Исходя из этого, можно сказать, что "рекомендации" возможности работы модемов на чипсете Lucent 1646 с процессором типа 486DX5-133 не иначе как вредными не назовешь.

Таких команд на самом деле очень немного. Перечислим их (без указания значений параметра):

s37 - ограничение скорости на протоколе V.34

-v90 - ограничение скорости (или запрет) протокола V.90

s38 - ограничение скорости (или запрет) протокола K56Flex

s28 - запрет/разрешение работы V.34

\n - выбор (или отключение) протокола коррекции ошибок: MNP, V.42.

ati11 - статистика последнего сеанса связи

at%t21,2f - регулировка уровня мощности сигнала передатчика

at%t21 - другие параметры этой команды помогают настроить распознавание сигналов АТС.

Остальные команды или бесполезны, или не работают:

\a - ограничение размера кадра протокола MNP: заявлено, но не работает.

Q3.12 Каким образом осуществить запрет (разрешение) символьных скоростей?

В модемах на чипсете Lucent 1646 такая возможность отсутствует. Правда, если не следовать рекомендациям по обходу ошибки "синдрома 31200" (п.3.4) и после начала связи вызвать ретрейн искусственной помехой - например, подключить к модему телефон и на пару секунд снять на нем трубку, - то таким образом можно запретить верхнюю символьную скорость - 3429 символов/секунду.

Q3.13 Почему переход на новую версию драйверов ничего не изменил в работе модема?

Совершенно не обязательно должно было что-то измениться в Вашем конкретном случае. Если почитать анонсы к каждой версии выходящего драйвера, то несложно заметить, что более половины проблем, решение которых обещано в "свежей" версии, относится к разряду ошибок при взаимодействии модема с конкретной ОС - совершенно не обязательно той, что стоит у Вас. Исправляются ошибки в работе виртуального порта, проблемы "с засыпанием" компьютера, возникающие "зависания" системы и прочее. Для всех разработчиков программных модемов (и Lucent здесь не исключение) эти проблемы имеют высший приоритет. Еще около трети содержания анонсов занимают общие фразы, начинающиеся со слов "Улучшено(а)...". Что конкретно улучшено (и как), нужно проверять. Возможно, улучшено распознавание RBS-сигнализации, применяемой в США, и Вам от этого не будет ни тепло, ни холодно. Исправление явных ошибок в работе протоколов связи и самого модема происходит крайне редко, и, как следствие, в редких версиях об этом сообщается.

В некоторых случаях изменения в работе все же могут появится, но далеко не всегда это будут изменения в лучшую сторону. Если все-таки с очередной версией драйвера стали заметны улучшения, подтверждением которых может послужить статистика сеансов с разными версиями драйвера, стоит считать это выигрышем в лотерее: оставьте эту версию драйвера. Если же модем стал работать хуже, или же появились ошибки, ранее не возникавшие, то стоит вернуться к ранее работавшей версии. Для того, чтобы корректно деинсталлировать "непонравившийся" драйвер, закройте все приложения и запустите утилиту ltremove.exe из комплекта драйверов. Возможно использование утилиты из более нового комплекта драйверов для удаления драйверов старых версий. Единственное, что стоит иметь в виду - если на Вашем компьютере установлены другие модемы, то в момент деинсталляции люцентовских драйверов прочие модемы тоже будут удалены. После деинсталляции запустите систему вновь и на этапе, когда Windows обнаружит Lucent 1646, предложите ей милую Вашему сердцу версию драйверов. Тем же путем установите другие требуемые Вам модемы.

Q3.14 Почему регулировка уровня выходного сигнала ни к чему не приводит?

Для того, чтобы убедиться, в том, что Ваших настройках модема предусмотрена регулировка уровня выходного сигнала, проконтролируйте непосредственно перед проведением связи значение at%t22,2f. Если полученное вами шестнадцатеричное число не соответствует ранее предусмотренному, то ищите ошибку. Вероятно, Вам не помогли "хитрые" строчки инициализации или предварительная правка .inf файла.

Кроме того, благодаря процедуре Power Drop модем может изменить уровень выходного сигнала сразу после начала сеанса связи, и здесь Вы ничем ему помочь не сможете, поскольку отключение этой процедуры у модемов на чипсете Lucent 1646 не предусмотрено. Более подробно вопрос регулирования уровня выходного сигнала см. в п.4.3.

Это проблема не вашего модема, а названных. Дело в том, что в полноценных модемах от Motorola и Eline 33600 на чипсете Davicom нестандартным образом реализован протокол согласования V.8, который отвечает за первоначальный этап установки связи. Если происходит попытка установки связи с модемами, поддерживающими 56K протоколы, то проба посылки запроса о возможности работы на 56K от вашего модема приводит к разрыву связи. Выход из положения прост: запретите вашему модему все 56K протоколы при установке связи. Это можно сделать на этапе инициализации модема (тогда 56К будут запрещены при связи с любыми модемами), или на этапе набора номера: например, AT-V90=0S38=0P(T)XXXXXXXX

Здесь XXXXXXXX - набираемый телефонный номер, а P или T выставляется в зависимости от способа набора: пульсовый/тоновый.

Q3.16 Почему при звонке с удаленного модема на мой во время использования CallBack не устанавливается соединение на протоколе V90?

Это говорит о том, что Вы используете драйверы с ранним номером версии. Ошибка, связанная с невозможностью установить соединение на V.90 при входящем звонке, исправлена в драйвере версии 5.97.

Q3.17 С какими особенностями работы модема придётся столкнуться при установке фоссила?

Начнём с того, что современный фоссил (fossil) - это гибкий специализированный коммуникационный драйвер, предназначенный для разгрузки работы последовательного порта, установки соответствия между логическими и физическими портами, установки и фиксирования скорости, а также изменения буферов приёма и передачи с возможностью их динамического обновления по размеру. Наиболее часто фоссил используют коммуникационные программы, предназначенные для работы в сети Fidonet, например, WinFossil .

Применение фоссила совместно с модемами на чипсете Lucent 1646 имеет свои положительные и отрицательные стороны.

К положительным следует отнести возможность работы модема в DOS сессии при любой версии драйверов. Кроме того, появляется возможность корректного снятия статистик в DOS ориентированных терминальных программах. Более того, несмотря на переинициализацию модема, сохраняются данные статистики связи после последней проведённой сессии. Последнее положение справедливо только для вышеуказанного фоссила и именно только с модемами на Lucent 1646.

К отрицательным моментам относится дополнительная нагрузка на CPU и вероятность нарушения синхронизации, особенно в моменты динамического изменения размера буферов приёма и передачи, что в конечном итоге может неблагоприятно сказаться на общем уровне CPS.

4. Вопpосы по анализу статистик и диагностике модема.

Q4.1. Как посмотреть статистику сеанса связи?

Статистика выводится командой ati11. Следует иметь в виду, что с последними версиями драйвера (начиная с версии 5.70) далеко не все терминальные программы позволяют вывести информацию по ati11. Посмотреть ее можно, в частности, в Гипертерминале из стандартной поставки Windows, в большинстве же ДОС приложений без применения специализированных фоссилов (см. п3.17) это не получится. Для того, чтобы цифры в статистике соответствовали действительности, снимать ее стоит после нормального завершения сеанса связи (отключения пользователем), при этом важно, чтобы в момент отключения модема от линии не проходил ретрейн. При просмотре статистики в "онлайне" цифры, показываемые модемом в период ретрейнов, также не соответствуют действительности.

Для того, чтобы использовать данные статистики для дальнейшей настройки модема или анализа условий связи, необходимо, чтобы статистика охватывала минимальный промежуток времени хотя бы в 5-6 минут, и при этом бы происходил прием данных, хотя бы 1 Мб сжатых файлов. В любом случае, чем больший период отражен в статистике, и чем больше данных принято, тем более объективные выводы можно будет сделать на основании этих данных.

Q4.2 Что значат параметры статистики?

Давайте посмотрим:

Description                         		Status
---------------                     		------------
1   	Last Connection                     	V.34
2   	Initial Transmit Carrier Rate       	7200
3    	Initial Receive  Carrier Rate       	9600
4    	Final   Transmit Carrier Rate       	9600
5    	Final   Receive  Carrier Rate 		16800 
6    	Protocol Negotiation Result   		LAPM
7    	Data Compression Result       		NONE
8    	Estimated Noise Level               	1276
9    	Receive  Signal Power Level  (-dBm) 	35
10   	Transmit Signal Power Level  (-dBm) 	18
11   	Round Trip Delay             (msec) 	3
    	Press any key to continue; ESC to quit.

Description                         		Status
---------------                     		------------
12	Near Echo Level              (-dBm)	34
13	Far  Echo Level              (-dBm) 	64
14	Transmit Frame Count                	3
15	Transmit Frame Error Count          	0
16	Receive  Frame Count                	3
17	Receive  Frame Error Count          	0
18	Retrain by Local  Modem             	2
19	Retrain by Remote Modem             	9
20	Call Termination Cause              	0
21	Robbed-Bit Signaling                	NA
22	Digital Loss                   (dB) 	NA
23	Remote Server ID                    	NA

Последний используемый протокол передачи.
Первоначально выбранная удаленным модемом (в начале сеанса) скорость передачи.
Первоначально выбранная локальным модемом (в начале сеанса) скорость на прием.
Текущая (или последняя, если статистика снимается после отключения от линии) скорость на передачу, выбранная удаленным модемом.
Текущая (или последняя, если статистика снимается после отключения от линии) скорость на прием, выбранная локальным модемом.
Используемый протокол коррекции ошибок, LAPM (V.42), MNP или NONE (в случае, если не удалось установить соединение с коррекцией ошибок).
Используемый протокол сжатия данных, V.42bis, MNP или NONE (если установлено соединение без сжатия данных)
Оценочный уровень шума в безразмерных единицах. Не несет смысловой нагрузки для пользователя.
Уровень мощности принимаемого сигнала, приблизительно соответствует истинному положению вещей на V.34. Не соответствует действительности и несет смысловой нагрузки на протоколе V.90
Уровень мощности сигнала передатчика, приблизительно соответствует истинному на V.34 и V.90.
Время прохождения сигнала по каналу.
Уровень "ближнего эхо" на входе модема. Смысловая нагрузка сомнительна, т.к. всё равно неизвестно, насколько успешно это эхо гасится далее соответствующими подсистемами модема. Работает только на V.34.
То же уровень "эхосигнала", но только "дальнего". Работает только на V.34.
Число отправленных модемом блоков данных (I-кадров) протокола канального уровня (V.42 или MNP).
Число запросов удаленного модема на повторную передачу блоков данных (I-кадров), начиная с определенного порядкового номера. Запрос приходит от удаленного модема в результате приема одного или более ошибочных блоков данных, в ответ на такой запрос заново посылается от одного до восьми блоков данных. Реальное число сбойных кадров, потребовавших повторной отправки, больше, нежели значение этого параметра.
Число принятых модемом блоков данных (I-кадров) протокола коррекции ошибок.
Число запросов локального модема на повторную передачу блоков данных (I-кадров), начиная с определенного порядкового номера. Как и в случае с запросами удаленной стороны, один такой запрос требует повторной передачи от одного до восьми блоков. Точное число повторно посланных ("ошибочных"^*) блоков можно увидеть в статистике удаленных модемов некоторых производителей.

^* Название параметра "Receive Frame Error Count" несколько неверно в контексте того, что выборочный перезапрос одного конкретного сбойного блока (SREJ) в модеме не реализован: даже если поврежден был только блок с номером N, а далее были приняты неповрежденные блоки N+1, N+2, то все равно потребуется повторная передача всех трех блоков. Следовательно, значение параметра, равное 2% от всего объема принятых I-кадров, снижает эффективную скорость приема отнюдь не 2% процента, как может показаться с первого взгляда.

^** максимальное значение счетчиков в пунктах 14, 15, 16, 17 ограничено числом 65535.

Число ретрейнов, запрошенных локальным модемом
Число ретрейнов и запросов на пересогласование скорости, запрошенных удаленным модемом.
Причина завершения или обрыва связи по версии производителя:

0 - модем получил локальную команду завершения связи.
1 - удаленный модем прислал команду завершения связи или была потеряна несущая.
2 - не удалось завершить (выполнить) процедуру установки связи.
3 - не удалось подобрать совместимый протокол коррекции ошибок.

Коды разъединения не проливают свет на истинные причины окончания сеанса связи. Характерный пример "неоднозначности" - пункт 1.^*

^* примечание: иногда причину разъединения можно узнать из статистики, выводимой по at#ud (хотя зачастую и там информация ошибочна). Рассматривать что-либо еще из статистики, выводимой по at#ud, не имеет смысла, т.к. остальные параметры или уже показаны в статистике по ati11 (и просто дублируются), или неверны. Данные, выводимые по команде at#ud, могут быть расшифрованы утилитой Станислава Механошина, последнюю версию которой можно взять здесь: ftp://ftp.inpro.us.com/utils.

Кроме того, в пункте Call Termination Cause встречаются явные ошибки. Например, в статистике по ati11 значится "0", на деле же произошел обрыв связи в момент ретрейна - данные по at#ud подтверждают это, и там причиной значится "Retrain Failed".

Количество кадров со служебной межстанционной сигнализацией в цифровом потоке T1. Определяется (и оказывает влияние) только при соединениях на V.90 и K56Flex. В России сигнализация подобного типа не используется (хотя модем и показывает иногда некие значения, отличные от нуля, это не соответствует действительности). Чем больше кадров занято служебной сигнализацией, тем меньшая скорость может быть обеспечена в сторону локального модема.
Величина ослабления входящего сигнала аппаратурой телефонной сети. Определяется только при соединениях на V.90 и K56Flex.
Служебная информация об удаленном серверном модеме (в том случае, если он поддерживает K56Flex). Отображается по результатам работы протокола согласования V.8bis - для получения параметра необходимо, чтобы регистр s38 у Lucent 1646 был не равен нулю.

Q4.3. Что же из данных представляет интерес и как можно влиять на ситуацию, располагая полученными данными?

Параметры, выделенные выше жирным шрифтом - основные, и именно они помогают разобраться, что происходит со связью, почему и что можно сделать. Рассмотрим их подробнее.

5 Final Receive Carrier Rate - текущая или последняя скорость приема. Выбирается локальным модемом исходя из условий в линии, почти всегда эта скорость ниже первоначальной - именно поэтому и представляет интерес. Во многих случаях отчасти отвечает на вопрос, "почему такой низкий CPS, хотя Windows показывает весьма приличную скорость Connect'а". На V.34 значение Final Receive Carrier Rate во многом определяется значением следующего интересного параметра:

9 Receive Signal Power Level. В подавляющем большинстве случаев чем выше этот уровень (меньше число по модулю), тем лучше. В случае, если мощность сигнала слишком высока и по этой причине сигнал искажается при приеме, локальный модем запросит у удаленного снижение уровня мощности до более приемлемой величины. Этот алгоритм работает всегда, за исключением ситуации, когда возможность снижения уровня мощности по запросу удаленной стороны умышленно отключена в настройках модема-напарника. В модемах провайдера возможность запроса снижения уровня мощности сигнала практически никогда не отключается.

Гораздо чаще уровень мощности сигнала недостаточен для достижения максимальной скорости в линии. Воздействовать на эту ситуацию невозможно, кроме как сменив модем (или напарника в соединении).

В общем случае "хорошей" можно считать мощность сигнала на уровне -15 -25 дБм, "удовлетворительной" на уровне -25 -35 дБм. Граница чувствительности модема для V.34 находится на уровне примерно -40 (+ -1) дБм, поэтому сигнал с более низким уровнем уже не может быть распознан: уровень мощности сигнала в диапазоне -35 - 40 дБм можно назвать "критическим".

В "критических" условиях можно также запретить V.34 (команда ats28=0), и перейти на использование V.32. На V.32 чувствительность модема лучше примерно на 3дБм. Правда, при выборе протокола V.32 скорость с большинством провайдеров не превысит 14400 бит/с (кроме тех пулов, на которых поддерживается протокол V.32terbo - 19200 бит/с).

Другой параметр, влияющий на выбор линейной скорости (уже не только на протоколе V.34) это

17 Receive Frame Error Count. Учет ошибок может вестись модемом только при приеме пользовательских данных, поэтому простое наблюдение за счетчиком в терминале с помощью перезапуска команды статистики ati11 не покажет увеличения значения. Однако, как только начинается интенсивный прием данных, значение счетчика сразу станет увеличиваться. При наличии существенного количества импульсных помех в линии рост числа ошибок заставит модем перейти на более низкую скорость.

Подобную ситуацию легко отследить следующим образом: если после соединения и до начала приема данных во включенном динамике на протяжении пары минут не слышно ретрейнов, но сразу же после того, как начат прием большого файла (обычно в первые 20-30 секунд от начала приема), происходит ретрейн, то следует сразу же проверить статистику - скорее всего, это именно упомянутое снижение скорости из-за роста числа сбойных блоков. А так как для целей снижения скорости модему требуется выполнять ретрейн вместо обычного пересогласования скорости, то зачастую целесообразно заранее ограничить скорость, неосмотрительно выбираемую модемом. Самый простой способ - посмотреть, какое значение Final Receive Carrier Rate является максимальным в большинстве сеансов связи с интенсивным приемом данных (на данной линии). В соответствии с ним и стоит ограничить скорость командой at-V90 или регистром s37. Например, последние скорости на прием в пяти разных сеансах составили: 36000, 33333, 36000, 37333 и 36000 бит/с. При этом совершенно неважно, какой была первоначальная скорость соединения - смело можем ограничивать скорость на 36000 (команда at-V90=8).

Результатом такого ограничения будет снижение числа перепосылаемых блоков данных одновременно с некоторым уменьшением числа запрашиваемых модемом ретрейнов (Retrain by Local Modem).

Рекомендация не поможет в том случае, если в разных попытках (или в разное время суток) наблюдается достаточно большой разброс демонстрируемых значений Final Receive Carrier Rate. Например, последний сеанс показал значение параметра 46666, а час назад этот же параметр показывал только 33333. В этом случае ограничивать скорость представляется бесполезным или даже вредным. Каких-либо других настроек у Lucent 1646 для такой ситуации нет, поэтому придется оставить все как есть, смирившись с избыточным числом ошибок в потоке данных.

18 Retrain by Local Modem. Далеко не все ретрейны будут являться результатом большого количества сбойных кадров. Они могут происходить даже при отсутствии обмена пользовательскими данными: так как Lucent не умеет изменять скорость с помощью запроса пересогласования скорости, для изменения скорости в связи с меняющейся помеховой обстановкой используется ретрейн. Если ретрейны возникают не слишком часто, о них можно не беспокоится. В то же время следует помнить, что прохождение двух последовательных ретрейнов заставит Lucent 1646 уйти с V.90 на V.34, а прохождение более трех ретрейнов подряд на V.34 (неважно, кто выступал инициатором этих ретрейнов) будет причиной обрыва связи (обрыв наступает в четвертой попытке). Если первое - переход на V.34 - явление нормальное и присутствует почти у всех других модемов, то второе - обрыв связи после трех ретрейнов подряд - ошибка конкретного Lucent 1646. Метод борьбы остается прежним - принудительное ограничение скорости до "безопасной" отметки.

Небольшое замечание относительно ограничения скорости. Регистр s37 ограничивает скорость в сторону провайдера при работе на протоколе V.90, но в то же время, ограничивает скорость при работе на V.34. Если связь на протоколе V.90 нестабильна, и зачастую сеанс заканчивается на V.34, то следует иметь ввиду, что после выбора модемом модуляции V.34 линейная скорость будет ограничена в соответствии со значением регистра s37. В то же время, при работе на V.90 ограничение скорости к удаленному модему с помощью этого регистра существенно уменьшит число пересогласований удаленной стороны. Это далеко не всегда принесет пользу, так как Lucent 1646 может использовать эти пересогласования для изменения собственной скорости: при их отсутствии значение счетчика Retrain by Local Modem может существенно возрасти. Поэтому следует проявлять осмотрительность, ограничивая скорость с помощью регистра s37 при работе на V.90. При работе на V.34 (или запрещении работы V.90 с помощью команды at-v90=0) таких противопоказаний не существует.

19 Retrain by Remote Modem - как уже говорилось выше, данный счетчик, в отличие от счетчика Retrain by Local Modem, учитывает как ретрейны, так и обычные пересогласования скорости с удаленной стороны. Последние возможны, если соблюдается два условия:

удаленный модем не является винмодемом от Lucent;
в настройках удаленного пересогласования не запрещены.

Если в статистике в значении Retrain by Remote Modem мы видим число, кажущееся подозрительно большим, первое что стоит сделать, включить озвучку соединения и послушать, сколько ретрейнов происходит за время связи. Далее, отключившись от линии и сняв статистику, вычтем из "услышанного" количества те ретрейны, которые зафиксированы счетчиком Retrain by Local Modem - там кроме ретрейнов ничего не содержится. Полученное после этих арифметических действий значение будет числом ретрейнов удаленного модема. В том случае, если хочется уменьшить число ретрейнов удаленной стороны, например, для борьбы с обрывами связи после трех подряд идущих ретрейнов, опять же рекомендуется ограничивать скорость передачи в регистре s37. Также в некоторых случаях поможет увеличение значения Transmit Signal Power Level (уровня мощности сигнала передатчика). Об этом параметре и способах его изменения расскажем поподробнее.

Велико общее число ретрейнов или нет - вопрос субъективного взгляда пользователя. Но следует иметь в виду, что ретрейн занимает примерно 6-7 секунд, простое пересогласование - около секунды. Таким образом, один ретрейн в минуту снижает эффективную скорость чуть больше, чем на 10%, а одно пересогласование примерно на 1,5%.

10 Transmit Signal Power Level - как утверждается в документации, может регулироваться регистром s91 в диапазоне от -6 до -15 дБм при установленной стране использования Japan. Однако, вопреки распространенному мнению, это совсем не так. Известны четыре основные проблемы, непосредственно связанные с регулировкой уровня.

Даже при установке страны Japan интервал иной, а его границы могут меняться в разных версиях драйвера. Поэтому для изменения параметра правильнее использовать команду at%t21,2f,<значение>. Значение представляет собой шестнадцатеричное число, соответствующее уровню мощности в десятеричном представлении: к примеру, для задания уровня в -13 дБм требуется подставить значение D. Данная команда работает вне зависимости от региональных установок.^*
^* Заданное значение не запоминается по команде &w. В строке инициализации команда должна быть последней, например:

at%t21,2f,b-v90=1- неправильно

ERROR

at-v90=1%t21,2f,b- правильно

OK
Установить желаемый уровень мощности сигнала при связи с цифровыми серверами доступа так просто не удастся. Чтобы команда заработала ожидаемым образом, необходимо отключить в модеме 56K-протоколы (at-v90=0s38=0). В противном случае, наблюдаемое в статистике сразу после установления связи число будет соответствовать уровню, автоматически выбираемому модемом: для V.90 это обычно -14, а для V.34 -10дБм.
В настройках модема отсутствует регистр, запрещающий снижение уровня по запросу удаленного модема. В том случае, если удаленному модему покажется, что выбран слишком высокий уровень сигнала, он может потребовать его снижения. В условиях линий с "плавающими" параметрами это может привести к обрыву соединения удаленной стороной.
Некоторые модемы имеют специальные команды, запрещающие просить снижение уровня сигнала (как раз для линий с "плавающими" параметрами). Но здесь-то и кроется самый неприятный для нас момент: даже если запросы на снижение уровня принудительно запрещены на удаленном модеме, Lucent 1646 все равно может самопроизвольно снизить мощность - последнее, кстати, отразилось и в приведенной статистике. Первоначальный уровень в -10дБм (явно не самый громкий с точки зрения удаленного) был сброшен модемом сразу до -18(!)дБм, несмотря на отсутствие запросов со стороны удаленного (которому, к слову сказать, совсем не стало лучше от такого произвола). Происходит это в момент ретрейна, инициированного Lucent 1646.

К сожалению, если в отношении первых трех проблем известны (и названы) способы обхода, то четвертая проблема на некоторых типах линий (там, где удаленный модем и так не очень хорошо нас слышит) будет частой причиной обрыва соединения или просто плохой связи. Для того, чтобы хоть как-то воздействовать на ситуацию, есть только два способа, эффективность которых весьма далека от 100%. Первый способ - тривиальное ограничение линейной скорости для того, чтобы любой ценой избежать ретрейна. Второй вариант - "лечить подобное подобным": зная, например, что первый же ретрейн даст сброс мощности до -18 дБм, заранее установить мощность на -16дБм. В некоторых случаях это помогает избежать сброса мощности на ретрейнах, выигрывая несколько дБ в SNR для удаленной стороны.

Еще одна проблема, связанная с самопроизвольным изменением значения Transmit Signal Power Level, не относящаяся, на наш взгляд, к "основным". При связи на протоколе V.90 иногда возникает ситуация, когда в результате ретрейна уровень Lucent 1646 увеличивается, с первоначально установленных модемом -14дБм до -10дБм. В результате этого возрастает риск ухода с V.90 на V.34 (что во многих случаях и происходит спустя непродолжительное время после такого увеличения мощности сигнала). По причине того, что с включенным V.90 настройка уровня "вручную" не работает, повлиять на ситуацию невозможно. Не фатально это по той причине, что ведь не связь оборвали, а просто ушли на более помехозащищенный протокол. Кроме прочего, шансы этой ошибки на исправление в будущих версиях драйверов значительно выше, чем у всех остальных ошибок.

5. Вопросы по сервисным возможностям модема

Если в состав модема не входит специализированный аудиокодек CSP1027, то использовать режим спикерфона Вам не удастся и даже полнодуплексная звуковая карта не поможет. Тем не менее, часть голосовых функций даже при такой неполной схеме модем способен выполнять.

Приём голосовых сигналов из телефонной линии и воспроизведение ранее записанных сообщений будут работать и в отсутствие аудиокодека, возможна также программная реализация автоматического определителя номера.

Q5.2 В документации большое внимание уделено протоколу V.80. Что это за протокол и как его использовать?

С большой долей вероятности можно сказать, что Вам этот протокол не понадобится, поскольку предназначен он для реализации и участия в видеоконференциях с обменом речевой и видеоинформацией по аналоговым телефонным линиям в соответствии со стандартом H.324. Для реализации этих функций необходим соответствующий аппаратно-программный комплекс. Как работает одно из таких решений, включающее в себя видеокамеру, плату видеозахвата и программное обеспечение, можно прочитать здесь: http://www.aopenpc.com/products/presalqa/vcqa.htm

Не вдаваясь в мелкие подробности, отметим основные особенности, связанные с использованием видеоконференций вообще и протокола V.80, в частности:

эффект от использования данного протокола будет проявляться только при связи двух клиентских V.34 модемов, при условии, что в обоих модемах этот протокол реализован;
можно организовать видеоконференцсвязь и без использования этого протокола, однако, качество изображения будет ниже;
этот протокол не применим для организации видеоконференций через интернет;
в ходе сеанса связи с использованием V.80 возможна передача только изображения и звука, передача других данных (например, файлов) в течение такого сеанса невозможна.

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

6. Вопросы совместимости с другими операционными системами

Q6.1 Можно ли без дополнительных программных средств заставить работать модем в DOS сессии?

Прежде чем ответить на этот вопрос необходимо сразу оговориться, что в "чистой" DOS без загрузки Windows модем работать не будет. В DOS сессии (при загруженной Windows) работа возможна, если Вы используете последнюю версию драйверов (необходимо уточнить, начиная с какой). При использовании более ранних версий драйверов, работа модема в DOS сессии также возможна, но для этого необходимо использовать дополнительную утилиту, эмулирующую COM порт, например fossil (в качестве такового рекомендуется использовать WinFOSSIL или VFossil) или программу TurboCOM. Ничего не мешает использовать эти программы совместно с поздними версиями драйверов модема.

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

Если рассмотреть драйверы модемов на чипсете Lucent 1646 для других операционных систем, то несложно, глядя на их версию и год создания, отметить, что ядро применяется старое. Это ведёт к тому, что в драйверах не ликвидированы ошибки, свойственные драйверам для Windows. Предположение о маркетинговых целях заслуживает достойного внимания, поскольку с момента выхода драйверов они не обновлялись, а работа их крайне неустойчива и сопряжена с ошибками. Исходя их вышесказанного вывод один - конечный пользователь становится заложником при использовании драйверов, поскольку вынужден заниматься их поиском в надежде на дальнейшие обновления.

Q6.4 Каковы особенности установки драйверов под Linux?

Начнём с того, что драйверов под Linux от самой фирмы производителя нет, а есть только от сторонних энтузиастов, например, драйвер от Eric Bentley, версия 5.68.2.2.12. - наиболее устойчивая версия, поддерживает все протоколы, дата компиляции драйвера 6 ноября 1998 года. Данный драйвер можно найти как http://linmodems.org/linux568.zip. Установка драйвера для последних версий ядра Linux вызывает ошибки.

Попытка дальнейшего совершенствования драйверов предпринята Mark Spieth, и драйверы версий v5.78(c,d,e,...) можно найти на сайте http://walbran.org/sean/linux/stodolsk . Эти драйверы имеют открытый код, но по устойчивости проигрывают 5.68. С ними работа на 56K протоколах сомнительна, поэтому лучше их сразу отключать на этапе инициализации модема.

Те, кто хочет поэкспериментировать может посмотреть open source tools от Pavel Machek на сайте http://www.close.u-net.com/ltmodem.html .

Заключение

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

Информация по статистике и настройкам, содержащаяся в документе, на 99% относится только к винмодемам на чипсетах Lucent 1646 (1645). Применять написанное к нормальным модемам на других чипсетах в большей части неразумно, в меньшей - бесполезно.

Авторы не дают своего согласия на использование данного документа (или любых его частей) в коммерческих "бумажных" СМИ. Прочим СМИ запрещена публикация отдельных частей в отделении от документа без согласования с авторами: документ - большой (и живой) организм, и может публиковаться только целиком и со всеми сопутствующими частями (введением, заключением, цитатами). Не возбраняется и приветствуется ссылка на данный FAQ и цитирование его отдельных частей при обсуждении функционирования рассмотренных устройств в технических конференциях сети FIDO и подобных форумах Интернета.

Игорь Белянин (Igor_Belyanin@USRSupport.ru) ,
http://www.people.nnov.ru/belyanin

Павел Митронов (eloy@aha.ru),
http://www.flashcom.ru/html/stat.shtml

Опубликовано -- 17 апреля 2001 г.

Украинская Баннерная Сеть

Главная • Алфавитный индекс • Справка • Добавить FAQ • E-mail

Новости • Поиск по сайту

Сайт создан в системе uCoz