Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

1 - можно.
2 - реализуемо.
3 - AT командами можно определить оператора. Особенности работы с конкретным оператором выясняются опытным путем.

А какой конкретно GPRS? TCP, UDP, почта, WEB? Только отправка данных, или двухсторонний обмен? Есть ли потребность в минимизации трафика?

Все пока на стадии инициации проекта. Толком еще не расставлены акценты. Все еще в виде черновика и мутных планов.
Но точно необходимо будет:

1. Технология будет похожа на клиент-серверную организацию;
2. Скоррее всего на стороне сервера будет статический IP;
3. Минимальный трафик;
4. Обмен данными двухсторонний, но есть мысли о том чтоб клиенты получали информацию читая данные из тиблиц БД на сервере, отправляли данные записывая данные в БД на сервере. Таким образом нам не нужно будет работать напрямую от сервера к клиенту.

В принципе можно поднять на сервере TCP сервер или WEB сервер. Выбор технологии будет связан с клиентской стороной. На стороне клиента(тов) будут SIM900 и Ethernet модули.

Всё это описано в документе "SIM900 TCPIP Application Note", с примерами команд.
Думаю, вам подойдет прозрачный режим - настроили модуль, подняли соединение, и общаетесь с сервером напрямую, посылая и принимая данные из сокета прямо с последовательного порта. Если при этом будет нужна обработка звонков и SMS, то можно подключить контакт RI к контроллеру, и модуль будет информировать о входящих SMS и звонках импульсами на этом контакте.

Да, спасибо.

Что имею на сегодня:
1. Поднял на сервере с статическим адресом от провайдера TCP-сервер.
2. AT командами установил на модеме SIM900 соединение с сервером.
3. Успешно попробовал отправлять данные от модема к серверу.

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

Подскажите, каким вы пользуетесь софтом для работы с АТ командами? Каким для работы с СОМ портом?
Попробовал "Terminal.exe" и "COM Port Toolkit 3.9". Мне показались они не оч. подходящими.

Спасибо!

PuTTY приличный терминал для COM-порта.

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

Насчет поддержания сессии - рекомендую определить на сервере какую-то последовательность, на которую он просто отвечает и не выполняет никаких действий. например, если отправить на сервер "NOP", сервер вернет "NOP OK". SIM900 должен отправлять этот "NOP" раз в минуту и если получает ответ, значит сессия жива, иначе её надо переустановить. Суть в том, что на механизм TCP надеяться не следует - если в течение какого-то времени по TCP-сессии не передается никаких данных, многие файрволы просто забывают о ней никак не уведомляя клиент и сервер, и оба шлют данные в никуда.

Спасибо за советы.

Еще не очень понимаю, как именно посмотреть статистику по расходу трафика на стороне модема? Как понять сколько трафика расходует SIM900 в GPRS режиме в данных конкретных обстоятельствах?

По поводу "NOP" - "NOP OK" это наверное правильно, ведь если на серверной стороне я еще смогу понять что нет линка с конкретным клиентом средствами самого сервера, то на клиенте все далеко не так очевидно. Хотя вообще чайник ,могу и ошибаться.

Сейчас у меня при простое модема с поднятой сессией отваливается "PDP DEACT"

Счетчиков трафика в модуле я не нашел, но я не вижу в них смысла - вы же сами принимаете и передаете все данные и сам знаете сколько передали и приняли. Есть, конечно, оверхед протокола TCP, но им можно пренебречь т.к. оператор всё-равно округлит количество данных, переданных по каждой GPRS-сессии до сотен килобайт в большую сторону, поэтому считать байты, как было на GPRS-WAP смысла нет.

Можно пойти пацанским путём: использовать PPP и внешний tcp стек, благо нынче и железа подходящего полно и софт есть
например lwIP и STM32 и любой модем включая проводные))

