[Гость SUPPORT7/6]

Здравствуйте!

Были дискуссии о NRESET и POWER о том что они не гарантируют аппаратного перезапуска модулю SIM900. Решение проблемы на форуме вытекло в отключение питания на SIM900 на ногу VBAT - способов много - от P-канального MOSFET и реле до применения контроллеров(стабилизаторов) питания с ногами типа EN - разрешения подачи питания на выход.

 

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

Поясню:

Топорно: Вот я планирую подавать через usart PIC-контроллера на SIM900 команду "AT" (например) и ждать ответа от модема "ОК".

Это слишком тупой вариант? Гарантирует ли он определение состояния зависания SIM900? Есть какие-либо более надежные способы - если они нужны? может быть можно подавать какую либо команду и следить за действием какой-либо ноги?

[masterofnature 0]

По остутствию активности (ответов) модуля - если модуль используется.

Если общения с модулем нет - можно просто периодически посылать AT и ожидать отклик OK.

Понятно, что в это время нужно находится в командном режиме.

[gegel 0]

А какую основную функцию будет выполнять модуль?

Если это действие, инициализируемое вами, то запускайте таймер в начале отработки, и останавливайте при полном завершении отработки. Если таймаут - считаем, что завис. Так проще и надежнее всего.

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

Зависнуть может, например, регистрация в сети, но на АТ отвечать будет.

[masterofnature 0]

Зависнуть может, например, регистрация в сети, но на АТ отвечать будет.

В этом случае можно контроллировать регистрацию в сети (AT+CREG?)

[Гость SUPPORT7/6]

Вот я поэтому и думаю как сделать чтобы максимально обезопасится от зависания. Модуль работает в режиме приема входящего звонка по команде RING в консоли (через прерывание). Мое ПО отправляет смс с состояниями выходов, управляется через поступающие смс-команды.

[Varyag 0]

В этом случае можно контроллировать регистрацию в сети (AT+CREG?)

именно так проверяю. В основном можно понять как модуль завис - от него ничего не идет в ответ. В этом случае его ни программно ни аппаратно выключить не получается. Но во всех случаях через некоторое время (пару минут) он отвисает.

[=F8= 0]

AT+CREG?

AT+CGREG?(необязательно)

AT+CSQ

Но самое неприятное, что все это не дает 100% гарантии, что вы еще в сети, по крайней мере так было с sim300. Поэтому лучше еще раз в 2-3 часа давать USSD запрос, например о состоянии счета.

[Гость SUPPORT7/6]

Я тоже думаю о USSD запросе баланса как проверке. Сразу чтобы всех зайцев убить. Однако, ответ может и не придет? также? или по тайм-ауту будет отчет об ошибке. Я не знаю как работают USSD команды. Еще только изучаю их

[gegel 0]

Можно также несколько раз позвонить на бесплатный сервис оператора и проконтролировать код ответа. Хотя тоже не факт, что сервис временно не падет в один прекрасный день.

Я когда-то похоже обжегся: для проверки жпрс пинговал рамблер на старте. И вот через три года рамблер упал на день (кто б мог подумать). Пришлось человеку ехать в Москву перешивать девайсы...

[Гость SUPPORT7/6]

А сам SIM900 не отслеживает внутри себя состояние того же приемо-передающего тракта или GSM-ного физ. и канального уровней и если он/они зависли сам без внешней помощи реинициализирует? или бывает так плохо что вообще что фиг отследишь.

[Romashki 0]

С тем что сим900 завис не сталкивался, но полный контроль в Ваших руках.

 

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

2 - ожидаем окончания регистрации в сети (CREG), если регистрация долго отсутствует (например на протяжении 40 секунд), пытаемся перезапустить модуль (поверкей или CFUN=1,1). Без регистрации дальнейшая работа с модулем бессмысленна.

3 - поднимаем GPRS, запускаем функции PING и т.д.

 

не совсем понимаю где проблема???

 

Если боитесь перегрева - спрашивайте у модуля температуру;

напряжение питания - спрашивайте питание;

если и это не 100% - то спрашивайте текущее время и сравнивайте с предыдущим значением.

 

 

[ilichev 0]

В документе "sim900_atc_v1 00.pdf" написано: "AT+CFUN=1,1 can be used to reset module purposely". Значит, подачей этой команды можно сбросить модем. Есть два НО:

1. Там же написано: "The <fun> power level will be written to flash except minimum functionality". То есть каждый раз при таком сбросе будет происходить запись во flash. Ресурс flash невелик (1 млн циклов записи), вдруг при полном отсутствии сети GSM будет постоянно лупить такой сброс? Flash в модуле сдохнет быстро.

2. При таком сбросе питание сим-карты снимается? Если да, то симки со счетчиком включений тоже будут сдыхать при длительном отсутствии сети GSM.

 

Коллеги, прокомментируйте, пожалуйста, эти выкладки.

Как лучше делать сброс?

 

P.S. Реальная ситуация: прибор с SIM900B лежит на столе (стационар), работает, GPRS подключен, данные передаются по TCP. Через веб-клиент билайна переводим сим-карту в состояние "Запасы" (перестает регистироваться в сети). Модем выдает PDP DEACT и дальше мы не можем отправить данные по TCP, закрываем сокет, отключаемся от GPRS и периодически пробуем подключить GPRS. На AT+CGATT=1 стабильно получаем ERROR. AT+CREG возвращает 0,1, AT+CGREG возвращает 0,0. Теперь переводим симку в состояние "Активирована". В 2 случаях из 10 модем еще минуту отвечает ERROR на AT+CGATT=1, а затем-таки подключает GPRS. Дальше работает как обычно, нормально. Но в 8 случаях из 10 модем продолжает отвечать ERROR и только выкл/вкл по PWRKEY дает эффект, симка регистрируется и модем подключает GPRS. Да, можно так сбрасывать, но этот вариант мне не нравится исключительно из-за того, что симки со счетчиком включений будут дохнуть.

