[R2AIV 0]

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

[jcxz 184]

2 минуты назад, R2AIV сказал:

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

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

[R2AIV 0]

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

[jcxz 184]

34 минуты назад, R2AIV сказал:

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

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

 

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

[R2AIV 0]

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

Изменено 29 октября, 2018 пользователем R2AIV

[gosha-z 2]

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

[kovigor 5]

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

 

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

[oljarus 0]

https://www.silabs.com/products/wireless/bluetooth

[alx125 0]

Добрый день.

Подсчитаем:

..данные АЦП накапливаются (допустим на частоте дискретизации 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 не трудно.
Профиль - это всего лишь для стандартизации и удобства.