Всем здравствуйте.

Есть следующая проблема.

Имеется gsm-модем на чипе SIM900. Он используется в мультиплескируемом режиме (далее для краткости мукс-режим), с помощью
модифицированной программы gsmMuxd; изменения касаются поддержки расширенных пакетов протокола gsm 07.10 (закомментированы по умолчанию в gsmmux, именно этот формат пакетов реализован в SIM900).

При попытке установить GPRS-соединение в мукс-режиме модем перегружается. В обычном режиме все работает.

Версия прошивки:

Revision:1137B09SIM900M64_ST

Лог прилагается. В логе строки, начинающиеся с serial[] -- это ответ от модема в 16-ричной/символьной формах.
В районе строки Dropping frame: expected packet length is 8751, received 107 произошла перезагрузка (+CFUN: 1 +CPIN: READY Call Ready), до этого шли пакеты по протоколу gsm07.10 (обрамленные байтами f9).

На 6-й (родной) прошивке была эта проблема, на одном из модемов вылечилась перешивкой на 9-ю версию прошивки, на другом модеме проблема не исчезла.

Что происходит и как это вылечить ?

Не видно, где прилагается.

Я правильно понимаю, используется внешний, относительно модема, TCP-стек? И сбой происходит в момент работы PPP-протокола?

Это печально.

Понимаете частично правильно. Сбой происходит на команде AT+CGDCONT, когда ppp еще не стартовал.
Вот прилагается.

А какая разница какой стек, внешний или не внешний ?

Модем SIM900D, если это имеет значение.

Очень интересно получается.

>>>Модем SIM900D, если это имеет значение.

А прошивку значит указываем от обычного

>>>Revision:1137B09SIM900M64_ST

И что, все работает? Не верю. Так что или с написанием ошиблись, или заливайте как положено прошивку.


Кроме того сами пишете что

>>>> На 6-й (родной) прошивке была эта проблема, на одном из модемов вылечилась перешивкой на 9-ю версию прошивки, на другом модеме проблема не исчезла.

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

Ну и последнее - на 900D лучше не ориентироваться.

Да непонятно что за модем у вас SIM900 или SIM900D; разница есть.
И также непонятно, зачем внешний стек ипользовать, боязьнь от SIM300 осталась?
Внутренний стек не так и плох, сделать ему аналог снаружи не просто, да и зачем?

Попробую ответить по порядку.


Вполне возможно что и залили не ту прошивку. Спасибо за замечание.

Где можно найти прошивку для sim900d ?


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

>>>Где можно найти прошивку для sim900d ?

Если брали у нас - то как обычно письмом запрос, я вышлю.

Обновили прошивку:

Revision:1137B08SIM900D64_ST_DTMF_JD_MMS

Уже даже не делаем AT+CGDCONT=1 итд. Перезагрузка просто на

AT+CGDCONT?

в мукс-режиме.

В обычном режиме отвечает

+CGDCONT: 1,"IP","vpni.kyivstar.net","0.0.0.0",0,0
+CGDCONT: 3,"IP","","0.0.0.0",0,0

Не думаю что дело в железе. Эта команда ведь не приводит к смене режима работы модема, потребления питания.

Можно получить полностью лог до момента перезагрузки ?

Вот лог

Нет, пожалуйста лог с RX/TX модема в виде АТ команд и данных. Желательно с временными метками.
Можно снять сниффером - например LGComSpyInst или терминалом с второго компа физически читающего обе линии.

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

Да, под линуксом. Вы озадачили...
Этот лог -- что приходит из порта.

Да, только вашей программой это так:

serial[2]=52/R
serial[3]=44/D
serial[4]=59/Y
serial[5]=d/
serial[6]=a/

gsmMuxd[18024]: is in extract_frames
gsmMuxd[18024]: Dropping frame: expected packet length is 8751, received 7
gsmMuxd[18024]: out of extract_frames
gsmMuxd[18024]: Serial Data
serial[0]=d/
serial[1]=a/

serial[2]=2b/+
serial[3]=43/C
serial[4]=46/F
serial[5]=55/U
serial[6]=4e/N
serial[7]=3a/:
serial[8]=20/
serial[9]=31/1

А надо как в терминале....

RDY

+CFUN: 1

Если не срочно, то как время будет переварю Ваш текст в удобочитаемый чтобы посмотреть что там к чему.

А как же его сделать как в терминале, если там бинарные пакеты идут ? RDY CFUN -- это как раз данные, которые хоть и в текстовом виде приходят (которые можно расписать в строки как вы хотите), но их там быть не должно!!! Должны приходить пакеты с ответами, завернутые в байты f9 (сигнатура начала/конца пакета в протоколе GSM 07.10), вместо этого модем перегружается и выдает RDY +CFUN итд -- заставку загрузки.

инициализация и все что предвараяет данные ведь не бинарная, а АТ команды.
кроме того бинарник можно вписать в виде массива.

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

и еще - питание линейный стабилизатор или импульсник?
второе - это на всех операторах такое?
третье работаете на автоопределении или фиксированой скорости?

По питанию ответит наш электронщик.
На всех операторах.
Работаем на фикс.скорости 115200 (на автоопределнии не срабатывает AT+IPR.

питание импульсник, 4,2 вольта, собран на LM2576

О, моя любимая LM2576
Если не против, уточните пожалуйста какая индуктивность (тип и исполнение) и какой диод применены в стабилизаторе.
Уже ловились на том что ставили не то что рекомендовано в даташите и стабилизатор или давал всплески/провалы или не обеспечивал ток.

Это так чтобы уже исключить питание.
Кстати проверить можно подключив к модулю нормальный Li-Ion аккумулятор (который может отдавать ток в режиме 2.5С) - если не будет перегрузок, то надо рыть питание.

диод MBRS3100, индуктивность RCH114NP-101KB
а как питание может влиять на перезагрузку при AT+CGDCONT?

первое
>>>В районе строки Dropping frame: expected packet length is 8751, received 107 произошла перезагрузка (+CFUN: 1 +CPIN: READY Call Ready), до этого шли пакеты по протоколу gsm07.10

второе
>>>>Сбой происходит на команде AT+CGDCONT, когда ppp еще не стартовал.


так все-таки когда уже идут пакеты или при команде?????

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

кроме того я уже написал что если

>>>> На 6-й (родной) прошивке была эта проблема, на одном из модемов вылечилась перешивкой на 9-ю версию прошивки, на другом модеме проблема не исчезла.

железо одинаково, прошивка одинакова - на одном из модемов проблема исчезает.
если это так то остается что ? - правильно то в чем разница - плата, обвязка, работа питания.
ищем в чем разница в работе и проверяем.

Можно использовать программу snooper, есть в репозитории дебиана, например.
Подключается к двум последовательным портам (вход одного на линию RX, вход другого на линию TX) и записывает в файл с временем.




А подключение к этому порту (SIM900) может иметь смысл вообще для себя, а не для SIMCOM? Имеет ли смысл на плате делать разъём для подключения к debug?

у меня сделан, я через него прошивку заливаю, так как основной отключается

Я с кутелом екпериментировал, по поводу перезагрузок могу сказать, что причин может быть много.
1. Питание. Для исключения ставьте свежезаряженный лиион и тестируйте с ним. Как можно ближе к модулю - конденсатор.
2. ВЧ-тракт. Убедился на собственном опыте - при несогласованной антенне (а она НИКОГДА не бывает такой, разве что случайно) при определенных условиях модуль спонтанно перезагружается, скорее всего, от наводок отраженной волны. Поменяйте антенну, цепи согласования, и посмотрите, что изменилось.
3. Сбои в RS232. Это и наводки на MAX232, и ее глюки, и фильтрация питания, и несогласование уровней. Попробуйте исключить штаные цепи, применив внешний переходник (можно и на USB).
4. Програмные (например, некоторые неверные форматы АТ-команд и т.п.).

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

ПС: в серии наших устройств на М12 причиной перезапуска в момент посылки жпрс-данных было несогласование с антенной. Причем голосовой звонок проходил на ура.

Для себя дебаг порт в первую очередь удобен именно для перепрошивки чтобы не коммутировать основной.
При работе с SIM08 (со спепрошивкой) и у SIM908 туда вываливается GPS NMEA
Он доступен в ЕАТ, правда пока только на 115200, но обещали сделать сменный битрейт
Ну и при явных глюках оттуда снимается инфа при помощи спайтрассера.

Ну может еще что туда сделают

Уточняю.

В обоих случаях общение идет по протоколу GSM 07.10.
Да, PPP не стартовал, но общение-то уже идет в мукс-режиме!

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

ОК - просмотрю повнимательней

Аналогично. Только с Телитом 865-м. Рассудил так - заявленный потребляемый ток (пиковый) подразумавает, что выходной каскад работает на согласованную 50-омную нагрузку. На "просто проводке" заявленные характеристики могут не совпадать. Замеры просадок напряжения это подтвеждали. 2А стабилизатор не вытягивал без больших емкостей (1500 мкФ). После замены проводка на нормальную антенну пульсации напряжения заметно уменьшились, все заработало.

100% совпадает и с нашими исследованиями. Причем, учитывая авторегулировку мощности от уровня сигнала соты, прояляется спонтанно. Хуже всего то, что по аналогии с антеннами, нет полной уверенности и в соответствии волнового сопротивления модуля заявленному...

что-то дискуссия ушла в другую сторону...

а можно сервисную программу получить каким-то образом?

Цитирую из мучений другого товарища.

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

AT+CGDCONT=1,\"IP\",\" www.ab.kyivstar.net\"

Вот-вот - необходимо экранировать \

В общем, настроился. Как оно работало раньше - Бог его знает

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

А я вот с линухом не сталкивался, для меня это было новостью.

Добрый день.

Уточните, пожалуйста. Кому то удалось запустить gsmmuxd с модемом SIM900?

Самому запустить не удалось. Проблема в том что при успешном соединения ppp через gsmmuxd пакеты не ходят, однако без использования gsmmuxd после установления соединения пакеты ходят.
Лог в приложении: Нажмите для просмотра прикрепленного файла

PS: Пробовал на прошивке модема B11 и B12

Мне кажется что автор сообщения должен обратится к разработчику этой софтины GsmMuxd
http://developer.berlios.de/projects/gsmmux/
Во всяком случае это будет продуктивнее

У нас под линуксом с SIM900R прекрасно работает вот с этой софтиной после небольших модификаций: https://github.com/contactless/cmux/ (ссылка на оригинальный репозитарий там есть).

В ядре нужна поддержка gsm line discipline или как-то так.