Я без карточки оператора не проверю. На наших операторах все нормально, по крайней мере перепроверил на Киевстаре и МТС.

Можно попробовать поиграться с командой AT+CNMI - чтобы отчет не ложился в память, а сразу шел на отображение.
Кстати проверьте что там по умолчанию - там есть хитрое сочетание параметров которое не рекомендовано и может привести к непредсказуемому поведению модуля.

It is possible that ME/TA result code buffer is in volatile memory. In this case messages may get lost if the power of ME/TA is switched off before codes are sent to TE. Thus, it is not recommended to use direct message routing (<mt>=2 or 3, <bm>=2 or 3, or <ds>=1) with <mode> value 0 or 2.

CADiLO, cпасибо!
дело было в симке....
поменял на мегафон и все заработало

ETK, они же Ростелеком, они же - U-Tel (не путать с Украинским Utel)

Я спрошу у Симкомовцев по поводу U-Tel карточек. Насколько я помню с ними был какой-то вопрос, но столкнулись с ним в SIM5215.

Спрошу тут... Ближе всего к теме... Чтоб новую не создавать...

В SIM900_SerialPort_ApplicationNote_V1.02.pdf в пункте 5.2 интересная строчка о том что DTR надо подтягиватьк "0" когда идёт передача данных... для того чтобы работал CTS. Это так или я чот не так понял?

Когда хотите использовать RTS-CTS и идет передача на модуль, то данная фраза верна.
Только не забывайте что у DTR еще куча функций определяемых командой AT&D и пунктом 6.3 апнотеса.
Если чесно? то написано слегка запутано, я сам каждый раз сталкиваясь с работой DTR заново разбираюсь

хм.. понятно... Т.е. в настойку мне ещё надо включить AT+CSCLK=0, чтобы отключить sleep режим - оно автосохраняется? Или 0 - это вообще дефолтный параметр( в ДШ по AT не указано почемуто) ?


ЗЫ И тут такая штука ещё . DTR я подтягиваю к земле через СОЕ... Но он не подтятун к VDD_EXT, но на самом выводе 2.78 В. Так надо его подтягивать к VDD_EXT? Потому как сейчас работает и так...

В схеме модуле подтяжка к Vext имеется только на RI, DCD, DSR. Остальные выходят прямо из чипсета.
Есть ли там внутри что-то подтягивающее - не знаю.
Но учитывая что согласно SIM900_HD_V2.00.pdf входы RTS и DTR можно оставлять в воздухе, то они таки подтянуты в чипсете.
На Vext рекомендуется подтягивать только RXD.

А кто нибудь отправлял текстовое sms c wavecom, я так понял что поле того как зарегистрировался в GSM сети, т.е. на at+creg? пришел ответ +CREG: 1,1 то можно отпарвлять sms, может у кого то есть пример с минимальными натсроками? не надо ни отчетов о доставке, ни входящих сообщений, ничего короче лишнего, только отправить смс с тестом. А то модем подключен к контроллеру и лишнее городить совсем не хочется. И еще интересно если сообщение будет слишком длинное? Спасибо!

А есть ли команда, которая останавливает выполнение предыдущей команды?
Например:
Отправлена команда
AT+CPBR=1,250 - прочитать все номера с сим карты
в ответном сообщении найден нужный номер,
а данные продолжают идти.
Можно ли их отменить?

Такой команды нет.

Существует ли команда для модемов SIM900D для возврата к заводским настройкам?

AT&F

Только нужно иметь ввиду, что эта команда возвращает заводские установки только по небольшому числу параметров.
Хорошо хоть, что они перечислены в документации.


Вопрос к CADiLO - давно уже хотел спросить - а Вы китайцем не намекали, что очень неплохо было бы указывать в описаниях AT команд, сохраняются ли параметры команды в ОЗУ или во Flash. Это должно быть указано в нормальной документации - а его нет