Гораздо проще использовать UDP. На сервере держите всего один сокет, при получении пакета от клиента проверяете контрольную сумму, сохраняете данные в базе, возвращаете КС на IP/порт отправителя.
Алгоритм клиента: если есть новые данные, поднимаете GPRS, отправляете данные и КС, ждете ответа 2-3 сек, если нет, то повторяете 3-5 раз. После получения подтверждения или исчерпания попыток рвете GPRS (если сеансы реже 5-10 мин), или оставляете, если чаще.
Преимущества: не нужна поддержка открытой ТСП-сессии, нет процедур конекта/дисконекта, гарантийность доставки и таймауты организованы под задачу, а не универсал. Т.к. у вас статический IP на сервере, не надо ресолвить доменное имя. Трафик, как минимум, в 1.5 раза меньше, чем в случае с ТСП.
С помощью OpenCPU/EAT это реализуется за час. И, кстати, почему Вы не хотите использовать EAT? Если нет желания изучать все команды, можете использовать всего одну - отправку данных в виртуальный порт. И один обработчик - получение данных с него. А дальше отсылайте АТ-команды, и получайте ответы так же, как и в случае с внешним процессором. И надежней, и дешевле, и код переносимый будет.

Что касается канала сервер-диспетчер, то тут как угодно, например, SQL.

Не соглашусь про разрыв GPRS - оператор округлит объем в большую сторону и 20 байт превратятся в 100 килобайт.
Про UDP тоже не всё так просто. Если сервер захочет передать модулю какие-то данные не сразу после прихода сообщение от модуля, а в произвольное время, то не факт, что они дойдут т.к. файрвол провайдера может просто забыть об этой сессии. Клиенты мобильных операторов сидят за NAT, адресов не так много, поэтому неактивные сессии там устаревают и сбрасываются очень быстро. С TCP же понятно подключен ли в конкретный момент конкретный модуль к серверу и дошло ли сообщение. Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

Не все операторы это делают, и объем округления тоже разный. Надо смотреть индивидуально, и учитывать время между активностью. Дело в том, что всегда имеется фоновый IP-спам, который тарифицируется в случае, если сисоп назначает модую "белый" IP. Поэтому решение о разрыве надо принимать по факту, исходя из задачи и условий.

По условию ТС сервер поднят на белом IP. Поэтому, независимо от того, какой IP назначен сисопом модулю, первый же и любой пакет, отправленный с модуля на сервер в любое время, инициирует фаервол провайдера, и будет выпущен наружу. Т.к. по определению на серверной части нет фаервола, то он будет доставлен. NAT со стороны провайдера будет инициализирован, и сервер имеет около 3 минут на ответ. По истечение этого времени NAT провайдера закроет соединение, и сервер никак не достучится до клиента, аж до следующей активности клиента. Если передачу "клиент-сервер" по условию задачи инитит только клиент, то все ОК. Если требуется возможность активации клиента со стороны сервера, то, как по мне, проще сделать это входящем звонком клиенту (при разумном количестве клиентов и редких случаях, например, конфигурирование клиента), чем держать все время отрытую TCP-сессию.

Именно к этому я и веду: многие разработчики, со студенческой скамьи запомнив, что TCP обеспечивает гарантированную доставку, понятия не имеют, как на самом деле это происходит. Более того, в большинстве случаев не могут повлиять на таймауты переотправки, закрытия и т.п. сокета, определяемые внутренними настройками TCP-стека. Известно: универсальных вещей хороших не бывает. Если вы сделаете свой слой гарантийной доставки и контроля под задачу над UDP, то он будет однозначно лучше штатного TCP. Но обычно лень побеждает, и придумываются оправдания.

Под SIM900 и AVR например есть готовые опенсорсные библиотеки, которые умеют TCP, у вас что будет подключено к SIM900? МК?

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

Не понял. А для чего именно РРР и внешний стек? Мне интересно использовать GPRS так как во многих местах и случаях это единственный способ связаться с сервером.
lwIP и STM32 это как раз сейчас в работе, но это канал связи там где есть инет.



