<AT+CIICR> + <RING> + <SIM300C> = ГЛЮК, Модем странно себя ведёт Опции

[david_off]

В своем посте "Краткий курс по TCP/IP" я писал про три чудо команды AT+CSTT, AT+CIICR, AT+CIFSF и про глючно работающую AT+CIPSHUT.

На горьком опыте убедился, что одна из чудо команд так же имеет особенность. Заметил, что если после посылки AT+CIICR поступает входящий звонок, то модем:
1) в упор отказывается присылать ответ на AT+CIICR, пока есть входящий звонок
2) пока есть входящий звонок - лезут сообщения RING, а любые команды посылаемые модему игнорируются.

Получается, что если кто-то дозвонился после посылки команды AT+CIICR и до приёма ответа на эту команду - то надо ждать пока на той стороне положат трубку. На нашей стороне нельзя ни отклонить ни принять звонок.

Отдалённо я понимаю, что эти модемы не мультизадачны, но должен же быть какой-то выход из этой ситуации?
Может хотя бы можно поставить ограничение на количество RING, после которых, если трубка не снимается, то модем сам выполняет ATH. Это конечно не решает проблему, но хотя бы сокращает время "зависания" модема.


Для лучшего понимания приведу лог. Лог реальный! CTRL+C, CTRL+V из окна терминала (кроме коментов кончено):

AT+CSTT="WWW.UMC.UA"
OK
AT+CIICR
RING
RING //в этот момент посылаю ATH первый раз
RING //в этот момент посылаю ATH второй раз
RING
RING
RING
NO CARRIER //положил на другой стороне трубку
+PDP: DEACT //модем ожил и вспомнил, что выполняет команду CIICR
ATH //получаю эхо на посланную первый раз ATH
ERROR //ответ на первый ATH
ATH //получаю эхо на посланную второй раз ATH
OK //ответ на второй ATH

Сообщение отредактировал david_off - Nov 4 2008, 19:00

[Baser]

Есть парочка соображений:

- конечно, SIM300 являет собой GPRS mobile station class B, которая не обязана уметь одновременно работать с GPRS и голосовой связью. Но все-таки разруливание задач в нем явно сделано криво и многие вещи на совести разработчиков.
Все же поглядите на версию ПО вашего экземпляра модема, может она старая, и есть новее с кучей исправлений;

- кроме применяемой вами группы команд, в SIM300 есть и другие варианты выполнения того же самого.
Поглядите здесь. Я сам применяю первый вариант, там по сути две команды, первая из которых, AT+CIPCSGP, из модема не вылазит (настраивает параметры в самом модеме). А вторая, AT+CIPSTART, автоматически обеспечивает все действия, необходимые для подключения.
Может быть такой вариант будет менее глючным;

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

[david_off]

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

Прошивка 12 - самая новая из доставаемых. Теоритически есть 14, но это пока только теория.

- кроме применяемой вами группы команд, в SIM300 есть и другие варианты выполнения того же самого.

Спасибо, попробую. Может действительно дело упростится

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

Отвечу вопросом на вопрос. А почему бы не побробывать сделать побыстрее?
Опишу слегка конфигурацию системы и может тогда станет понятно зачем ускорять. Задача на один модуль собрать инфу о разных объектах. У меня в системе один из модулей (на котором замечено зависание) является "типа основным". Он пытается обзвонить все вторичные модули и узнать их IP адреса. Если вторичный заметил слет GPRS, то сам может позвонить на главный и инициировать обновление своего IP. Все вторичные настраивают себя как сервера. Когда на основной модуль приходят IP от от "вторичных модулей, то тот начинает у них сдаивать инфу о состояние их систем (через GPRS).
Опрос одним всех, вместо сливания всеми на один сделано для того, что бы на главный модуль не валилась куча пакетов от кучи вторичных. TCP/IP глючный в модуле SIM300C c 12 прошивкой. 100% замечено, что данные TCP пакета могут вывалится из порта раньше, чем поступит сообщение REMOTE IP:xxx. Т.е не получается в сплошном потоке корректно обрабатывать пакеты. Про этот баг даже сами китайцы писали
Когда же один опрашивает всех, то он может и подождать пару сек, пока там гарантированно вылезет REMOTE IP...

Так вот, в системе есть тонкое место, когда в районе пропало питание, разрядились все УПС а потом дали элекричество, то потом практически все начнут одновременно ломится на главное устройство. И чем раньше закончится ломление = обновится список IP на главном, тем раньше продолжится нормальная работа.

[Baser]

Отвечу вопросом на вопрос. А почему бы не побробывать сделать побыстрее?

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

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