Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: WT-12 Bluegiga
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Wireless/Optic
MiklPolikov
Сопрягаю модуль WT12-A-AI4 с телефоном.
Если связь рвётся, модуль присылает сообщение "ERROR" или "NO CARRIER".
Но тонкость в том, что если связь рвётся спустя более чем 1-2 минуты после соединения, то это сообщение возникает за доли секунды. А если рвётся в каком-то небольшом промежутке времени сразу после соединения, то сообщение об ошибке нужно ждать секунд 10. Почему так происходит ? Для меня принципиально, что бы сообщение об ошибке появлялось быстро.
Настраиваю режим соединения так :

BLUETOOTH_SEND_DATA("SET BT POWER 4 4 4");
BLUETOOTH_SEND_ENTER();

BLUETOOTH_SEND_DATA("SET BT SNIFF 0100 10 3 0010");
BLUETOOTH_SEND_ENTER();

BLUETOOTH_SEND_DATA("SET BT ROLE 0 F 0200");
BLUETOOTH_SEND_ENTER();

BLUETOOTH_SEND_DATA("set bt pair *");
BLUETOOTH_SEND_ENTER();

BLUETOOTH_SEND_DATA("SET BT PAGEMODE 3 2000 1");
BLUETOOTH_SEND_ENTER();
Radox
Скажите, а если установить связь между этими же модулями и проделать такие же манипуляции, эффект будет тот же самый? Когда я делал проект на других Bluetooth модулях, у меня была проблема при установлении связи с телефоном, вроде как связь есть, начинаю что-то передавать, например картинку, соединение рвется, тут же вылетает сообщение. А между двумя модулями поведение немножко другое.
jcxz
Цитата(MiklPolikov @ Nov 28 2013, 05:03) *
Но тонкость в том, что если связь рвётся спустя более чем 1-2 минуты после соединения, то это сообщение возникает за доли секунды. А если рвётся в каком-то небольшом промежутке времени сразу после соединения, то сообщение об ошибке нужно ждать секунд 10. Почему так происходит ? Для меня принципиально, что бы сообщение об ошибке появлялось быстро.

Сейчас тоже работаю с WT12A. Коннект с PC через SPP-профиль. Описанной проблемы не наблюдаю - дисконнект менее секунды.
Настройки:
SET BT PAGEMODE 3 2000 1
SET BT POWER 3 3 3
SET BT ROLE 1 f 7d00
SET BT SNIFF 0 20 1 8
А вы какой профиль используете?
MiklPolikov
Цитата(jcxz @ Nov 30 2013, 13:40) *
Сейчас тоже работаю с WT12A. Коннект с PC через SPP-профиль. Описанной проблемы не наблюдаю - дисконнект менее секунды.
Настройки:
SET BT PAGEMODE 3 2000 1
SET BT POWER 3 3 3
SET BT ROLE 1 f 7d00
SET BT SNIFF 0 20 1 8
А вы какой профиль используете?


Использую OPP "CALL 00:19:4f:70:fb:ee 1105 OPP\n"
Но мне единственное что нужно, это держать соединение с любым сотовым и быстро узнавать о том что оно порвалось (надеюсь уже все догадались что за гаджет laugh.gif )

С режимом SNIFF какое-то непонимание.
Документация обещает потребление 2.3мА при таких настройках "SET BT SNIFF 1000 20 1 8" и 4.7мА при таких "SET BT SNIFF 40 20 1 8"
У меня оно от настроек не зависит и всё время 5мА
Может я не захожу в SNIFF ?
Выбираю режим SNIFF так "SET BT ROLE 0 4 200"
Но из документации не ясно, нужна ли во втором параметре цифра 4 или 8. (картинка) Делаю и так и так, никаких изменений не вижу.
jcxz
Цитата(MiklPolikov @ Nov 30 2013, 19:57) *
Но из документации не ясно, нужна ли во втором параметре цифра 4 или 8. (картинка) Делаю и так и так, никаких изменений не вижу.

Хмм... Я так понял, что там просто опечатка - начало нумерации битов от 1, а не от 0. Там же приведено значение F как "всё включено".
Я как раз ставлю F.
У меня кстати тоже проблема с режимом SNIFF - не включается никак. Ни через SET BT SNIFF, ни через SET {link} SNIFF после установления соединения.
Второй способ работает для переключателя ROLE (по установке SET BT ROLE оно не меняется, а только так - после коннекта через SET {link} ROLE) .
Если же пробовать дать SET {link} SNIFF ... после коннекта, то почему-то включается ROLE в режим MASTER, а ACTIVE как было так и остаётся. wacko.gif
Может где какой ключик я забыл?
Вот лог обмена с модулем после входящего соединения (видно что после непонятного переключения в SLAVE после команды SET {link} SNIFF, моё ПО
пытается обратно переключить в SLAVE, но новый SET {link} SNIFF всё гробит):
CODE
>> CONNAUTH 00:02:72:37:68:ba 0 3? \Gok
<< CONNAUTH 00:02:72:37:68:BA 0 3 OK
>> CONNAUTH 00:02:72:37:68:BA 0 3 OK \Gecho
>> OK. \GprintOk
Result parse: \GOK
>> CONNAUTH 00:02:72:37:68:ba 1 1? \Gok
<< CONNAUTH 00:02:72:37:68:BA 1 1 OK
>> CONNAUTH 00:02:72:37:68:BA 1 1 OK \Gecho
>> OK. \GprintOk
Result parse: \GOK
>> RING 0 00:02:72:37:68:ba 1 RFCOMM 3b538b4 \Gok
<< LIST
>> LIST \Gecho
>> LIST 1 \Gok
>> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE SLAVE ENCRYPTED 0 \Gcomplete
>> OK. \GprintOk
Result parse: \GOK
FLAGS: 02 01 01 02
<< SET 0 SNIFF 100 10 3 10
>> SET 0 SNIFF 100 10 3 10 \Gecho
>> OK. \GprintOk
Result parse: \GOK
<< LIST
>> LIST \Gecho
>> LIST 1 \Gok
>> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE MASTER ENCRYPTED 0 \Gcomplete
>> OK. \GprintOk
Result parse: \GOK
FLAGS: 02 01 02 02
<< SET 0 SLAVE
>> SET 0 SLAVE \Gecho
>> OK. \GprintOk
Result parse: \GOK
<< SET 0 SNIFF 100 10 3 10
>> SET 0 SNIFF 100 10 3 10 \Gecho
>> OK. \GprintOk
Result parse: \GOK
<< LIST
>> LIST \Gecho
>> LIST 1 \Gok
>> LIST 0 CONNECTED RFCOMM 127 0 0 0 8d 8d 00:02:72:37:68:ba 1 INCOMING ACTIVE MASTER ENCRYPTED 0 \Gcomplete
>> OK. \GprintOk
Result parse: \GOK
FLAGS: 02 01 02 02
<< SELECT 0
>> SELECT 0 \Gecho
>> OK. \GprintOk
Result parse: \GOK
CONNECT
MiklPolikov
Цитата(jcxz @ Nov 30 2013, 18:25) *
Хмм... Я так понял, что там просто опечатка - начало нумерации битов от 1, а не от 0. Там же приведено значение F как "всё включено".

Как я понимаю, не нужно ставить F разрешающий всё что бы работать в SNIFF , а нужно ставить именно тот бит который разрешает один SNIFF
jcxz
Почему? Ведь в доке ясно сказано:
F This value enables all of the above modes (the default value)
В любом случае - попробовал и 4 и 8 и 12, без разницы, SNIFF всё равно не включается. Разве что перестаёт переключаться в MASTER по команде SET {link} SNIFF.

