|
Telit datacall, Не могу понять как правильно |
|
|
|
May 22 2012, 13:23
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
Пришлось недавно заняться 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 меня ждет видимо то же самое Спасибо.
|
|
|
|
|
May 24 2012, 08:53
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
Так вот и непонятно как это сделать. Вот фрагмент передачи данных
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 - за канал передачи данных
|
|
|
|
|
May 24 2012, 09:56
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
Ну вообще говоря, у меня должно и по 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 - в командном?
|
|
|
|
|
May 28 2012, 08:34
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
mempfis_, спасибо. Теперь все понятно. Проблему я так и решил - путем установки автоподъема командой через MDM2. Все сразу стало как надо. Неясно вот что: Цикл работы программы предполагает периодическое чтение по MDM2 для приема данных и отслеживания NO CARRIER. Но после опроса возможен случай, когда мне необходимо выполнять действия в течении нескольких минут. Пока не выполнятся все необходимые операции, в начало цикла (там, где я читаю по MDM2) я не попаду. Иными словами, в течение нескольких минут отловить NO CARRIER я не могу. Насколько я понял, в модулях нет возможности сделать многопоточность (тогда я бы смотрел MDM2 в другом потоке), каких-то прерываний тоже нет. Не произойдет ли потеря при приеме данных (пропуск NO CARRIER)?
|
|
|
|
|
May 30 2012, 13:50
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
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, все работает, но отладки нет, а это сильно мешает...
|
|
|
|
|
Jun 1 2012, 08:47
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
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, если их прямое использование проблематично.
|
|
|
|
|
Jun 1 2012, 09:41
|

Профессионал
    
Группа: Свой
Сообщений: 1 001
Регистрация: 27-06-06
Пользователь №: 18 409

|
Цитата(White_rat @ Jun 1 2012, 11:47)  +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 скорее всего также)
|
|
|
|
|
Jun 4 2012, 15:38
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

|
Да, я так и понял, что ловить 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, выполнял эти же команды - все то же самое. Как будто команда вообще не поддерживается модемом. Из-за этого не получается ловить статус сокета и соответственно разрыв соединения отследить не могу... Спасибо заранее
|
|
|
|
|
Jun 5 2012, 06:46
|

Профессионал
    
Группа: Свой
Сообщений: 1 001
Регистрация: 27-06-06
Пользователь №: 18 409

|
Цитата(White_rat @ Jun 4 2012, 18:38)  Работаю по 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)
После установки соединения проверяю статус (уже по MDM): MDM.send('AT#SS\r\n',0)
Возвращает ошибку. CME ERROR 4. Ну много чего думал, оказалось, что AT#SS вообще выполняться не хочет никогда. По поводу команд работы с GPRS - посмотрите набор AT#SCFG/AT#SD - я в первом посте писал о них. Укажите модем и версию прошивки (AT+CGSN вроде - нет под рукой списка at-команд). В модемах с которыми я работал - точнее в последних версиях прошивок для GE863-GPS, GE864, GL865, GL868 во всех AT#SS работал как положено. AT&K0 - отключает управление потоком - врятли поможет при проблеме с AT#SS. Рекомендую прошить модем последней версией прошивки. Проверьте код ошибки по по списку CME ERROR.
Сообщение отредактировал mempfis_ - Jun 5 2012, 06:47
|
|
|
|
|
Jun 8 2012, 07:55
|
Группа: Новичок
Сообщений: 8
Регистрация: 22-05-12
Пользователь №: 71 957

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