Спасибо за совет.
Во-первых: мне нужно не проще а надежнее, стабильнее и прозрачнее. То есть, канал связи обязательно должен быть построен с использованием правильной архитектуры. Если не будет хватать знаний и навыков - будем вникать. Алгоритм клиента планируется в принципе иной. Я хочу отправлять и принимать данные на клиенте через БД на серверной стороне. Таким образом что для отправки данных клиент пишет в БД, а для получения информации ее (БД) читает. С другой стороны сервер работает с этой же БД. Таким образом клиент работает не с сервером а с БД на сервере. Это важно.
А вот трафик да, тут нужно конечно думать. Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.
OpenCPU/EAT хорошие и нужные вещи, но наверное не в нашем случае. Для нас GPRS это канал связи, а модем портал для работы в этом канале. Не хочется усложнять.

>>> Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.

Так небось это на стандартный "разговорный" пакет. Спросите у оператора пакет для M2M - они специально ориентированны на передачу данных и мониторинг трафика должен быть.

Примеры таких пакетов у нас

http://www.kyivstar.ua/ru/ck-238/business/...s/messages/m2m/
http://corp.mts.com.ua/rus/telematic_tariff.php

и в России

http://www.corp.mts.ru/telematika/tariffs/telematika/

Гибкие условия тарификации Интернет - трафика:
оплата по факту потребления - для небольших объемов передаваемых данных;
пакеты GPRS трафика – для более интенсивного обмена данными;
безлимитные опции;
округление GPRS трафика 1 Кбайт - вы не платите за трафик, который не потребляли;


И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

•IPV4/IPV6 Dual protocol stack
•Mutil-PDP
•Secondary PDP active

Смотрю много решений с 2мя SIM-картами. Используя одни АТ команды для TCP коннекта, необходимо будет как-то со стороны внешнего процессора переключать карточки?



Почитаю о нем. Не совсем понял, что значит нет встроенного TCP/UDP стека и зачем мне два потока IP/V4 и IP/V6 в любой комбинации?
А вот поддержка 3G это здорово. В любом случае это будущее.

А я бы не рекомендовал 3G для автономных и удаленных устройств. Покрытия 3G гораздо хуже 2G, поэтому энергопотребление будет намного выше, а также будут спонтанные переключения между 3G и 2G, во время которых связь будет теряться. 3G нужен только там, где требуется передавать большие объемы данных.

Так это тесно коррелирует: чем оно проще, тем все остальное перечисленное.


Как раз наоборот - упрощать. Но это кому как, на любителя, навязывать не буду.



Несколько раз перечитал, но так и не понял. Понятно, что имеется мобильный клиент с GSM-модулем. Понятно, что имеется постоянно работающий сервер с белым IP и БД на борту. Еще имеется диспетчер, подключенный к серверу, но это не важно.
Вопрос в том, кто инициирует обмен "клиент <> сервер"? В варианте с UDP клиент может первым послать на сервер пакет в любое время, и затем обмениваться данными с БД сервера. Если же обмена нет длительное время (>3 мин), то сервер не сможет первым связаться с клиентом и должен дождаться пакета от клиента. Если это допустимо по условиям задачи, то сохраняйте в БД сервера необходимые данные для клиента (переданные диспетчером), и они будут доставлены клиенту при первой же его активности.
Кроме того, "расшевелить" клиента также можно входящим звонком: после звонка клиент тот час отправляет пакет на сервер, тем самым инициируя обмен по запросу диспетчера, и забирает с сервера заготовленные для него данные.

GSM модулю по барабану сколько карт - их можно внешним процессором переключать, только првильные параметры GPRS надо давать по IMSI коду. Модуль GSM можно любой использовать - главное что бы работал (не все модули одинаково хороши). БД и прочая лабуда для GSM - как рыбе зонтик.
Можно TCP/UDP, но мастера php/aspx/... могут и через http всё реализовать - разницы нет.
Вообще не понятно в чем проблема - примеров и кодов готовых - тонна.

Доброе! Сервер НЕ будет связываться с клиентом вообще. Я хочу отказаться от модели в которой сервер общается с клиентом напрямую.
Клиент передает данные на сервер записывая информацию в БД. Получает информацию читая из БД.
БД тут только для некоторого удобства и простоты, как бы это не казалось странным на первый взгляд.

Я на самом деле советуюсь с вами, и далеко не гуру в принципе.

