Модуль зарегистрирован, на тел дозваниваеться нормально:

at+creg?
+CREG: 0,1
OK

Линию DTR тоже отключаю:

at&d0
OK

Да действительно подключил вывод DTR на корпус все заработало!

at+cusd=1,"*111#",0

OK

+CUSD: 0,"Na rahunku: 8.09 grn. Info pro bonusy na *112# i *119#. SMS XL: SMS za
1 kopijku! Info:477*15 (bezkosht)",64

Оказалось что проблема даже не в линии DTR... а в формате вывода данных. Если установить:

at+cscs="GSM"
OK

Тогда нормально:

at+cusd=1,"*111#",0
OK
+CUSD: 0,"Na rahunku: 8.09 grn. Info pro bonusy na *112# i *119#. SMS XL: SMS za
1 kopijku! Info:477*15 (bezkosht)",64

Если же:

at+cscs="UCS2"
OK

Тогда:

at+cusd=1,"*111#",0
+CME ERROR: 3

Странно? СимКом выдает данные и в Юникоде...? Как же тогда быть если баланс передается кириллицей - слышал такое бывает?

Вы уж если выбрали уникод то пишите все строковые параметры в уникоде.
Т.е. at+cusd=1,"002A0031003100310023",0

Сообщение отредактировал =F8= - Dec 12 2009, 21:24

Спасибо понял...

Маленькое дополнение (относится к модулям SAGEM) - пишите все большими буквами - т.е. AT+CUSD... маленькие буквы не прокатывают...

Нет нормально и с маленькими работает:

at+cusd=1,"002A0031003100310023",0

OK

+CUSD: 0,"004E006100200072006100680075006E006B0075003A00200038002E00300039002000
670072006E002E00200049006E0066006F002000700072006F00200062006F006E00750073007900
20006E00610020002A0031003100320023002000690020002A0031003100390023002E0020005300
4D005300200058004C003A00200053004D00530020007A0061002000310020006B006F0070006900
6A006B0075002100200049006E0066006F003A003400370037002A00310035002000280062006500
7A006B006F0073006800740029",64

Прокатывает, только надо зафиксировать скорость(AT+IPR=....). Похоже автодетект недолюбливает маленькие буквы.

на 8 прошивке не прокатывают маленькие буквы. и AT+IPR не спасает

Проблема с буквами родилась не вчера. Видимо многие по разу наткнулись, поэтому сами французы (которые из техподдержки - которых вопросами терзают) строго советуют пользовать только большие буквы. Наверное уверены, что это сработает всегда. А то, что в описании написано, что прокатит и то и то, обещали убрать, но не сразу, а как руки дойдут. Кстати в описании есть еще пара советов (по схемотехнике), которые они настоятельно советуют выполнить. Лично я прочел их пару раз, и для меня необходимость показалась неочевидной, а они очень СТРОГО рекомендуют. Если кого интересует - выложу нарезку.

интересует.

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

После прошивки 8-й версии столкнулся с такой проблемой:
Если передавать блоками большой объем данных через встроенный TCP/IP стек с помощью at+ktcpsnd то модуль после определенного кол-ва переданных блоков не реагирует на EOF. Т.е. передавать уже ничего не передает, но и в командный режим не выходит. Такая ситуация тем более вероятна, чем больше размер блоков. С 6-й и 7-й версиями прошивок такой проблемы нет.

А по резисторам что...?

Самый правильный выход из ситуации - обратиться к тому у кого покупали модуль (дистрибьютер) и попросить его задать этот вопрос французам - через OTRS. Мне велено отвечать на вопросы только российских клиентов. В Украине есть свой дистрибьютер. По новой версии пока опыта мало - видимо Вы первый, кто на это наткнулся. Мне известна проблема, когда модуль, передавая большое количесвто коротких файлов, беспричинно затыкается и не может ни закрыть соединение, ни удалить его. Иногда возвращается к жизнии секунд через 50 (со слов заказчика). Иногда соединение удается удалить успешно, иногда возвращается ошибка. Если модуль к жизни не вернулся, то открытое соединение остается и номер следующей открываемой сессии инкрементируется. Такая ситуация довольно быстро исчерпывает количесвто возможных сессий (200 - максимум) и модуль затыкается навсегда - только аппаратный RESET спасает. Причем после него новое соединение с сервером всегда открывается нормально (со слов заказчика). Французы думали недели две и пришли к выводу что аппаратный RESET (сразу - на первом зависшем соединении) пока самое лучшее средство. По этой причине строго рекомендуют сажать вход RESET на GPIO процессора. Пока говорят, что всему виной оператор, его оборудование, качество связи и пр. Еще я слышал что такая ситуация встречается у многих производителей - вообщем дело темное.


Три подтягивающих к VGPIO резистора по 100к на сигналы RI DCD и DSR. Они открытые коллекторы в модуле и если принимающий процессор или драйвер без пулапа - будут болтаться.