Плавающие задержки ответов на AT команды, SIM800C Опции

[Rash]

Доброе время суток.

В результате анализа логов работы SIM800C заметил плавающие задержки получения ответов на AT команды. Вот список команд, для которых задержки появляются регулярно:
1. AT+CFUN=1 ответ приходит через 0.2 - 4.2 сек.
2. AT+CSMINS? ответ приходит через 0.05 - 3.6 сек.
3. AT+IPR? ответ приходит через 0.05 - 2.5 сек.
3. Включение BT модуля (AT+BTPOWER=1) ответ приходит через 2 -7.5 сек.
4. Разрешение на передачу данных по профилю SPP ">", приходит через 4.3 секунды,
если предыдущей командой был запрос RSSI (AT+BTRSSI=1) или был запрос сети AT+CREG?
5. AT+BTSPPCFG="MC",1 ответ приходит через 0.05 - 2.7 сек.
6. AT+BTSTATUS? ответ приходит через 4.1 сек.
7. AT+BTSPPCFG="MC",1 ответ приходит через 1.3 сек.
8. AT+BTRSSI=1 ответ приходит через 0.2 - 2.5 сек
9. AT+CBC ответ приходит через 0.2 - 1 сек.
10. AT+CREG? ответ приходит через 0.2 - 2.9 сек.

Возможно, такое поведение есть и на другие команды.
Появления факта задержки заметил при переходе от одного системы к другой. Например, 1. Был сделан запрос наличия сети AT+CREG?, ответ на неё быстрый. А потом передача по BT (AT+BTSPPSEND=1,37), то приглашение на передачу (“>”) придёт уже с задержкой.
2. Был сделан запрос АКБ (AT+CBC), а потом был сделан запрос наличия сети AT+CREG?, ответ пришёл с задержкой. Потом передача по BT (AT+BTSPPSEND=1,37), то приглашение на передачу (“>”) приходит уже без задержки.

Питание модуля от ST1S14PHR, напряжение 4.1В. Напряжение стабильное, без просадок, измерено осциллографом. При питании от лабораторного БП, макс. ток которого 3А, поведение такое же. 2 платы ведут себя одинаково. Инициализация PWR KEY по даташиту.

Теперь вопрос, это нормальное поведение? Т.к. на SIM900R я таких задержек не замечал.

[Alechek]

CADiLO, это понято, что время исполнения плавающее. Только вот порядок разброса времени у разных модулей разный. Честно, устал уже слышать от Симком-а что все это не они, а производители с их ОС (MTK) виноваты...
Хватит уже пенять на зеркало!

По поводу цитаты с BGS2:
>> • There is no way to control the minimum time to wait between finishing an AT command and sending the next one.
Так тут про минимум, а не максимум! Ну, и как бы <OK> надо ждать по-любому.

>> • The sequence of processing the AT commands may be different from the sequential order of command input.
Куда-то в лужу. Если по окончании выполнения комады идет <OK>, и его надо ждать, то как порядок может быть нарушен?
>> • Many AT commands cannot be concatenated. Concatenating these commands might end up with an error result code, or leads to an unexpected order of responses.
Ну, возможно есть ограничения. Так может написано какие можно, а какие - нет. В любом случае, претензии к ним уже.

Симком же ссылается на какие-то "высокие материи" в MTK OS, а про невозможность объединять в одной строке несколько умалчивает (хотя по документации своей же разрешает).