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

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

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



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

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



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, скажите, что из приведенных Вами цитат документации я не выполнил?

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


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


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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

Может где лишнюю подтяжку на UART поставили?

Покажите кусок схемки - UART часть.

Схему загрузил
Цепи идущие на мк STM32
GSM_PWRKEY - используется
GSM_STATUS - используется
GSM_TXD - используется
GSM_RXD - используется
GSM_RTS - не используется
GSM_CTS - не используется
GSM_RI - не используется
GSM_RF_SYNC - не используется

Уберите резистор R64 и вроде будет счастье

на линиях CTS и RI делитель тоже не нужен

Ну как бы да, в даташите нет этих резисторов. Возможно подтяжка держит стоповое состояние....

понял, спасибо, ближе к вечеру уберу резисторы R64, R70, R72.
Забыл указать, на схеме он не нарисован, что установлен резистор 10k на землю на линии DTR (увидел о его включении на форуме, после того как плата в заказ ушла).
Скажите, ножка RF_SYNC для чего-нибудь полезного нужна? Была разведена на всякий случай.

>>>>Забыл указать, на схеме он не нарисован, что установлен резистор 10k на землю на линии DTR

If these pins are unused, keep open.


Хотя апнотес пишет что

NOTE: The DTR signal must pulled to low level voltage when DTE is sending data to module.
If DTR does not connect with DTE, DTR must be connected to GND via a 10K resistor.

Но тут скорее всего коллизия с тем что апнот более старый и создавался на основе доки от 900 серии.
В практическом применении, если DTR не пользуемся, то висит себе в воздухе и никому не мешает.
Хотя я бы завел на контроллер - удобно будить модуль или переключать дата/команд моде.

А по умолчанию ножка игнорится, поэтому резистор там не нужен.


6.4 DTR
Module will automatically go into SLEEP mode (set AT+CSCLK=1) if DTR is set to high level and there is no on air and no hardware interrupt (such as GPIO interrupt or data on serial port). In this case, the current consumption of module will reduce to the minimal level. During SLEEP mode, the module can still receive paging message and SMS from the system normally. If DTR Pin is pulled down to a low level, this signal will wake up module from SLEEP mode. The serial port will be active after DTR changes to low level about 50ms. DTR must be held low during the call.
The AT command “AT&D” can be used to set DTR function mode.

􀁺 When it is set to "AT&D0", TA ignores status on DTR.

􀁺 When it is set to "AT&D1", ON (low)->OFF (high) on DTR: module will be changed to command mode when the connected call is remained.

􀁺 When it is set to "AT&D2", ON->OFF on DTR and pull DTR to high more than the time that the setting value by ATS10: call is disconnected, module is changed to command mode.

TCP/IP applications only support AT&D1 and AT&D0. In TCP/IP application (for more detail, please refer to TCP/IP application NOTE), DTR line of serial port can also be used to switch from data mode to command mode. To use this method, AT&D1 should be set firstly. Pull DTR line to ground for at least 1 second and then pull up, the module will switch from data mode to command mode and OK will be returned which indicates the module is in command mode.



>>>ножка RF_SYNC для чего-нибудь полезного нужна?

Используем если применяем навигацию - заводим на ключик который коротит вход GPS при пассивной антенне или снимает питание с активной.
Предусмотрено чтобы передатчик GSM при разных проблемах по вч части не убил чуствительный вход GPS

Удалил резистор R64 на линии TXD отчасти помогло. Спасибо.
Удалил все лишние резисторы с не используемых пинов и делитель в цепи STATUS. Новая схема в приложении. Ничего больше не изменилось.

Удаление резистора R64 помогло только в части моей инициализации. Также для теста добавил посылку несколько подряд команд AT.
При обмене следующими командами, задержек при ответе не выявлено, ответ почти сразу или макс. 100-400 мсек, считаю это нормальным. Задержка ответа только в команде включение BT модуля, обычно около 2 секунд, но это хоть объяснить можно.
Код инициализации:


Но после этих команд в дальнейшем обмене начинаются задержки, которые иногда имеют периодичность, это хорошо видно когда передавать одну и туже команду подряд. Ответ на 1-ую команду приходит сразу, а на вторую с задержкой 1.8-2 сек., потом на следующую команду ответ приходит сразу, а посл неё опять с задержкой 1.8-2 сек..



Также если сим карта не вставлена, то ответ на передачу нескольких команд AT при инициализации, проиходит всегда с задержкой до 4 сек.

Картинка показывающая задержку
Нажмите для просмотра прикрепленного файла

