[=F8= 0]

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

[Telit 0]

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

 

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

 

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

 

 

[molecul 0]

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

Дополнительная информация по RTC

[molecul 0]

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

[=F8= 0]

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

Цифры перед сообщениями - системное время в мс.

 

//Нормальный входящий вызов

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

[molecul 0]

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

to answer a call you have to wait for the RING indication that is sent just after the #ECAM: 0,6,1 URC.

 

 

 

at+clcc

+CLCC: 1,1,4,0,0,"+39xxxxxxxxxx",145,""

 

 

OK

ATA

NO CARRIER (not ready)

 

 

#ECAM: 0,6,1,,,

 

 

RING

 

 

ATA

#ECAM: 0,3,1,,,

 

 

OK

 

 

Only after #ECAM or RING the module is ready to answer a call.

 

[CADiLO 11]

Остается только понять почему самопридуманая ECAM имеет приоритет над описаной в стандарте GSM 07.07 командой CLCC.

А потом говорят что китайцы самодеятельностью занимаются.

Ну и как же тесты на то что прибор соответствует "М2М" ?

Там тестирование должно пройти только с применением команд описаных в GSM 07.07 - нестандартные команды применять запрещено.

А получение значка "M2M compatible" как раз и говорит об унификации - то есть модем сменили, а софт продолжает работать.

 

[sobr 0]

Остается только понять почему самопридуманая ECAM имеет приоритет над описаной в стандарте GSM 07.07 командой CLCC.

А потом говорят что китайцы самодеятельностью занимаются.

Ну и как же тесты на то что прибор соответствует "М2М" ?

Там тестирование должно пройти только с применением команд описаных в GSM 07.07 - нестандартные команды применять запрещено.

А получение значка "M2M compatible" как раз и говорит об унификации - то есть модем сменили, а софт продолжает работать.

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

[CADiLO 11]

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

:)

 

[=F8= 0]

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

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

[alexQ 0]

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

 

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

[Telit 0]

Остается только понять почему самопридуманая ECAM имеет приоритет над описаной в стандарте GSM 07.07 командой CLCC.

А потом говорят что китайцы самодеятельностью занимаются.

Ну и как же тесты на то что прибор соответствует "М2М" ?

Там тестирование должно пройти только с применением команд описаных в GSM 07.07 - нестандартные команды применять запрещено.

А получение значка "M2M compatible" как раз и говорит об унификации - то есть модем сменили, а софт продолжает работать.

 

CADiLO, а почему больший приоритет.

CLCC я так понимаю работает с аппаратным RING согласно 3GPP?

[CADiLO 11]

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

 

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

 

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

[molecul 0]

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

AT+CLCC // режим ожидания

 

OK

AT+CLCC

 

OK

AT+CLCC

 

OK

AT+CLCC

AT

OK

+CLCC

AT+CLCC // поступление вызова по CLCC, RINGа нет!

 

+CLCC: 1,1,4,0,0,"+7911XXXXXXXX",145,""

 

OK

 

// и так около 2 секунд

 

AT+CLCC

 

+CLCC: 1,1,4,0,0,"+7911XXXXXXXX",145,""

 

OK

 

RING // и только через 2 секунды приходит RING

AT+CLCC

 

+CLCC: 1,1,4,0,0,"+7911XXXXXXXX",145,""

 

OK

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

 

[CADiLO 11]

Прошу - стандартное использование 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 - и если там есть ошибки, то убираются в первую очередь именно в нем - остальные модули по принципу - "когда руки дойдут"