Здесь часто ломают голову, как парсить баланс. Вот и возникла идея его проговаривать. Но конечно англицкий язык не фонтан. А вот китайский здОрово. с-string иероглифами. "Купи сегодня трекер и получи в подарок диск с самоучителем китайского. Оптовикам Сен-сей из Пекина".

особенно когда он прийдет транслитом по русски - это еще прикольней китайского будет.
или сначала переводить на английский будете ?

кроме того некоторые операторы сокращения лепят в текст.

М12 поддерживает кодировку GB2312. Даже функция конвертанции в юникод есть: Ql_ConvertCodec
Да и сам Stanley часто коменты в ней делает, я уже приноровился переводить



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

PS: смотрел по украинским сисопам - цифры баланса всегда идут первыми в ответе. Может, недосмотрел кого, то поправьте. И кто может, подскажите в теме парсинга баланса, так ли у росийских операторов (транслитом).

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

Лайф у меня ругается, когда меньше пятёрки.
Раз уж зашло о голосе ... у операторов ведь бывает и голосовое меню. Посредством его и конференц-связи тоже можно дистанционно узнать состояние баланса. Понадобится приложение, умеющее набирать номер, декодировав DTMF-комбинацию - то же, что в GSM-шлюзах.

Скорее всего у разных опереторов оно различно. Да и нет уверенности, что завтра его изменят\расширят\урежут.

Естественно. Автоматизировать дозвон не получится, только запросить вручную с удалённого мобильника.

А можно ли платы с модулями QUECTEL мыть в УЗ-ванне (и как долго)?

Вообще то в УЗ не рекомендуется засовывать ничего содержащее низкочастотные кварцы 32 или 16 килогерц, ПАВ, АРФ на керамике.....
Где-то в инете есть документ чего можно, а чего нельзя мыть в УЗ.

Именно вопрос про кварцы меня и волновал. Придется булькать.

Добрый день!

Столкнулся с проблемой при работе с М10, пытался найти решение в интернете и наткнулся на это обсуждение. Может здесь помогут.

Суть в следующем: М10 будет использоваться для удаленного мониторинга и передачи цифровых данных от датчиков под управлением микроконтроллера PIC 18XX. Данные будут передаваться на персональный компьютер и в реальном времени выводится на какой-нибудь ВП из LabView 8.6. Для передачи данных планируется использовать обычный протокол TCP/IP т.к. он единственный поддерживается на обеих сторонах. И вот тут как раз загвоздка, ибо модуль никуда не хочет подключаться, равно как и в серверном режиме "прослушки" не принимает никаких клиентов.
Алгоритм следующий:

at+ipr=115200
OK

at+qsimstat?
+QSIMSTAT: 0,1
OK

at+cimi
250015200221958
OK

at+csq
+CSQ: 9,0
OK

at+creg?
+CREG: 0,1
OK

at+cgatt?
+CGATT: 1
OK

at+qifgcnt=0
OK

at+qicsgp=1,"internet.mts.ru","mts","mts"
OK

at+qimux=0
OK

at+qimode=0
OK

at+qidnsip=0
OK

at+qiregapp
OK

at+qiact
OK

at+qilocip
10.236.36.45

at+qiserver
OK
SERVER OK

at+qilport?
TCP: 2020
UDP: 3030
OK

at+qistat
OK
STATE: IP STATUS

at+qiopen="TCP",83.167.121.105,8080
OK
CONNECT FAIL

Симка от МТС, Москва. Может кто сталкивался с таким? Слышал где-то, что такая проблема происходит из-за МТС и решается как-то хитро через туннелирование, но я не до конца понял о чем речь. Признателен, если кто поможет)

В случае сервера см. вложение.

Скорее всего, здесь посмотрите:
http://electronix.ru/forum/index.php?showtopic=106898

Для начала вставьте вашу симку в обычный модем, поднимите с компьютера GPRS и убедитесь, что с него доступен ваш сервер. Установите нет-монитор, и сразу станет видно, что там происходит. Как добъетесь доступа, тогда пробуйте с модуля.

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

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

Спасибо за советы, но тут скорее дело в другом: модуль и PC находятся за NAT и друг до друга они достучаться не могут. Думаю использовать VPN по принципу точка-точка или ковырятся через dydns.com

Ваши слова да к богу бы


Вы хотите поднять VPN с модуля??? И куда, ведь сервер все равно недоступен...
- Дайте IP вашего компьютера, на котором сервер (выполните ipconfig /all)
- Зайдите на 2ip.ru/ и посмотрите, что там покажет
- укажите, как компьютер с сервером подключен к интернет: непосредственно, через роутер, через беспроводное соединение и т.п.

