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

Нет. Слишком многое зависит от сети, ОпСоСов, расположения планет и прогноза погоды на вторник. Это ни Вам, ни разработчикам модемов неподвластно. Так что не экономьте на копеешном ключе, чтобы не получить проблему на рупь.

это планируется подключать к embedded PC , и лишний ключ, это не только ключ, а еще целый MCU который будет это все контролировать и перезапускать, вот хотелось бы без костылей.

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

Ерунду говорите, в embedded PC точно есть полноценные ком-порты с кучей дополнительных ног, которыми управлять не сложнее, чем самим комом. Подключите ключ к одному из этих выходов и будет вам счастье

ЗЫ. Ну а если уж совсем ничего ручками делать не хочется, то посмотрите в сторону готовых решений, как-то разбирал модем от телеофиса, если память не изменяет, там уже стоит этот МК, который ресетит и управляет модемом...

Да,да у них так и написано, что если не пингуются монстры типа 8.8.8.8, то модем (роутер 3G) завис и надо ресетнуться модулю 3G))).

а нету, всего один UART обрезанный до RTS, CTS и GPIO нет, да и привязываться к самой плате не правильно
понятно что можно на USB прикрутить свой watchdog, но это место и костыли, и это будет уже 3 плата на USB



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



готовые решения слишком большие, нужно по размерам не более USB 3G модема, подойдет и USB модем, но там с надежностью еще хуже.




некоторые роутеры работающие с модемами 3G умеют переключать питание в случае зависания

Ну так GPIO в RS-232 никогда и не было.
Поинтересуйтесь как в свое время делали управление и питание для RS232 мышек. DTR, RTS, RI рулят.

У M680 OpenCPU есть Watchdog, при зависании должен перезагрузить модуль. Т.е. управляться модуль может внешними командами, а внутреняя пользовательская прошивка - только периодически подкармливать Watchdog.

А если немного подумать и не решать задачу в лоб?

Представьте что у модема батарейное питание и он 90% времени спит.
Сколько батареи сожрет ваша активная задача крутящаяся в модеме?
Внешний XLP контроллер обойдется десятком микроампер, а задачу решит надежнее.

Теперь учитываем что зависание это в 98% вина оператора или кривая работа с модемом.
Решение сброса через UART тоже элементарное - на линии передачи в сторону модема сидит микроконтроллер и слушает чего там передается.
Если там от управляющей ePC проскочит сообщение типа AT+PIZ@EZ, то модем ответит error (или вообще не ответит), а контроллер увидев в потоке единственно правильную для него сигнатуру - сбросит модем.
И со спячкой тоже просто - усыпили модем, контроллер увидел что нет активности на UART и тоже уснул. Проснется он быстрее чем модем по первому же стартовому биту.
Цена вопроса меньше доллара - тот же PIC12F1822 - UART аппаратный, ног мало, спит крепко....
Кроме того этот контроллер может и еще несколько функций выполнять - правильное включение по устаканиванию питания, контроль батареи... да мало ли что можно на него повесить и давать команды по тому же самому UART.

любопытно, а внутренняя прошивка может ( параллельно с установленным внешним PPP соединением) сама контролировать соединение?



GPIO нет в embedded PC,
в последовательном порту который на нем есть (который кстати UART), есть только сигналы RX,TX, CTS, RTS и все, и нет никаких DTR, RTS, RI



думаю нужно в потоке ловить ICMP пакеты ping и только по ним определять наличие связи,




не очень понимаю, как получить доступ к UART, если его перехватила windows и качает там свои байтики

>>>не очень понимаю, как получить доступ к UART, если его перехватила windows и качает там свои байтики

Так же как и любой аппаратный сниффер или логгер.

От эмбедед PC идет линия передачи - приемником является модем.
На нее вешаемся паралельно вторым приемником - контроллером.
Контроллер на передачу не работает - он только слушает поток и ждет команду которая бессмыслена для модуля, но будет понятна ему.

Если же вы имеете в виду программную часть, то я подразумеваю написание своей программы, а не использование чужой котрая неизвестно как работает.
Народ уже неоднократно обжигался на применении подобных рассыльщиков SMS, прозвонщиков и прочего, которые посылают в модем недопустимые или кривые команды.
Если Вы до такой степени озабочены надежностью аппаратной части, то программой должны владеть не хуже - иначе надежность модема до одного места если не знаете где взбрыкнет софт.

это понятно



писать свой драйвер PPP/TCP/IP для виндов это сильно

Зачем драйвер???

Пишется софт или утилита которая является командной для модема.
Настраивает его и контролирует. А драйвер для передачи данных - стандартный виндовый.

Мне кажется что у Вас есть небольшое недопонимание как это все в связке работает, так сказать не продумана идеология проекта.
Если подробнее опишете конечную задачу, то может подскажу как проще решить.

модем управляется по одному порту, либо свой прогой, либо драйвером windows (PPP протокол), как они поделят порт? Если есть соединение, то доступа к порту нет.

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





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

к примеру в платежный терминалах есть специальное устройство, wathdog, которое перезапускаться из программы на PC (которая постоянно пингует удаленный узел) , этот watcdog может снять питание с модема, вот хорошо бы без такого устройства обойтись

