Вожусь уже который день пытаясь заставить 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 и них в приоритете а не ВТ .




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