Есть, конечно, документ SIM900_SIM300_ATC_Comparison_V1.01.pdf, где присутствует табличка.
Но этот документ все же не основной и старый.
А команды добавляются и частенько их поведение по части сохранения параметров от версии к версии меняется без предупреждения.
Что тоже напрягает. Приходится каждый раз производить натурные эксперименты

+1
Или, если выразить вышесказанное предельно прямолинейно - нет команды возврата к заводским настройкам.
Хотя команда AT&F в SIM900 номинально поддерживается, но в полном объеме она этого возврата, к сожалению, не делает...

AT&F возвращает только критические настройки - то есть после нее можно сделать нормальную инициализацию.
Полной "защитой от дурака" является только перепрошивка модуля - тогда полностью обновится область настроек.
Самое простое сделать один раз таблицу нужных вам настроек и прописывать ее всегда при инициализации модуля.

+100
Золотые слова!
Хочется вот только уточнить: о каком дураке речь? Дураке-пользователе или же дураке-разработчике?
Хотя, если принять во внимание факт, что для сброса ВСЕХ настроек вместо того, чтобы просто сбросить их одной командой (между прочим, специально для этого предусмотренной в стандарте!) приходится перепрошивать модуль, то ответ и так достаточно очевиден.

Вопрос может не совсем по АТ-командам, но не хочу создавать новую тему.
При AT+CREG=1 — разрешается выдача сообщения о смене регистрации в сети.
Антенна у меня PCB, и ловит заррраза хорошо, не могу сэмулировать пропажу сети.
Так вот - когда теряется сеть - что мне присылает модуль? Сперва +CREG: 0, потом +CREG: 2, и когда найдет сеть +CREG: 1? Или может +CREG: 0 пропустит, и сразу перейдет к +CREG: 2?

Рискну предположить, что это зависит как от модуля, так и от поведения чужих сетей. Telit GL868 + МТС:

У меня без антенны и пятерка иногда проскакивает - типа в роуминге.
Но чтобы долго держалась не получалось - пытаешься работать - хлоп - опять =0.

Т.е. получается надо обрабатывать все случаи, когда СREG не равно 1. Жаль, думал можно один обработать )))

Здравствуйте
А помогите разобраться чайнику,никогда не имевшему дела с Gsm модулями
Какая вообще последовательность инициализации модуля?
Собственно мне нужно - позвонить, установить csd соединение, передать пакет данных и разъединиться
Как это сделать?

1. Подключиться терминалом к модулю и подать питание
2. Для некоторых модулей нужно притянуть сигнал ON/~OFF (он же PWR_KEY) к земле, а потом желательно отпустить.
3. Определить скорость, на которой работает модуль и поменять в терминале скорость на нужную, либо заставить сработать автодетект скорости на модуле, если он есть.
4. Подать команду AT и поглядеть ответ.
5. Установить режим передачи данных AT+CBST=71, хотя и без этого должно работать.
6. Набрать ATD+7номер телефона
7. Дождаться соединения: CONNECT 9600
8. Набрать что угодно в терминале - это будет передано по модему на удаленный модем.
9. Набрать +++
10. Набрать ATH

Всё.

Так заработало
Большое спасибо.
А я начал с discovery tools сиерровской, думал там подсмотрю чего шлеться,
- а с нее даже позвонить не получается

Помогите чайнику. Собрал охранное устройство + модем на SIM300DZ. Звонит, отправляет SMS.Не отвечает на запросы с текстом stat и rst.
Вот выдержка из описания устройства.
Данное устройство предназначено для охраны и наблюдения за удаленными объектами. Оно может дозваниваться до телефонных номеров из списка (не более 3), записанных в EEPROM PIC'a, а также отправлять SMS. Основу составляет PIC16F628A. Он отсчитывает необходимые интервалы времени и управляет мобильным телефон посредством некоторых AT команд, а именно:
• ATD<тел. номер>; - вызов.
• ATH - отмена вызова.
• AT+CMGS=<pdu length> - отправка SMS.
• AT+CMGR=n - читать SMS с sim.
• AT+CMGD=n - удалить SMS c порядковым номером n.
Чтобы процессор знал о приходе новой SMS, устанавливается режим индикации входящих сообщений командой AT+CNMI=1,1,0,0,1.
Есть возможность узнать в любой момент состояние всех четырех датчиков, для этого надо отправить на номер SIM карты используемого в устройстве мобильника сообщение с текстом "stat". Для сброса устройства необходимо использовать текст "rst"
Ввожу команду AT+CNMI=1,1,0,0,1 Пишет: OK.
Спрашиваю AT+CNMI? Отвечает AT+CNMI:1,1,0,0,0
Как ни бился последнюю цифру изменить не смог. У автора телефон Siemens C35, у меня модем на SIM300DZ. Что я не так делаю?
Суважением.

