В общем такая ситуация: Берем модуль, подключаем питание на RTC - потребляемый ток около 0.1mA. Затем подаем и снимаем основное питание, при подключенной батарейке - потребляемый ток падает до 6uA. Вывод - после того как поставили батарейку надо включить-выключить основное питание.

не готов сразу комментировать ... "надо посоветоваться с шефом"

На самом деле, мы готовим большой апноут по энергопотреблению GSM модулей. правда обещали его опубликовать еще в августе, но пока почему то он не готов. как только будет готов, я сразу выложу сюда. тем более он процентов на 80, думаю, будет применим к любым GSM модулям...

Дополнительная информация по RTC
Нажмите для просмотра прикрепленного файла

И вот обещанный апноут.

Еще одна багофича от телита, чтоб не создавать новую тему опишу здесь.
Цифры перед сообщениями - системное время в мс.

//Нормальный входящий вызов
44475 ->gsm: AT+CSQ
44487 <-gsm: +CSQ: 17,0
44489 <-gsm: OK
//Сообщение о входящем вызове
45451 <-gsm: #ECAM: 0,6,1,,,
45453 <-gsm: RING
//В ответ на сообщение проверяем состояние модуля с помощью AT+CLCC
45453 ->gsm: AT+CLCC
45471 <-gsm: +CLCC: 1,1,4,0,0,"###########",145,""
45473 <-gsm: OK
gw: Alering //Переходим в состояние приема вызова
//Повторно проверяем состояние непосредственно перед подачей ATA
45502 ->gsm: AT+CLCC
45517 <-gsm: +CLCC: 1,1,4,0,0,"###########",145,""
45520 <-gsm: OK
//Принимаем вызов
46028 ->gsm: ATA
46410 <-gsm: #ECAM: 0,3,1,,,
46412 <-gsm: OK
46432 ->gsm: AT+CLCC
46450 <-gsm: +CLCC: 1,1,0,0,0,"###########",145,""
46452 <-gsm: OK
.....................................................

//Системма переодически проверяет свое состояние с помощью CLCC
//Перед этим сообщений #ECAM не было, т.е. CLCC "видит" изменение сотояния до прихода #ECAM
61839 ->gsm: AT+CLCC
61857 <-gsm: +CLCC: 1,1,4,0,0,"###########",145,""
61860 <-gsm: OK
//Тест состояния модуля получение текущего времени итд.
61860 ->Phone::Test()
61880 ->gsm: AT+CREG?
61902 <-gsm: +CREG: 0,1
61904 <-gsm: OK
61910 <-Phone::TestNetReg() 1
61924 ->gsm: AT+CCLK?
61940 <-gsm: +CCLK: "00/01/01,00:00:59+00"
61942 <-gsm: OK
gw: Test OK

//Повторно проверяем состояние непосредственно перед подачей ATA
61971 ->gsm: AT+CLCC
61992 <-gsm: +CLCC: 1,1,4,0,0,"###########",145,""
61995 <-gsm: OK
//Принимаем вызов
62503 ->gsm: ATA
62521 <-gsm: NO CARRIER //В ответ NO CARRIER
63451 <-gsm: #ECAM: 0,6,1,,, //Наконец получаем сообщение о входящем вызове теперь можно давать ATA


6345 - 61857 = 1594mc AT+CLCC "увидила" входящий вызов на 1.6 сек раньше чем пришло сообщение #ECAM

Официальный ответ производителя:

Остается только понять почему самопридуманая ECAM имеет приоритет над описаной в стандарте GSM 07.07 командой CLCC.
А потом говорят что китайцы самодеятельностью занимаются.
Ну и как же тесты на то что прибор соответствует "М2М" ?
Там тестирование должно пройти только с применением команд описаных в GSM 07.07 - нестандартные команды применять запрещено.
А получение значка "M2M compatible" как раз и говорит об унификации - то есть модем сменили, а софт продолжает работать.

Телут всегда прав, если Телут не прав - смотри пункт первый

Ну это понятно - с мЭтром не поспоришь.....

Ответ в стиле "задокументированный баг становится фичей" ), благо хоть обойти эту фичу несложно.

как бы названия путаете

