Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SIM800C - Пауза перед вводом следующей AT-команды
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Сотовая связь и ее приложения
Alt.F4
Здравствуйте.
Еще с SIM300DZ используем задержку в 300мс после получения ответа на AT-команду и вводом следующей.
Подскажите, пожалуйста, изменились ли эти требования в серии SIM800 и возможно данные задержки избыточны?
Спасибо.
CADiLO
>>>Еще с SIM300DZ используем задержку в 300мс после получения ответа на AT-команду и вводом следующей.

А зачем????

Даже в 300-х если скорость по порту фиксирована, то задержка там не нужна. Получили ответ - даем следующую команду.
Оптимальная скорость обмена - 9600.
115200 большого выигрыша не дает, зато с некоторыми контроллерами стабильность обмена падает.
Alt.F4
Цитата
А зачем????

По-моему, в каком-то аппноте русскоязычном про SIM300DZ с конференции (там еще ST1S10 представлен) это было сказано даже не как рекомендация, а как требование.
Попробую вечером поискать этот документ, и вроде бы в конфе этот вопрос тоже обсуждался...

P.S. При обмене TCP-пакетам по 1кБ 115200 дает хороший выигрыш
CADiLO
В TCP - может быть. А на командах много не выиграешь.

Пересмотрел все свои старые презенташки по 300 серии.
Рекомендация паузы есть только в одном месте:

Передача данных в command mode

После появления ”>” сделайте задержку не менее 200ms перед началом передачи данных


Больше нигде пауза для SIM300x не требуется.
Alt.F4
Цитата
После появления ”>” сделайте задержку не менее 200ms перед началом передачи данных
Больше нигде пауза для SIM300x не требуется.

Подскажите, пожалуйста, для серии SIM800 это тоже относится или можно без паузы вводить данные после ”>”?..

P.S. Вот интересное открытие, были уверены, что задержки жизненно необходимы для общения с модемом
CADiLO
Времянки есть только для передачи данных - смотрим апнотесы.
Для АТ команд задержек не нужно - получили ответ, даем следующую команду.


SIM800 Series_TCPIP_Application Note_V1.01.PDF

Например:

2.2.2
How to Configure Transparent Mode

To enable transparent mode, the command AT+CIPMODE should be set to

1. In transparent mode, the command AT+CIPCCFG is used for configuring transfer mode, which has 7 parameters NmRetry, WaitTm, SendSz, Esc, Rxmode, RxSize, Rxtimer.
􀁺
NmRetry: Number of retries to be made for an IP packet.
􀁺
WaitTm: Number of 200ms intervals to wait for serial input before sending the packet
􀁺
SendSz: Size in bytes of data block to be received from serial port before sending.
􀁺
Esc: Whether turn on the escape sequence, default is TRUE.
􀁺
Rxmode: Whether to set time interval during output data from serial port.
􀁺
RxSize: Output data length for each time, default value is 1460.
􀁺
Rxtimer: Time interval (ms) to wait for serial port to output data again. Default value: 50ms
jcxz
Цитата(Alt.F4 @ Apr 3 2018, 11:04) *
P.S. Вот интересное открытие, были уверены, что задержки жизненно необходимы для общения с модемом

Откуда Вы вообще такое выкопали (про задержки)??? В каком именно документе? Нигде даже краем глаза не видел упоминания на про какие задержки на N мсек...
PS: Но по факту на существующем ПО по крайней мере некоторых модулей SIM8xx в определённых случаях паузы всё-таки нужны. Видимо из-за багов этих самых прошивок
См. https://electronix.ru/forum/index.php?showtopic=146429
Но по логике работы AT-командного интерфейса - он сам по себе не предусматривает никаких задержек.
CADiLO
Ну SIM808 это отдельная песня sm.gif
Существует их 2 версии на разных чипсетах, причем на АЛИ часто сливают как раз то, что было первым.
Прошивки не совместимы и в первой версии до ума так и не доведены.
Сами Симкомовцы неофициально сказали эту бяку даже не предлагать, так как делали ее для внутреннего рынка, а потом каким-то образом она выплыла в мир.

SIM800C, SIM868E - это то что массовое и можно сказать "вылизаное" и наиболее поддерживаемое.
Кстати у нас SIM800C24 сейчас в розницу $4.9 c НДС - дешевле краденого sm.gif

SIM800 - для тех кому еще нужно CSD

и SIM800F - для тех кто не хочет переделывать плату от SIM900

P.S.
в SIM868E блютуз двойной - простой и BLE
крайний апнотес прилагаю
jcxz
Цитата(CADiLO @ Apr 3 2018, 11:32) *
Ну SIM808 это отдельная песня sm.gif
Существует их 2 версии на разных чипсетах, причем на АЛИ часто сливают как раз то, что было первым.
Прошивки не совместимы и в первой версии до ума так и не доведены.
Сами Симкомовцы неофициально сказали эту бяку даже не предлагать, так как делали ее для внутреннего рынка, а потом каким-то образом она выплыла в мир.
SIM800C, SIM868E - это то что массовое и можно сказать "вылизаное" и наиболее поддерживаемое.

Блин! Где-ж Вы были раньше! laughing.gif
Сами уже тоже склоняемся к замене на SIM868E.
В дальнейшем с большой вероятностью потребуется работа со всяким яблочным железом, поэтому буква 'E'. Но не можем найти в продаже EVB с SIM868E, всё только SIM868. Не можете порекомендовать, где можно купить EVB с SIM868E?