Я и не говорю что проблема. Но очевидно что не все так просто.
На данный момент у меня есть понимание многих из ранее заданных вопросов. Есть и темные "места". Вот например я не понимаю на сколько это правильно/разумно и эффективно держать открытой TCP сессию открытой долго. Если таких сессий будет тысячи на одном сервере ,то как это отразится на работе системы? Вопросы ламерские, но ответы на них для меня не столь очевидны.

Количество никак не отразится, если памети в нем не 128 Мб. Сервер напрягается по количеству пакетов в секунду и запросами к БД. Чтобы существенно напрячь его по трафику нужны миллионы клиентов, а вот как его напрягут запросы к БД зависит исключительно от правильности написания этих запросов программистами и правильности настройки СУБД сисадмином. В целом, VPS за 5 долларов в месяц с 512 Мб памяти должен без проблем вытянуть тысяч 5 клиентов, присылающих информацию раз в минуту, если сервеную часть писали нормальные программисты.

Открытые TCP сессии однозначно зло! Особенно если клиенты цепляются по GPRS. Клиент должен подключиться, сделать свое дело и отпустить сервер. Когда клиентов больше 1000-1500 начинает очень заметно ощущаться "мертвые души" соединений, если, конечно, сервер сам не будет по таймауту неактивности их закрывать. Дело не в трафике, а в количестве одновременно существующих соединений.

Да ну я бы не сказал. Поднимал сервер на 5000 TCP-соединений (GPS-трекеры), проблем именно с соединениями не было, в базу тоже всё всё успевало писаться.
Думаю, запариваться над этим на старте проекта не стоит. Если клиентов станет действительно очень много, тогда денег уже будет достаточно, чтобы распределить прием данных на несколько серверов при помощи, например, DNS.

Помнится, ТС заказывал надежнее, стабильнее и прозрачнее. А если еще и инициализация соединения "клиент <> сервер" нужна только со стороны клиента, то тут сам бог велел использовать UDP, сразу решается масса проблем.
В клиенте отпадает необходимость TCP-конекта/реконекта и проверять, не отвалился ли сервер. Нет постоянного расхода трафика на KeepAlive.
В модуле на старте:
- инициируете GPRS;
- создаете UDP-сокет;

Когда есть данные к отправке, упаковываете их в пакет, сопровождая crc и просто отсылаете на сервер, запоминаете crc, запускаете таймер и счетчик повторов. При истечении таймаута дублируете пакет. По исчерпании попыток пингуете 8.8.8.8. пару раз. По истечении таймаутов ресетите модуль.
При получении данных с сокета проверяете: если от 8.8.8.8, то пинг ОК, если с IP сервера, то сверяете crc в ответе с запомненной, если ОК, то завершаете.
Ответ сервера содержит crc полученных данных, данные для клиента, и общее crc пакета.

На сервера запускаете легковесный демон, написанный на голом С + легковесная С-библиотека SQL. В цикле опрашивате единственный открытый UDP-сокет. Если получен пакет, сверяете crc, извлекаете данные из полей пакета и пишете в БД, затем читаете с БД данные для этого клиента, распихиваете по полям, отдельно возвращаете crc принятого пакета, и отправляете на IP-порт, откуда пакет пришел.

Диспетчер работает с серверной БД обычным способом, тут ничего сложного нет.

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

Да, пожалуй соглашусь: UDP это то что мне подходит.
А зачем пинговать 8.8.8.8 ? Ведь если мне не отвечает сервер, то все остальное мне фиолетово так как нет канала связи. Да, есть инет, но сервак-то "валяется")

У меня статический адрес у сервера. Но он в силу разн. причин и обстоятельств может быть изменен. У клиента же зашит один фиксированный адрес. Может быть правильнее клиенту записывать/указывать адрес через некоего посредника? Люди для сайтов покупают доменное имя, и таким образом абстрагируются от всех вопросов с IP адресами.

Переписал сервер для работы с UDP сокетом. Модем SIM900 при создании сессии указываю UDP вместо TCP. Сутки почти модем отсылает с периодом в 20 с небольшой пакет на сервер. Не отваливается. С TCP было по-другому: сессия отваливалась в течении небольшого промежутка времени.

Вариант - воспользоваться бесплатным DNS-сервисом. Который, правда, вдруг может стать платным, и придется искать замену, поэтому жестко зашить не получится...

