Вожусь уже который день пытаясь заставить SIM808 хоть как-то передавать по Bluetooth через SPP.
Но блуждания по граблям уже просто достали! Просто не понимаю - где они (SIMCOM) берут настолько безмозглых быдлокодеров???!!
Хочу просто элементарно передать с устройства на комп по Bluetooth поток данных. Ну и принять небольшой поток в обратном направлении.
Вроде казалось: бы чего может быть проще? Это же базовая вещь - должно работать как часы. Ага - как же!
Первый сюрприз был в том, что оказывается режим автоматического приёма (AT+BTSPPGET=0 - дефолтный) работает как звёзды сложатся - данные могут прийти, а могут и потеряться (видимо если в этот момент идёт передача (командой AT+BTSPPSEND) - то не судьба; видимо быдлокодеров из SIMCOM никто не предупредил, что UART - это оказывается полно-дуплексный интерфейс).
Ну ладно - обойдёмся и без автоматического режима. Переписываю всё на мануальный режим. Ну и в нём конечно же уже ожидаемо не работает уведомление о пришедших данных (+BTSPPMAN) видимо всё по той же причине (может прийти, а может не прийти). Ну в этом режиме хоть данные не теряются, а мирно лежат в буфере в SIM808.
Переписываю драйвер на периодический поллинг (командой AT+BTSPPGET=3,...) приёмного буфера SIM808. Что поделать - приходится пользовать то го#%о, что имеется.
Ладно - приём через пень-колоду заработал.
Дальше дело пошло смешнее - передача.
Если просто передать одиночный блок данных AT+BTSPPSEND, то он доходит до терминалки на компе.
Но если попытаться передавать поток данных (за первой AT+BTSPPSEND сразу вторую AT+BTSPPSEND и третью и так далее) начинаются чудеса чудесатые!
Сначала неприятным сюрпризом явилось то, что если вот так слать данные блок за блоком (даже небольшими блоками по 10 байт - без разницы), то на очередной команде после выдачи приглашения к вводу данных "> " и отправки мной этих данных модулю, он тупо зависает. И зависает намертво - пока с ноги RESET ему пендаля не дашь. Зависает - в смысле просто молчит и ничего не отвечает хоть минуту хоть 10. И ни на какие данные более не реагирует (думал - может у меня где-то косяк и какие-то символы не досылаются - переключал провода на переходник USB-UART и вручную с терминалки пытался добить ему данных - без толку).
На прошивке, что была в модуле изначально (1418B02SIM808M32_BT_EAT) зависание случалось обычно уже буквально секунд через 2...5 после начала потока. Перешил на 1418B03SIM808M32_BT_EAT - стал виснуть уже позже - успевал проработать иногда даже полминуты, но один фиг! Что ещё интересно - ещё при этом на новой прошивке и скорость выросла - с максимум ~20КБ/сек до ~29КБ/сек (460800 бод).
Аппаратный flow control включен - без толку за всё время тестов CTS ни разу не шевельнулся (быдлокодеры SIMCOM в курсе, что у них в даташите написано про flow control?).
Да даже без FC в команде AT+BTSPPSEND уже есть свои возможности по управлению потоком (если вдруг вх.буфера не хватает): можно приглашение "> " выдать когда место в буфере освободится, можно "SEND OK" в конце отправки задержать также до момента освобождения буфера. Даже CTS то собственно и не нужен.
Так нет же - лучше просто тупо повиснуть!
Ладно - решил попробовать сразу после AT+BTSPPSEND слать какую-нить другую команду, запрос статуса например AT+BTSTATUS? - может она мозги прочистит модулю? (хотя надо их прочистить тем, кто писал прошивку для него). Так теперь иногда стал на эту команду (AT+BTSTATUS?) получать "SEND OK" Приехали!!!
Т.е. - отправил данные AT+BTSPPSEND, получил в конце "SEND OK", после этого сразу запросил статус AT+BTSTATUS? и опять в ответ - "SEND OK". А вот если сделать паузу между командами, то этого "SEND OK" уже нет. Ну это уже ни в какие ворота не лезет!!! Там похоже внутри не ПО, а какое-то недоразумение.
И это ещё не говоря о том, что иногда модуль ни с того ни с сего вдруг вообще может прислать какой-нить левый символ. Ну т.е. - установлено соединение, приёма/передачи нет, 10 минут нет, 15 нет - и тут вдруг БАЦ!! - из UART вылазит например 0xF1 или ещё какой мусор. Не в команде запроса данных, а просто из UART, когда никакая команда не выполняется.

Если после AT+BTSPPSEND ставить паузы в несколько мсек, то тогда он начинает более-менее устойчиво работать. Даже иногда несколько десятков МБ удавалось передать. Но всё равно в конце концов виснет. 40 минут непрерывной передачи - это был абсолютный рекорд, и ни разу потом его повторить не удалось.