И dyndns тут тоже не при чем на даном этапе.

Собственно в домашних условиях я работаю с ноута, подключенного по беспроводному соединению, но вообще предполагается работа с компьютером подключенным через роутер

ОК, тут понятно.



Тут непонятно: ноут подключен по беспроводному соединению к ЧЕМУ? Если к вашему роутеру, то модель роутера укажите. Или к публичной WiFi?

Также зайдите в меню роутера и посмотрите, какой IP висит на WAN-интерфейсе роутера (назначен провайдером).

И еще: перезапустите роутер и компьютер и проделайте все снова (посмотрите локальный IP, WAN-IP роутера и внешний на 2ip.ru).

Тогда иформация будет полной, можно будет посоветовать, что делать.

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

Я вообще хочу понять, один ли у него роутер (свой) между сервером и сетью. Если да, то проблем нету - прописать VirtualServer в роутере. А если кроме своего, есть еще провайдерский (дающий, скажем, 10.10.XX.XX), то тогда проблема.

Звиняйте за мою неграмотность, раньше просто никогда подобными вещами не интересовался

Для меня сейчас более актуально заставить модуль работать и подсоединяться к институтскому ПК. До 30 числа, у меня к сожалению возможности узнать модели роутера не предвидится. Хотя если мне память не изменяет, внешний адрес там, который выдает 2ip, 192.233.70.243. Роутер стоит, только между сервером и сетью, поэтому адреса 10.10.ХХ.ХХ я не встречал за то беглое знакомство, что мне предстояло провести. Более детально смогу сообщить только во вторник

Добрый день.
Можно ли с М12 слить прошивку ОCPU, если да, то как тогда залочить модуль?

Слить можно. Например, используя Flash_tool от MediaTek.
Физически залочить (как МК) нельзя.
Защитить прошивку от запуска на другом модуле можно (т.е. привязать прошивку к конкретному модулю).
Если сделать привязку динамической (например, в виде первичной активации и т.п.), храня активационный ключ в файле, то получим защиту от клонирования устройства.

модем M10
симка мегафон, беда просто данные по TCP не проходят (на других операторах все нормально), если ставить симку в модем SIM900 то все работает.

лог:

ATI
Quectel_Ltd
Quectel_M10
Revision: M10BR06A07N32
OK

AT+CFUN?
+CFUN: 1
OK

AT+CPIN?
+CPIN: READY
OK

AT+GSN
359231039718174
OK

AT+CSQ
+CSQ: 26,0
OK

AT+CREG?
+CREG: 0,1
OK

AT+CGREG?
+CGREG: 0,1
OK

AT+CGCLASS?
+CGCLASS: "B"
OK

AT+CGATT=1
OK

AT+QIREGAPP="internet","inet","inet"
OK

AT+CSQ
+CSQ: 31,0
OK

AT+QISTAT
OK
STATE: IP START

AT+QIACT
OK

AT+QILOCIP
10.159.85.162

AT+QISTAT
OK
STATE: IP STATUS

AT+QIAUTOS=0
OK

AT+QIHEAD=1
OK

AT+QIPROMPT=1
OK

AT+QISTAT
OK
STATE: IP STATUS

AT+QIOPEN="TCP","62.165.36.34","1082"
OK
CONNECT OK

AT+QISEND=10
>1234567890
SEND OK

AT+QISACK
+QISACK: 10, 0, 10
OK

AT+QISACK
+QISACK: 10, 0, 10
OK

AT+QISACK
+QISACK: 10, 0, 10
OK

AT+QISACK
+QISACK: 10, 0, 10
OK

…. и так продолжается 10-20 мин (пакет «1234567890» так на сервер и не приходит!)

AT+QISTAT
OK
STATE: CONNECT OK

AT+CSQ
+CSQ: 31,0
OK

AT+CPIN?
CPIN: READY
OK

AT+CREG?
+CREG: 0,1
OK

AT+CGREG?
+CGREG: 0,1
OK

На других операторах все работает замечательно, где искать ошибки?

А есть возможность посмотреть сетевой обмен на сервере? Если под win32, используйте сетевой анализатор типа SoftPerfect Network Protocol Analyzer или что-то в этом роде, запустив его на машине сервера. Интересно, отрабатывается ли вообще тройное рукопожатие при tcp-конекте модуля к серверу, или это модулю только кажется. И приходит ли затем на сетевой интерфейс IP-пакет с данными "1234567890".
Если нет возможности проверить, напишите в личку: подключитесь на мой ip, я гляну.

