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




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


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

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

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

На уровне регистров можно в обход виндов достучаться к этому выводу и использовать его как I/O чтобы дернуть сброс модуля или ключик.
Как ни странно, но даже в NT системах есть способы получить доступ к железу напрямую.
А если малость модифицировать драйвер, то тогда вообще никаких проблем.

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

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

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

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

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

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



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




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

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



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

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




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

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

Сообщение отредактировал mantech - Sep 9 2015, 11:42

Добрый день.
Telit является одним из крупнейших производителей надёжных модемов.
Помимо возможности записать скрипт на Python, который может следить и ребутать модуль при необходимости, также есть возможность включить периодическую перезагрузку (например, раз в сутки).
А вообще, т.к. многое действительно зависит не от GSM-модуля, можно рекомендовать ставить ключ по питанию и простейший внешний вачдог.

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

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

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

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

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

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


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

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



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




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

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


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

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

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

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