Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SIM600 и SIM700
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Сотовая связь и ее приложения
Sergey Xi
Тема: SIM600 и SIM700
Описание темы: Проблемы с RI, DCD и +++

Имеются модули SIM600 в виде USB-модема Novacom GNS-60iu, информация по ATI:
CODE
Onda_Communication_Spa
Onda_N60
Revision:N60_V16.0.4_B03

и SIM700 на отладочной плате SIM700_EVB_V2.02, информация по ATI:
CODE
SIMCOM_Ltd
SIMCOM_SIM700
Revision:1604B01SIM700M32_ST


Для управления этими модемами с PC-шного компьютера разрабатывается компонент, который стучится к ним по интерфейсу последовательного порта (честного в случае с SIM700, либо FTDI-ного в случае с SIM600). В обоих модемах не работает заявленное производителем функционирование линий RI и DCD, которые обе всегда находятся в высоком потенциальном уровне (смотрел осциллографом соответствующие линии до драйвера RS-232 в случае SIM700 и FT232B для SIM600). Командочка AT&C никак не влияет в обоих случаях (что AT&C0, что AT&C1), при этом AT&D1 честно задает переключение по перепаду DTR 1->0 из data-режима в командный.
Проблема заключается в том, что для обнаружения факта разрыва data-соединения приходится анализировать поток входящих данных на предмет наличия в хвосте парочки байт "3<CR>", соответствующих verbose-коду "NO CARRIER". При обнаружении их, переключиться в командный режим, дергая за DTR, получить в ответ парочку "0<CR>" ("OK") в случае успешного переключения, когда парочка "3<CR>" относится к высокопротокольным данным, или не получить, если действительно наличиствовал разрыв, и тогда "3<CR>" надо вытолкнуть из буфера высокопротокольных данных. При этом, все существенно усложняется за счет буферизации данных коммуникационным драйвером Windows, и теоретически, к моменту обработки парочки "3<CR>" в буфер может пролезть парочка байт "0<CR>" (тоже высокие данные) и немедленный разрыв, или разрыв после шевелением DTRа с получением отклика, т.к. после этого до выдачи "0<CR>" требуется выдержать некоторый таймаут. Безусловно, это все вероятностные процессы с малой долей вероятности их возникновения, однако она далеко не близка к нулю, и в случае неблагоприятного совпадения сопутствующих факторов, конечный автомат, обслуживающий и без того дебильный механизм AT-команд (привет 80-90-м годам, когда модемами управляли операторы с терминалов, вводя AT-команды!), в лучшем случае выплюнет высокоуровневому протоколу несколько лишних байт — кодов управления модема. А в хучшем — может и вообще уйти в ошибочное состояние.
При наличии рабочей DCD эта проблема в значительной степени решалась бы. Причем, в других модемах (например, на основе модуля Teltonika Tm2 — старый USB-шный G10), обе линии RI и DCD честно "шевелятся", зато в нем отсутствует multiplexer-режим, который вроде бы заявлен в новой AT-Guide, но на команду AT+CMUX модем ругается.

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

Еще один подвопросик касается пресловутых трех плюсов ("+++"), призванных переключать модем из data-режима. Мне они вообще не упали, я DTR-ом вывожу модем из ступора, но... вдруг возникнет ситуация, когда высокоуровневому протоколу придется автономно передать три плюса?! Я понимаю, что решение обычно укладывают в соответствующую инкапсуляцию высокого протокола, исключающую такую ситуацию, но все же? Пробовал по таймауту: если перед первым плюсом выдержать заявленное время, и после последнего — тоже, то при наличии третьего срединного плюса обязательно осуществляется переключение в командный режим. Единственное решение, которое пока удалось найти, приделывать к посылке из трех плюсов четвертый "левый" символ в начале, или конце. Может быть имеются другие решения, основанные на таймаутах хотя бы?! И почему-то еще SIM600 после получения всех плюсов предварительно выкидывает их в канал (а удаленная стороная честно получает), а потом вываливается в командный режим, а SIM700 только вываливается в командный режим, без передачи их в канал (что, вообще говоря, разумно).

С уважением.
V_G
Похоже, у этих модулей хронические проблемы с аппаратными ногами. У меня SIM700D. С RI - та же песня. Более того, нога STATUS честно устанавливается в 1 после включения питания только на время соединения с сетью. После того, как поймали оператора и светодиод NET медленно замигал (раз в 3 с), STATUS уходит в 0. Так что если случайно возник ресет (а при отладке с эмулятором это вообще не случайно), анализировать эту ногу нельзя. Придется давать просто "AT" и по наличию или отсутствию ответа определять, включен модуль или нет...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.