Перейти к содержанию

    

Bluetooth и потоковая передача данных (подобрать чип)

Здравствуйте! Встала (комом в горле) задача - надо реализовать потоковую передачу данных с аналогово датчика через Bluetooth. До этого никогда с Bluetooth не работал. Пробовал NRF51822 - передавать либо обновлением характеристики, либо через notofication - данные теряются, либо все вообще виснет. Нужно что-то типа SPP или A2DP. Причем, желательно с Cortex на борту и быстрым порогом вхождения. Смотрел в сторону NRF52840, но похоже, оно тоже этого не умеет. Пробовал также модуль HC-05 - все прекрасно работает, но уж больно громоздко - устройство должно быть максимально миниатюрным и энергоэкономичным. Посоветуйте, пожалуйста, в какую сторону смотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 минуты назад, R2AIV сказал:

Пробовал также модуль HC-05 - все прекрасно работает, но уж больно громоздко - устройство должно быть максимально миниатюрным и энергоэкономичным. Посоветуйте, пожалуйста, в какую сторону смотреть.

Потоковая потоковой рознь. Какая скорость нужна? И что имеете в виду под "громоздкостью"? Вы хотите своё приложение в BT-чипе запустить или нужен внешний BT-чип (в режиме модема), а Ваше приложение - в отдельном чипе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не уточнил, прошу прощения. 100кБит хватит за глаза. Нужен чип именно с ядром Cortex, т.е. SoC, чтобы запустить в нем свое приложение, именно. Под внешние чипы просто нет места, увы (( Девайс должен быть не больше зажигалки примерно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
34 минуты назад, R2AIV сказал:

Не уточнил, прошу прощения. 100кБит хватит за глаза. Нужен чип именно с ядром Cortex, т.е. SoC, чтобы запустить в нем свое приложение, именно. Под внешние чипы просто нет места, увы (( Девайс должен быть не больше зажигалки примерно.

100кб/с - это уже неплохая скорость. К тому же ещё и непрерывным потоком. Уже даже на отдельных BT-модулях не всегда получается её получить. Про встроенные не знаю - не пользовал. Но думаю, что с малым потреблением будут проблемы. И непонятно куда собираетесь пихать ещё и аккумулятор в зажигалку (ёмкости достаточной для такой передачи сколько-нибудь прилично времени)? Хотя это конечно не относится к данному вопросу. Но боюсь, что чип будет всё время в активном режиме, без сна и быстро съест аккум.

 

PS: И вроде как NRF51822 - это BLE. В то время как HC-05 - обычный BT. Так что же Вам действительно нужно? А может вообще BT не нужен, а нужна просто беспроводная передача?  :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Беспроводную передачу я уже предлагал. Хотел сделать на NRF24L01, но заказчику нужен именно Bluetooth... Про энергопотребление тоже понятно, но это не объяснишь, так что миримся с тем, что есть. Насчет непрерывности я не совсем корректно выразился - данные АЦП накапливаются (допустим на частоте дискретизации 300Гц до объема 4096 байт (это сейчас так сделано), потом высылаются, затем опять накапливаются и цикл повторяется. Т.е. передача данных будет с перерывами на их накопление. Главное, передать данные потоком и, по возможности, максимально быстро. Про BLE речь уже не идет - он с этим не справится, ищу именно классический Bluetooth. Есть версия, что и новомодный NRF52840 это может не потянуть...

Изменено пользователем R2AIV

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот вам готовый инструмент. Аналог обрабатываете в блоке Sensor Controller, дальше вам его M4F выстреливает куда надо. BLE5 Stack (и не только) в комплекте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может, подойдет ? Раньше этот производитель назывался Promi, а теперь он называется Initium:

 

http://www.senanetworks.co.kr/download/manual/manual_promi_esd-v2.0.0.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добрый день.

Подсчитаем:

..данные АЦП накапливаются (допустим на частоте дискретизации 300Гц до объема 4096 байт (это сейчас так сделано), потом высылаются, затем опять накапливаются и цикл повторяется..

Допустим, что выборка АЦП -это 2 байта (= 16 бит).  (Если выборка АЦП это 1 байт - то все в 2 проще.)

300гц * 16 бит = 4800 бит/сек.  - требуемая скорость

Такую скорость для  payload передаваемых пакетов может обеспечить даже BLE v4.0. !!!

Допустим,  что особенность проекта - обязательное накопление 4096 байт,  а затем передача по BLE.
(В противном случае все еще проще - передаем сразу же как накопится размер payload  для пакета).

Время накопления в буфере (вариант 2-х байтной выборки АЦП):
T= 3.33ms * (4096 байт / 2) = 6.8 sec !!! 

И столько же времени накапливаются следующие 4096 байт.
Т.е. (при наличии 2-х буферов) для передачи мы имеем ~7 сек,  что позволяет нам спокойно передать содержимое буфера.
И требуемая скорость - те же 4800 бит/сек.

BLE  прекрасно подойдет для вашей задачи.
Все будет очень маленькое и малопотребляющее.
При непрерывной работе (7sec передаем/7 sec накапливаем) и питании от CR2032, все проработает несколько месяцев.

При редком включении BLE - годы.

Если, все же, нужно быстрее - выбирайте SoC+SDK  с поддержкай BLE v.4.2  или BLE 5
При этом , конечно,  важны возможности второй стороны обмена.

Но Вам требуется такая низкая скорость передачи,  что все заработает без особых настроек...
Обычно эти SoC  содержат и ADC, и SRAM  >4096 байт, что может упростить конструкцию прибора.

Я,  например, использую SoC от TI:  CC2640, CC2640R

 

...Пробовал NRF51822 - передавать либо обновлением характеристики, либо через notofication - данные теряются, либо все вообще виснет...
BLE работает "железобетонно".
Только учтите, что вариант notification - это без подтверждения доставки пакета (как в UDP). (Лучше бы Indication).

Или вообще измените логику работы: вторая сторона (например, Android) раз в 7 сек запрашивает соединение и читает 4096 байт.

Тогда можно и без notification, Indication

..Нужно что-то типа SPP или A2DP..
Наверное Вы имели в виду SPP  и протокол RFComm?
Ни того ,  ни другого в BLE  нет.
Но это не проблема,  т.к. написать приемлемый вариант эмуляции SPP не трудно.
Профиль - это всего лишь для стандартизации и удобства.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация