Обсуждение NRF52840

[azt59]

@cheblin Датчика пока три, уличная температура, температура и co2 в помещении и тестовый блютус электрочайник, все должны быть доступны через web по https. по первым двум еще нужна база данных для логирования и удобного показа логов через web

а в будущем задумка то универсальная, как пробросить ble в сеть

 

[cheblin]

как пробросить ble в сеть

воткнуть стандартный BLU-UART в такой UART-Ethernet свисток



300 рублей

 

[azt59]

а кухню как организовать?
как у вас из стандартного BLE-UART через этот свисток пакеты полетят на нужный мне mqtt брокер? тут еще один контроллер просится, или это будет не стандартный а самописный ble-uart который умеет настроить ethernet законнектиться с mqtt забрать нужные данные с датчика и опубликовать их в нужном топике, ну и наобот все с приемом команды

 

[cheblin]

или это будет не стандартный а

я правильно понимаю, что эти вопросы возникли уже после прочтения документации на CH9121 где это всё подробно расписано?

 

[azt59]

я правильно понимаю, что эти вопросы возникли уже после прочтения документации на CH9121 где это всё подробно расписано?

Конечно, но понимания каким чудесным образом у вас это заработает я не понял.

Напомню конфиг:
3+ nrf52840 вещают в эфир надо собрать с них данные и положить в mqtt, если в mqtt что-то новое то отправить на устройство

 

[azt59]

Вопросик на засыпку.
Блютус блютусом, но нужна связь с локальным сервером(роутер с mqtt). Варианты:
1. скрестить nrf52- с rtl8710 или esp
2.скрестить nrf и ethernet shield w5500
3. Купить nrf52 usb-dongle и по usb воткнуть в роутер и писать софт под openwrt
4. Ничего не изобретать а задействовать что-то готовое если таковое имеется

Пусть по минимуму функционал :датчик периодически коннектится к серверу ble и отсылает допустим температуру и заряд АКБ, наш "gateway" транслирует эти сообщения и размещает в неком топике mqtt. И обратно, если в топике mqtt посвященному данному датчику появляется какая-то инфа например сигнал на включение gpio1 гейтвей ждёт следующего коннекта от клиента и передаёт ему сигнал на включение чего либо.
Естьп что-то подобное? На открытых адекватных протоколах или изобретать велосипед?
Я пока что склоняюсь к связке nrf52840->>w5500->>mqtt

Тут я предлагал подобное но на другом модуле, пока отложено ибо сначала проверю как работает стандартное решение от нордика ble over ipv6 по протоколу 6lowpan

 

[pvvx]

воткнуть стандартный BLU-UART в такой UART-Ethernet свисток

Посмотреть вложение 8808

300 рублей

Оно стоит от 550 рупь, аж целый MIFI 3G/4G Router (с OpenWRT, USB2.0, 150 Mbps WiFi) ->https://aliexpress.ru/item/32840062592.html который запросто по USB сожрет nRF52 или TLSR8266, но можно и впаять во внутро и к UART.
А CH9121 не умеет HTTPS и вообще не известно как работает с UART. Да и жрет как MIFI!
Прежде чем предлагать всякую хрень - произведите испытания на:
1) Какой длины UART блок в него лезет и при дуплексе. Он гарантированно не тянет постоянный поток.
2) Какая пауза на линии UART считается концом блока и является событием для отсылки.
Потом будете писать, что нифига в вашей доке не описано.

я правильно понимаю, что эти вопросы возникли уже после прочтения документации на CH9121 где это всё подробно расписано?

 

[pvvx]

Мне, к примеру, проще поставить один разъем LAN со встроенной в него OpenWRT (Eport Pro EP10) и подключить к нему любой BLE чип, т.к. версия OpenWRT для него откатана мной и тестерами на всевозможные баги и вырезаны все ошибки, да всё переписано вдоль и поперек... Там от OpenWRT мало осталось не переписанного, т.к. каждая утилита в OpenWRT имеет глобальные и алгоритмические ошибки.
https://esp8266.ru/forum/attachments/eport_pro-ep10-jpg.7934/

 

[azt59]

А софт для ble чипа? По вашим замерам весь траффик оно не протолкнет в уарт, значит надо будет писать обработку управляющих команд для настройки какие пакеты и от кого нужно передавать в openwrt

 

[pvvx]

А софт для ble чипа? По вашим замерам весь траффик оно не протолкнет в уарт, значит надо будет писать обработку управляющих команд для настройки какие пакеты и от кого нужно передавать в openwrt

Проталкает и в виде готовых текстовых MQTT запросов-ответов. USB1.1-COM даже на TLSR826x прокачивает за 500 килобайт в сек. Со встроенного ADC или I2C шины TLSR8266 гонит 400 кбайт/cек (I2C - 200 тысяч опросов 16 битного регистра вешнего устройства) на CLK CPU 16 MHz. А обработка I2C поболее чем что-то другое, т.к. CPU занят во время работы по I2C.