>>>Что я не так делаю?

Не читаете документацию

+CNMI: <mode>,<mt>,<bm>,<ds>,<bfr>

SIM300_ATC_V2.03.pdf
страничка 3
4.2.9 AT+CNMI Remove the value 1 of parameter <bfr>

Поэтому последний параметр всегда и будет 0

Я не программист, я практик. Почитал форум, купил SIM300D, спаял схему и получил облом.
Текст SMSок и номера телефонов записаны в контроллере. На SIM карте ни чего не должно откладываться. В буфере модема тоже. Вся информация при приходе SMS должна идти сразу в контроллер. Почитал Руководство по использованию АТ-команд для GSM/GPRS моде- мов.: Пер. с англ. – М.:
9.9. Индикация нового сообщения: +CNMI
9.9.1. Описание
Данная команда производит отбор процедуры индикации о получении но¬вого сообщения.
И если честно мало что понял.
Может, подскажете, какие значения нужны в моем случае?
С уважением.

Подозреваю что таки AT+CNMI=2,2

Спасибо. В понедельник попробую. Дома нет СОМ порта. Остальные значения можно оставить как есть? - AT+CNMI:2,2,0,0,0

Вот есть вопрос по автомату состояния, обслуживающему входной поток символов от модуля (SIM900). Собственно, хочется сделать его относительно гибким, чтобы можно было усложнять функции, а также как-то упорядочить процесс их выполнения при асинхронном возникновении различных событий.
Пока что имеем такие задачи:
1) Отправка SMS по событию, детектированному прибором с датчика.
2) Прием SMS из сети с просьбой подключится к серверу
3) Установление GPRS-соединения с сервером и отправка журнала работы, прием команд и сопутствующих бинарных данных.

На данный момент разработана схема, где к микроконтроллеру подключены только RXD, TXD, RI, в расчете на Software flow control и аппаратное определение событий по сигналу RI, таких как прием СМС.

Вопросы:
1) Нужно ли работать с включенным эхо или нет? Вначале я думал по эху контролировать, что модуль честно принял команду, и можно перевести автомат обработки в состояние ожидания ответа, но на самом деле он может в ответ сам начать что-то слать в середине моей команды, см пример ниже. В этом случае получается какой-то непредсказуемый обмен.
2) Каким образом отслеживается условие, что модуль закончил ответ на последнюю выданную команду? Проблема заключается в том, что есть команды, которые выдают только один ОК, есть такие, которые выдают ответ, потом ОК, есть такие, которые выдадут ответ, но без отдельного ОК. Наконец, бывают такие, которые выдают сначала ОК, потом подумают, и еще чего выдадут, например AT+CDNSGIP. В итоге, идея о том, что можно будет сделать какой-то простой детектор, накрывается медным тазиком. В особенности, если учесть, что возможны вклинивающиеся ответы, см следующий пункт.
3) Каким образом отличать, что в ответе относится к ответу от моего запроса, от того, что пришло, скажем из сети. Ниже я привожу пример, как я стал писать команду AT+CPIN? и в этот момент позвонил на этот номер, потом повесил трубку и закончил ввод. В данном случае посыпался RING. Аналогично может посыпаться +CMTI от SMS и Бог его знает, сколько еще всего неизведанного. Можно ли так построить код, чтобы все подобные неожиданности не порушили задуманных алгоритм работы?
4) Как вообще правильно поступать, если возможны асинхронные события, порождающие независимые задания для модуля? Например, пришла СМС-ка, подключились к серверу, стали передавать ему журнал работы (лог). Пока передавали лог за сутки, сработал датчик, и теперь надо послать СМС. СМС подсистему можно дергать сразу или нужно дождаться конца сессии с сервером, успокоить модуль, забрать и проанализирвоать все статусы и вот потом начинать с ним затею с СМС?
5) Если много команд выдается подряд без эха, то как узнать где ответ на какую команду? Или, не надо так делать? Если ждать ответа на каждую, то скорость обмена падает. Хотя пока что для нас это не очень критично, объем данных относительно невелик, зато NAND-буферы огромны.

