Если нет ответа на команду, что делать? Опции

[Rash]

Добрый день.
Есть несколько вопросов относительно правильной последовательности при общении AT командами с SIM800R?

1. В SIM800R была передана AT команда, но на неё нет ответа или пришел ошибочный (битый) ответ. Что делать по истечению определённого таймаута? Какое это должно быть время (хотя бы для команд независимых от сети)?

Предполагаю, что если нет ответа, то необходимо послать эту команду ещё раз, например через 1..5 секунд. Но этот метод не эффективный, т.к. на самом деле модуль задумывается (это уже выяснили почему) и даёт ответ потом на две команды подряд. Например:

Код

AT        // Проверка связи и ждём 2 секунды ответа
AT        // ответа нет, истёк таймаут, посылаю ещё раз
OK        // ответа на 1-ую команду AT

AT+CBC    // Запрос напряжения АКБ, т.к. я получил OK на предыдущую команду

OK        // ответа на 2-ую команду AT  [b]!!! Тут происходит коллизия[/b]

+CBC: 0,92,4136    // Ответ напряжения АКБ
OK            // Ответ OK для запроса напряжения АКБ

В данном примере коллизию можно обойти т.к. я жду конкретный ответ для обработки +CBC

Но вот вариант с вклиниванием передачи данных, например по BT, смещает мой обработчик. Можно дописать ещё различных условий, но не считай, что так работать правильно.

Код

AT        // Проверка связи и ждём 2 секунды ответа
AT        // ответа нет, истёк таймаут, посылаю ещё раз
OK        // ответа на 1-ую команду AT

+BTSPPDATA: 1,16,SIMCOMSPPFORAPP    // Пришли данные по BT

AT+CBC    // Запрос напряжения АКБ, т.к. я получил OK на предыдущую команду

OK        // ответа на 2-ую команду AT  [b]!!! Тут происходит коллизия[/b]

AT+BTSPPSEND=1,11    // Запрос на передачу по BT, т.к. я получил OK на предыдущую команду

+CBC: 0,92,4136    // Ответ напряжения АКБ
OK                // Ответ OK для запроса напряжения АКБ

> SPP APP OK        // Передаю по BT, т.к. я получил OK на предыдущую команду
SEND OK            // Подтверждение передачи

2. Другой вариант - установить таймаут ожидания где-то 60 секунд, на любую команду (независимую от оператора) и если нет ответа, перегружать модуль.

Подскажите, кто как делал и какие есть рекомендации от производителя?

[CADiLO]

А ведь это описано в документации

Установить фиксированную скорость обмена и запомнить ее.
После этого модуль не будет синхронизироваться по первой АТ.

[Rash]

Скорость фиксированная 9600 кбит/сек (было и 115200 разницы не заметил). AT посылая для проверки, что модуль живой. Вместо AT может быть любая другая команда. Это пример.
Вопрос в другом, как корректно обработать таймауты если вдруг ответ не получен (не важно по какой причине) или получен сбойный пакет?

[CADiLO]

Странно... Чтобы модуль на АТ не ответил....
Теоретически возможно только в одном случае - подана следующая команда до получения ответа от предыдущей и она отменила действие предыдущей.
Поэтому следующую команду посылаем только получив любой ответ от предыдущей. Спешить там совершенно некуда.

V.250 : Serial asynchronous automatic dialling and control

5.6 Executing commands
Upon receipt of the termination character, the DCE shall commence execution of the commands in
the command line in the order received from the DTE. Should execution of a command result in an
error, or a character be not recognized as a valid command, execution is terminated, the remainder
of the command line is ignored, and the ERROR result code is issued. Otherwise, if all commands
execute correctly, only the result code associated with the last command shall be issued; result
codes for preceding commands are suppressed. If no commands appear in the command line, the
OK result code is issued.

5.6.1 Aborting commands
Some action commands that require time to execute may be aborted while in progress; these are
explicitly noted in the description of the command. Aborting of commands is accomplished by the
transmission from the DTE to the DCE of any character. A single character shall be sufficient to
abort the command in progress; however, characters transmitted during the first 125 milliseconds
after transmission of the termination character shall be ignored (to allow for the DTE to append
additional control characters such as line feed after the command line termination character). To
insure that the aborting character is recognized by the DCE, it should be sent at the same rate as the
preceding command line; the DCE may ignore characters sent at other rates. When such an aborting
event is recognized by the DCE, it shall terminate the command in progress and return an
appropriate result code to the DTE, as specified for the particular command.

[Rash]

Модуль на AT команду отвечает. И отвечает 2 раза.
В Логе я прокомментировал строчки.

*Первый раз послал AT
* Жду ответ, если в течении 2-х секунд
* Ответа нет, посылаю команду AT ещё раз
* Приходит ответ OK, практически сразу (как я понимаю на первую команду AT)
* Потом ещё через время, приходит ещё раз ответ OK (как я понимаю на вторую команду AT)