А вы используете переключение role в master?
Если верить доке, то это также должно уменьшать потребление в 3-4 раза...
Может то, что у меня происходит (переключение в MASTER при подаче SET {link} SNIFF) случается, потому что сторона на PC не поддерживает SNIFF и модуль
чтобы хоть как-то выполнить поставленную SNIFF-ом задачу уменьшения потребления, переводит его хотя-бы в MASTER-режим rolleyes.gif
Sergey SN
Цитата(jcxz @ Nov 30 2013, 19:10) *
Почему? Ведь в доке ясно сказано:
F This value enables all of the above modes (the default value)
В любом случае - попробовал и 4 и 8 и 12, без разницы, SNIFF всё равно не включается. Разве что перестаёт переключаться в MASTER по команде SET {link} SNIFF.

А вы используете переключение role в master?
Если верить доке, то это также должно уменьшать потребление в 3-4 раза...
Может то, что у меня происходит (переключение в MASTER при подаче SET {link} SNIFF) случается, потому что сторона на PC не поддерживает SNIFF и модуль
чтобы хоть как-то выполнить поставленную SNIFF-ом задачу уменьшения потребления, переводит его хотя-бы в MASTER-режим rolleyes.gif

И есть ещё один вопрос - как может быть совместим энергосберегающий режим с профилем, предполагающем сравнительно интенсивный трафик в случайные моменты времени? Может, вся проблема в этом?
MiklPolikov
Цитата(Sergey SN @ Dec 5 2013, 14:58) *
И есть ещё один вопрос - как может быть совместим энергосберегающий режим с профилем, предполагающем сравнительно интенсивный трафик в случайные моменты времени? Может, вся проблема в этом?

Не вижу принципиальной проблемы.
И в доках об этом не видил.
jcxz
Вы о каком профиле? SPP?
А почему Вы решили, что будет интенсивный траффик? Откуда Вам известна моя задача?
Вообще-то SPP - эмуляция UART, который суть - асинхронный интерфейс, т.е. - данные могут быть или их вообще может не быть и известна только максимальная скорость данных, но никак не минимальная.
И почему SNIFF может быть не совместим с SPP?
Sergey SN
Цитата(jcxz @ Dec 5 2013, 15:04) *
Вы о каком профиле? SPP?
А почему Вы решили, что будет интенсивный траффик? Откуда Вам известна моя задача?
Вообще-то SPP - эмуляция UART, который суть - асинхронный интерфейс, т.е. - данные могут быть или их вообще может не быть и известна только максимальная скорость данных, но никак не минимальная.
И почему SNIFF может быть не совместим с SPP?

Теоретически - потому что классический SPP - это режим постоянной готовности, и, без настроечных довесков, должен быть заточен под приоритет этой готовности над возможностью поэкономить электричество.
Что касается сообщений о дисконнекте и скорости их появления - могу предположить, что на начальном этапе модуль пребывает в готовности подхватить неустойчивый канал, восстанавливая связь. Но убедившись в её устойчивости выключает этот алгоритм в пользу приоритета тревожной сигнализации. Поэтому потом мы её вилим сразу, а вначале - он пытается бороться с дисконнектом и не торопится с такой сигнализацией.
Apollo
Купил на пробу данный модуль. Подал питание и с помощью телефона обнаружил новое устройство. При попытке подключения с телефона к модулю происходит запрос PIN-кода. Пытался вводить разнве комбинации, но что-то не получается подключиться.
Где вообще можно раздобыть документацию с описанием команд для этого модуля?
MiklPolikov
Цитата(Apollo @ Dec 26 2013, 17:55) *
Где вообще можно раздобыть документацию с описанием команд для этого модуля?


Архив во вложении
Apollo
Спасибо огромное! Буду изучать.
MiklPolikov
Ещё посмотрите тему
http://electronix.ru/forum/index.php?showt...uegiga&st=0
Про то что для работы с айфоном нужен другой модуль.
Apollo
Спасибо! До написания в этой теме, когда искал ответ на свой вопрос наткнулся и на указанную выше тему. Благо, что пока с iPhone связываться не по Bluetooth нет необходимости. Больше интересует в перспективе связаться с устройством под управлением Android.
Не выясненным остался пока вопрос какой же PIN-code хочет получить свежекупленный WT12 ("из коробки" так сказать). Пытался с телефона отправить и "0000" и "1234" не принимает. Думаю, конечно вылечится, когда я подключу управляющий МК или компьютер и либо выдам команду на отключение запроса PINa, либо команду на установку нового PINа. Хотя остается спортивный интерес узнать что же он требует в качестве PINа по умолчанию.
MiklPolikov
Цитата(Apollo @ Dec 28 2013, 00:43) *
Спасибо! До написания в этой теме, когда искал ответ на свой вопрос наткнулся и на указанную выше тему. Благо, что пока с iPhone связываться не по Bluetooth нет необходимости. Больше интересует в перспективе связаться с устройством под управлением Android.
Не выясненным остался пока вопрос какой же PIN-code хочет получить свежекупленный WT12 ("из коробки" так сказать). Пытался с телефона отправить и "0000" и "1234" не принимает. Думаю, конечно вылечится, когда я подключу управляющий МК или компьютер и либо выдам команду на отключение запроса PINa, либо команду на установку нового PINа. Хотя остается спортивный интерес узнать что же он требует в качестве PINа по умолчанию.

Там наверняка есть команда по которой Вы узнаете PIN от производителя. Но какой в этом смысл ?

