|
|
  |
CMUX полуработает, Quectel M72 |
|
|
|
Feb 26 2013, 15:41
|
Знающий
   
Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594

|
Прошу помощи кто воевал с CMUX: Странности: 1. Даю команды AT+CMUX? +CMUX: -1,0,5,127,10,3,30,10,2 OK AT+CMUX=0,0,5,31,10,3,30,10,2 OK модем переходит в режим, я его там инициализирую на 2 виртуальных порта, и прверяю на одном из портов AT+CMUX? +CMUX: 0,0,5,127,10,3,30,10,2 Почему во первых mode сначала -1, а затем 0? Типа выключено/включено? И самое главное - почему значение размера пакета остается по умолчанию - 127, я же ясно пишу 31!?
2. Когда пакеты короткие, то все нормально, но когда передается GPRS, где один PPP пакет состоит из нескольких пакетов CMUX - у меня данных накидывает даже более 127 байт. При чем количество объявляет 127, а пофакту вижу, что прилетело на несколько штук больше (3-4), при чем лишних каких нибудь данных в пакете не наблюдается (побайтно проверил - все четко), как будто он действительно нарезает не по 127, а скажем по 130 байтов. Что за...?
Информация о модеме: ATI Quectel_Ltd Quectel_M72 Revision: M72R01A05N32 OK В целом более менее работает - на одном порту поднимаю PPP, другой оставляю на АТ командах, и оно работает за исключением пунктов выше. Но мне это критично. Что не так я делаю?
|
|
|
|
|
Feb 28 2013, 08:39
|

Частый гость
 
Группа: Свой
Сообщений: 188
Регистрация: 21-04-06
Из: Украина, Киев
Пользователь №: 16 335

|
Цитата(kan35 @ Feb 26 2013, 18:41)  И самое главное - почему значение размера пакета остается по умолчанию - 127, я же ясно пишу 31!? А с какой целью уменьшаете размер пакета?
|
|
|
|
|
Mar 1 2013, 08:08
|

Частый гость
 
Группа: Свой
Сообщений: 188
Регистрация: 21-04-06
Из: Украина, Киев
Пользователь №: 16 335

|
Цитата(kan35 @ Mar 1 2013, 10:53)  Что делать.... Вы личные сообщения читали? Дайте свою аську, скайп или мыло.
|
|
|
|
|
Apr 10 2014, 06:35
|
Участник

Группа: Участник
Сообщений: 17
Регистрация: 9-04-14
Пользователь №: 81 290

|
Уважаемые знатоки, при использовании команды CMUX модем отвечает всего две секунды, после затыкается и далее не реагирует ни на AT команды ни на мультплексорные. Хотя в первые две секунды полностью отвечает и на те и на другие. использую модем Sierra Wireless WS6318. В чем может быть проблема?
|
|
|
|
|
Apr 11 2014, 04:16
|

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

|
Цитата(kan35 @ Mar 1 2013, 10:53)  Проблемный момент: Например случилось, что я кидаю в канал GPRS данные, а ответа нет, типа висит в неизвестном состоянии. Или просто хочу переоткрыть сессию. В обычном режиме отпарвлял +++ и модем переходил в AT режим. Тут же отправляю +++ через CMUX - бесполезно. Хотя просто +++ - работает (видимо при этом CMUX закрыается автоматом), но закроются и остальные каналы мультиплексора - а там своя жизнь и возможно никаких проблем и нет. Закрытие одного лишь проблемного канала через средства CMUX решит проблему? И закроется ли соединение GPRS когда я закрою этот канал? Или есть другие варианты?
Сам же отвечу. Не помогает переоткрытие витртуального порта. Как порт в GPRS режиме находился, так и продолжает. Пробовал кидать ATH по другому каналу - тоже нулевая реакция. Что делать.... А зачем Вам в режиме CMUX отправлять +++? У Вас как минимум 3 виртуальных канала. Если Вы по одному открыли соединение с сервером, то проконтролировать статус соединения вероятно можно по другому. Например в Telit при открытии соккета по одному каналу, можно отправлять команду AT#SS (Soket Status) по другому каналу и прекрасно мониторить текущее состояние соединения. Я использую такой подход помимо отлавливания стандартных ERROR/NO CARRIER, которые могут прийти по каналу, по которому открыто соединение. По поводу +++ и работы с виртуальными каналами Код When in Multiplexed mode, the escape sequence ‘+++’ will not be detected by the module. It is responsibility of the application to use the break octet of the MSC (Modem Status Command) instead. Break octet of the MSC produce the same effect as ‘+++’ escape sequence. MSC прекрасно работает заменяя при этом контроль линий управления потоком, которые в режиме CMUX не доступны. В одном из недавних проектов MSC были успешно использовано для RTS/CTS управления потоком при передаче больших блоков данных. Ещё Вы писали по поводу ограничения размера пакетов в 31 байт. В самом описании CMUX сказано что пакеты могут содержать до 127 байт - и это действительно так. Я без каких-либо сбоев отправлял как одиночные байты, так и посылки по 127 байт. Но в проектах использую в основной пакеты по 64 байта. И по поводу скорости работы процессора - 12 МГц вполне достаточно для обработки пакетов CMUX на скорости 115200. С этим справлялась 16тимегагерцовая ATMega, а CORTEX-M3/M0 и подавно. Возможно у Вас просто недостаточный размер буффера UART (если конечно используете FIFO) или Вы просто теряете одиночные байты из-за чего у Вас получаются битые пакеты.
|
|
|
|
|
Apr 22 2014, 12:24
|
Участник

Группа: Участник
Сообщений: 17
Регистрация: 9-04-14
Пользователь №: 81 290

|
Как еще можно разорвать режим передачи данных для GPRS соединения, без команды WIPCLOSE и использования +++ в мультиплексорном режиме? Проблема заключается в том чтобы на другую сторону не передался +++ и желательно не закрывалась сесия GPRS
модем WS6318
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|