CADiLO, а почему больший приоритет.
CLCC я так понимаю работает с аппаратным RING согласно 3GPP?

Да, поэтому АТА сразу после изменения состояния CLCC должна приводить к соединению, а не ждать изменения ECAM.

Кстати если посмотреть на то что выдает CLCC, то видно что состояния команды явно стянуты с протокола ранее использовавшегося в межстанционном ИКМ - а там ответ (еще до появления MFC-R2 и далее SS7) был аппаратный сразу на изменение состояния.

Мне кажется что это было сделано с целью упрощения подключения GSM коммутаторов к городским станциям через ИКМ тракты, и чтобы не мудрить сделали сквозной совместимый протокол. Состояния CLCC просто транслируются в/из соответсвующих битов служебного фрейма и совпадают по назначению. Очень на то похоже.

Ну что ж, сделал эксперимент на SIM900B:

Соответственно, если использовать +CLCC в строгом соответствии со стандартом 3GPP, задержка между ответом на +CLCC по поллингу и RING также измеряется секундами. А вот проверить нестандартную функцию +CLCC (+CLCC=1) таким образом не удалось, поскольку URC и ответ на AT+CLCC ничем не различаются.

Прошу - стандартное использование CLCC=0

AT+GSV
SIMCOM_Ltd
SIMCOM_SIM900
Revision:1137B08SIM900M64_ST_DTMF_JD_MMS

OK
AT+CLCC?
+CLCC: 0

OK

AT+CLCC
OK

AT+CLCC
+CLCC: 1,1,4,0,0,"+38056236xxxx",145,""
RING
OK
// здесь ответ СLСС и первый RING всегда одновременны, та же ситуация и при автоматическом отслеживании при CLCC=1
ATA
OK
//стазу же снимаем трубку - никакого ожидания


Хочу повториться что SIM900В изначально для нашего рынка не предназначался (Индусам делали) и сертификации под некоторые стандарты не проходил.
Кроме того он может значительно отличаться в логике работы даже в пределах прошивок для ST и SAMSUNG.
Поэтому мы их не возим, окромя как "особо хотящим" под заказ и на правильность работы SIM900B не полагаемся.
Эталонным является SIM900 - и если там есть ошибки, то убираются в первую очередь именно в нем - остальные модули по принципу - "когда руки дойдут"

Вы не упомянули, какой временной интервал между первой командой AT+CLCC и второй. По большому счету, нужно сделать поллинг AT+CLCC и ATA сразу после первого ответа +CLCC: 1,1,4,0,0,"+38056236xxxx",145,"". Не факт, что модуль сразу поднимет трубку. Если получится - сниму шляпу
Касательно SIM900B - просто он первый под руку попался. Не сомневаюсь, что и SIM900 так же работает.

Второе CLCC сразу по завершению набора номера на вызывающем телефоне.

Я подчеркиваю что если поставить автоопределение CLCC то его изменение на этой прошивке всегда будет одновременно с первым RING.
И ответ ATA можно отдавать сразу же.

Что мы кстати видим и на логе, иначе бы первый ринг проскочил до того как я успел отдать команду CLCC.
Так как команды отдавал вручную из макросов, то естественно старался угадать именно момент изменения состояния CLCC.
Увидел ответ - тут же АТА. Время конечно по принципу "увидел-нажал", но это доли секунды и никак аж не две и более.

То есть все работает так как и положено.

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

Можно было бы предположить что модуль сам дает паузу ПЕРЕД изменением CLCC, потому и приходит одновременно с RING.
Но я отправлял AT+CLCC фактически после нажатия последней кнопки на телефоне с которого вызывал модуль и уже был вызов.

Собственно, поскольку +CLCC=1 это нестандартная фича (по отношению к 3gpp), то же самое можно сказать и про #ECAM - его изменение будет всегда одновременно с RING

Согласен, но CLCC=1 я не применял. Привел просто для примера.
А RING все равно идет одновременно с изменением состояния CLCC.

Впрочем неважно - можно отключить текстовые URC и ориентироваться только на появление изменений в CLCC.
Но то что АТА в SIM900 отработает по факту изменения без паузы, тут я уверен.

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

Не могу не согласиться.