Пришлось недавно заняться GSM-модулями Telit. В целом довольно понятно, пока не приступил к datacall.
В общем, логика такова. На прием звонка стоит автоподъем. По третьему звонку поднимает, коннектится. Пишет CONNECT 9600. Все хорошо.
Далее приходит команда, парсер ее отрабатывает, принимается решение что делать.
Вот дальше не совсем понял - модуль находится в режиме передачи данных и мне необходимо перевести его в командный режим.
Перевожу при помощи +++
Все хорошо, переходит.
Потом перед отправкой данных снова перевожу его в режим передачи данных при помощи AT0
Все опять же работает
Ну и так далее, перевожу в командный +++ и по кругу

Все замечательно отрабатывает, пока не надо прервать соединение.
Вообще у меня есть бесконечный основной цикл, где программа постоянно крутится (ну так было указано в примерах, насколько я их понял)
res=MDM.receive(10)
ab = res.find('NO CARRIER')
if(ab!=-1):
StopDataMode()

Если вижу NO CARRIER, то останавливаю выполнение программы, перехожу в командный режим.
Только вот этот самый NO CARRIER может прийти и во время выполнения каких-то команд. В результате я его не всегда отлавливаю и все плохо.

Вопросы.
Правильно ли вообще постоянно переключаться с одного режима во второй?
Что делать для с проблемой отлова NO CARRIER (вообще говоря, любая команда тоже может не отпарситься по той же причине)

Извиняюсь, если вопросы дурацкие, не нашел толкового примера... При соединении по GPRS меня ждет видимо то же самое
Спасибо.

Если Вам мешают левые сообщения при попробуйте перевести работу с datacall в MDM2 а в MDM обрабатывайте всё остальное. У Вас будет отдельный канал для datacall без левых сообщений в нём, не нужно будет переходить в командный режим для выполнения других задач.

Так вот и непонятно как это сделать.
Вот фрагмент передачи данных

MDM.send('ATO\r',20) переводим в режим передачи данных
MOD.sleep(TIMEOUT_SEND) задержка 1 с
MDM.send(tagtext,50) передаем данные (они уже сформированы)
MOD.sleep(TIMEOUT_SEND) еще одна задержка
MDM.send('+++',20) переводим в командный режим
MOD.sleep(TIMEOUT_SEND) снова задержка

Если сделать просто:

MDM2.send(tagtext,50)

То на приемной стороне видно AT-команды....

Если поменять MDM на MDM2, то ничего не меняется (да и с чего бы) - видны AT-команды на приемной стороне

Т.е. я не понимаю как сделать так, чтобы MDM отвечал за работу самого модуля, а MDM2 - за канал передачи данных