Здравствуйте, извините может не в ту тему пишу...
Такая проблема, на модеме RX100-R4 с GL868 dual v3, включил #CMUXSCR, и теперь модем ни в какую не отвечает на AT-команды в терминале.
Как можно сбросить настройки без AT-команд?

Проверьте как настроен режим управления потоком в модуле командой AT+IFC? и соответственно настройте его под схему и программу.

Возможно ошибаюсь или что-то не правильно понял, но судя по картинке модуль работает нормально, задержки около 50 мс. Время передачи команды "AT" и ответа "OK" с учетом \r и \n на скорости 9600 бит/с занимает примерно 4 мс, но т.к. горизонтальная развертка сжата, пакеты приема и передачи видны как вертикальные столбики (импульсы). По картинке видно по линии RX передается команда и примерно через 50 мс на линии TX виден ответ на команду. Причем во время ответа или почти сразу после него по линии RX передается повторная команда и на линии TX также через 50 мс виден ответ на вторую команду. Примерно через 2,18 с все повторяется.

Команда передаётся по линии TX. Первый ответ по RX лини это ответ с задержкой на предыдущую команду AT. Это фрагмент обмена передачи из 10 команд AT. Следующая команда передаётся через 50 мсек от полученного ответа.
Если не считать этих задержек, модуль работает нормально. Использую входящие/исходящие CМС, звонки, DTMF и BT.

Запрос -ответ

что означает, что нет контроля потока, но это и так ясно было

Попробуйте использовать переходник USB - UART и через терминал общайтесь с модулем, никаких задержек быть не должно и ответы должны четко приходить. Если все будет хорошо, то где то в программной части проблемы, так как по схеме вроде бы нет ошибок
у микроконтроллера какая величина логического уровня?

Что-то не понятно откуда такие задержки, конкретно с BLUETOOTH не работал... и проверить времени нет

Ответ на AT-команду всегда должен быть.
Никаких следующих команд модулю посылать нельзя до его ответа на предыдущую, так как протокол общения АТ-командами - синхронный протокол.
Если модуль ничего не ответил на АТ-команду в течение некоего разумного времени (зависит от поданной команды), то это - критическая ошибка. Реакция на неё - RESET модулю и рестарт управляющего драйвера.

Mysteo, в чём может быть логическая ошибка ПО, если модуль отвечает, но не сразу и то не всегда. Специально для этого привёл скрин анализатора. Контроллер STM32, питание от 3.3В.

jcxz, Про ответ всегда это я понял. Если не отвечает, то так и решил делать, перезагрузкой модуля.
До ответа OK, ни какие команды не посылаю.

Это сколько? минута или 10 секунд. Есть же документированный таймаут.

Предполагаю, что может где-то перекос по земле происходит или фантомная запитка, хотя всё лишнее отключено.

Добавлю ещё одно интересное наблюдение.
В ожидании ответа на команду AT (задержка 2 секунды описана ранее) можно спокойно получить BT данные, даже несколько раз. Но эта задержка есть, хоть с подключенным BT, хоть без.

И ещё неприятный подарок от модуля, на скорости 115200. Разрыв в ответе на команду. Может это и по стандарту какому то, но писатели обмена по UART, про DMA явно не слышали.
Первый символ '\r' от ответа передаётся отдельно.
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Хоть и считается что RTOS в модуле многозадачная, но в любом модуле безусловным приоритетом N1 является GSM стек.
Если он посчитает что нужно прервать все операции и общаться с сотой, то ему пофигу был там обмен по UART или не было.
Простой пример - вы забираете данные с модуля. А оператор решил отправить на устройство команду изменения соты или мощности или еще что.
Так вот пока модуль эту ситуацию не проглотит, то ничего другого он делать не будет.

И это вопросы не к производителям модуля, а к тому кто придумал GSM стек и тому кто писал RTOS под модуль.

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

А по поводу периодической задержки на команду AT, двумя постами ранее, помочь можете? Или списывать тоже RTOS.

Я уже говорил по поводу АТ.
Запустите в цикле скрипт с терминалки в компе и увидите что задержек не будет.

Вот вам в цикле 50 запросов с временными метками - задержка между запросами установлена 50 mS - могу поставить меньше
Но и так видно что ответ мгновенный - так что причина как бы не в модуле....

[2017-10-11_14:14:58:661]AT

[2017-10-11_14:14:58:661]OK
[2017-10-11_14:14:58:715]AT

[2017-10-11_14:14:58:715]OK
[2017-10-11_14:14:58:769]AT

