[let's see 0]

Имеется старый проект, в котором два устройства соединены классическим БТ. Естественно, один мастер, один слейв. Обмен данными двусторонний и достаточно интенсивный. Задержки - неприемлимы.

Необходимо добавить к этой сети смартфон, в основном, в качестве индикатора и несколько(пока 4) сенсоров/актюаторов. Об'ем данныь низкий, требования к энергопотреблению очень жесткие, задержки совершенно неприемлимы.

Пожалуйста посоветуйте возможные архитектурные решения с их обоснованием. Расстояние между устройстами до 3 метров.В случае потери соединения, сеть должна снова сама воссоединиться.

 

Заранее благодарен.

Изменено 25 июля, 2018 пользователем pitt

[alx125 0]

Имеется старый проект, в котором два устройства соединены классическим БТ. Естественно, один мастер, один слейв. Обмен данными двусторонний и достаточно интенсивный. Задержки - неприемлимы.

Необходимо добавить к этой сети смартфон, в основном, в качестве индикатора и несколько(пока 4) сенсоров/актюаторов. Об'ем данныь низкий, требования к энергопотреблению очень жесткие, задержки совершенно неприемлимы.

Пожалуйста посоветуйте возможные архитектурные решения с их обоснованием. Расстояние между устройстами до 3 метров.В случае потери соединения, сеть должна снова сама воссоединиться.

 

Заранее благодарен.

 

Добрый день.

Лучше, если будут обозначены числа.

Сколько задержка сейчас? Сколько приемлемо? Более подробно об условиях применения.

В какие моменты возникают "неприемлемые задержки"?

BT Classic не славится сильно экономичный потреблением!

А BLE v4.x не подойдет для большИх скоростей обмена.

(кроме , BLE v.5. Но мне известен лишь смартфон с поддержкой этой версии BT)

[gerber 7]

Насколько я понимаю, это нереальная задача. БТ подразумевает установление соединения между 2-мя узлами с возможным обменом ключами для шифрования трафика. Вклиниться в обмен (даже просто прослушать его) обычным смартфоном не представляется возможным, это будет весьма нетривиально даже при разработке собственного низкоуровневого устройства.

[x893 33]

Насколько я понимаю, это нереальная задача. БТ подразумевает установление соединения между 2-мя узлами с возможным обменом ключами для шифрования трафика. Вклиниться в обмен (даже просто прослушать его) обычным смартфоном не представляется возможным, это будет весьма нетривиально даже при разработке собственного низкоуровневого устройства.

Вообще всё не так.

 

goole.com

BLE Mesh

 

https://habr.com/post/418539/

[gerber 7]

Имеется старый проект, в котором два устройства соединены классическим БТ. Естественно, один мастер, один слейв. Обмен данными двусторонний и достаточно интенсивный. Задержки - неприемлимы.

Необходимо добавить к этой сети смартфон...

Каким местом тут BLE Mesh, интересно.

[let's see 0]

Добрый день.

Лучше, если будут обозначены числа.

Сколько задержка сейчас? Сколько приемлемо? Более подробно об условиях применения.

В какие моменты возникают "неприемлемые задержки"?

BT Classic не славится сильно экономичный потреблением!

А BLE v4.x не подойдет для большИх скоростей обмена.

(кроме , BLE v.5. Но мне известен лишь смартфон с поддержкой этой версии BT)

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

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

Обновление. В старом проекте идет обмен пакетами по 120 байт, каждые 4 миллисекунды, т.е. матер->слейв; подтверждение(8 байт) + свои 120 байт, мастер подтверждает и все сначала.

Для обмена с фоном пакет 180 баит каждые 200 миллисекунд.

Для сенсоров и актуаторов задержка не боле 4 миллисекунд при пакетах в 16 байт.

Изменено 31 июля, 2018 пользователем pitt