Результаты поиска

Тут на одной шине много датчиков и всё в порядке. Используют либу https://github.com/Thinary/AHT10

CB2S Module Datasheet

https://aliexpress.ru/item/4000478798085.html Связанные ссылки: Beken SDK Programming Guide Tuya-iotos-embeded-sdk-wifi-ble-bk7231n Wi-Fi & Bluetooth LE SoC NANO (BK7231N) Али модуль за дорого

Новые и навороченные - умеют, старые и дешевые - нет. Запускаете "nRF Connect", в нем, в верхнем левом боковом меню, "Device information".

WiFi на 2.4ГГц – это какая-то промежуточная хрень, которая в скором будет забыта. Её заместят WiFi на 5ГГц далее (WiFi6+), т.к. уже имеют естественные и встроенные ограничения для локализации своей зоны и уменьшения помех от соседних. 433 MHz – в реальности не лучше ZigBee и BLE Long-range. Это...

Нет. Это уровень PHY (передатчика-приемника), но не приема-передачи потока данных. Для BLE 4.0 реально и стабильно примерно до 115200 бит в сек полезных данных при соединении. Смысл в BLE только такой - автономное устройства и прочее работающие в личной зоне. Для пользователей железобетонных...

И как там дела - достигнуто ли нормальное потребление в 6LN и 6LR для 6BLEMesh в реализации BLEach? А я вот и совместимость тупых BLE устройств без режима соединения в "каскадный" вариант с нижайшим потреблением на стандартных дровах BLE разработал/дорабатываю и уже испытал/испытываю... Пора имя...

Это и хорошо, что недалеко. И так в городе весь радиоэфир зашумлен. А данные от любой WiFi AP принимаются на всей улице/проспекте и кто угодно может их рассматривать и хулиганить...

Для собственной реализации дуплексной связи в режиме BLE рекламы всё и так предусмотрено в стандарте. На каждом канале, после передачи advertise фрейма, устройство включает приемник на пятьсот микросекунд для приема стандартных запросов на соединение или на запрос дополнительной рекламы...

Это не BLE-MESH и не Zigbee, а для использования имеющихся в продаже BLE датчиков, без их перепрограммирования, а так же для случая двухсторонней передачи данных между BLE устройствами без режима соединения. В WiFi это равносильно работающей AP c подключенным к ней устройством в спящем режиме...

Где пинок? Была просто проверка что там налепили в ESP32 за годы. Ну и как всегда оказалось, что ничего хорошего. Предполагалось рассмотреть вариант реализации нестандартного но часто нужного алгоритма работы с BLE, но на имеющихся чипах от Espressif, завяленных как малопотребляющие :) Оно нужно...

В Long-range битрейт в 4 раза меньше.

SDK как-бы по два - IoT и MCU + от разных источников. От производителя совмещенные: Bouffalolab bl_iot_sdk. Support BL602 Wi-Fi/BLE Combo RISC-V based Chip and BL70X Zigbee/BLE RISC-V based Chip. bl mcu sdk for BL602/BL604, BL702/BL704/BL706 от Pine64: Pine64 bl_iot_sdk только для BL602...

Это вы гадаете погуливая тут, не заглянув в кривоватые доки и не держа в руках это новое чудо от Espressif? Напишите директору Espressif и его работягам - они вам объяснят, что это вы неправы, раз уж посмотреть даже первую страницу темы не смогли. Гуляйте дальше. --- Пришлось взять другой SoC...

В github добавлены логи SPI и снимки с логического анализатора, т.е. всё что необходимо для работы c имеющимся у XMWSDJO4MMC E-Ink. Работа с Simplicity Studio имеет специфику - завязке на доступности серверов SiLabs. К примеру вчера не работало :)

Bluetooth Low Energy (BLE) 5.1 есть только в CH32V208. Но в текущей документации таблицы потребляемого тока в разных режимах пока пусты (кроме никому не нужного отключенного состояния :)). Документация ясности о возможности выключить всё и оставить поддержку только RAM не несет. А это первое...

В данной теме измерение без включенного WiFi и с sleep. Спустя много лет Espressif и выпустило на замену ESP32-C3FN(H)4, что и есть в данной теме.

Вот с вентилятором и в спец. закрытом объеме в тестовой ванне. ваш BME280 показал на +1.63С больше, чем без куллера - там +2.0С от истины. А паршивый древний SHT85 - 0.08 как максимум из кучки тестированных и наверно нагрелся от BME280 с куллером, т.к. без обдува отклонения меньше :p А туты...

А тут с вашим "Мне глубоко насрать" Arduino тестировщики сенсоров не согласны. Они такие впечатляющие паутины плетут: Что никак не могут проверить на быстрый опрос и самонагрев сенсоров. Устранить самонагрев они пытались вентилятором :) У вас с ESP32 отклонение в +1.5C от нагрева ESP - сенсор...

Это ваши ответы на вопросы как убрать сопли в sleep, в вашем любимом ESP? Или как в режиме BLE достичь хотя-бы того, что когда-то было сделано патчами в ESP32, а затем обратно извращено и осталось одной из тысячи открытых и висящих проблем в ESP/IDF? Видать хорошо вы знаете ESP :) Какую-то...