Цитата(CADiLO @ Apr 3 2018, 11:32) *
SIM800 - для тех кому еще нужно CSD
и SIM800F - для тех кто не хочет переделывать плату от SIM900

Нам нужно только BT+GPS (AT+CFUN=0, и желательно после BT-соединения сразу режим APP без всяких AT). Почему SIM8x, а не 2 отдельных? - чтобы сэкономить на кол-ве UART (и числе пинов) и был более простой драйвер (лучше писать/отлаживать один драйвер чем два).

Цитата(CADiLO @ Apr 3 2018, 11:32) *
в SIM868E блютуз двойной - простой и BLE
крайний апнотес прилагаю

Да, спасибо, дока эта есть.
Ещё такой вопрос вдогонку: пока работаю чисто с обычным BT (3.x или что там). Устройство работает в пассивном режиме, сервер (ждёт входящих подключений, само никогда их не инициирует). Подключения по SPP. Нужно только максимум одно активное соединение в каждый момент времени.
SIM868E сможет ждать входящих подключений одновременно или по обычному BT или по BLE? Или после активации BLE, входящие соединения обычного BT (профиль SPP) не будут устанавливаться? Или я по характеру входящего запроса подключения смогу определять какое именно идёт соединение и работать соответственно?
На клиенте соединение должно устанавливаться обычной терминалкой (ANSI-режим). По крайней мере по обычному BT.
Пока не могу самостоятельно протестить интерфейс BLE АТ-команд за неимением SIM868E.
CADiLO
>>>Блин! Где-ж Вы были раньше!

Тут и был. Поиск по форуму работает и про 808 я так точно рассказывал несколько раз что там и почему.

>>>Не можете порекомендовать, где можно купить EVB с SIM868E?

Мы с Е не заказывали пока, а для себя я взял TE с простым 868, "сдул" его и припаял SIM868E.
Кстати с яблочным железом в BLE - работает. У нас есть клиент, делает сигналки с сопряжением со смартфонами - тестировали.

>>>Нам нужно только BT+GPS (AT+CFUN=0).

Ну я бы не так сделал если GSM не нужно

SIM868E - $10 в розницу

ESP-WROOM-32 + SIM68M = получится $13, или дешевле если не нужен ГЛОНАСС и ставить только GPS SIM28ML
Еще дешевле и по размерам меньше если брать не модуль ESP32, а сам чип, там обвязки кот наплакал.
Сам чип ESP32-DOWDQ6 стоит 4 бакса в розницу с НДС.
При этом достаточно мощный контроллер уже стоит в ESP32. Плюс Wi-Fi бонусом.


И туда же ваш вопрос по соединениям, там все же BT получше будет.
Baser
Цитата(CADiLO @ Apr 3 2018, 11:17) *
Времянки есть только для передачи данных - смотрим апнотесы.
Для АТ команд задержек не нужно - получили ответ, даем следующую команду.

Действительно, в документации Симкома нигде не встречал упоминания о необходимости пауз между АТ командами.
Но здесь, в конфе, таких тем уже было много, и вы не раз рекомендовали противоположное rolleyes.gif

Вот, даже ссылались на Телит, у которого все-таки было подобное упоминание:
Цитата
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.
CADiLO
Дык то ж таймауты выполнения или выхода из команды - они есть в доках.
А специально задержка после каждой команды не нужна.
Baser
Цитата(CADiLO @ Apr 3 2018, 12:20) *
Дык то ж таймауты выполнения или выхода из команды - они есть в доках.
А специально задержка после каждой команды не нужна.

Я тоже всегда считал, что не нужна - стандарты ее не требуют.
Но в выделенной строчке вроде "ясным Аглицким" говорят о паузе после приема OK<CR><LF> и подачей следующей команды cool.gif

з.ы. и это вы эту цитату приводили...
CADiLO
Да, но там я брал в качестве примера фразу из доков ТELIT. Другой чипсет, другая операционка.
У Simcom я такой фразы не нашел.
Но и даже если делать паузу, то 20mS и 300mS (как у ТС) это таки на порядок разница.
jcxz
Цитата(CADiLO @ Apr 3 2018, 12:11) *
ESP-WROOM-32 + SIM68M = получится $13, или дешевле если не нужен ГЛОНАСС и ставить только GPS SIM28ML

Я же говорю: это будет уже два порта, соответственно и два драйвера. Не очень сильно, но хуже - последовательных портов и ног не так уж много.
WiFi не нужен. Устройство мобильное, необходимо оперативно конфигурировать его без проводов в поле (поле, лес) или на стационаре. Время разработки ограничено и что-то дополнительное писать, если оно особо не нужно, не имеет смысла.

Цитата(CADiLO @ Apr 3 2018, 12:35) *
Но и даже если делать паузу, то 20mS и 300mS (как у ТС) это таки на порядок разница.

Всё-таки очень важно - нужна или нет пауза? Если этого явно не указано в даташитах - значит не нужно.
А иначе можно многое нафантазировать того, чего нет....
Да даже по логике работы АТ-командного протокола, задержки там не нужны. Так как если даже модулю по каким-то причинам нужно время чтобы "подумать", так сам этот протокол в себе уже включает возможности управления потоком АТ-команд (он может на необходимое время задержать response). Так что любые паузы - это заплаты на какие-то баги кривой реализации протокола обмена АТ-команд. laughing.gif
CADiLO
Отложим даташиты и возьмем реалии.
На сегодня в первой десятке крупных клиентов никто паузы на 800 серии не делает.
Это я знаю точно, так как монстрам всегда внимание в первую очередь.
И на сбои в работе жалоб нет, а то б меня сожрали уже sm.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.