Насколько я понимаю, все эти проблемы не относятся напрямую к теме FLOW CONTROL, так как никто не отказывается от приема данных с максимальной скоростью, вопрос лишь в том, как их обрабатывать.

Вот такой фрагмент сессии из гипертерминала был:


вот такой вот бывает ответ на AT+CDNSGIP

1. Эхо рекомендую выключать. Кроме всего прочего оно существенно замедляет обмен.
2. Действительно, о простоте говорить не приходится.
3. Асинхронные посылки модуля НИКОГДА не попадают внутрь строки ответа модуля. Посему каждую строку принятую от модуля в процессе обработки команды нужно проверять на совпадение с ожидаемой асинхронной репликой (тем же RING, например) и регистрировать их в очереди входных событий. А очередь эту обрабатывать уже после завершения обработки самой команды.
4. Можно поступать, как душе угодно, но команды на модем должны отдаваться последовательно: следующая команда должна подаваться ТОЛЬКО ПО ЗАВЕРШЕНИИ предыдущей. Под завершением понимается выдача OK|ERROR. Все, что команда выдает после этого нужно уже рассматривать как асинхронную посылку.
5. Да, скорость обмена падает, но не настолько, как при включенном эхе. Но в данном-то случае нас интересует же не скорость обмена, а скорость выполнения команд.

Спасибо, это уже что-то. Тогда дополнительные вопросы еще:
1) Как определить, какая входящая строка есть ответ на мою команду, а какая - асинхронный вывод на произвольную команду? Чтобы не быть голословным, приведу пример команды AT+CCID, лог которой в предыдущем посте есть. Видно, что первая строка ответа есть запрошенный идентификатор, но можно ли рассчитывать, что так будет всегда, и что туда не вклинится какой-нибудь RING или другой асинхронный ответ? Был бы ответ вида +CCID: nnnn, проблем бы не было.
2) Существует ли какой-нибудь критерий асинхронного ответа, чтобы его можно было игнорировать, если для него нет обработчика? Мне не очень нравится перспектива, когда в процессе работы асинхронные ответы начнут появляться и портить логику работы необходимых команд.
3) Существует ли вообще перечень асинхронных ответов, которые могут порождаться конкретным модулем?

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

Что бы легче было понять где чей ответ включаю эхо, на идиотские ответы приходится ожидать уже не просто ОК, а ожидать строку (в конце знак конца строки всегда есть), ту же входящую строку можно проверять на длину/наличие определенных знаков/их количество и т.п.

Как определить ответ на AT+CCID ??? Ну можно пробовать ориентироваться на:
1. Эхо AT+CCID
2. Длину ответа
3. Проверить весь ответ что бы там были цифры, без букв/точек и т.п.

Как проверить ответ на AT+CIFSR ??? (ответ IP)
1. Эхо AT+CIFSR
2. В IP 100% должно присутствовать 3 точки + все остальное цифры, между точками должно быть от 1 до 3 цифр и т.д.

и т.п.

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