модуль поднимаю ручками, сам модуль стоит на макетке, подключил только COM порт. С сервером соединение открывает с ошибкой, т.е. сервер не открыл соединение а вот модем открыл и вывел "CONNECT OK". После этого данные не поступают на сервер что и понятно т.к. соединение не получилось установить.
Вопрос, почему в 95...98% случаев у модема не получается установить соединение с сервером, хотя он выдает "CONNECT OK" и уровень сигнала соты приличный, "+CSQ: 31,0".

В случае когда соединение проходит успешно, модем данные отправляет нормально, вот только это продолжается не долго,
минут через 5...10 опять не может отправлять, запрос "AT+QISTAT" ответ "STATE: CONNECT OK", сигнал тоже "+CSQ: 31,0", а вот сервер просто перестает получать пакеты из соединения.

Опять же, чем гадать о происходящем, запустите на стороне сервера сетевой снифер и помотрите, что там на самом деле происходит: откуда приходит fin-пакет, и приходит ли он вообще. Возможно, просто NAT сисопа в таймаут уходит ( у вас ведь серый айпи 10.х.х.х), тогда надо keepalive вводить.
Вобщем, одним созерцанием терминалки модема тут не поможешь, нужен более конструктивный подход с пониманием того, как функционирует tcp-соединение на уровне ip-пакетов, а не того, как его открыть/закрыть.

ЗАПУСКАЛ снифер! сказал уже о результате. тройное рукопожатие не завершается, получаю только первый запрос от модема, все остальные ответы сервера модем не видит и не отвечает на них. Хотя строчку CONNECT OK выдает очень резво.

вот что показывает:
http://imglink.ru/show-image.php?id=424aef...78e52846cd2e228
http://imglink.ru/show-image.php?id=bd0fb9...812d45f706551db
http://imglink.ru/show-image.php?id=7b27d0...790103276383dc9
http://imglink.ru/show-image.php?id=a9fc1f...6866813fa37d79b


Процесс начала сеанса TCP - обозначаемое как "рукопожатие" (handshake), состоит из 3 шагов.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

* Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента.
o В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED.
o В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

* Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED.
* Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
* Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

* В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.


Что мне то делать, если модем неправильно выполняет требуемую процедуру подключения и рапортует CONNECT OK? Опять же повторюсь такое происходит только на карточках "Мегафон", остальные операторы работают нормально, если ставить карточку "Мегафон" в SIM900 то работает нормально.

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

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

Да, ситуация действительно весьма интересная. Можно было бы все списать на NAT сисопа, если бы не одно но: Вы в начале утверждали, что на сим900 в полностью аналогичной ситуации все работает. Можно глянуть снифером ситуацию с сим900? Интересен исходящий порт со стороны NAT провайдера.
Попробуйте также на другом порту сервер поднять.

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

И еще один эксперимент неплохо бы: поднять мегафонное соединение с РС, подключив М12 по RS232-PPP в качестве стандартного модема и открывая соединение с сервером с PC. Т.о. дифференцируем проблемы провайдера от проблем стека.

ПС: и еще вопрос - если сервер вообще отключен, выдается ли CONNECT OK?

Может я ошибаюсь - тогда пусть меня питерские коллеги поправят - в свое время с одним из операторов России были проблемы и с SIM900 и даже карточки для устранения на симком высылали. Но был ли это Мегафон 100% не скажу.

Значит вот какая ситуация, то о чем вы говорите тоже пробовал. Если сервер не запущен то и CONNECT OK не выдает в том то и прикол, что подключение начинается но разрушается на передаче ACK на SYN модема. Винда при этом не может создать связанного сокета а вот модем МОЖЕТ! CONNECT OK. Если сервер вообще не запускать то все как и должно быть CONNECT FAIL, т.е. выходит, что кто то вместо моего сервера все это дело подтверждает ну или стек такой у модема кривенький.

Подключать M10 по RS232-PPP в качестве стандартного модема не очень хочется время тратить, потому как переделываю протокол приборов на UDP и делаю свой протокол доставки. Ну и собственно UDP я пробовал и работает нормально.

По поводу SIM900 там все в порядке с "рукопожатием" при подключении причем подключается он явно дольше! т.е. CONNECT OK выдает когда уже я вижу снифером, что винда сокет образовала. Модем M10 выдает CONNECT OK при первом же ответном пакете сервера при установлении соединения т.е. я вижу, что соединение ещё в стадии открытия а он уже отвечает CONNECT OK.