PS: Вобщем - извините за такое повествование. Но просто накипело - уже который день кувыркаюсь с этим говноподелием SIM808. Уже никаких слов кроме нецензурных о нём не осталось.... ((((((((((((((

PSS: Условия мытарств: управление потоком включено AT+IFC=2,2 или выключено - без разницы; скорость по UART фиксирована - AT+IPR=460800 (пробовал и ниже - то же самое); функцинальность пробовал AT+CFUN=4 и AT+CFUN=1 и AT+CFUN=0 (в последнем работает наиболее устойчиво, GSM мне не нужно и симки не будет, только BT+GPS). Вначале тестил на 1418B02SIM808M32_BT_EAT, потом перешил на 1418B03SIM808M32_BT_EAT - стало лучше, но если без пауз после AT+BTSPPSEND работает пару минут - это уже счастье!

jcxz, и только не говорите, что Вас не предупреждали.
Ждите рассказов как Вы не правильно модуль используете.

То, что ПО модуля в эпоху ARMов корявое и тормознутое, я с Вами абсолютно согласен. То, что производители не хотят понять, что UART асинхронный, то ему ещё отводят лимитированное время на обработку из "мего крутой" операционной системы, к которой Симком не имеет ни какого отношения. Только это их разработчики выбирали этот чипсет, с такой операционкой. Про DMA режим и кольцевой буфер команд, думаю говорить им бесполезно. И напоследок, рекомендованная скорость это 9600 бит/сек.

Но если вы внимательно почитаете это форум, то найдёте кучу предупреждений, что это прежде всего GSM модуль. И даже, если Вы не используете GSM, в его ПО заложен приоритет на GSM, а не BT модуль. Также следующее предупреждение будет, что модуль это не пулемёт и не ждите от него быстрой реакции. Посылать команды сразу, даже спецификация не позволяет. Задержка между приёмом ответом на предыдущую команду и передачей следующей команды должна быть не менее 50мсек. Но если бы это работало так, это можно было бы назвать счастьем. А так послал команду, а она может прийти тебе когда угодно.

Повторю, из собственного опыта, что передача и приём по BT работают в автоматическом режиме на модуле SIM800С, период посылки 500 мсек, длина пакета порядка 60 байт. Работает часами, модуль от этого не виснет. Работает как с присутствием СИМ карты, так и без неё.

Я вообще-то использую его согласно документации. В каком именно месте я отступаю от документации - укажите?


Что значит "тормознутое"? Вот у меня работой с этим го#@о-модулем занимается одна из задач ОС на CPU с тактовой 120МГц. При старте драйвера общая загрузка CPU вырастает менее чем на 1%. Один процент - максимум, Карл! А для разбора этого протокола на той стороне нужно примерно столько же ресурсов.
Т.е. - если у них там стоит такой же CPU который всё время загружен на 99%, то да - наверное он не будет успевать. Но как нужно писать код чтобы загрузить их мощный ARM (мощнее моего ведь вроде) на 99% постоянно??? И что там такое нужно делать??
Какой бы ни был UART, хоть 115200, хоть 460800, с DMA или без - это всё доли процента загрузки такого CPU. Это всё ни о чём.


Если он так работает, то это прежде всего - хлам.


Я писал, что использую режим +CFUN: 0, при этом как говорит даташит:
AT command ”AT+CFUN” can be used to set the module to a minimum functionality mode
without removing the power supply. In this mode, the RF part of the module will not work or
the SIM card will not be accessible, or both RF part and SIM card will be closed, and the
serial port is still accessible.
А каком GSM Вы тогда говорите? Всё выключено и GSM и SIM-карта. Чем он там может заниматься??? Этот мощный процессор?


Это где Вы такое вычитали? Приведите ссылку.
Я вообще не понимаю такую фразу, что значит "модуль это не пулемёт"? Это что так теперь можно оправдать любой говнокод???


Вы похоже не поняли того, что я написал...
Дело не в том когда ко мне приходит ответ на команду. Естественно я жду прихода ответа на команду и ничего не передаю пока не получу этот ответ.
Дело же не в этом, а в том что если сразу после ответа на предыдущую команду послать сразу следующую (или через небольшой интервал времени), то после этого модуль может вообще перестать что-либо выдавать. А может вдруг прислать ответ на предыдущую команду! Никак логически не связанный с этой командой.
Это то почему такое может происходить?
Это говорит, что у них там в прошивке куча багов при работе с входными или выходными буферами UART: что-то не туда пишется, или баги взаимодействия обработчиков прерываний, которые принимают поток символов UART и задачи обработки или ещё где-то...


И что?? В данном конкретном режиме баги не проявляются. И о чём это говорит? Да ни о чём.
Если ваше устройство на стол положить - работает, а если на тумбочку - не работает, это разве тумбочка виновата?

PS: Только что наступил на очередной баг SIM808. С приёмом данных из BT. На стороне компа порт открыт виндовым Гипертерминалом, просто жму и держу нажатой клавишу 'Z' в окне терминала. Мой драйвер периодически опрашивает SIM808 на предмет наличия входящих BT-данных. Какое-то время всё работает нормально (несколько секунд), потом вдруг получаю следующее:

Т.е. - в очередной раз получаю от модуля уведомление что есть входящие символы "+BTSPPMAN: 1", даю команду чтения этих символов "AT+BTSPPGET=3,14", получаю ответ что ничего нет "+BTSPPGET: 1,0", а через некоторое время после очередного опроса состояния входного BT-потока "AT+BTSPPGET=3,14" вдруг получаю что-то невразумительное: ",Z". Это что такое??? Похоже и приём в SIM808 нормально не работает. (((((((((((
Rash, а у Вас как приём работает? Или у Вас нет приёма?

jcxz, я не разработчик модуля и его ПО, поэтому не пойму ваших претензий ко мне, КАРЛ.


Для моего восприятия, ПО модуля тормознутое. Это значит, что я не получаю ответ от модуля после своего запроса, в заранее известные промежутки времени, а время ожидания ответа может быть больше чем 50-100 мсек.


Я где то писал, про тумбочку? Мною описано то, что у меня работает для моей задачи. Хоть на тумбочке, хоть на столе.


Сейчас не вспомню где это читал, но читал. Можете не придерживаться этого правила.

А где я высказывал какие-то претензии к Вам? Только к разработчикам сего юродивого девайса...


Во-первых: самая главная проблема не в том что "тормознутое" или нет, а что оно КРИВОЕ. Пускай оно как угодно долго отвечает на команды - логика работы от этого не нарушится.
Я же писал, что оно в каких-то случаях виснет на совершенно ровном месте. Либо выдаёт ответы на команды, совершенно не соответствующие этим командам (мусор), либо вообще - какие-то группы символов похожие на обрывки ответов на предыдущие команды (кривая работа с буферами UART в прошивке?).
То что тормозит - это тоже конечно очень плохо, на самое плохое что - глючит!
И во-вторых: а почему Вы ожидаете, что время ответа должно быть 50-100 мсек? У меня ни для одной команды нет таймаута ожидания ответа менее 500мсек.


Я нигде в доках не увидел упоминания, что после завершения выполнения какой-то команды (получения всех строк её ответа) нужно выдерживать паузу сколько-то времени перед следующей командой. Есть команды после которых необходимо поллить статус пока он не станет равным чему-то (это AT+BTPOWER=x). Но вот про какие-то паузы - нигде не видел. Да и вообще-то это противоречит логике работы подобных модулей (уж это у меня не первый модуль с AT-командным или подобным интерфейсом).

Глюков таких у себя не наблюдал, паузы в ответах огромные есть, на 2-х платах. Паузы также возникают и в приглашениях на передачу данных. 2 платы ведут себя одинаково. Сейчас проект на паузе, по нехватке времени. Ещё лежать 3 не запаянных модуля, как только руки дойдут проверю их на паузы на обычной терминалке подключив только питание и антенну.

Посмотрите питание, всё ли там в порядке, также, может нагрузить антенный выход GSM на 50 Ом резистор. Хоть его Вы не используете, но модуль может всё равно пытаться общаться с базовыми станциями. А т.к. антенный выход не нагружен, может потреблять больше , чем нужно. Встречал такое при работе с RF усилителями, когда без антенны они потребляли ток больше, чем с антенной, разница была в 2 раза.

Паузы меня не особо волнуют - по общей скорости потока меня всё устраивает. С помощью нескольких костылей мне удалось добиться стабильной односторонней работы (от SIM808 в комп) в течение полутора часов и думаю больше. И передаётся за это время ~122 МБ без сбоев (запись в лог-файл на терминалке и контроль CRC32 - всё ок).
Но дело в том, что это если работать только на передачу (SIM808->комп), а мне нужен дуплексный обмен. С произвольным моментами передач в обе стороны, моменты передач в одну сторону никак не зависят от моментов передач в другую (Хотел через этот BT-канал прокинуть доступ через ANSI-терминал к меню настроек устройства).
Но для такого обмена мне нужно всё время с периодом хотя-бы 50мс поллить модуль командой BTSPPGET на предмет наличия новых данных (от терминалки). Вот тут и начинаются чудеса. И костылями их уже похоже никак не победить - модуль в произвольные моменты времени просто мусор из обрывков обмена выкидывает на TXD. (((((
А иногда бывало что несколько КБ мусора выплюнул (моя прога в самом начале остановилась на брекпоинте из-за недопустимого сообщения от SIM808 (и естественно никак не могла ничего передавать после этого), и после этого SIM808 выплюнул ещё несколько КБ предыдущего обмена, покорёженного местами).
Видимо в вашем режиме работы (запрос-ответ, чистый полудуплекс, да ещё редкий) он ещё как-то работает без глюков. И ни на что большее он не годится. Со всеми своими МГц.

Антенны - тут не при чём. Я же повторяю ещё раз - дело не в каких-то тормозах, а в том что модуль в каких-то случаях начинает выдавать мусор. Т.е. - где-то ошибки в работе его встроенного ПО. Что-то с работой с буферами обмена UART видимо. Либо с обработкой команд или связанными с ней буферами. Или с указателями.
Питание тоже вряд-ли - я работаю с готовой демо-платой. Хотя и китайской. Этой: https://arduino-kit.ru/catalog/id/plata-ras...-s-gps-antennoy


А как вы принимаете? Данные с удалённой стороны. AT+BTSPPGET=0 или AT+BTSPPGET=1?

Между прочим такая плата может быть причиной многих "бед".
Китайцы очень склонны к экономии , так что питание все таки проверить стоит осциллографом (скорее всего схему питания на плате "упростили" для снижения цены и УАРТ драйвер думаю тоже ) .
А еще лучше раз такое дело купить фирменную Симкомовскую плату отладки ( как не грустно для кошелка) .
Хотя сама тема очень любопытна . А у Вас одна такая плата ?

Да, надо будет проверить. И попробую поменять источник питания на другой.
Только что обнаружил, что случайные символы (0xF1 или 0xF0) которые периодически внезапно получаю от SIM808 (в то время когда он просто ожидает BTSTATUS="Idle", активного соединения нет) - это похоже модуль иногда самопроизвольно перезагружается. А эти символы - просто короткие импульсы лог."0" на TxD модуля в моменты перезагрузки.
Но характер багов по приёму очень похож на программные проблемы с работой с буферами или указателями в модуле.
"UART-драйвер" - что вы имеете в виду? На этой плате ноги TxD/RxD/CTS/RTS модуля вроде как напрямую идут на разъём, без каких-либо интерфейсных чипов. По-крайней мере кроме самого SIM808, чипа линейного стабилизатора и SMF05C (TVS-сборка; на аудио разъёмах вроде), других больших чипов на плате не наблюдается. Есть 3 шт. каких-то элементов в SOT23 (по 3 ноги), но это или транзисторы или максимум может быть один из них - супервизор питания.


Да, плата одна. Думаем купить SIM868 - возможно там другая прошивка и может менее кривая. Хотя хотелось бы SIM868E, но их нигде не найти.

Так, может, ну его в баню тот SIM808, пока не поздно?
Есть же МК соответствующие, со встроенными RF трансиверами. И модули на их основе. UART для подключения GPS модуля завсегда найдётся... Хотя там из-за закрытости библиотек блютуса свои приколы, почти что иной мир...

Так в том то и вопрос - а как УАРТ SIM808 к компу подключаете ?
В даташитах кажись уровни не более 3.1 В ?
А Вы проверяли с какими уровнями Ваши TxD/RxD/CTS/RTS .
И судя по фото TxD/RxD/ имеют драйвера на транзисторах а /CTS/RTS напрямую . Хотя тоже все это проверять желательно .
В фирменной плате стоит драйвер для СОМ порта .

Вот именно - ещё багов вагон. Работал когда-то с CC2530 с ZigBee-стеком - то ещё глюкало, сколько костылей пришлось наваять пока более-менее заработало.
Хочется готовый модуль с готовым ПО. Время проекта совсем не предусматривает изучение ещё какого-то другого чипа со своей архитектурой и написание прошивки для него.
SIM808 мне первоначально понравился ещё и по той причине, что его BT-API очень похоже на API ESP8266, для которого я давно написал стабильно работающий драйвер (работающий в режиме потока по много часов и потока более быстрого чем здесь). Собственно я его и взял и переделал под SIM808.


Я не к компу подключаю, а к своему МК. На комп у меня идёт выход TxD модуля (т.е. - TxD SIM808 идёт и на RxD МК и на комп; это для контроля обмена, чтобы убедиться что проблема не у меня в прошивке). Идёт через USB-UART 3.3V.
МК тоже - 3.3V.
Да, сейчас глянул в даташит: действительно там рекомендуется 3.3V МК с модулем соединять через последовательные резисторы. Надо будет добавить. Спасибо за рекомендацию!


Надо будет прозвонить.

Но всё равно, я же писал, что характер сбоев он говорит не о проблемах согласования уровней (иначе был бы мусор никак не связанный с последовательностью обмена).
Если после отправки порции данных AT+BTSPPSEND и получения "SEND OK", сразу послать следующую AT+BTSPPSEND без паузы, то через несколько десятков...сотен таких повторов модуль перестаёт что-либо отвечать. И перестаёт отвечать он всегда в одном и том же месте - после выдачи приглашения на ввод очередной порции данных "> ". А в предыдущей прошивке зависание происходило примерно в 10 раз раньше. А после добавления паузы в 12 мсек между "SEND OK" и последующей AT+BTSPPSEND (на новой прошивке) поток данных работает часами (не было ни одного зависания пока хотя уже несколько раз запускал тест на 40мин...1.5часа и 64МБ...122МБ данных).
Также если не делать данную паузу, то на следующую команду AT+BTSPPSEND или любую другую (например AT+BTSPPGET или даже AT+CGNSINF) можно с большой вероятностью получить ответ "SEND OK" сразу же, до выдачи приглашения ввода данных "> ".
То же самое и с командой AT+BTSPPGET (лог я приводил выше) - в ответ приходят явные обрывки ответов из прошлых транзакций "запрос-ответ".
Если бы проблема была с согласованием уровней, то приходил бы мусор никак не связанный с текущей последовательностью команд-ответов.

На полке лежит отладка с SIM800C, китайская с Aliexpress.
Как раз на нее были планы с Bluetooch поиграться, GSM был вторичен.
Но jcxz прям подлил масла в огонь ненависти к продукции SIMCOM Давно наслышан о лютых багах в работе модулей этой компании... Причем действительно не совсем понятно, откуда ТАКОЕ количество ошибок и недокументированных ситуаций. Куда у них смотрит отдел тестирования?

Тоже хотел взять на тесты sim800 модуль с Али. Что ожидать от него, такие же грабли?

То что купили на Али - официалы "открестянся" как от заразы прокаженной !
И модули тоже не сильно рекомендуют там брать .(хотя цена приятная )
Суть в том что сделаны они для другой страны и там прошивка с другими "тараканами" .
А плата сделана по очень сильно упрощенному пониманию даташита .
А вот напряжение 3.3В на входе в модуль не столько на уровни влияет а просто "жарит" мозги процессору .
Грешен и я таким . 40 В на вход 8051 подвал. Проц грелся как паяльник но работал сбоил правда.
Так что для начала внимательно все параметры по даташиту а потом уже "хаять" модуль .
Если не ошибаюсь в модуле 3 процессора . Каждый проц своим "делом" занят и GSM и них в приоритете а не ВТ .




Там совсем может БТ отсутствовать !
Лотерея !
Я там тоже покупал . И на Ебей . Все были без БТ !
Если точнее там прошивка без БТ .
Так что все что купили на Али нужно перепрошивать .

Я ничего не могу сказать по поводу других SIM8... . У них для каждого - своя прошивка. Может это только SIM808 так не повезло?
Настораживает ещё тот факт, что на официальном сайте компании http://www.simcomm2m.com/russian/module/ среди модулей SIM808 не значится (хотя если полазить по сайту, то можно найти файлы, относящиеся к SIM808). Вот почему они не светят вовсю SIM808? У меня теперь закрадывается подозрение, что он ещё не доделан (или недотестирован), сырой вобщем. Хотя блин - уже несколько лет его производят и до сих пор не довели до ума???
Только на http://simcom.ee/documents/?dir=SIM808 светят такой модуль. Оттуда и брал последнюю прошивку для него (с той что была изначально, дела были ещё хуже, как уже писал).
Эта прошивка (1418B03SIM808M32_BT_EAT.rar) уже довольно старая - файлы внутри имеют дату 02.11.2016.
В то время как на том же сайте для SIM800C есть прошивка датируемая февралём 2018.
Так что возможно, что для SIM800C баги могли уже исправить, но почему-то не пересоберут никак прошивку для SIM808. (((((

3.3В подавать на модуль запрещено, не более 3.0В, иначе может выпалить порт или модуль, а может только сбоить, уже обсуждалось.
Китайские платы с модулями это шлак, люди тут уже проходили это не раз. Если хотите дальше пробовать модули, порекомендовал бы, купить модуль у офицалов, развести плату, заказать её в Китае, 10 плат за 2$ изготовление и 12$ доставка (доставка обычно 2-3 недели), и тогда уже драть шкуру у офицалов, если Вы всё выполнили, а модуль не работает.
По китайским модулям, офицалы, пошлют погулять и даже разбираться не будут. Оно и понятно, чего им разбираться за чужое, да и как сказали, прошивка может быть какая угодно.
Если не ошибаюсь, то SIM808 вообще не рекомендован в новые разработки, а рекомендован SIM868, где нужен GPS в модуле.
В моём понимании SIM8xx неженка ещё та, что чихнуть с ним рядом боязно.

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

Интерфейс у модулей СИМ8хх допускает подачу не более 3.0В на вход. Для МК с питанием 3.3В нужно согласование. Для пробы можно поставить делители на линии МК -> Модем.
Из-за согласования могут быть глюки. Из-за плохого питания тоже.

Если посмотреть SIMCom_Roadmap_2018, то видно что развитие идет SIM808 -> SIM868 -> SIM868E
Российские и Украинские дистрибьюторы вроде сначала обозначили SIM808, но потом его сняли и не продавали. Продают только SIM868. Видимо не спроста. Скорее всего SIM808 больше не развивают.

Ориентироваться лучше на то, что продают у нас, т.к. дистрибьюторы временами хвалятся своими объемами, и тем, что благодаря объемам могут влиять на китайцев в области доработок (исправления багов и внесения новых фич). Плюс в Москве вроде есть центр разработки Симкома, что тоже сильно ускоряет устранение ошибок.
В результате на популярные модули исправления и дополнения последние годы выходят довольно регулярно.

А по поводу кривого до ужаса АТ-стека Симкома, на форуме говорилось, что там лицензионная ось с GSM стеком, и китайский АТ-стек крутится в ней как задача c ограниченными ресурсами, поэтому никакого быстродействия от него ждать не приходится

У меня вообще на sim800c не получается отправить данные...
После AT+BTSPPSEND модуль тупо молчит. Уже даже лог. анализатор подключил и проверил что у меня все в порядке.

К sim800c подключаюсь терминалом с телефона.
После подключения:
AT+CGMR
Revision:1418B06SIM800C24_BT
AT+BTSPPCFG?
+BTSPPCFG: S,1,1
Т.е. модуль Server и в APP mode

Если что-то отправить с терминала, то до модуля все доходит:
+BTSPPDATA: 1,11,blablabla
После чего я хочу ответить:
AT+BTSPPSEND.... и тишина

Если модуль перевести в режим AT mode:
Для этого
1. AT+BTSPPCFD=KEYFORAT
2. Первыми данными после подключения отправляем "KEYFORAT"
После этого
AT+BTSPPCFG?
+BTSPPCFG: S,1,0

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

На AT+BTSPPSEND отвечает +CME ERROR: 1056 что соответствует документации:


Подскажите как его заставить работать?

После этого модуль должен прислать "> ". Без завершающего "\r\n" !!!
Подозреваю, что Ваша терминалка просто ждёт этого самого "\r\n" и не выплёвывает "> " на экран.


Да - и если нужен полный дуплекс, то "automatic mode" в BTSPPGET использовать нельзя - теряются данные. Хотя возможно, что это баг только SIM808.

В том то и дело что приглашения вообще нет. Смотрел анализатором.
Если важно? то для коммуникации использую cmux

SIM800C - версия прошивки?

И крайний апнотес по BT в соседней теме - "SIM800C - Пауза перед вводом следующей AT-команды"
Естественно что исключить BLE команды - в SIM800C его нет.

Revision:1418B06SIM800C24_BT берем у Вас.

По поводу апнотесов: все что там написано про SIMCOMSPPFORAPP - какая-то провокация.
Во-первых строку SIMCOMSPPFORAPP я не нашел в найденных на просторах прошивках SIM800с.
Во-вторых эта волшебная фраза должна соответствовать тому что мы послали в AT+BTSPPCFD=
В-третьих эта фраза наоборот переключает модуль в AT mode.

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

Невнимательно читаем - SIMCOMSPPFORAPP это <data string>, передаваемая строка, то есть если вместо SIMCOMSPPFORAPP написать LA-LA-LA то это будет равнозначно.

Обратите внимание что количество символов соответствует <cnfLen2>

Константы SIMCOMSPPFORAPP нету в прошивке sim800c С чем ему сравнивать?
В B02 (кажется) только ее нашел - там еще видимо не было AT+BTSPPCFD

В B06 по дефолту модуль и так в APP моде сразу после подключения. И вот этой SIMCOMSPPFORAPP (или что там прописано ранее в AT+BTSPPCFD) переводится в AT mode.
С этим проблем нет кроме того что этот механизм неправильно (наоборот) описан в апнотесе.
Вообще с приемом проблем нет (Андроид -> sim800c). Есть проблема в обратном направлении.

AT+BTSPPSEND пробовал в разных вариациях. И с мультиконектом и без. Приглашение на ввод строки никогда не появляется.

Вот пример:
В первом случае AT+BTSPPCFD=SIMCOMSPPFORAPP , во втором AT+BTSPPCFD=bla
По дефолту AT+BTSPPCFD="" поэтому SIMCOMSPPFORAPP вообще не срабатывает.
Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла

Как я понимаю из документации - это не константа. Это сигнальная лексема переключения, которую Вы сами должны задать для AT+BTSPPCFD. Естественно, что её нет в прошивке, так как SIM800C по дефолту в APP. Значит дефолтное значение её ему не нужно.


Так если Ваш модуль по дефолту уже в APP, то зачем Вы заморачиваетесь этой AT+BTSPPCFD?


Проблема с потерей входящих данных на SIM808 у меня наблюдается при одновременном приёме и передаче. А у Вас нет передачи.


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

Смотря как понимать "одновременность" - если буквально, то в силу TDD это невозможно физически.

Для меня этот линк представлен UARTом. Он дуплексный. Как уж там внутри данные упаковываются в кадры радио-канала и как делится время канала на приём/передачу - это уже проблема BT-стека.
Одновременно для меня - это одновременная передача с обоих концов этого UART.

Я уже писал не раз здесь, что использую EVB, а не модуль. Эту: https://arduino-kit.ru/catalog/id/plata-ras...-s-gps-antennoy
Линейный стабилизатор на ней имеется. Мощный. Ему на вход подаю 9...12V. Тоже от мощного источника.


Я использую не модуль, а готовую EVB. С установленным на ней мощным линейным стабилизатором. На него подаю 12V со стабилизированного лабораторного источника выдающего несколько ампер. Так что каких-то проблем питания быть просто не должно.
Насчёт согласования линий IO: схему на плату я найти не смог, но судя по той документации, что имею, на плате для TxD, RxD есть цепи согласования для любого напряжения IO до 5V включительно (на паре транзисторов). Про что в доке сказано:
Т.е. - есть пин разъёма VMCU, на который я подаю 3.3V с платы МК.

PS: Вобщем - заказали EVB на SIM868. Надеюсь с ней все проблемы решатся.

Документация на ваш шилд от производителя, со схемой, лежит тут:

http://www.tuxti.com.br/arquivos/arduino/m...SIM808_V3.1.rar

Наконец то я увидел китайский шилд где сделали правильно согласование уровней и вообще нормальная схемотехника.

Что-то я сходу не могу придумать как снять лог обмена т.к. там используется мультиплексор. Писать какой-то велосипед чтоб это все распарсить и красиво показать пока что нет времени...
Может кто-то сталкивался и знает решение как снять лог обмена по CMUX подручными средствами?

С уверенностью могу сказать что после AT+BTSPPSEND на uart полная тишина. Где-то тут ранее проскакивало что на sim800c нет одновременно BT и CMUX.
Я обрадовался что все-таки есть. Из BT активно использую AT+BTSCAN - все работает хорошо, но иногда тоже есть проблема - UART начинает молчать. Лечится перезагрузкой модуля.
Частота зависаний зависит от частоты вызова AT+BTSCAN. Если не делать паузы после окончания сканирования (+BTSCAN: 1), то зависает часто. В итоге пришел к паузе 2,5с.
В sim800 BT реализован где-то криво именно в части общения c UART.

>>>Где-то тут ранее проскакивало что на sim800c нет одновременно BT и CMUX.

Да, это было в некоторых прошивках с EAT.

Есть такая чудная команда - AT+CLIST
Она показывает что реализовано в модуле
Если дать AT+CLIST=<группа>, то покажет все доступные команды в этой группе.

Вырубил CMUX... at+btsppsend работает.

Вы писали ранее, что пробовали и без CMUX

Так выложите без.
Что такого сложного в снятии лога? Печатаете (printf) весь обмен в отладочный UART на комп (с метками времени и метками приём/передача) и сохраняете его в файл любой терминалкой.
Но более достоверно и независимо (чтобы исключить ошибки в своём коде): берёте два COM-порта и на их входы RxD заводите TxD и RxD с UART-а между МК и модулем. Данные из этих двух COM-портов также сохраняете в файл терминалке на компе. С метками времени обязательно!


Спасибо! Я полный этот архив не находил, только его части. Хотя уже наверное и не нужно - проблема не в схеме, а в SIM808.


Ну не особо то и правильно - TxD, RxD как-то согласованы, но вот остальные сигналы - CTS, RTS, ... - нет.
Сейчас заказали вот этот:
https://www.mikroe.com/gsmgnss-2-click#heading1
Ссылка на принципиальную схему есть внизу страницы.
Согласование уровней сигналов тут сделано лучше, даже лампочки подключены аккуратно - через транзисторы, а не напрямую к пинам модуля как на плате с SIM808.
Но вот с питанием какая-то лажа. (((
Использованный здесь MCP1826 судя по даташиту может отдать только 1А, что как бы маловато для SIM868.

Про мультиконектом я подразумевал мультиконект bluetooth. Не путайте его с CMUX

>>>Ну не особо то и правильно - TxD, RxD как-то согласованы, но вот остальные сигналы - CTS, RTS, ... - нет.

По сравнению с тем что раньше видел - уже прогресс.

>>>Ссылка на принципиальную схему есть внизу страницы.

USB не вывели - очень не помешало бы
VRTC в воздухе - а 4.7 мкф там должен стоять
STATUS и DTR тоже наружу бы не помешали

ну и совсем прикол - развели уже SD карточку, так поставьте и второй SIM держатель.

Это Вы тут всех путаете. На SIM800C нет мультиконнекта BT. Если верить доке:
MTK6261 platforms: SIM808, SIM800C, SIM800A, SIM800F.
...
For the MTK6261 and MTK2503 platform module, only supports the simultaneous connection of
1 device.

Как Вы могли пробовать то, чего нет?


Учтём. Спасибо.


Это у них в этот разъём одновременно и микро-SIM-ка и микро-SD ставятся что-ль?

>>>Это у них в этот разъём одновременно и микро-SIM-ка и микро-SD ставятся что-ль?

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

Да вот так:


Реально правда второе соединение не проверял т.к. не нужно мне это.

Продолжаю раскопки
Проблема оказалась не в CMUX...к сожалению она глубже закопана

AT+BTSPPSEND работает только до того момента как я не начинаю PPP сессию.
Ниже ситуация когда я после CONNECT OK специально не запустил PPP и мы видим входящие LCP пакеты.
После какого-то таймаута (я же молчу) происходит NO CARRIER и AT+BTSPPSEND чудно заработала.
Чтобы проверить реакцию на АТ команды несколько раз отправлял at и получал OK
В лог валится все что приходит от модуля. Мои же команды отправляются в 3-й канал CMUX. PPP поднимается по 1-му каналу CMUX.


Еще поэкспериментировал. Если дать PPP соединению установится, то 100% не работает BTSPPSEND. Если соединение разорвать, то начинает работать. На прием BTSPPDATA не влияет.
С активным PPP похоже все функции BT работают кроме BTSPPSEND. BTSCAN работает, гарнитуру подключает, SPP если перевести в APP mode тоже отвечает на AT команды.

Ну так я же приводил выше выдержку из даташита про "only supports the simultaneous connection of 1 device". Видимо это относится не только к BT-соединениям. Вы бы лучше документацию повнимательнее изучили....

Не забивайте себе голову мультиконектом к SPP.
Ограничение mtk6261 описано в SIM800 Series_Bluetooth_Application Note_V1.07 и явно это только про Bluetooth. Мне мультиконект не нужен совсем. Даже вреден будет.
Завтра попробую еще тоже самое с SIM868. Про него там тоже самое написано , но он на другой платформе

SIM868 ведет себя так же
Где-то есть досадная ошибка в софте simcom касательно работы с UART.
Сам стек BT совместно с открытым PPP 100% работает т.к. в режиме +BTSPPCFG: S,1,0 он и принимает и передает ответы по SPP. A вот в режиме +BTSPPCFG: S,1,1 не работает только AT+btsppsend, прием работает без замечаний (по крайней мере на малых объемах данных).

Подкину еще одну доку - может кому пригодится.
Не самая свежая, но кое-что отсутствующее в апнотес там имеется.


Вычитал интересный момент.

///К популярным профилям, наиболее широко востребованным в самых различных приложениях и поддерживаемым (или поддержка которых может быть реализована) модулями 800-й серии, относятся:

.... DUN (Dial-up Networking Profile) стандартный профиль для предоставления доступа в Интернет. Базируется на SPP, включает в себя команды PPP и AT, определенные в спецификации ETSI 07.07


Вот тут скорее всего и кроется причина - если задействовали PPP, то капут.....

Было бы классно, если бы профиль OPP мог работать не только с внутренней памятью SIM800, а ретранслировал бы запросы по чтению/записи файлов в UART (AT-командами).
Т.е. - при передаче файла командой AT+BTOPPPUSH, модуль читал бы файл не из своей внутренней памяти, а запрашивал бы файл по частям по UART у пользовательского микроконтроллера. То же самое при приёма файла - принимаемый по команде AT+BTOPPACPT файл не писал бы во внутреннюю память SIM800, а отправлял пользовательскому МК через AT-командный интерфейс.
Почему интересно в SIMCOM-е не додумались сделать такую полезную вещь? Тогда бы и профиль OPP был бы тоже очень полезным, не только SPP.
А сейчас придётся ещё поверх SPP прокладывать свой протокол передачи файлов.

Да! Я тоже за! Было бы весьма полезным.

Может ув. CADiLO донесёт наши чаяния до руководства SIMCOM?
Использование для OPP внутренней ФС модуля мне кажется бесполезным малополезным для случая работы SIM800 в связке с внешним МК. А ведь такая работа - это наиболее распространённый путь использования SIM800. (без EAT).

Я не против, только сейчас китайцы опять на своих "нешинал холидей" потом я на выставке.
На работу вернусь 23 апреля.
Поэтому чтобы не ждать можно написать прямо работнику Симкома на форуме - bator.batuev/собака/sim.com

Только что получил этот модуль: так оно и есть - там 2-этажный магазин SIM+microSD, первый этаж - симка, 2-й (поверх неё) - micro-SD.
Так что один недочёт из списка можно вычеркнуть
А вот то, что они GND, RXD, TXD, CTS вывели на одну линейку пинов (разъём), а RTS - отдельно на другую (хотя в первой линейке есть NC-пины) это конечно совсем неудобно.

>>>Так что один недочёт из списка можно вычеркнуть

Нельзя - модуль умеет работать с ДВУМЯ симками!!!

Для 868Е вот такая прошивочка нужна - 1418B01SIM868E32_BLE_DS
И тогда весь его функционал становится доступным.