Что, на столько у nRF52 USB хуже?

Предельный то поток у самого продвинутого BLE -
Для BT4.2: "We can say with certainty based on our own testing that ~50 KB/s data throughput is achievable on newer Android and iOS devices with DLE enabled on the default LE 1M PHY."
Для BT5.x, nRF52: Case 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 400 millisecs)
Data throughput reported by firmware:
Time: 6.11 seconds elapsed.
Throughput: 1371.82 Kbits/s.
Sent 1048712 bytes of ATT payload

1371.82 Kbits/s в пределе это 171.4775 кбайт/сек и никто 2 Mbps PHY не юзает - не все жрут. И это влезет в USB-COM. В USB1.1 bulk-у обязано влезать 800 килобайт в сек, иначе чип с дровами в помойку.

 

[pvvx]

Всё это теоретические и пиковые нагрузки при одном устройстве BLE как точка-точка и без подтверждений приема.
На CSR (USB-брелке, хост) и BLE 4.2 чип выходит всего 5 килобайт линейного непрерывного трансфера. При этом почему-то уходит до 4-х Connection Event/Interval в 7.5 ms, а пачка в 9 блоков (234 байтов данных) передается в первый interval - далее три они что-то там мутузят, возможно подтверждение...

 

[pvvx]

Т.е. при теоретическом и практическом возникает расхождение при BT4.2 и PHY 1 Mbps:
Должно быть 7800 байт при 234 полезных байта в 4*7.5 ms, а выходит что меньше, т.к. если загнать на 7800 - то возникают пропуски и скорость падает до 5 кило, где и держится уверенно часами...

 

[pvvx]

Nordic и USB:
В прошлый раз мы тестировали скорость MSC самого стека, она составляла около 700 КБ / с (при использовании dd на диске EMPTY - 512 МБ нулей).
USBD with CDC ACM class Windows 10 maximum data rate
"когда пользователь stevenB заявляет, что он достигает скорости 2,5 Мбит / с, bjorn -spockeli заявляет, что достижимая скорость составляет 700 КБ / с (5,6 Мбит / с) с MSC.
Я действительно сомневаюсь, что 2 и 2,5 Мбит / с действительно достижимы с драйвером CDC ACM, предоставленным в SDK 15.2.0. Я более склонен принять что-то около 500 кбит / с (62,5 кбайт / с) для CDC ACM.
Может ли кто-нибудь @nordic уточнить, что на самом деле достижимо, и, возможно, дать некоторые рекомендации о том, как получить скорости выше 1 Мбит / с (если это вообще возможно с CDC ACM)?"
->
"Команда быстро ответила, и вот их результаты:
MSC записывает нули на пустой диск (Linux): 513 кБ / с (4104 кбит / с)
Передача двоичных файлов CDC ACM (Windows): 215 кБ / с (1720 кбит / с)"

 

[pvvx]

Кароче с nRF52 всё неизвестно и сИкретно. Никто ничего не знает, показания путаются на десятичные порядки что в скорости, что в потреблении чипов, и прямо в документации
Толи дело китайские чипы BLE - всё известно, измерено, перепроверено, и могу подсказать как и что

 

[pvvx]

@azt59 подруга моего друга спрашивает... . а что за данные собрались передавать? и в каком объёме?
если это просто термометр в парилке...то и обсуждать нечего.

В парилке? Да там много чего надо! Диапазон температур, влажность (корпус) и автономное питание от спец элемента. Т.е. никакой из продаваемых для бытовых целей не годится.
Придется поковыряться.
Обсуждать нечего с вашим AdHoc, т.к. он и там не вперся ну ни как.
Можно поставить UBIA, но диапазон температур... Питание возможно от элемента Пельтье, если есть что с хорошей разницей температур - как раз будет включаться когда парилка работает...

 

[goodwin]

Повозился пару дней с NRF52. Успел поставить раком один модуль - отвалился SWD. Никакиt "фирменные" утилиты от нордика не помогли. Наковырял вот это для J-Link (во вложении) - разлочил... Ну и на вкусненькое вот это вот СвежачОк'с...

 

[pvvx]

Добрый день, Всем!
Наконец-то свершилось.
Что?
Упали цены на модуль NRF52840 (229 руб).

Кроме того лишь в 52840 (поправьте если ошибаюсь)
реализован протокол BLE 5 Long-range

Прошло более года, но дешевых NRF52840 так никто и не дождался. Цена на устройства с ними только возросла, что говорит о малом спросе.
Народных устройств на NRF5 не появилось и на горизонте не видно...
Использования BLE 5 Long-range не видать - какое-то нежизненное творение у Нордик
Единственное использование чипов NRF5 наблюдается в тупых снифферах, т.к. после покупки более делать с ними нечего.

@nikolz вы осознали от чего зависит популярность любого чипа в современности?