[2017-10-11_14:14:58:769]OK
[2017-10-11_14:14:58:823]AT

[2017-10-11_14:14:58:823]OK
[2017-10-11_14:14:58:877]AT

[2017-10-11_14:14:58:877]OK
[2017-10-11_14:14:58:932]AT

[2017-10-11_14:14:58:932]OK
[2017-10-11_14:14:58:986]AT

[2017-10-11_14:14:58:986]OK
[2017-10-11_14:14:59:040]AT

[2017-10-11_14:14:59:040]OK
[2017-10-11_14:14:59:094]AT

[2017-10-11_14:14:59:094]OK
[2017-10-11_14:14:59:149]AT

[2017-10-11_14:14:59:149]OK
[2017-10-11_14:14:59:203]AT

[2017-10-11_14:14:59:203]OK
[2017-10-11_14:14:59:257]AT

[2017-10-11_14:14:59:257]OK
[2017-10-11_14:14:59:311]AT

[2017-10-11_14:14:59:311]OK
[2017-10-11_14:14:59:366]AT

[2017-10-11_14:14:59:366]OK
[2017-10-11_14:14:59:420]AT

[2017-10-11_14:14:59:420]OK
[2017-10-11_14:14:59:474]AT

[2017-10-11_14:14:59:474]OK
[2017-10-11_14:14:59:528]AT

[2017-10-11_14:14:59:528]OK
[2017-10-11_14:14:59:582]AT

[2017-10-11_14:14:59:582]OK
[2017-10-11_14:14:59:637]AT

[2017-10-11_14:14:59:637]OK
[2017-10-11_14:14:59:691]AT

[2017-10-11_14:14:59:691]OK
[2017-10-11_14:14:59:745]AT

[2017-10-11_14:14:59:745]OK
[2017-10-11_14:14:59:799]AT

[2017-10-11_14:14:59:799]OK
[2017-10-11_14:14:59:854]AT

[2017-10-11_14:14:59:854]OK
[2017-10-11_14:14:59:908]AT

[2017-10-11_14:14:59:908]OK
[2017-10-11_14:14:59:962]AT

[2017-10-11_14:14:59:962]OK
[2017-10-11_14:15:00:016]AT

[2017-10-11_14:15:00:016]OK
[2017-10-11_14:15:00:071]AT

[2017-10-11_14:15:00:071]OK
[2017-10-11_14:15:00:125]AT

[2017-10-11_14:15:00:125]OK
[2017-10-11_14:15:00:179]AT

[2017-10-11_14:15:00:179]OK
[2017-10-11_14:15:00:233]AT

[2017-10-11_14:15:00:233]OK
[2017-10-11_14:15:00:288]AT

[2017-10-11_14:15:00:288]OK
[2017-10-11_14:15:00:342]AT

[2017-10-11_14:15:00:342]OK
[2017-10-11_14:15:00:396]AT

[2017-10-11_14:15:00:396]OK
[2017-10-11_14:15:00:450]AT

[2017-10-11_14:15:00:450] OK
[2017-10-11_14:15:00:504] AT

[2017-10-11_14:15:00:504] OK
[2017-10-11_14:15:00:559] AT

[2017-10-11_14:15:00:559] OK
[2017-10-11_14:15:00:613] AT

[2017-10-11_14:15:00:613] OK
[2017-10-11_14:15:00:667] AT

[2017-10-11_14:15:00:667] OK
[2017-10-11_14:15:00:721] AT

[2017-10-11_14:15:00:721] OK
[2017-10-11_14:15:00:776] AT

[2017-10-11_14:15:00:776] OK
[2017-10-11_14:15:00:830] AT

[2017-10-11_14:15:00:830] OK
[2017-10-11_14:15:00:892] AT

[2017-10-11_14:15:00:892] OK
[2017-10-11_14:15:00:946] AT

[2017-10-11_14:15:00:946] OK
[2017-10-11_14:15:01:000] AT

[2017-10-11_14:15:01:000] OK
[2017-10-11_14:15:01:055] AT

[2017-10-11_14:15:01:055] OK
[2017-10-11_14:15:01:109] AT

[2017-10-11_14:15:01:109] OK
[2017-10-11_14:15:01:163] AT

[2017-10-11_14:15:01:163] OK
[2017-10-11_14:15:01:217] AT

[2017-10-11_14:15:01:217] OK
[2017-10-11_14:15:01:272] AT

[2017-10-11_14:15:01:272] OK
[2017-10-11_14:15:01:326] AT

[2017-10-11_14:15:01:326] OK