Имхо, при проектировании обмена следует считать, что OK/ERROR - это ответ модуля на команду: "Команда принята к исполнению/Отвергнута". Команды должны передаваться по одной (одна за другой по получении ответа OK/ERROR или по тайм-ауту, в случае, если нет ответа). Всё остальное в ответах, считать приходящим асинхронно (возможно, а иногда - как правило, до ответа OK/ERROR). Впрочем, и сами ответы OK/ERROR можно расматривать как асинхронные.
В этом случае выдача команд производится следующим образом:
1. Выдаём команду (предватительно сбрасывается признак приёма команды OK/ERROR)
2. Некоторое время опрашивать "драйвер/диспетчер команд" на предмет получения OK/ERROR
3. При ОК - запросить у "драйвера/диспетчера команд" ответ на эту команду (как правило, начинаются они на "+команда" - исключений не так уж и много). Запрашивать ответ - в течении некоторого времени.
4. При неполучении ответа за некоторое время в п.п.2 и 4 - тайм-аут.

Integral

Похоже, Вы не читали мое предыдущее сообщение, первое в этой теме. На эхо вообще нельзя ориентироваться, потому что в него может вклиниться любой асинхронный ответ модуля. В качестве примера я привел RING.

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

Вопрос только в том, есть ли какое-либо простое правило, по которому можно сказать, что очередная строка от модуля - это асинхронный ответ? Если все асинхронные ответы пустить через отдельный обработчик, то тогда можно вполне довольствоваться тем, что ответом на AT+CCID является первая не пустая строка.

И еще. Для устойчивости приложения ставится цель: не ловить всякие нестандартные ответы, а игнорировать их, чтобы они не мешали работать основному алгоритму.

Палыч
Проблема в том, что, как я писал уже в первом посте:
1) есть команды, которые не выдают OK, а выдают ответ.
2) есть команды, которые выдают ответ, а потом ОК
3) есть команды, которые выдают ОК, потом выдают ответ.
4) не все ответы имеют формат "+команда: ...", что затрудняет их идентификацию в качестве ответа.

Пример, пожалуйста. Возможно, Вы имеете в виду команду отправки СМС, которая, можно считать, состоит из двух частей (команд), тогда на первую часть (команду) аналогом ОК будет приглашение ввода тела СМС (символ ">").

Если ответ ОК считать таким же асинхронным, то оба этих варианта превращаются в один...

Да, затрудняют, но не делают задачу невожможной. Тем более таких ответов: раз-два и обчелся (навскидку - RING, и, что-то не вспомнилось более...)

Тогда сработает таймаут и отправим повторно команду, не будет же до бесконечности вклиниваться, та и случаи такие редкие, или нужен мегоалгоритм за 100 лет работы ни единого еррора от модуля?

Где мало памяти я вообще пробовал не ловить ответы, ловлю только ерроры, есть такое мнение, что если НЕ ЕРРОР, значит все ОК, для компактности шлем команды "в слепую" с предусмотренной задержкой, и все, нормально работает, а вот если уже появился еррор, цпин нот реади, коннект клосед и т.п. уже разбираемся. В общем по компактности/сложности/универсальности можно реализовывать под конкретные задачи оптимальные решения

Вот как раз AT+CIFSR у симкома. Выдает ip адресс и никакого OK.
Я для таких случаев, да и вообще для любых команд ответ на которые отличается от OK/ERROR, использую одельныю функцию-обработчик котрая вызывается(если указатель != NULL) перед обработчиками unsolicited result code и стандартных ответов(OK/ERROR). В итоге если попадается то-то вроде AT+CIFSR эта функция сама отправляет сообщение OK когда приймет ip адрес. Кроме того при таком подходе не нужно парсить все возможные ответы тогда когда они в принципе прийти не могут, плюс расширяемость...

На эхо не нужно ореитнироаться потому, что это совершенно излишне. Ориентироватся надо на ответ. Вероятность, что модуль приймет вашу команду за другую и выдаст при этом корректный ответ практически равна 0. Эхо, собственно, нужно только для удобства работы с модулем/модемом через терминал.