Ещё, мне не понравилось как организована установка бодрэйта UART. Бодрэйт устанавливается командой, и сохраняется после сброса питания. Если во время установки произойдёт какая-то ошибка,
модуль может запомнить какой ему вздумается бодрейт. Получается, что для гарантированно стабильной работы нужно предусмотреть перебор всех бодрэйтов пока модуль не ответит , что бы выйти из этого дэд-лока.
jcxz
Полностью согласен!
По-моему - это большое неудобство в WT12 - сохранение в его flash всех настроек и невозможности их установки в дефолтные по одному простому сигналу (RESET).
Много плевался уже по этому поводу.... sad.gif(((((

Гораздо правильнее было сделать сохранение настроек в ОЗУ WT12, а при вкл. питания или reset-е - сброс в дефолтные настройки.
Всё равно если модуль подключен к МК, то МК должен при старте дать ему сброс, потом проверить все его текущие настройки и изменить те, которые необходимо.
У меня сейчас firmware так и делает, но перед этим приходится перебирать все битрейты UART (может оказаться на заводском bitrate, а может на уже моём установленном
ранее, а может на моём-же битрейте установленном ранее, но предыдущей версией ПО (если потребовалось изменить в новой версии битрейт)).
Плюс - ещё для каждого битрейта делаю определение режима (MUX или не MUX), определение режимов парсинга команд модулем (с эхом или без, с OK после команд или без),
во всех комбинациях, так как в своём ПО сделал всё это опциональным (можно условной компиляцией разрешать или запрещать эти режимы).
Соответственно при старте надо определить какие в модуле текущие настройки и переключить их на необходимые, с какими скомпилено ПО.

Если-бы по reset всё сбрасывалось в дефолтные настройки и сохранялось только в ОЗУ модуля, это бы сильно упростило ПО.
Apollo
Спасибо за ценное предупреждения насчет настроек. Предполагаю что может возникнуть ещё и не совсем точное определение битрейта, ибо бывает что при близких скоростях UART микроконтроллера может вполне корректно воспринять короткий ответ "ОК" и подумать что эта текущая скорость и есть искомая. Как вариант нужно проанализировать ответ модуля, содержащий значение текущей скорости.

А вот что написано в iWRAP4_User_Guide:

If you enter an incorrect or invalid baud rate and can not access iWRAP any more, the only way to recover the module is via the SPI interface by deleting the value of PS-key : PSKEY_USR26. Please see chapter 9.1 PS-keys and how to change them for information how to change the PS-keys.

Короче надо на всякий случай, если железо дает возможность, подключиться ещё и по SPI. Это даст возможность реанимировать модуль.

И тут возникли траблы... Почитал поподробнее, но нашел только описание способа с применением компьютерной программы PSTool. Как добраться до регистров PS-keys через SPI пока не понятно.

Чем дальше в лес... Отыскал на сайте техподдержки BlueGiga ссылку на рекомендуемый переходник USB-PSI DEV-SYS-1808-1A-ND. Платить за переходник 211$ что-то не очень айс. Тем более это только малая часть того что нужно сделать. Этот переходник лишь позволит настраивать PS-keys с компьютера. Выходит, надо ещё сделать устройство для перехвата протокола, чтобы понять что передавать с МК. В общем какой-то сложный путь получается. Попробую отыскать информацию по командам SPI для модуля, если она вообще есть.

Народ, оказывается это уже тут обсуждал http://electronix.ru/forum/index.php?showtopic=112444
jcxz
Цитата(Apollo @ Dec 29 2013, 00:26) *
вполне корректно воспринять короткий ответ "ОК" и подумать что эта текущая скорость и есть искомая.

Я не ОК ищу.
И даже AT/ОК не совпадёт - это же минимум 8 байт. И что значит близкие? Соседние скорости отличаются в 1.5-2 раза.

Цитата(Apollo @ Dec 29 2013, 00:26) *
Короче надо на всякий случай, если железо дает возможность, подключиться ещё и по SPI. Это даст возможность реанимировать модуль.

Вот когда найдёте описание протокола, тогда и расскажете всем как подключиться wink.gif
Apollo
Докладываю о продвижениях.
Подопытный модуль WT12 собран на чипсете BlueCore4. Таких чипсета у CSR два и какой именно применен я ещё не разобрался. Есть чипсет BlueCore4-PC-ROM и есть BlueCore4-External.
Мне удалось скачать документы на каждый из чипсетов.
В документах есть раздел посвященный CSPI (SPI доработанный и запатентованный CSR'ом).

В документе на BlueCore4-PC-ROM это раздел 8.2 Serial Peripheral Interface, а на BlueCore4-External - 11.7 Serial Peripheral Interface.

Набор PS key

Разобрался. Чипсет всё же BlueCore4-External, так как и в WT12 и в BlueCore4-External есть интерфейс PCM, а в BlueCore4-PC-ROM его нет.
Apollo
Мозг уже закипает от вала информации, причем разрозненной и на мой взгляд неструктурированной. А главное то что важно не описано пока нигде.
Прочитав документ от CSR "CSR SPI (CSPI) Specification Issue 2" понял что все же в нашем чипсете этот протокол не используется и вот почему:

- во первых:
"CSPI is an extension of a basic SPI interface, with the access type determined by the following fields:
■ 8-bit command
■ 24-bit address
■ 16-bit burst length (optional)";

-во вторых:
"Command
Bit Function
[7] Start bit (must be 0)
[6] nRegister/Burst
[5] Write
[4] Read
[3] Reserved (must be 0)
[2:0] Function number.
To initiate a CSPI access, command bit 7 must be 0, and one of command bits 5 and 4 (not both) must be high,
indicating a read or a write access. Any other bit combination is ignored.";

То есть в CSPI используется 24, а не 16 битный адрес и в байте команды биты, указывающие на то чтение это или запись другие и не могут быть одновременно "1".

Файл со спецификацией CSPI прилагаю

В документе на чипсет протокол совсем другой. Адресация 16 битная, а байт команды записи и чтения выглядят соответственно так: 00000010 и 00000011.
Apollo
Подскажите какие команды давать при инициализации модуля и какие для установления соединения.

Выдаю команду на соединение как в примере в даташите,
CALL 0C:00:A0:E7:EE:3B 1101 RFCOMM


но получаю вот что:
CALL 0

NO CARRIER 0 ERROR 311 SDC_NO_RESPONSE_DATA


Подозрение на параметр 1101 - это номер канала, может надо какой-то другой установить? Как узнать какой нужен канал?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.