digital, можем Вам в Питере дать отладку на время попробовать.
Модуль сам может играть роль управляющего контроллера.

>>>модем управляется по одному порту, либо свой прогой, либо драйвером windows (PPP протокол), как они поделят порт? Если есть соединение, то доступа к порту нет.

Неверно.
Любой драйвер API прозрачный - то есть может быть проключен в своей проге использованием in/out стека.
Другое дело что в это время вторая прога к нему не будет иметь доступа.

Ведь сам драйвер PPP не может работать с внешним миром - ему нужно пихать параметры и потом поток данных - а этим должен кто то заниматься на более высоком уровне.


>>>вот хорошо бы без такого устройства обойтись

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

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

я об это и говорю,
при подключение модема к системе, драйвер поднимает на нем PPP, запускает TCP/IP , сверху начинает пахать HTTP, FTP и прочий кардабалет, и куда нам приткнуться ?



Вот именно

так что, этот микроконтроллер должен сам анализировать трафик на UART и без посторонней помощи из PC принимать решение о перегрузки



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



типичный сторожевой таймер

В упрощенном варианте - перезагружают периодически. Но в M680-OC можно реализовать свою логику работы WD.

встроенное ПО может работать параллельно работать с PPP соединением установленным по входу UART?
Судя по примерам внутреннее ПО управляет модемом через эмуляцию UART, или я чего то не понимаю

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

ЗЫ. Вообще всегда умиляет то, когда работают под виндой и ищут "очень надежный модем"



Как правило - так и есть, причем иногда бывает, что сбрасываются и настройки, которые были введены без &W в командах.
Видать программерам там не больно надо было, например, отследить отсутсвие данных от модема и тогда уж его сбрасывать

вот на практике винда, с прогами, ПЛИС и т.д., работает неделями, а 3G модем часы




да вы правы, но не нужен "очень надежный модем ", нужен надежный как винды хотя бы (не смеяться !!!) , устройство все же обслуживаемое, и можно попросить его перегрузить, но не не каждый день по несколько раз



мдя, я то размечтался что в промышленных модемах, сделано по нормальному

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

Только не на ножку "сброса", потому, что она там - фикция, это не физический сброс МК модема, а просто сигнал его операционке, если она не зависла, что надо сделать "теплый" сброс. Нужно ставить полевичек на питание модема - самый надежный способ.



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

Предполагаю что дешевые "свистки" надежнее работают, ибо прошивка уже сменилась пару раз, но в этом и проблема, что их не найдешь, а если найдешь, то нет никакой гарантии что они потом будут





в свое время и wavecom (тогда еще) и simcom, уверяли что вот в этой новой версии reset теперь аппаратный, как сейчас не знаю

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

Я больше скажу. Эксплуатировал сервер на линуксе дома. Он выходил из ждущего режима и раздавал инет по сети. Стоял обычный 3G свисток (huawei e171), за полгода не повис ни разу. питание с него не снималось.

Аппаратный сброс и сброс по питанию могут работать по-разному. Например, при аппаратном сбросе содержимое ОЗУ можно сохранить, со всеми вытекающими.

при аппаратном сбросе содержимое ОЗУ и не меняется, оно стирается всегда программно

По поводу сброса поправлю - это аппаратный сброс baseband + interface. DSP не сбрасывается.
А значит если подвисон по вине сбоя сети, то этот ресет не поможет, только снятие питания.

О, как еще оказывается! С каждым разом узнаешь все более интереснее
А если без шуток, тогда непонятна одна вещь - если сбрасывается основной контроллер, то почему б ему, при запуске не проинициализировать и дсп?? Вроде, как логично, например, когда моя прога запускается, то в любом случае инициализирует повторно и всю периферию и граф. сопроцессор и т.п. А тут как-то странно все...

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

Если грубо то старт модуля выглядит так

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




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


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

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

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

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

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

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

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

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

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

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



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




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

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



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

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




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

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

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

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

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

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

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

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

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


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

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



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




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

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


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

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

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

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

Не уверен, что винда использует этот механизм, кроме как для завершения связи. Впрочем, не знаю.

Но это ни в коей мере не отменяет необходимость перезапуска PPP при сбросе модема.

А что делать если зависнет сама винда? Что-то глядя на все это и мой опыт работы с GSM-модемами, модем в этой конструкции окажется самым стабильным устройством.

Вот уперлися в виндовс - забудьте про него. Вы должны пользовать только API драйвера - вошли с параметрами и вышли.
Программа своя должна быть, полностью контролируемая и управляемая - так чтобы поток данных в любой момент остановили, обменялись командами, считали состояние.
А юзать чужую программу и дрожать что "ой мамочки винда своим PPP не дает всунуться", то можно заранее не браться, работать нормально не будет.

Какое еще API драйвера? напрямую с портом работать нужно



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

Это к мелкомягким вопрос Сам спасался только перезагрузкой раз в сутки, по таймеру...



Хоба-на!!! И хде, позвольте узнать?? Особое сочетание сигналов D+ D-???
Если без хохмы, то я имел ввиду - нет аппаратного ресета