Да, действительно. Заглянул в документацию и был неприятно удивлен, что команды из раздела "AT Commands for TCPIP Application Toolkit" резко "выпадают" из не такого уж стройного ряда АТ-команд.

Имхо, эхо - только усложняет разбор ответов от модуля, подключенного к контроллеру/компьютеру. Эхо включаю только в единственном случае: когда с модулем идёт работа "руками/глазами" через какой-нибудь терминал.

Сделайте векторными обработчик Ок и ERROR. Кроме того можно сделать векторный таймер. Все остальные ответы можно считать асинхронными. При получении нужного ответа по Ок до Ок обработчик Ок переключаем на заглушку.

ЗЫ. Как ни странно самая каверзная команда - отправка SMS т.к. она не заканчивается переводом строки, что вынуждает ее обрабатывать особенно...


У которого нет мониторинга исходящего потока и нет собственного эха.

А бывают ли команды, которые выдают содержательный ответ после ОК, но не в форме "+команда: ответ"?

Если нет, то можно не мудрить с обработчиками, а использовать парадигму Aurochs, согласно которой синхронный ответ выдается до тех пор, пока не придут OK или ERROR. Все следующие ответы можно считать асинхронными, и они имеют, как правило, признаки причастности к породившей их команде. Например, AT+CDNSGIP выдает OK, потом через секунду - +CDNSGIP: "ip-адрес".

Для SIM900 знаю только одну такую команду AT+CIPSTATUS
И для нее нужен специфический обработчик.
Фразы CONNECT OK, CONNECT FAIL и т.д. можно и нужно рассматривать не как часть ответа на команду, а как асинхронную реплику. В противном случае придется "западать" на несколько минут на обработку одной команды, никак не реагируя на другие события (на тот же входящий звонок, например).

Ответ весма специфический. Нет бы сделать +CIPSTATUS: N, где N - номер состояния сокета.
Но ничего не поделаешь.


Зачем "западать"? Да ещё и на несколько минут?
Больше минуты на наблюдал.



Просто нужно быть готовым принять RING (и другие нужные реплики) во время ожидания ответа на AT+CIPSTART.

Как можно отослать несколько команд одной строкой?
Для составных команд понятно (AT+IPR=19200;+CREG=1;+CMGF=1\x0d)
А как быть, когда среди них есть простая команда, вроде ATE0 или ATV0?

AT+IPR=19200;E0;V0
не помогает?
Вот только не все команды вместе так прокатят... Помнится именно с AT+IPR и еще чем-то у меня получилась проблема...

Зависит от модуля. Стандартами это не описано, поэтому каждый производитель делает по своему разумению. В некоторых случаях и "простые" команды выполняются по одной команде в строке.

Поделитесь пожалуйста примером парсинга +CLIP: "+7928XXXXXXX",145,"",,"Name",0.
Пока пользуюсь:

может есть что-то изящнее?

Здравствуйте.

Я хочу попробовать считать контроллером СМС от модуля SIM900. Мне необходимо сохранить номер отправителя и само сообщение, провести простейшую операцию над сообщением и отослать ответ обратно отправителю. Когда я запрашиваю контроллером СМС, то модуль, по даташиту, должен ответить следующее:
Нажмите для просмотра прикрепленного файла
Подскажите пожалуйста, что в этой команде (ответ модуля) будет постоянным всегда ? Как лучше считать номер и само сообщение ? У меня, на первый взгляд, такие варианты:

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

Контроллер PIC16, компилятор MPLAB + CCS C.

Мне кажется, лучше, после получения +CMGR, считать запятые и, уже после первой запятой, читать содержимое в кавычках.

Telit модуль, терминал Termite 2.9, оператор МТС Украина
Не могу проверить счет
При запросе
все хорошо, ответ приходит как видно, а при запросе проверки счета получаем следующее:
, если првильно понимаю +CUSD: 4 - ответ не поддерживается

Раньше эта сим карта стояла в модуле Wavecom получал следующий ответ:

Подскажите в чем может быть проблем?