ISG2015
Можно зашить в EEPROM 3 бесплатных доменных имени и при подключении перебирать их по очереди, а в случае проблем с каким-то из них просто отсылать клиенту информацию о новых доменах, чтобы он у себя в памяти их обновил.

А TCP-сессия отваливалась именно при отправке данных каждые 20 секунд? Очень странное поведение.

Дело в том, что нет доверия к самому GSM-модулю: внутренний стек или GPRS может глюкнуть, тест состояния будет ОК, но пакеты не будут даже выходить. Контроллер будет считать, что умер сервер, и ждать, ситуация зациклиться. Если же после нескольких неудачных попыток получить ответ сервера пробовать пинговать что-то гарантийно работающее, то сразу ясно: причина в модуле или в сервере. И если в модуле, то можно перезапустить.
Причем 8.8.8.8 можно даже не пинговать, а отсылать в 51 порт UDP-пакет с DNS-запросом доменного имени, заведенного для вашего сервера, а по получению UDP-ответа парсить датаграмму и извлечь IP.
Сам запрос шаблонный: захватите снифером с РС и запишите в виде сonst в контроллер. С поиском IP в ответе сложнее: он не по фиксированному смещению, и есть два варианта упаковки. Если не лень, посмотрите мой ассемблерный код по ссылке выше и переведите на С. Или, лучше, почитайте rfc по DNS и напишите парсер сами.
Таким образом, убиваете сразу двух зайцев: убеждаетесь, что модуль не висит, и получаете новый IP сервера, если он изменился. Т.е. можно даже поднять сервер на динамическом IP c использованием DynDNS (правда, он сейчас полностью платный стал).

GeGeL, спасибо за советы. Да, может и стек в симкоме глюкнуть, и GPRS. Контроллер может ошибочно считатьчто умер сервер. Пингуя 8.8.8.8 (или не пингуя а запрашивая адрес, как Вы описали) можно убедиться в том что именно "висит", но при всем при этом выход из ситуации только один: перезагрузка модуля.
Но пинговать 8.8.8.8 безусловно может оказаться полезно, так как перегружать модуть бесконечно нет смысла. Нужно обдумать логику работы модуля, особенно если учесть, что у меня 2 SIM-карты.

Сейчас озадачился написанием "стека" АТ команд для модема. Как я погляжу народ все делает на задержках (функции Delay под различными соусами), но я думаю это не айс. Не хочется изобретать велосипед, но чувствую, что буду вынужден)

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

С периодом 20с отправлял 2е суток (UDP слот). Сейчас поставлю 60 с.

Думаю что перепроверить с разным временем лучший выход.

У нас, у Киевстара, нет такого глюка, а у Лайфа - 3-5 минут нет данных и все - большой шанс отправить "в никуда"

Поставил на компьютер программу снифер/анализатор сетев. протоколов "Wireshark". Отправляю по UDP 1 байт. Получаю: "Frame Length: 60 bytes (480 bits)" о_О

Таким образом, отправляя на сервер пакетик раз в 5 минут и получая на него ответ (контроль канала) я в месяц попадаю на 1 Мбайт
Что-то жирновастенько учитывая что мне бы хотелось чаще мониторить железку и канал связи.

Так провайдер тарифицирует трафик на 3 уровне, весь фрейм отбрасывается ещё на оборудовании оператора, остается только внутренность IP-пакета. Хотя, этот момент я бы уточнил у оператора, но весь фрейм 2 уровня целиком уж точно никто не тарифицирует.

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

Это проблема Ethernet - кадр дополняется нулями. В вашем случае внутреннего стека GSM-модуля оверхед будет 24 байта на пакет (на IP+UDP заголовки). Раньше они тарифицировались, сейчас не могу сказать, тем более по каждому оператору.

Эдуард, это то, о чем я писал. И это только начало...

Эдуард? о_О

С Лайфом договорился, обещают завтра помочь с доступом к билинговой системе. Вот там и посмотрю ,что именно тарифицируется.

>>> Эдуард? о_О

Да. А шо?