КАК БЫТЬ?

[gegel 0]

Учитывая Ваши страхи, я бы организовал аглоритм где-то так: пробуем подключать жпрс каждую минуту (чаще не вижу смысла из-за инертности оператора). Если в течние 5 попыток не получилось, перезапускаем PWRKEY. Причем в этом случае тщательно конролируем STATUS: чтобы он стал 0, пауза, затем чтобы 1, пауза, опять 1 для гарантии. Если что-то не так, тогда дергаем питание.

Т.о. перезапуск по POWERKEY будет раз в 5 мин при блокировке сим. Если и это пугает, то можно ввести счетчик перезапусков, и спосле 2-х подряд перезапусков пропустить, скажем, следующие 10. Т.о. 2 попытки перезапуска будут каждый час (если это допустимо задачей).

 

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

 

Что касается счетчика включения сим, то я про такой не слышал. Был счетчик запуска аутентификации (COMP128), но он все равно будет инкрементироваться при любой перерегистрации в сети, хоть со снятием питания с сим, хоть нет. Реально ни разу не видел симки, блокированной в штаном устройстве, только в ридере при сканировании.

 

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

 

 

PS: и еще - в этих 8 из 10 случаев регистрация в сети появляется, но жпрс не поднимается? Или нет и регистрации? Если последнее, то возможно, есть недокументированные команды из расширенного инженерного меню, позволяющие принудительно перерегистрировать в сети по IMEI (получить новый TIMSI). Тогда нет необходимости дергать питание. Уточните у Эдуарда.

Изменено 16 октября, 2011 пользователем GeGeL

[Гость SUPPORT7/6]

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

2 - ожидаем окончания регистрации в сети (CREG), если регистрация долго отсутствует (например на протяжении 40 секунд), пытаемся перезапустить модуль (поверкей или CFUN=1,1). Без регистрации дальнейшая работа с модулем бессмысленна.

....

не совсем понимаю где проблема???

 

Нет нет - нет проблем. Я собственно приблизительно такой алгоритм сейчас и реализовал вместо посылки АТ и ожиданием OK. Я был озадачен тем, на сколько это, как бы, объективно.

С AT+CREG? это конечно лучше - так как и ответ придет (стык с модемом на уровне USART) и регистрацию проверяем (на канальном уровне GSM). Если что-то возникнет более существенное в опытной эксплуатации за 3 мес. - то буду править код под уже возникающие проблемы.

 

Если боитесь перегрева - спрашивайте у модуля температуру;

напряжение питания - спрашивайте питание;

если и это не 100% - то спрашивайте текущее время и сравнивайте с предыдущим значением.

 

Эти моменты я учел в проверке. Думаю на данном этапе все эти меры будут конечно не 100% гарантировать слежение за зависанием, но хотябы избежать большей части (если конечно это вообще наступит).

 

Возник еще такой вопрос:

Есть ли какой-либо параметр определяющий максимальное время ответа модема SIM900 по USART на команды?

Т.е. я имею ввиду что, MCU посылает модему команду AT на скорости 9600, через какое максимальное время мне ожидать прием первого символа ответа?

Я понимаю, что например в команде AT+CMGDA=6 - ответ идет долго - потому что стираются смски. Но для простых команд типа ATZ, ATE, AT и т.п есть ли такие временные рамки?

 

Я к чему спрашиваю. К примеру, посылаю команду, в ответ ожидается "OK" и через сколько его ждать от SIM900? 100 мс, 300 мс, 1 с? Дело в программном ожидании ОК от модема. Через прерывания в данном случае не могу реализовать - там задействован другой код программы. Если я не буду ограничивать время ожидания ОК и если оно не придет - то гаджет бесконечно зациклится на этом ожидании. Думал решить такую проблему через "хитросбрасываемый" watchdog - но слишком уж жестко это, хотя...

Изменено 16 октября, 2011 пользователем SUPPORT7/6

[MKdemiurg 1]

Я к чему спрашиваю. К примеру, посылаю команду, в ответ ожидается "OK" и через сколько его ждать от SIM900? 100 мс, 300 мс, 1 с? Дело в программном ожидании ОК от модема. Через прерывания в данном случае не могу реализовать - там задействован другой код программы. Если я не буду ограничивать время ожидания ОК и если оно не придет - то гаджет бесконечно зациклится на этом ожидании. Думал решить такую проблему через "хитросбрасываемый" watchdog - но слишком уж жестко это, хотя...

 

Используйте аппаратный таймер... Если в течении 5-6 секунд не пришёл ОК - ребут модема или повторение запроса( хотя если документированый ОК не пришёл - то это точно висяк и спасёт только ребут). Я так делаю. На каждую команду 5 сек ожидаение ОК( на самом деле приходит моментально и таймер останавливается - но вдруг). CREG? CGREG - делаю опрос с интервалом 2 секунды до 20 раз пока не приходит +CREG: 0,1 . Превышен лимит опроса - ребут модема. Вообщем в любом случае отловите зависон. Т.е. идеально на каждую команду проверка ответа - тогда висяки не страшны. Ну и ограничить кол-во перезагрузок 2-3 штуки.

Изменено 16 октября, 2011 пользователем MKdemiurg