Перейти к содержанию
    

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

Добрый день.

Есть несколько вопросов относительно правильной последовательности при общении 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 секунд, на любую команду (независимую от оператора) и если нет ответа, перегружать модуль.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Установить фиксированную скорость обмена и запомнить ее.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вопрос в другом, как корректно обработать таймауты если вдруг ответ не получен (не важно по какой причине) или получен сбойный пакет?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Странно... Чтобы модуль на АТ не ответил....

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

Поэтому следующую команду посылаем только получив любой ответ от предыдущей. Спешить там совершенно некуда.

 

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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Модуль на AT команду отвечает. И отвечает 2 раза.

В Логе я прокомментировал строчки.

 

*Первый раз послал AT

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

* Ответа нет, посылаю команду AT ещё раз

* Приходит ответ OK, практически сразу (как я понимаю на первую команду AT)

* Потом ещё через время, приходит ещё раз ответ OK (как я понимаю на вторую команду AT)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

>>> Жду ответ, если в течении 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ув. 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 и показать, если проведений выше информации недостаточно.

Могу даже плату прислать, что б убедиться в этом.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Почему у меня больше чем за десяток лет работы с модулями, а начинал я еще до Гаммы разрабатывая устройства с GR47 и MC55, ни разу не было чтобы модуль не ответил ?

Да и достаточно много клиентов знаю которые жаловались на что угодно, но только не на то что модуль не отвечает.

Так что надо смотреть все - от физического уровня (согласование и питание), до логического (алгоритм и идеология софта)

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

 

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

и умеющую распознать приход ответа (любого), зациклить ее и писать лог пока не надоест. И увидите что модуль отвечает всегда.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все предусмотреть невозможно :)

Одесситы лет 8 назад выпускали модемы на Wavecom модулях. Ставились они в ящики к контроллерам управления светофорами.

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

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

 

И я еще когда-то показывал классический зависон из-за логической ошибки в GSM стеке.

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

Причем такая "черная дыра" есть у меня на огороде. Если я пройду через нее с телефоном в момент когда CLCC <stat> = 5 , то все, только выключение.

 

Или как предусмотреть заскоки операторов? Вон LMT в свое время плюнул на стандарт и поменял логику работы с командой COPS.

И все, приехали - часть модулей не может зарегиться в сети, так как тупо получает неверный ответ на какой-то там слой шифрования.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хм.. Я тоже периодически проверяю кроме регистрации - просто ответ на АТ - есть ответ АТ - идем дальше в цикле..

Если нету ответа - значит этот модуль "висит"(на всякий случай предусмотрено такое) и выключаем-включаем модуль.

И так во всех устройствах. На АТ команды всегда! отвечает.

Может все таки проц некорректно реагирует?

 

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

 

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

Изменено пользователем Short Circuit

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Разок была ситуация с SIM900D , что он первые байты данных никак не воспринимал, приходилось два раза подряд одной итоже отсылать, но решилось прошивкой , попробуйте перепрошить ваш модуль.

Может что программно на уровне МК у вас, пробуйте через терминал и USB-UART преобразователь

Изменено пользователем Mysteo

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...