Проверил в терминалке, результат точно такой же. Другого я не ждал. Передача команды AT, ответ приходит, когда сразу, когда с задержкой.

Добавил в предыдущий пост ещё одну картинку, где в 2-х ответах касающихся передачи данных по BT - Первый символ '\r' от ответа передаётся отдельно. Может такое есть и в других командах, тут увидел, т.к. стоит в программе была на него проверка и целостность пакета. Я очень сомневаюсь, что это вклинивается GSM стек, т.к. время практически одинаковое и разрывается только один символ. Это происходит очень редко (1 раз на несколько сотен или тысяч пакетов), но только один 1-ый символ.

Если у всех не бывает задержек при передаче несколько команд подряд, то вариант такого поведения остаётся пока только плата или подгоревший модуль. Задержки появляются после команд которые у меня проходят как инициализация (перечень их выше) или когда отсутствует СИМ карта. А с терминалки, даже без инициализации, через 4-5 команд появляются задержки. Что можно измерить или какой тест запустить?

Напряжение на ножках UART SIM800C - TXD: 2.8В; RXD: 2.56В. Это при подключении через преобразователь FT232RL.
На плате кроме модуля и сим карты ничего больше не подключено. Питание от 3A лабораторного источника питания 4.1В

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

И еще - если не включать блютуз, тоже есть задержка?

Вечером вообще всё лишнее отключил. Запитал от лабораторного источника 3А макс. Выставил напряжение 4.15В. Подключил FT232RL (I/O запитаны от 3.3В). Подал питание, после нажал кнопку POWER_KEY (через транзистор как на схеме), светодиод NETLIGHT замигал. Пришли в терминал ответы от модуля

После посылаю в ручную команду AT, следующую посылаю тоже вручную, после прихода OK. Первые 4-5 раз, ответ приходит практически сразу, потом опять начинает чередоваться - сразу, потом с задержкой, потом опять сразу, потом с задержкой. Бывает 2 раза ответ сразу, потом опять с задержкой. Никакие другие команды, больше не посылал.
Скорость в терминале была 115200.
Когда работал с модулем через контроллер, разницы между 115200 и 9600 не заметил.
Пробовал 2 симки, разницы нет. Симки Водафон, но без симки задержки ещё больше.

Из положительного. Функционал звонков (dtmf) и смс работает без проблем.
Как работает BT модуль, пока тоже нравиться. Передаю каждые 500 мсек, модуль вполне справляется. Просматривал лог несколько минут передач по BT, не было ни одной задержки ожидания приглашения для передачи. Единственное, что очень редко, символ первый разрывался от посылки, но может это из той же серии, откуда задержки появляются.

А че выдает по AT+GMR и AT&V ?

После включения

СТОП!!!

+IPR: 0

Скорость стоит в автоопределении - конечно имеет право тормозить из-за пересинхронизации.

AT+IPR=9600
AT&W

выключить включить, проверить что запомнилось

Я на это тоже обратил внимание.
Но когда читаю скорость с контроллера в логе инициализации IPR возвращает установленную скорость. В логе выше это есть. Почему тут IPR 0, не знаю
Запрос после включения

Странно.....

>>> Подключил FT232RL (I/O запитаны от 3.3В).

Потом делители стоят?
Может действительно подпалили порт......

Я на отладке крутнул цикл из 500 запросов AT (выкладывать простыню не буду или могу в .doc выложить)
Ни одного разрыва или задержки в ответе.

FT232RL подключал сейчас, потом делители стоят, как на схеме. До этого подключено было только через контроллер STM32, который запитан от 3.3В. Делители как по схеме были всегда. Собрано 2 платы, и эти 2 платы себя так ввели изначально. На это не обращал внимания, т.к. решил завершить всю логику устройства, а потом к этому вернуться.
Также есть ещё не запаянные модули и платы, можно собрать для проверки, но что-то мне подсказывает, что результат будет такой же.

Странно. Помимо раздела DEFAULT PROFILE должны быть такой-же раздел с USER PROFILE и ACTIVE PROFILE . Кто съел?
Че говорит AT+CSCLK?

ArtemKAD, Отредактировал предыдущий пост с командой, возможно не все скопировал прошлый раз

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

Попробуйте погонять в цикле другую команду, к примеру AT+GMM и посмотреть будут ли задержки. Думаю стоит зафиксировать скорость обмена AT+IPR=ххх т.к.повторные команды АТ заставляют модуль выполнять повторную синхронизацию при включенном автоопределением.

Скорость зафиксирована. На команду GMM поведение такое же. Через раз или два задержка.