Команда AT показана для примера, такое может произойти с любой командой, если модуль не отправил ответ в отведенный мной таймаут. Возникает такое не всегда. От наличия Сим карты не зависит, от включённого BT модуля тоже, питание стабильно 4.1В. Время контролировалось логическим анализатором.

[CADiLO]

Вы так и не поняли.

>>> Жду ответ, если в течении 2-х секунд

Таймауты в даташите для некоторых команд указаны, но там есть специфика выполнения.

Остальные - ждать не 2 секунды и не придуманное время, а ДО ОТВЕТА.
Если ответа нет никакого, значит или модуль вас не понял или что-то забыли отправить - тут только копать что в обмене не так.

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

В свое время Телит описал эту ситуацию с временами - данный текст на 90% справедлив для модулей любого производителя.

Every command issued to the modules returns a result response if response codes are enabled (default). The time needed to process the given command and return the response varies from
command to command and may depend also from the network on which the command may interact. As a result every command is provided with a proper timeout time, if this time elapses without any
result from the operation, then an ERROR response can be reported as if the operation was not successful and the operation is anyway terminated. The timeout time is quite short for commands that imply
only internal set up commands, but may be very long for command that interact with the network (or even a set of Networks). The default timeout is 100 ms for all the commands that have no interaction
with the network or upper software layers. In the table below are listed all the commands whose timeout differs from the default 100 ms and their effective timeout is reported:


Command Time-Out (Seconds)
+CBST 0.2
+CR 0.2
+CRC 0.2
+CRLP 0.2
+CSCS 0.2
+CEER 5
+CGMI 5
+CGMM 5
+CGMR 5
+CGSN 20
+CIMI 20
+CNUM 20
+CREG 5
+COPS 180
+CLCK 180
+CPWD 180
+CLIP 180
+CLIR 180
+CCFC 180
+CCWA 20
+CHLD 20
+CUSD 180
+CAOC 20
+CSSN 20
+CLCC 20
+CPAS 5
+CPIN 20
+CSQ 5
+CPBS 5
+CPBF 20
+CPBW 20
+CALM 5
+CRSL 5
+CLVL 5
+CMUT 5
+CACM 20
+CAMM 20
+CPUC 20
+CMEE 5
+VTS 20
+GMI 5
+GMM 5
+GMR 5
+GSN 20
I3 5
I4 5
I5 5
+CSMS 5
+CPMS 5
+CMGF 5
+CSCA 20
+CSMP 5
+CSDH 5
+CSAS 5
+CRES 5
+CNMI 5
+CMGS 180 / 5 for prompt”>”
+CMSS 180
+CMGW 5 / 5 for prompt”>”
+CMGD 5
+CMGR 5
+CMGL 5
+CGACT 180
+CGATT 180
+CGDATA 20
+CGDCONT 20
+CGPADDR 20
+CGQMIN 20
+CGQREQ 20

The chain Command -> Response shall always be respected and a new command must not be issued before the module has terminated all the sending of its response result code (whatever it may be).
This applies especially to applications that “sense” the OK text and therefore may send the next command before the complete code <CR><LF>OK<CR><LF> is sent by the module.
It is advisable anyway to wait for at least 20ms between the end of the reception of the response and the issue of the next AT command. If the response codes are disabled and therefore the module
does not report any response to the command, then at least the 20ms pause time shall be respected. During command mode, due to hardware limitations, under severe CPU load the serial port can loose
some characters if placed in autobauding at high speeds. Therefore if you encounter this problem fix the baud rate with +IPR command.

[Rash]

Ув. CADiLO, скажите, что из приведенных Вами цитат документации я не выполнил?

The default timeout is 100 ms for all the commands that have no interaction
with the network or upper software layers. In the table below are listed all the commands whose timeout differs from the default 100 ms and their effective timeout is reported:

Я жду 2 секунды на несчастную команду AT

It is advisable anyway to wait for at least 20ms between the end of the reception of the response and the issue of the next AT command.

В случает ответа, следующую команду я посылаю не раньше чем через 50 мсек.

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

Допустим ответа нет никакого, как мне узнать об этом? если:

ждать не 2 секунды и не придуманное время, а ДО ОТВЕТА.

В самой посылке всё в норме. Посылка не меняется от времени. Могу снять ещё раз логическим анализатором Saleae и показать, если проведений выше информации недостаточно.
Могу даже плату прислать, что б убедиться в этом.

[CADiLO]

Почему у меня больше чем за десяток лет работы с модулями, а начинал я еще до Гаммы разрабатывая устройства с GR47 и MC55, ни разу не было чтобы модуль не ответил ?
Да и достаточно много клиентов знаю которые жаловались на что угодно, но только не на то что модуль не отвечает.
Так что надо смотреть все - от физического уровня (согласование и питание), до логического (алгоритм и идеология софта)
Я не склонен думать что Вы что-то делаете неправильно, скорее всего как говорится - "замылился глаз" - и вот какую-то мелочь упустили из вида.

