[digital 0]

Ну если RTS есть, то в чем проблема?

 

 

эээ, а как поможет RTS ? по нему диагностировать зависание?

 

По поводу сброса поправлю - это аппаратный сброс baseband + interface. DSP не сбрасывается.

А значит если подвисон по вине сбоя сети, то этот ресет не поможет, только снятие питания.

 

 

очень интересно

 

 

кстати а как обычно зависают модемы? полностью недоступны или могут показывать формы жизни, но при этом нет связи ?

 

можно диагностировать что модем нормально работает по просадке напряжения или по выходу работы передатчика?

[CADiLO 12]

>>>а как поможет RTS

 

На уровне регистров можно в обход виндов достучаться к этому выводу и использовать его как I/O чтобы дернуть сброс модуля или ключик.

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

А если малость модифицировать драйвер, то тогда вообще никаких проблем.

 

>>>кстати а как обычно зависают модемы?

 

а как угодно - непредсказуемо.

 

я уже приводил пример основаный на кривом GSM стеке (кстати болезнь любого модуля ибо стек менять нельзя)

 

если в предответном состоянии пропадет сигнал с соты, то стек останется в вечном цикле и даже после появления сигнала можно оживить только по снятию питания и полной инициализации

это как раз тот глюк когда виснет DSP - никакой ресет не поможет

[digital 0]

>>>а как поможет RTS

 

На уровне регистров можно в обход виндов достучаться к этому выводу и использовать его как I/O чтобы дернуть сброс модуля или ключик.

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

А если малость модифицировать драйвер, то тогда вообще никаких проблем.

 

RTS постоянно срабатывает при нормальной работе

 

достучаться до управления RTS не сложно, сложности возникают когда управление порта перехватил драйвер модема

 

 

А если малость модифицировать драйвер, то тогда вообще никаких проблем.

это как, да еще и без исходников, это вам не linux

 

 

если в предответном состоянии пропадет сигнал с соты, то стек останется в вечном цикле и даже после появления сигнала можно оживить только по снятию питания и полной инициализации

это как раз тот глюк когда виснет DSP - никакой ресет не поможет

 

модем при этом пытается что либо передать в сеть ?

[artemkad 81]

эээ, а как поможет RTS ? по нему диагностировать зависание?

 

RTS это программно доступный из компа выход RS-232 которым можно дернуть для пересброса модема или переподачи его питания. Анализировать завис модем или нет тебе придется все равно программно на основании того чего модем отвечает по Rx/Tx.

 

достучаться до управления RTS не сложно, сложности возникают когда управление порта перехватил драйвер модема

 

Таки подозреваю у драйвера надо отключить включенный аппаратный контроль потока.

[digital 0]

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

 

это понятно, проблема в том что это нужно делать при поднятом виндами PPP соединение , т.е. порт захвачен и недоступен

 

 

Анализировать завис модем или нет тебе придется все равно программно на основании того чего модем отвечает по Rx/Tx.

 

анализировать поток PPP ? :rolleyes:

[mantech 49]

Я еще больше вас огорчу - этим даже производители модулей управлять не могут

 

Я предполагал что-то подобное, но чтоб ТАК!!

Изменено 9 сентября, 2015 пользователем mantech

[Ion 0]

Существуют надежные GSM -модемы? Которые не зависают и не требуют снятия питания для перезапуска?

Добрый день.

Telit является одним из крупнейших производителей надёжных модемов.

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

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

[aaarrr 69]

это понятно, проблема в том что это нужно делать при поднятом виндами PPP соединение , т.е. порт захвачен и недоступен

А зачем "поднятому PPP соединению" сброшенный модем? Логично сначала бросить соединение, а затем уже сбросить модем.

[digital 0]

А зачем "поднятому PPP соединению" сброшенный модем? Логично сначала бросить соединение, а затем уже сбросить модем.

 

потому что сбросом соединения занимается драйвер виндов, и по каким критериям он это делает непонятно, предполагаю невозможности доставить TCP не является обязательным условием перегрузки PPP соединения

[aaarrr 69]

потому что сбросом соединения занимается драйвер виндов, и по каким критериям он это делает непонятно, предполагаю невозможности доставить TCP не является обязательным условием перегрузки PPP соединения

Замечательно, но чем тогда поможет сброс модема?

 

Тут уж или дождаться сброса соединения, сбросить модем и устанавливать соединение снова, или оборвать соединение по каким-то своим критериям и затем восстанавливать. Но ни в одном из сценариев не просматривается нужды в сбросе модема при активном соединении - PPP при этом так и останется висеть.

[mantech 49]

Замечательно, но чем тогда поможет сброс модема?

Затем, что сброс модема и соединения - разные вещи. Что может сделать винда, если зависла операционка в модеме? Питание усб она "передергивать" не может, а ресета в шине усб нет

[aaarrr 69]

Затем, что сброс модема и соединения - разные вещи. Что может сделать винда, если зависла операционка в модеме?

Ох. Что будет делать "винда", если модем был сброшен при активном PPP-соединении?

 

ресета в шине усб нет

Есть :) Но речь в теме не про USB модем.

[digital 0]

Что может сделать винда, если зависла операционка в модеме? Питание усб она "передергивать" не может, а ресета в шине усб нет

 

надеюсь, она хотя бы закроет и откроет PPP соединение

 

Замечательно, но чем тогда поможет сброс модема?

 

Тут уж или дождаться сброса соединения, сбросить модем и устанавливать соединение снова, или оборвать соединение по каким-то своим критериям и затем восстанавливать.

 

зависания могут быть весьма своеобразны, модем может вполне отвечать на команды, но к примеру не может отправить пакет, это явно не основание перегрузки PPP, ибо возможно проблема в сервере

 

 

Но ни в одном из сценариев не просматривается нужды в сбросе модема при активном соединении - PPP при этом так и останется висеть.

 

ну вообще то все промышленные модемы имеют безусловный ватчог, и логично что при сбросе модема винды должна перезапустить PPP

[aaarrr 69]

зависания могут быть весьма своеобразны, модем может вполне отвечать на команды, но к примеру не может отправить пакет, это явно не основание перегрузки PPP, ибо возможно проблема в сервере

Какие могут быть команды модема при поднятой PPP-сессии?

 

ну вообще то все промышленные модемы имеют безусловный ватчог, и логично что при сбросе модема винды должна перезапустить PPP

Когда-нибудь перезапустит. Но логично было бы сделать это самому, раз уж решили перегрузить модем, нет?

 

Это все к тому, что "порт занят" - надуманная проблема.

[CADiLO 12]

>>>Какие могут быть команды модема при поднятой PPP-сессии?

 

Обыкновенные. Дергаем DTR или в потоке передаеи +++

Перешли в командный режим, обменялись командами-ответами с модемом и опять вернулись в передачу данных