<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 практически равна нулю, и проще подождать пару минут.

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

[david_off]

В моих применениях CSD не используется

А позвольте поинтересоваться, как вы пользуясь GPRS узнаёте IP адреса удалённых точек? Может я как-то нерациоанально сделал?
Сначала сам думал о приобретении статических IP - оказалось что оператор не может это сделать.
Потом думал пользоваться DynDNS и в главном модуле пользовать сервис DNS. Но так и не понял, как со вторичных мудулей посылать запросы на сервер DynDNS для обновления их IP.
Если вы подскажите как разрулить с DynDNS, то буду признателен. Мне кажется это будет более красивое решение обновления IP, чем через CSD.

Сообщение отредактировал david_off - Nov 7 2008, 09:37

[Baser]

А позвольте поинтересоваться, как вы пользуясь GPRS узнаёте IP адреса удалённых точек? Может я как-то нерациоанально сделал?

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

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