Проверить можно достаточно просто - отсоединить контроллер, взять USB <> UART с правильными уровнями 2.8 вольта, запустить терминалку работающую со скриптами
и умеющую распознать приход ответа (любого), зациклить ее и писать лог пока не надоест. И увидите что модуль отвечает всегда.

[Rash]

Я просто предусматриваю такую возможность, что может не ответить. В релизе стараюсь сделать программные вочдоги на все внешние интерфейсы и определить логически адекватное время ожидания выполнения. Сработал, сохранил ошибку, перезапустил интерфейс или модуль. Т.к. считаю лучше сделать самовосстанавливающуюся систему, нежели зависшее устройство. Научен горьким опытом. А причины по чьей вине это другая история.

[CADiLO]

Все предусмотреть невозможно
Одесситы лет 8 назад выпускали модемы на Wavecom модулях. Ставились они в ящики к контроллерам управления светофорами.
Так вот случилось так что один из ящиков висел на том же столбе где висело управление стрелкой для трамвая.
Ну а трамваи естественно на стрелке часто искрят пантографом. Не знаю уж как там эта искровая помеха наводилась, но модем не просто зависал, а зависал так что только питанием перезапускался.

И я еще когда-то показывал классический зависон из-за логической ошибки в GSM стеке.
Если модуль или телефон находится в предответном состоянии и пропал сигнал соты, то после появления сигнала он не выйдет из цикла и так и будет тупо ждать.
Причем такая "черная дыра" есть у меня на огороде. Если я пройду через нее с телефоном в момент когда CLCC <stat> = 5 , то все, только выключение.

Или как предусмотреть заскоки операторов? Вон LMT в свое время плюнул на стандарт и поменял логику работы с командой COPS.
И все, приехали - часть модулей не может зарегиться в сети, так как тупо получает неверный ответ на какой-то там слой шифрования.
А телефоны, не использующие это, так как они не М2М устройства и им не нужно это по стандарту, конечно регятся в сети быстрее.

[Rash]

Я ж думаю одесситы в следующей версии добавили возможность перезагрузки в этом случае и больше не будут вешать модули с искрящими элементами.
Всё да не возможно, но то что в голову пришло и то, что ранее опытом получено, думаю необходимо предусматривать. Я уже проходил непредусмотренное программное состояние для приёмопередатчика (не GSM), когда можно сказать прожил месяц в шахте и каждый день наматывал по несколько километров там. Но там свои проблемы с питанием из-за искробезопасности и помех хватает. После общения с производителем, я сделал управление приёмопередатчиком не по даташиту, и проблема решилась. Заодно добавил таймауты на кучу состояний при работе с ним, т.к. ещё раз попадать так желания не было.
Поэтому для меня время выполнения секунды, это вечность, На отладку уходит много времени. Стараюсь все всегда сделать с минимальным временем исполнения, все интерфейсы через DMA, отдельными библиотеками отвязанными от приложения, даже если задача этого не требует, что бы быстрее отладить возможные состояния, даже те которые не предусматриваются.

[Short Circuit]

хм.. Я тоже периодически проверяю кроме регистрации - просто ответ на АТ - есть ответ АТ - идем дальше в цикле..
Если нету ответа - значит этот модуль "висит"(на всякий случай предусмотрено такое) и выключаем-включаем модуль.
И так во всех устройствах. На АТ команды всегда! отвечает.
Может все таки проц некорректно реагирует?

Поэтому для меня время выполнения секунды, это вечность, На отладку уходит много времени.

Это модем МОДЕМ.. и у него своя жизнь, приходится под него подстраиваться.

Сообщение отредактировал Short Circuit - Oct 6 2017, 04:41

[Mysteo]

Что-то у вас правда в схеме наворочено, работал с модулями не так часто, но были разной линейки в течение 6 лет, на стандартную AT там практически мгновенный ответ должен быть.
Разок была ситуация с SIM900D , что он первые байты данных никак не воспринимал, приходилось два раза подряд одной итоже отсылать, но решилось прошивкой , попробуйте перепрошить ваш модуль.
Может что программно на уровне МК у вас, пробуйте через терминал и USB-UART преобразователь

Сообщение отредактировал Mysteo - Oct 6 2017, 05:23

[Rash]

Я уже ранее писал, такое бывает не всегда и может быть на любую команду. Бывает быстрый ответ, бывает долгий. Даже ранее тему отдельно создал . Сказали операционка такая. Ну и ладно, хрен с ней. Решил выяснить сколько ждать чтобы обработать вариант завившего модуля или если по какой то причине я принял битую посылку.
Навороты они все добавляется после. И повторюсь ещё, на SIM900R этот же код работает и таких задержек от SIM900R нет. Где платы CPU, SIM900R и плата приёмопередатчика между собой соединены проводочками в несколько сантиметров, навесным монтажом. Прошивка последняя B06 для SIM800C32.

[gerber]

Судя по всему, у вас включен какой-то Hardware Flow Control на UART-e контроллера, ответ приходит только тогда, когда включен передатчик, похоже на замыкание линий TxD и RTS.