да ОЧЕНЬ
Люлей мне уже выдали за такое, а интересно в Quectel серьезно занимаются такими случаями? просто вот любопытно как там разбор полетов происходит?

Нет, не так немного, как Вы описали. Вот что происходит, я так понимаю:
1. Модем посылает первичный SYN, он удачно доходит на сервер.
2. Сервер инициирует сокет и посылает модему свой SYN.
3. Этот пакет модем ПОЛУЧАЕТ (иначе не выдал бы CONNECT OK), скорее всего отсылает серверу ACK и вполне резонно считает, что соединение создано.
4. Но вот этот ACK на сервер не доходит. Но почему? Банально пакетлосс? (тем более что иногда, с ваших слов, все же соединение устанавливается). Возможно, сокет стека М12, в отличие от SIM900, делает меньшее к-во повторов (или не делает совсем).

Если так, то надо бы переориентировать модем не на CONNECT OK, а на подтверждение получения любых инит-данных, иначе рвать соединение и устанавливать по новому до успеха.
Но, что интересно, в результате каждой попытки имеем зависший в SYN-RECEIVED сокет на сервере, который ликвидируется по таймауту. При агрессивных реконектах множества устройств - типичная DDos получится.

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

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

да так и есть, сокет сервера не доходит до состояния ESTABLISHED. Хотя иногда доходит и обмен вроде возможен, но работает 10 мин. и потом опять затык.
Теперь вопрос: почему это происходит только на одном операторе Мегафон?
Всю ситуацию так же изложил тех. поддержки Quectel, сказали занимаемся, проверяем...
Может в другом дело? я не знаю... наводки... помехи... уже голову всю сломал хотя уровень сигнала показывает больше не куда, симка стоит надежно (хотя могу и запаять намертво, но это уже перегиб), антенну проверял, разъемы менял, разные модемы со склада брал, короче ахтунг кажись UDP, это все на что стоит рассчитывать. Не очень понимаю для чего производители модемов анонсируют все эти новые технологии типа 3G... и все такое, тут самые простецкие вещи не работают.

Несколько не в тему, но
я тоже немного не понимаю, зачем люди используют TCP для M2M. Все равно же идет, как правило, свой контроль пакетов.
Единственный минус UDP - соединение в NAT опсоса живет от силы секунд 15. поэтому обратно данные надо пропихивать быстро.

Ну и еще минус - в 285 приказе написано - устройство должно соединятся по TCP!

Возможно, из-за потери IP-пакетов, причем скорее не по вине помех на радиосегменте, а, может, из-за каких-то шейперов в сети провайдера. Именно поэтому иногда соединяется. И именно поэтому спонтанно рвется соединение через случайное время.
Как видно из сетевого лога, сервер повторяет свой SYN-пакет (так как не получает на него ACK), но, скорее всего, баг Quectel-сокета в том, что однажды получив SYN и ответив на него ACK, модем становится нечувствителен к повторным SYN, таким образом потерянный ACK не дублируется модемом.

ПС: будьте готовы к масовым потерям и UDP-пакетов. Обязательно должен быть алгоритм многократной повторной отсылки по таймауту до подтверждения, а также периодически проверка связи (т.к. с пингом я уже обжегся, то троекратно отправляю UDP-DNS пакет на 8.8.8.8:53 - гораздо надежнее), переподключение GPRS при неудаче, и перезапуск модуля при таймауте времени, выделенного на поднятие GPRS (скажем, 3 мин). Если еще и внешний вотчдог на пике, то вобще неубиваемый девайс получается


И в результате девайс может быть доступен из сервера (например, для управления) не в любой момент, а только после передачи очередного пакета данных. Если это неприемлемо, то надо вводить keepalive. Кстати открытая TCP по идее, живет в NAT столько же и тоже поддерживается с помощью keppalive (самим сокетом), так что трафик одинаково утекает. В случае с UDP даже экономнее за счет более коротких заголовков и того, что можно оптимально подобрать интервал под настройки конкретного NAT).

По UDP все хорошо и быстро передается, без всяких тормозов. Мне кажется что в TCP соединении и передаче, участвуют промежуточные узлы, которые берут на себя функции выдавать ACK. По верх TCP можно ещё протокол положить, многие же протоколы верхних уровней работают по TCP.