Если Вы хотите принимать datacall в MDM2 то и управляйте им тоже в MDM2. Т.е. после автоподъёма трубки шлите команду в MDM2 а не MDM, туда же отправляйте ваши данные, туда же отправляйте +++ если надо, оттуда же ожидайте NO CARRIAR. Я с datacall не работал, но работал с GPRS. После установления соединения скажем по MDM2 всё что будете отправлять в MDM2 будет попадать на сервер и наоборот. В то же время в MDM можно отправлять обычные ат-команды и получать ответ (напр. MDM.send('AT#SS\r\n' res = MDM.receive(50); )

Ну вообще говоря, у меня должно и по datacall и по GPRS все работать. GPRS пока не пробовал толком, т.к. не готова приемная сторона. Но по GPRS насколько я понимаю, нужно выполнять команды AT#SKTSET, AT#SKTSAV, AT#SKTOP на MDM2. Т.е. сокет подымется на MDM2 и соответственно все что по GPRS сыпется мне и то, что должен отправлять я идет по MDM2.send и recieve. Я правильно понимаю?

Еще соображения. Что происходит при автоподъеме трубки. Попробовал вот что.
В основном цикле было
res=MDM.receive(10)
res вывожу в консоль
При звонке вижу
RING
RING
CONNECT 9600, после этого вижу команды от передающей стороны
После этого перехожу в командный режим
Выполняю AT-команды - вижу команды и их выполнение
Перехожу в режим передачи данных
Отправляю данные - приемная сторона их видит
Переходу в командный режим

Попробовал
res=MDM2.receive(10)
res вывожу в консоль
При звонке вижу
RING
RING
CONNECT 9600 уже не видно как и команд
Т.е. я так понимаю, в режим передачи данных перешел MDM?
Можно ли выполнить самостоятельно подъем трубки в виде MDM2.send(ATA). Будет ли в этом случае MDM2 в режиме передачи данных, а MDM - в командном?

Для определения наличия входящего вызова можно ловить RING а можно в любой момент получить целый список входящих вызовов, их ти и статус.
Есть команда AT+CLCC которая выдаёт список входящих вызовов.
С её помощью вы можете самостоятельно обнаружить входящий datacall используя MDM (почитайте описание команды AT+CLCC).
Далее можете поднять трубку MDM2.send('ATA\r') и выполнять любые действия - т.е. принимать команды с сервера, отправлять на сервре. После ATA MDM2 уже связан с сервером и недоступен для АТ-команд Захотите положить трубку - +++ пауза MDM2.send('ATH\r')
А можете положить трубку послав команду в MDM без +++.
Если команды с сервера требуют запрос чегото там у модема с помощью АТ-команд, то принимать команды можете с помощью MDM2.receive(10), а опрашивать модем с помощью MDM а результат отправлять на сервер с помощью MDM2.
Если нужен автоответ то настраивайте его в MDM2.send(AT0=3\r)

Для работы с GPRS есть новые команды рекомендованые телитом SCFG - настройка соккета, SD - набор соккета, SS - статус соккетов

mempfis_, спасибо. Теперь все понятно. Проблему я так и решил - путем установки автоподъема командой через MDM2. Все сразу стало как надо. Неясно вот что:
Цикл работы программы предполагает периодическое чтение по MDM2 для приема данных и отслеживания NO CARRIER. Но после опроса возможен случай, когда мне необходимо выполнять действия в течении нескольких минут. Пока не выполнятся все необходимые операции, в начало цикла (там, где я читаю по MDM2) я не попаду. Иными словами, в течение нескольких минут отловить NO CARRIER я не могу. Насколько я понял, в модулях нет возможности сделать многопоточность (тогда я бы смотрел MDM2 в другом потоке), каких-то прерываний тоже нет. Не произойдет ли потеря при приеме данных (пропуск NO CARRIER)?

Да там вроде буффериируется ответ. Не считали сейчас считаете позже. Вы можете проверить статус звонка (точнее разрыва соединения) с помощью AT+CLCC через канал MDM непосредственно перед необходимостью использования канала связи с сервером.
На питоне тяжело (точнее медленно) организовать много одновременно выполняющихся задач, но возможно. Мне лично больше мешает дурацкий синтаксис. Ну и раздражают тормоза. Я подозреваю что тот кусок кода выполнение которого занимает у Вас несколько минут можно разбить на подзадачи, которые будут вывполняться поочереди и время от времени давать возможность выполняться другим кускам кода.

mempfis_, спасибо, все получилось. Автоподьем убрал, поставил поднятие трубки на MDM2 и все ОК.
Хочу у Вас спросить насчет CMUX. Доки посмотрел, не все понял.
Установил CMUX.
Настройки:
COM3 - основной (модуль на USB-переходнике)
COM7 - виртуальный 1
COM8 - виртуальный 2
COM9 - виртуальный 3
COM10 - виртуальный 4
Птичка "Питон" установлена

Настройки в Telit Phyton Selection Tool
MDM - COM7
SER - COM8
MDM2 - COM9
SER2 - COM10

Нужно запустить модуль с отладкой, т.к. сейчас я его отладить не могу (с наскока не разобрался с CMUX, а делать было надо). Как я понял, в модуль скрипты должны загружаться и запускаться с Питона, туда же через порт COM10 должна идти отладка.
Установил в модуле AT#CMUXSCR=1,115200 и собственно и все... Все порты в Telit Serial Port MUX - idle. Попытка выполнить LSCRIPT из под Питона ни к чему не приводит (ошибка соединения).
Открываю гипертерминалом (точнее, Round Solution GSM Terminal) последовательно все порты, там ничего нет, хотя скрипт запущен. Я ожидал на одном из портов (на COM8) увидеть как отрабатывает скрипт.
Открываю порт COM3 - тоже ничего не вижу (ну там я ничего и не ждал). В итоге скрипт загружаю на модуль через Round Solution GSM Terminal, все работает, но отладки нет, а это сильно мешает...

CMUX вообще нужен для организации обмена данными по нескольким виртуальным каналам между процессором и модемом используя один физический канал (UART). Грубо говоря каналы CMUX со стороны процессора это аналог модулей MDM/MDM2. При запущеном скрипте для реализации MDM/MDM2/SER модем использует теже ресурсы, что и для организации мультиплексорного режима. Думаю что Вы не сможете запустить скрипт и модем в мультиплексорном режиме одновременно. Если Вы хотите выводить из модема какую-либо информацию в uart используйте модуль SER.
Попробуйте перевести модем в мультиплексорный режим и последовательно подключится к каждому виртуальному каналу и подать команду АТ\r чтобы проверить работоспособность.

mempfis_, спасибо в очередной раз. Не работают у меня виртуальные COMы... Где-то виде на форумах, что проблема может быть в самом USB-COM-переходнике (не очень понятно почему).
если можно, еще один вопрос. Вот была у меня проблема с определением RINGа. Решилась путем проверки +CLCC - все хорошо. Теперь похоже на то, что с приходом СМС тоже самое. Т.е. +CMTI приходит
и я его отслеживаю в основном цикле

res=MDM.receive(10)
a = RES.find('+CMTI: "SM",')
if(a!=-1):
Собственно смотрю что пришло

+CMTI может прийти не только в основном цикле, но и как я понимаю при любой команде MDM.recieve
Выход я вижу в AT@CMGL с опцией "REC UNREAD". Не очень нравится, что постоянно придется обращаться к SIM-карте...

И вообще, зачем тогда вообще нужны и RING и +CMTI, если их прямое использование проблематично.

Опрашивайте периодически используя AT+CMGL="REC UNREAD".
Я сам так делаю. Но перед опросом Вы должны проверить готовность SIM. Например AT#QSS=2\r - это настройка делается один раз, AT#QSS - проверка.

Будет так
AT#QSS
Ожидание OK
если 2,3 - можно читать СМС
иначе выход
AT+CMGL="REC UNREAD"
Ожидание OK
разгребание ответа.

В скрипте сложно выполнять поиск RING/CMTI т.к. он вклинивается в ответы на MDM.read.
Другое дело когда модем подключён к процессору. Там эти сообщения намного проще отловить особенно в режиме CMUX т.к. они приходят одним фрэймом, а вся работа с CMUX построена на ожидании фреймов. Да и если не в CMUX работать всёравно в обработчике сообщений от модема можно легко отловить RING/CMTI анализируя принятые строки (RING например приходит как RING\r\n\r\n CMTI скорее всего также)

Да, я так и понял, что ловить RING и CMTI не выход.
mempfis_ и если можно, еще один вопрос назрел (хоть уже далековато от datacall)

Работаю по GPRS (по MDM2).

comm='AT#SKTSET=0,'+port+','+IP+'\r'
res = MDM2.send(comm,0)
res = MDM2.send('AT#SKTSAV\r',0)
res = MDM2.send('AT#SKTOP\r',0)

Чтение ответов пропустил
port и IP получаю заранее

Соединение устанавливается, хотя иногда модем уходит в перезагрузку (что-то было про AT&K0 в качестве панацеи, но пока не пробовал)
После установки соединения проверяю статус (уже по MDM):
MDM.send('AT#SS\r\n',0)

Возвращает ошибку. CME ERROR 4. Ну много чего думал, оказалось, что AT#SS вообще выполняться не хочет никогда. Все время одна и та же ошибка 4. Даже не запускал скрипт, ручками вводил ПИН, включал GPRS, выполнял эти же команды - все то же самое. Как будто команда вообще не поддерживается модемом.
Из-за этого не получается ловить статус сокета и соответственно разрыв соединения отследить не могу...
Спасибо заранее

По поводу команд работы с GPRS - посмотрите набор AT#SCFG/AT#SD - я в первом посте писал о них.
Укажите модем и версию прошивки (AT+CGSN вроде - нет под рукой списка at-команд).
В модемах с которыми я работал - точнее в последних версиях прошивок для GE863-GPS, GE864, GL865, GL868 во всех AT#SS работал как положено.
AT&K0 - отключает управление потоком - врятли поможет при проблеме с AT#SS. Рекомендую прошить модем последней версией прошивки.
Проверьте код ошибки по по списку CME ERROR.

mempfis_,большое спасибо за помощь. Все получилось. Использовал #SD, вообще проблем нет: или соединяется или срабатывает тайм-аут. AT#SS тоже хорошо работает, только почему-то AT#SS=n уже нет. Но не страшно, пролистываю все 6 сокетов, смотрю свой.
Отработал чтение СМС по CMGL без всяких +CMTI, все работает. В общем, все хорошо.
Единственное, обнаружил опять проблему с datacall - через раз перегружается модуль при ATA. Причем когда стоял автоподъем, все было хорошо. Если в терминале ручками поднимать трубу по ATA, то тоже не перегружается. В общем, буду что-то думать

По поводу перезагрузок модема ничего сказать не могу.
AT#SS тоже использую без явного указания номера соккета. Буду на работе проверю как работает AT#SS=X на GL868 и GE864. По докам вроде должно работать.

GE864-DUAL V2, GL868-DUAL AT#SS\r\n и AT#SS=1\r\n работают без проблем.