Как мне сказал начальник Кемеровского ОРТПЦ
- Днепропетровца узнать легко - "шо", "га" и "тю" одновременно в лексиконе есть только там.

К сожалению это наша действительность - волкИ хотят "еды".

Это была реплика к CADiLO в продолжение нашей старой дискуссии.

Правильно думаете. Велосипед давно придуман - switch, описывающий состояния автомата. На Delay делают первокурсники - тошно видеть такое от многоопытных дядек.

То есть отправляем команду, и ждем пока не получим OK или не истечет таймаут, а дальше анализируем вывод команды или обрабатываем ситуацию таймаута?
А как реализуют обработку незапрошенного вывода? Например, модуль выводит текст длинного SMS, и в этот момент на него позвонили и он выводит RING прямо в середине текста, как это обрабатывают многоопытные дядьки?

AT+GSMBUSY=1
-прочесть SMS
AT+GSMBUSY=0

это так - навскидку....


второй вариант
завести RI на контроллер, а URC RING отключить AT+CFGRI


кстати интересный момент - надо будет специально проверить
я что-то не видел чтобы в текст SMS вклинивались URC

Сегодня таки выяснил какие накладные расходы на передачу 1 байта поверх сетей GSM (Life Украина) по технологии GPRS:
8 байт на UDP заголовки и 20 байт на IP. Итого 28 байт. Ну это уже нормальненько так
Остается надеяться, что подобного рода расклады с тарификацией и у других операторов.

CADiLO
Так там же куча всяких URC может приходить, про SMS, про регистрацию в сети, про выход питающего напряжения за пределы... Их что, все отключать перед каждым запросом и включать после него? Хотелось бы услышать совет из практики.

ISG2015
А SIM-карту в устройство будет вставлять пользователь, или вы сами? Если пользователь, то у какого-то оператора наверняка найдется какой-то тариф с дорогими разговорами и дешевым трафиком. У меня GPS-трекер с SIM-картой Мегафон и тарифом "Мегафон-Онлайн" уже года три на 300 рублях катается.

Насколько я помню, вывод текста SMS это тело команды и до ОК прервано быть не может.
Я перепроверю конечно, но скорее всего что в текст SMS подмешаться URC не может.

CADiLO
А остальные команды? AT+CNETSCAN, AT+CENG, AT+HTTPREAD, AT+CIPGSMLOC, которого ждать надо пару секунд? Во все не могут пролезть? На сколько я помню по экспериментам с SIM908, пролезают ещё как (правда, не помню версию прошивки, на которой тестировал). Если бы не пролезали, алгоритм конечного автомата управления модулем можно было бы очень упростить.

Подскажите, где взять прошивку для SIM900R? Мне нужно сбросить модем в заводские настройки. Спс!

UPD
Вопрос снимается, разобрался.

Вот как люди умудряются усложнять себе жизнь... Я давно работаю с Quectel ОЦПУ, и никогда не сталкивался с проблемами в этом плане. Конечно, при ожидании ответа на АТ-запрос может прийти левый URC, но ведь все равно все должно проверяться, перед тем, как парситься. Т.е. одной state-машины недостаточно, надо каждые данные парсить и проверять на соответствие ожидаемым. Для этого используется strstr. Ради интереса посмотрите код Quectel RIL (от производителя). Там обработчик события UART с подключаемыми парсерами, которые формируют callback-и.

Честно, тут я категорически не согласен со Stanley - он пошел на поводу юзерофильности, и потерялась изящность и прозрачность предыдущих версий ОЦПУ с опросом getEvent в цикле. Теперь фиг поймешь, в контексте какой нити выполняются callback-и и какие данные защищать мутексами. Но зато школьники тащутся - привычная и уютная среда...


Не заморачивайтесь на абстракциях. Просто попробуйте сесть, сосредоточиться и ясно представить, как реально будет идти обмен с модулем, и предвидеть по возможности все ситуации, а также предусмотреть вывод отладочного лога с указанием номеров строк и параметров.
ПС: АТ-ответы и URC никогда не разрываются другими URC - все становится в очередь. Любой ответ и URC, как правило, имеет префикс, указывающий на его принадлежность.