Хотя я столкнулся с комплексной проблемой, во первых ладно бы просто по TCP пакеты теряться могут, бывает но редко. Но тут ещё и соединение не получается открывать нормально, точней никак не получается, 95 попыток из 100 неудачны. У меня прибор потратил почти 2000р в неделю, на симке мегафон, пере подключаясь к серверу. Как мне сказали в "мегафон", кто то ФИЛЬМ смотрел с этой симки!

Кстати, по поводу Мегафона и UDP. Было дело, что именно в роуминге (внутрисетевом) бились пакеты UDP.
Причем CRC UPD пакета было верно, но данные искажены (либо отсутсвовала часть).
Сделал вывод, что кто-то по пути перепаковывает пакет....

По TCP, когда использовали, давно еще, тоже заметили, что с некоторыми операторами SEND OK (SIM300) приходит быстрее, чем сервер принял данные.
Значит, ACK на пакет отправляет маршрутизатор ОПСоСА. И гарантированной доставки пакета до сервера нет.

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

Текущая ситуация такая:
Просматривая документы обратил внимание что модем SIM900 поддерживает GPRS multislot class 10 максимум, а Quectel M10 GPRS multislot class 12. Действительно в настройках Quectel M10 можно понизить GPRS multislot class но там стоит по умолчанию 12!!! что такое GPRS multislot class можно почитать тут : http://ru.wikipedia.org/wiki/%D0%9A%D0%BB%...1%81%D1%8B_GPRS
В итоге если понизить GPRS multislot class до 10 или лучше 8 то ВСЕ РАБОТАЕТ! УРА!!! Конечно может радоваться рано потому как тестирую всего 5 часов, но уже четкий результат виден. Так же допускаю, что это косвенно связано и до конца не лечит болячки TCP стека. При установлении сессии оборудование договаривается о количестве слотов, т.е. устанавливается доступный режим, по всей видимости класс 12, но при фактическом использовании такого количество слотов, у модема начинаются проблемы с обменом и по всей видимости это сказывается на работе стека TCP.

Что примечательно с понижением GPRS multislot class до класса 8 модем быстрее отправлет т.е. вообще махом задержек практически нет, вот такой парадокс, понизил скорость и стало работать ЕЩЁ БЫСТРЕЙ!

И Вам спасибо за эксперимент, будем знать! Очень полезная информация. Значит, все таки на уровне GPRS-транспорта проблема существует.
Скорость и надежность все таки взаимоисключающие вещи, на CDMA аналогичное наблюдал: EVDO давал сплошные пакетлосы, а на 1x - потерь ноль...

в догонку...
раздел 2.1. ЗНАЧЕНИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА ОБСЛУЖИВАНИЯ
http://static.mts.ru/upload/images/files/T...ission_2010.pdf

Вопрос по OCPU (М12). Хочу оцифровать звук с микрофона и сложить в буфер. Думаю с выхода динамика подать на вход АЦП модуля ( или микрофон- ОУ-вход АЦП модуля). Пока более умного не придумал, может есть иные варианты средствами OCPU?
1 Возможно ли как-то добраться до таймеров, предделителей и их прерываний? Про ШИМ там вроде есть, а вот таймеры не нашел.
2 Еще необходимо читать АЦП по его прерываниям. Считывать АЦП по таймеру, как то не Айс вроде. А вешать внешний проц для одной этой процедуры не хочется.
3 И как глобально разрешить\запретить прерывания? (Аналог #asm("cli") #asm("sei"))

Сам все перепутал

Большое спасибо за ваши изыскания. Очень помогли. Я никогда не работал с Мегафоном, и особых проблем не было. Но тут вдруг пришлось, заказчик хотел именно Мегафон. И тут всё пошло не так. Полный неуспех. Снижение multislot class помогло. Но самое крутое, класс 10 или 8 помогли улучшить, но по-настоящему лучше стало при указании класса 1. AT+QGPCLASS=1
Самое интересное, что и на "нормальных" опсосах картина заметно улучшилась. Девайс не теряет связь СУТКАМИ. Это фантастика. Спасибо.

SIM900 поддерживает GPRS multislot class ( 2,4,8,9,10) AT+CGMSCLASS=8. Отмечу что комманда немного другая. Но вот только для старта или постоянный остается класс не знаю. Также как опсос может это сменить или нет? По умолчанию 10 класс, но выше классы в текущей прошивке не поддержаны.

Подскажите пожалуйста как послать USSD запрос и принять ответ из под ocpu , сейчас пока реализовано через AT+CUSD а парсится в выхлопе мопеда.