vartom
commented
1 year ago НА в докере, не получилось заставить работать с LR по предложенной инструкции. Может быть нужно ещё что то предпринять?
Open pvvx opened 1 year ago
vartom
commented
1 year ago НА в докере, не получилось заставить работать с LR по предложенной инструкции. Может быть нужно ещё что то предпринять?
pvvx
commented
1 year ago На ходу, когда уже загружен HA, переключение адаптера не работает. Требуется остановить HA. Или выполнить:
hcitool -i hci1 cmd 08 31 03 04 04
hciconfig -a hci1 down
hciconfig -a hci1 upВ Linux, в Bluez, адаптер BT5.0 по старту системы инициализируется неправильно. От этого все проблемы в Linux. Это аналогично тому, что адаптер с USB3.0 принудительно переключается в USB1.1, а API для переключения в USB3.0 нет. В итоге неясно, как Bluez получил какие либо сертификации. Остается одна надежда на ChatGPT и массовые увольнения “программистов”.
Интеграция "bluetooth" работает через прокладку "Bleak". "Bleak" в свою очередь работает через DBUS, Далее следующая "прокладка" - "Bluez", далее kernel. Это упрощенно, т.к. там десятки так называемых API прокладок. Писатели "Bleak" вообще не в курсе что в 2016 году вышел стандарт BT5.0 и есть какие-то переключения PHY у адаптеров. Просто недавно в bluez починили ошибки и в запрос сканирования теперь вставляется значение PHY по умолчанию, которые заданы на низком уровне адаптеру. Но утилиты bluez ещё не умеют создавать connect с разными вариантами PHY описанными в BT5.0. Там ещё не исправлены ошибки.
WEB Bluetooth API нормально не работает в Linux. В Android оно может соединяться с любыми PHY, но меню сканирования у Chrome ещё не умеет работать с BT5.0. В Windows ситуация с WEB Bluetooth API почти аналогична с Linux, но там другие проблемы. Linux тормозят Bluez и Товальдс, подписывая кривые решения.
API Android работает без проблем с Coded PHY и всеми остальными форматами PHY. Примером является nRFConnect и многие другие приложения на Android.
Apple вообще никогда не придерживалось стандартов Bluetooth SIG. И там свои предрассудки.
По идее, в докере, всё должно быть аналогично, если произвести переключение в той части, которая управляет адаптером. Адаптеры BT5.0 умеют сканировать во всех вариантах PHY с 2016 года. Бесшовно принимают рекламные пакеты от Bluetooth и всех вариантов BLE BT5.0, включая не стандартные на 2M PHY, если включить эти опции. Но работать с LE Long Range обычным пользователям не дают писатели софта и корпорации по неизвестным причинам. Возможно это подрывает коммерцию ZigBee...
pvvx
commented
1 year ago Интеграция "ble_monitor" в HA включает сканирование только на 1M PHY. Автор ещё не умеет переключать адаптер на работу в BT5.0.
vartom
commented
1 year ago Спасибо за описание. Удалось таки перевести датчики lywsd03mmc на использование BLE LR в HA в докере. Пришлось перейти с ble_monitor на xiaomi_ble и заново их определить. Через btmon проверил подключение действительно в LE Coded. Посмотрю как это будет работать.
pvvx
commented
1 year ago Посмотрю как это будет работать.
Потребление от батарейки сильно возрастает в режиме LE Long Range. Более чем в 3 раза из-за увеличения времени передачи в 8 раз на пониженной модуляции. Желательно изменить период трансляции рекламных сообщений на более чем 5 секунд. Включение LE Long Range актуально если термометр расположен на удалении и адаптер его плохо видит. Тестовые проверки при включении LE Long Range в Xiaomi LYWSD03MMC показывают, что связь с ним сохраняется на расстояниях более 500 метров и до 1 км по прямой видимости. В основном это требуется на отдельных частных участках с большими размерами. В городских "человейниках" эта опция бесполезна, т.к. 2.4ГГц плохо распространяется через препятствия в виде железо-бетонных и каменных стен.
Для достижения той же дальности в режиме "Legacy", по сравнению с режимом "LE long Range", требуется увеличение отдачи RF TX с +7 дБм (без учета коррекции ошибок в режиме "LE long Range"). Это недоступно на CR2032 из-за увеличения тока во столько же раз, во сколько требуется увеличение мощности передатчика. По сравнению с Bluetooth 4.0 требуется ещё увеличить мощность передатчика в несколько раз... При переключении на "LE Long Range" время передачи возрастает в 8 раз, но ток от батареи остается прежним (6..7мА при +0 дБм).
Стабильность работы проверена на приеме на дешевый адаптер без доп. антенн (указанный в заголовке темы) от термометра в соседнем доме-бане, находящимся примерно в 100 метрах. При этом уровень приема (RSSI) колеблется на уровне -102..-108 дБм по показаниям данного адаптера. Смартфон при этом спокойно соединяется с термометром в nRFConnect...
Это температура в предбаннике... При протопке печка дает повышение, без печки температура удерживается электронагревателем (мелкая волнистость линии - авто включение/выключение обогревателя)...
pvvx
commented
1 year ago # lsusb
Bus 007 Device 002: ID 0a12:0001 USB2.0-BT# hciconfig -a
hci0: Type: Primary Bus: USB
BD Address: 04:7F:0E:4A:0C:C9 ACL MTU: 1021:9 SCO MTU: 255:4
UP RUNNING INQUIRY
RX bytes:6445 acl:0 sco:0 events:463 errors:0
TX bytes:3579 acl:0 sco:0 commands:347 errors:0
Features: 0xbf 0xee 0xcd 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
Link policy: RSWITCH SNIFF
Link mode: PERIPHERAL ACCEPT
Name: 'BlueZ 5.64'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 5.1 (0xa) Revision: 0x89
LMP Version: 5.1 (0xa) Subversion: 0x89
Manufacturer: Barrot Technology Limited (2279)hcitool -i hci0 cmd 08 31 03 05 05
Long Range - ok.
almirus
commented
1 year ago @pvvx
Добрый день! Xiaomi LYWSD03MMC прошит LYWSD03MMC Custom Firmware Version 4.2 на компе веб скрипты (сканер) видит устройство, дает прошить, иногда не может получить температуру влажность, иногда получает :)
19:48:54: Watching advertisements from "ATC_0B27B9"... 19:48:54: Argh! TypeError: device.watchAdvertisements is not a function
НО в HA со свистком Bluetooth 5.0 Realtek один раз добавился через Xiaomi BLE. Потом я недолго поигрался с параметрами через веб конфигуратор, и потом, чтобы я не делал, устройство более не добавляется (не видится)в HA (при этом CGPR1 продолжает нормально работать). Я и прошивал и на оригинальную и на модифицированную и батарею вынимал, и команду DD слал и 56, ничего не помогает.
Термометр в 3 метрах от Bluetooth свистка
pvvx
commented
1 year ago на компе веб скрипты (сканер) видит устройство, дает прошить, иногда не может получить температуру влажность, иногда получает :) 19:48:54: Watching advertisements from "ATC_0B27B9"... 19:48:54: Argh! TypeError: device.watchAdvertisements is not a function
На Windows "Advertising.html" практически не работает. Это проблема в Windows c Web bluetooth API.
Работает только на Android.
НО в HA со свистком Bluetooth 5.0 Realtek один раз добавился через Xiaomi BLE.
В HA две интеграции для работы с термометрами - "Bluetooth" и "Bluetooth Low Energy Monitor - Passive BLE monitor".
"Bluetooth Low Energy Monitor" работает со всеми выбранными в TelinkMiFlasher.html форматами.
"Bluetooth" имеет расширения "BTHome" и "Xiaomi BLE". Для них необходимо выбрать в TelinkMiFlasher.html формат BTHome или Mijia. А так-же поставить галочку "AdFlag":
со свистком Bluetooth 5.0 Realtek
Рисунки и названия адаптеров от продавцов ни о чем не говорят. В Windows надо смотреть свойства адаптера в "диспетчере устройств".
По USB VID/PID можно узнать какой чип.
По номерам HCI/LMP - какой версии bluetooth:
almirus
commented
1 year ago @pvvx Может стоит в шапке веб конфигуратора указывать что нужно с мобильного заходить или я не нашел. с телефона конфигуратор заработал. Спасибо Попробовал два формата BTHome, Mijia - не находит. Настройки же сразу применяются, батарею вытаскивать не нужно?
pvvx
commented
1 year ago Настройки применяются сразу, но BLE реклама не работает во время соединения. Подключаться для настроек в TelinkMiFlasher.html можно в любой ОС. А вот прием BLE рекламы в Windows зависит многих факторов. И пока в Chrome и других это опция - экспериментальная и предупреждение описано. Если не что-то там не работает - обращайтесь примерно туда: https://github.com/WebBluetoothCG/web-bluetooth https://github.com/WebBluetoothCG/web-bluetooth/blob/main/implementation-status.md
almirus
commented
1 year ago По USB VID/PID можно узнать какой чип.
almirus
commented
1 year ago цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком
pvvx
commented
1 year ago Google: _USB\VID_0BDA&PID8771 а это и есть 8761B
цель зависти все это не на виндовс, а на RPI 4 c Home Assistant и с этим свистком
А это уже ваши проблемы с версиями ОС на RPI 4 и Home Assistant. Данный адаптер = тормоз. Ловит в 5..10 раз меньше реклам в единицу времени чем другие...
almirus
commented
1 year ago
то есть просто ждать и выгадать верное время для соединения ?
pvvx
commented
1 year ago Может отсоединяется по причине посаженной батарейки. Для соединения желательно чтобы было более 40% (+20С). Далее будет работать c HA и до 0%.
almirus
commented
1 year ago батарея 99%. а подключение к chrome на телефоне может мешать подключению к RPI4?
pvvx
commented
1 year ago Во время подключения BLE реклама, ту которую принимает HA, не передается. При подключении потребление больше...
almirus
commented
1 year ago спасибо за уделенное время. пока безуспешно. на тлф в браузере все ок на HA - тишина, хотя с таким же конфигом неделю назад термометр соединился, а теперь ни в какую
pvvx
commented
1 year ago Отключите соединение с термометром в Android и в других. Закройте эксплорер. В HA термометр появляется с задержкой... Лучше перезапустить всю систему с HA и подождать пару минут.
almirus
commented
1 year ago @pvvx еще маленький вопрос, значок Bluetooth на самом устройстве что обозначает и должен ли он отображаться в момент рекламы (или соединения)?
pvvx
commented
1 year ago Значок Bluetooth активен только во время соединения и мигает если нажата впаянная кнопка или геркон с выбором в меню функции геркона/кнопки "соединение" (обычно для Long Range).
almirus
commented
1 year ago @pvvx вместо Xiaomi BLE, установил аддон Passive BLE Monitor
И он нашел оба BLE устройства ¯_(ツ)_/¯ (на том же железе)
fanoush
commented
1 year ago
hcitool -i hci0 cmd 08 31 03 05 05Long Range - ok.
Hello, I got this dongle and tried to enable long range on my thermometer. Since none of my phones can do 5.0/coded phy and nrfconnect don't see the device I tried this dongle in Ubuntu 22.04 and I have partial success :-)
hcitool switch works and then when using bluetoothctl for scanning like described here https://stackoverflow.com/questions/60318829/bluez-bluetoothctl-scan-vs-hcitool-scan I can see the thermometer - its name and mac address. Then I tried gattool to connect to the mac address but unfortunately it does not work when trying to enumerate services/characteristic and for everything it fails with
Command Failed: DisconnectedSo most probably it does not even connect properly. Here is output from btmon advertisement
> HCI Event: LE Meta Event (0x3e) plen 57 #247 [hci0] 1065.463599
LE Extended Advertising Report (0x0d)
Num reports: 1
Entry 0
Event type: 0x0001
Props: 0x0001
Connectable
Data status: Complete
Address type: Public (0x00)
Address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Primary PHY: LE Coded
Secondary PHY: LE Coded
SID: 0x00
TX power: 127 dBm
RSSI: -96 dBm (0xa0)
Periodic advertising interval: 0.00 msec (0x0000)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Data length: 0x1f
12 16 1a 18 1e 52 c9 38 c1 a4 db 09 14 12 c1 0a .....R.8........
4f 0e 04 0b 09 4c 59 57 53 44 30 33 2d 31 45 O....LYWSD03-1E
Service Data (UUID 0x181a): 1e52c938c1a4db091412c10a4f0e04
Name (complete): LYWSD03-1Eand here is connection attempt
< HCI Command: LE Extended Create Connection (0x08|0x0043) plen 42 #250 [hci0] 1065.465694
Filter policy: Accept list is not used (0x00)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Initiating PHYs: 0x05
Entry 0: LE 1M
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
Entry 1: LE Coded
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #251 [hci0] 1065.466611
LE Extended Create Connection (0x08|0x0043) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #252 [hci0] 1069.513740
> HCI Event: Command Complete (0x0e) plen 4 #253 [hci0] 1069.515681
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 31 #254 [hci0] 1069.521684
LE Enhanced Connection Complete (0x0a)
Status: Unknown Connection Identifier (0x02)
Handle: 0
Role: Central (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Local resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Peer resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Connection interval: 0.00 msec (0x0000)
Connection latency: 0 (0x0000)
Supervision timeout: 0 msec (0x0000)
Central clock accuracy: 0x00
somehow it does not handle the connection - gives error " Unknown Connection Identifier (0x02)" what is interesting is that there are those two connection entries Entry 0: LE 1M Entry 1: LE Coded
Is this something that can be changed in the firmware? Maybe it does not make sense to offer LE 1M connection if the advertisement is only over Coded PHY? Maybe with only one "LE Coded" entry gattool would not be confused and would possibly connect?
fanoush
commented
1 year ago but when thinking about it maybe those two entries are on PC side(?) so not related to firmware - maybe it says which phy versions the PC supports/can try.
Just tried hcitool -i hci0 cmd 08 31 03 04 04 and indeed, it enables only Coded PHY and there is only 1 entry when connecting and it does not work too, same error.
With this 04 setting bluetoothctl scan shows only thermometer and nothing else, which may be sometimes good.
fanoush
commented
1 year ago Oh, is is a bug, and quite old one https://www.spinics.net/lists/linux-bluetooth/msg65444.html
The unknown connection identifier is actually the success case for LE Create Connection Cancel command.
And the cancel is sent becasue of the 4s connection timeout.
pvvx
commented
1 year ago Linux does not support the Bluetooth 5.0 specification released back in 2016. All utilities included in Bluez (hciattach hciconfig hcitool hcidump rfcomm sdptool ciptool gatttool in 2017) have long been declared obsolete and cannot be used to work with BLE devices. All other functionality has violations or neglect of the Bluetooth SIG specification There are only small pieces of Bluez and kernel v6.4+ code that work with some adapters.
USB-BT released a couple of years ago on ATS2851, like many others, does not work on Linux, even if all the latest patches to the kernel are applied. Patches in the Kernel are built according to the scheme - we do not understand how the function works or what flags are returned - a patch is put on excluding the use of this function. That is, the implementation of the functioning of BT5.0 and higher by such patches is simply excluded from support (the type of this HCI_xxx_BROKEN) for many BT adapters (selectively by functions). This leads to incomprehensible errors in old utilities as well.
Just tried hcitool -i hci0 cmd 08 31 03 04 04 and indeed, it enables only Coded PHY and there is only 1 entry when connecting and it does not work too, same error. With this 04 setting bluetoothctl scan shows only thermometer and nothing else, which may be sometimes good.
Yes. Because the rest of the functionality is performed by the adapter itself, and the reception of advertising with the reinitialization of the primary and secondary PHY is not patched yet :)
And the cancel is sent becasue of the 4s connection timeout.
Originally, in ancient times, timeouts were set correctly. Then they were fixed so that Linux would not work with BLE, and then fixed by many patch variants. But they never fixed it.
Now the solution is as follows: https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
PS: The only OS in which it is possible to work with BT5+ devices today is Android.
fanoush
commented
1 year ago Now the solution is as follows: https://gist.github.com/mironovdm/cb7f47e8d898e9a3977fc888d990e8a9
Thanks! That worked and now it waits much longer however then after those 22 seconds it is cancelled anyway (maybe it does not get any data from thermometer?). Can this be related to some connection parameters like the scan window or max connection interval so that the dongle is not really listening when the data comes?
< HCI Command: LE Extended Create Connection (0x08|0x0043) plen 26 #1336 [hci0] 78319.407277
Filter policy: Accept list is not used (0x00)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: A4:C1:38:C9:52:1E (Telink Semiconductor (Taipei) Co. Ltd.)
Initiating PHYs: 0x04
Entry 0: LE Coded
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #1337 [hci0] 78319.408178
LE Extended Create Connection (0x08|0x0043) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #1338 [hci0] 78341.829151
> HCI Event: Command Complete (0x0e) plen 4 #1339 [hci0] 78341.830377
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
That worked and now it waits much longer however then after those 22 seconds it is cancelled anyway (maybe it does not get any data from thermometer?).
Linux does not support the Bluetooth 5.0 specification released back in 2016. The connection in the "Long Range" mode works very well in Android in a variety of applications using the basic API, including nRFConnect. Similarly, no problems are observed in many SDKs for SoC with BLE. But not on Linux.
I was unable to achieve a connection with BT5.0 devices in Linux on the available adapters. I also used kernel v6.4+ with the latest patches.
Due to the implementation curves in Linux and Windows, the "Web bluetooth API" cannot come to the implementation of BT5.0 scanning. But if:
In Android, the connection will be successful. As a result, the browser does not yet know how to scan devices with extended and other advertising (BT5.0), but it can connect :) Linux and Windows keep users from accessing new features...
For these reasons, for bad operating systems, thermometers have a button to temporarily switch to the outdated mode for connection.
pvvx
commented
1 year ago now it waits much longer however then after those 22 seconds
This is the reason for the use of incorrect algorithms in BT Linux drivers. Earlier it was announced that the implementation of scanning and connecting via the BLE protocol in Linux blocks the driver. This is unacceptable for implementation. It's as if the whole system or program is standing still until the driver figures it out. To connect, it is enough to get one advertising event. But not in Linux - it requires at least two. And if the second one is lost, then a timeout will come out, and 22 seconds will not be enough. Although for other operating systems, 10 seconds is enough, without any blocking.
fanoush
commented
1 year ago Ok, then maybe it is worth to try some other bluetooth stack like https://github.com/bluekitchen/btstack and forget about bluez. btstack is opensource and free for non-commercial usage and is supposed to work in linux directly with usb dongles over libusb. BTW, this is the stack which also used in Raspberry Pico W.
pvvx
commented
1 year ago The scanning and connection functions available in the Linux API for BLE do not have a primary and secondary PHY installation. This is required by the BLE specification starting from version 5.
The current Bluez has a separate function for installing primary PHY, but most programs don't know about it. https://github.com/hbldh/bleak/issues/1225#issuecomment-1435282901
Most likely, the connection request is transmitted when PHY is incorrectly installed for Cоded PHY mode (Long Range)....
All this limits the possibilities. Thermometers can already provide "Periodic advertising with Responses (PAwR)", "Encrypted advertising data", significantly reducing consumption. But external software is not ready to support this functionality, unlike hardware. It remains only to wait, for years...
Ircama
commented
1 year ago Perhaps, rather than relying on BLE USB sticks with dubious O.S. support of the BLE 5.x version, an alternative method could be exploiting an I2C-BLE 5 module, like TB-03F (or similar), to acquire Coded PHY advertisements sent by BLE thermometers in range, so that they are saved to RAM and cataloged by each MAC with related storage timestamp. Then, an I2C slave interface implemented in the device can read the last values saved in RAM each time an I2C master (host) polls them. But this requires developing this gateway from scratch.
pvvx
commented
1 year ago @Ircama - The main purpose of the project is precisely to raise the level of external software related to BLE. Only in this way is it possible to ensure the availability of these technologies for the majority of users. I am not a programmer, but a developer, and I can only provide such an option - the gradual inclusion of new standards in the device so that users increase the requirements for external software. As time has shown, other variants of the approach have not yielded any results. The latest developments in this area are exclusively with Google (Android, Chrome, ...), but they do not release devices with BLE and the development of this direction is stuck.
To support the latest BLE standard, version 5.4 requires a chip that supports version 5.0 (released back in 2016) in hardware. Changes are exclusively in the software part, except for AoA and AoD technology. Many USB-BT adapters use downloadable software and Bluetooth version 5.4 support does not require chip replacement (except in cases of marketing :) ). The latest innovations in the BLE standard completely abolish proprietary protocols such as ZigBee. And it seems that for a long time there has already been opposition to the introduction of simpler and cheaper solutions to the masses using BLE technology... And Linux has long been mired in the "copyright" introduced by its founder. As a result, there have been no innovations for many years and everything new in Linux is not supported.
fanoush
commented
1 year ago BTW I recently got Motorola Edge 30 phone and can confirm it finds my thermometer advertising over Coded PHY just fine in nRF Connect. I went a bit farther away so all other BLE devices from same location could not be found and I still saw my LYWSD03-1E in the scan and could connect to it reliably and repeatedly and read various characteristics when RSSI was reported as dBm -106.
So I can confirm it works just fine when BLuez stack is not involved :-)
splitice
commented
10 months ago Has anyone ever found a single USB BT device that is capable of scanning both 1M and CODED at the same time? And connecting at minimum over LE 1M.
The closest I've got is wioth the 0bda:8771 Realtek Bluetooth Radio, I have tested quite a few other chips but few support even receiving coeded announcements (despite supposed support).
I also have one nRF52840 USB module that I flashed Zephyr too (which theoretically could support a coded PHY). Havent managed to be successful yet. However it appears the nRF52840 can only scan one PHY at a time.
The 0bda:8771 Realtek Bluetooth Radio is unable to connect to any devices as soon as CODED scanning is enabled in my testing. And is only able to scan a single PHY at a time.
Ignoring Linux support, I'm yet to find a single hardware product that can complete this element of the specification.
pvvx
commented
10 months ago Realtek RTL8761 BT-USB (0bda:8771) scans all PHYs.
PHY 1M/2M/Coded:
hcitool - i hci1 cmd 08 31 03 07 07
Edit /lib/systemd/system/bluetooth.service
ExecStart=/usr/local/libexec/bluetooth/bluetoothd --experimental
USB\VID_10D7&PID_B012 scans all PHYs. HCI 12.513 / LMP 12.513 (BTv5.3)
The 0bda:8771 Realtek Bluetooth Radio is unable to connect to any devices as soon as CODED scanning is enabled in my testing.
Linux has been dead for a long time. Bluez does not support Bluetooth 4.2 or higher. Only Bluetooth 4.0. Bleak not support Bluetooth 4.2
Use Android. It supports BT 5.0+
splitice
commented
10 months ago @pvvx When you have time I would love a btmon dump from start to finish for comparison.
I wonder if mine has an older firmware or similar. Or perhaps its the commands I'm sending.
Whenever I try and connect over either LE_1M or LE_CODED if CODED scanning is enabled the module refuses to connect. It's fine if scanning in LE_1M mode. I just assumed the dongle had incomplete CODED support.
I'm developing a custom bt stack (using raw HCI socket) currently. Not currently open source, but hoping the stakeholder will allow release to open source in the future.
Tend to agree re; linux. HCI support is incredibly buggy.
pvvx
commented
10 months ago Connection to Coded PHY in Linux does not work! BLE scanning only. (Also, SSD “fast parking” is not called up in Linux. If there is an unexpected power outage, the SSD may become damaged! Micron also failed with kernel patches... That is, with Linux kernel everything is very bad and has been for a long time.)
The firmware in the RTL chip in Linux is loaded at startup.
splitice
commented
10 months ago The firmware in the RTL chip in Linux is loaded at startup.
Its likely loaded by the Realtek drivers, no guaruntee we are on the same versions - or even that is the cause.
Connection to Coded PHY in Linux does not work! BLE scanning only.
In raw (HCI_CHANNEL_USER) mode this might be bypassable if the cause is understood and the issue not the fault of firmware or hardware.
pvvx
commented
10 months ago In raw (HCI_CHANNEL_USER) mode this might be bypassable if the cause is understood and the issue not the fault of firmware or hardware.
No support in API and Bluez.
splitice
commented
10 months ago Anyway we will never know if there could be support because I don't have my USB dongle even getting to the stage you have yours at. Nor any way to tell what the difference is.
pvvx
commented
10 months ago Android connection with encoded PHY works well. Even in Explorer. However, the Web Blutooth API cannot scan the encoded PHY. But if the device (MAC) is stored in Explorer, then Explorer is connected to Coded PHY. The problem is the same - there is no way to provide support for Linux and Windows.
For Realtek RTL8761 BT-USB (0bda:8771) use these fw: bt_adpter.zip
fanoush
commented
10 months ago However it appears the nRF52840 can only scan one PHY at a time.
what do you mean one at a time? The S140 stack do accept multiple PHY in a bitfield for scanning https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v6.1.0/structble__gap__scan__params__t.html#a369859ca03e34c8220452ae95d1aa02f and it should work
As for hardware features I guess with single radio you can scan only one channel and one PHY at the same time so the solution is to alternate between them and that would be true for most/all of the BLE hardware? True that for nrf52 there is MODE register https://infocenter.nordicsemi.com/topic/ps_nrf52840/radio.html?cp=5_0_0_5_19_0#register.MODE where you select data rate but I guess most/all other hardware would use same solution?
pvvx
commented
10 months ago And who will upgrade Bluez and the Linux kernel to support HCI from Nordic? And add support for Bluetooth 5.0?
PS: At the moment, it is only possible to expect support (Linux patches) for BT5.0 for some small platforms such as RPi from the Chinese...
pvvx
commented
10 months ago what do you mean one at a time?
The LE Coded PHY uses 1Mbit PHY but payload is coded at 125kbps or 500kbps. It also adds Forward Error Correction and Pattern Mapper. RF reception occurs in the same buffer and is then decoded. Purely software implementation.
splitice
commented
10 months ago And who will upgrade Bluez and the Linux kernel to support HCI from Nordic?
Actually very little is needed you get a mostly complete HCI stack from nordic, Zephyr wraps this up (and the HCI stack is "mostly to spec"). hciattach can handle the uart attachment already, no special support required.
We have our hardware wired up this way. Zephyr firmware with Nordic Radio exposing HCI over USB. udev rules to call hciattach, custom bt stack to speak hci (and gatt etc)
And add support for Bluetooth 5.0?
Our custom stack has theoretical support. However we do not have any known working bluetooth 5.0 dongles, hence the request for a btmon. Its easy enough to replay those command parameters outside the linux stack from a custom stack and verify that the hardware does indeed support BT 5.0. We would love that to be the RTL dongle, we have that in hand and got pretty close with it in the past.
With that we can begin to investigate what issues are blocking and if they are software or hardware (and share those results back to the community).
Regardless of who builds support and which stack knowledge on working hardware is incredibly useful to any further development efforts (and this issue is easily findable on Google). If theres no hardware capable of BT Coded connection for example you should not expect BlueZ or Linux BT maintainers to prioritise support.
what do you mean one at a time?
We have not (yet) been successful in getting it to receive coded announcements when both PHYs are active (only when CODED is the only one active). Or to begin join over coded (this may be our test device). This has been a side project however (which is getting consideration for some more engineer time) so it might be something simple.
Its easy for us to blame the hardware at this point, however I'm certainly willing to entertain that we might not be not exercising HCI correctly etc. Or a HCI command need hooking and handling differently within Zephyr (as we have done a couple times already).
At some point we will update our sniffer dongle to one that supports coded sniffing (any suggestions?) and it will become more obvious probably. Also planning on getting a Xiaomi Mijia or one of the other devices to act as a known working BT 5 coded device incase the issue is with our android phone we are using as the announcing & slave device.
We are using a special order nRF52840 devkit with a LNA&PA however any devkit should work. There exists plenty on marketplaces like aliexpress.
fanoush
commented
10 months ago HCI from Nordic
AFAIK Nordic does not support HCI over USB or serial (or SPI) with nrf5x chips at all, typically it is standalone solution where the application runs on same CPU as the BLE stack (or in case of nrf5340 on separate application core) . Also it offers so called serialization for multi MCU solution which is similar to HCI but non standard. It is also used by their own nrfConnect software for linux/windows via their own pc-ble driver with so called connectivity firmware https://github.com/NordicSemiconductor/pc-ble-driver/ so it is completely separate from any OS BLE support (which may actually help with solving some use cases where the OS support is poor?) I'll check whether it supports CODED PHY at all.
nrf52 chips work with linux as HCI over usb or serial only in Zephyr with the hci sample applications https://docs.zephyrproject.org/latest/samples/bluetooth/hci_usb/README.html but that is opensource solution not supported by Nordic (?) Also it can only do BLE not classic bluetooth.
splitice
commented
10 months ago nrf52 chips work with linux as HCI over usb or serial only in Zephyr with the hci sample applications https://docs.zephyrproject.org/latest/samples/bluetooth/hci_usb/README.html but that is opensource solution not supported by Nordic (?) Also it can only do BLE not classic bluetooth.
Correct, BLE only. Mostly correct on the lack of direct Nordic support (not that you should ever rely on a hardware manufacturer for software support). The Zephyr HCI implementation is very small, its mostly just framing, flow control etc of the Nordic commands for the Radio. It still requires the Nordic Radio components which provide the stack (and therefore define many of the potential limitations).
You can get it to provide a decent HCI stack. We have done so. I do not know if BlueZ, noble or similar would find it compatible, its not something I've looked into.
Its been about a year since I touched our Dongle code / hardware or looked into CODED support. I might be incorrect but I think thats accurate.
fanoush
commented
10 months ago The LE Coded PHY uses 1Mbit PHY but payload is coded at 125kbps or 500kbps.
Interesting, I am not that familiar with it. If it is only about payload then it should work indeed, however the Nordic docs says even the packet preamble is different https://infocenter.nordicsemi.com/topic/ps_nrf52840/radio.html?cp=5_0_0_5_19_0#concept_hz4_cjl_4r "For MODE = Ble_LR125Kbit and MODE = Ble_LR500Kbit the PREAMBLE is 10 repetitions of 0x3C." so I am not sure the hardware could match it together with Ble_1Mbit mode which uses different preamble. All just my guesses, haven't tried it on such low level yet.
pvvx
commented
10 months ago You can get it to provide a decent HCI stack. We have done so. I do not know if BlueZ, noble or similar would find it compatible, its not something I've looked into.
But mostly people use Home Assistant, which is built on Bluez... And the situation with BLE in Linux has not changed since the release of Bluetooth v4.2. A decade has passed...
however the Nordic docs says even the packet preamble is different
The hardware features on the chips may vary, including hardware CRC packet checking...
Предварительное описание решения.
Для примера можно взять: Low-cost Realtek RTL8761 BT adapter
USB ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio
Сurrent version of Linux fw on RTL8761 supports BT5.1:
Для работы HA c LE Long Range в интеграции “Bluetooth” желательно установить последнюю версию bluez и добавить в файле /lib/systemd/system/bluetooth.service ExecStart=/usr/local/libexec/bluetooth/bluetoothd --experimental
Из-за неверной инициализации адаптеров BT5.+ в Bluez, перед запуском Home Assistant необходимо переключить BT адаптер на работу в режим Bluetoch 5.0: hcitool -i hci1 cmd 08 31 03 05 05 или во всех режимах PHY 1M/2M/Coded: hcitool -i hci1 cmd 08 31 03 07 07 Номер hciN - свой. Проверить переключение возможно в btmon (log btmon):
В итоге, в интеграции "BTHome" получаем успешный прием термометров со стандартной рекламой и работающих в LE Long Range:
Если адаптер будет работать неустойчиво, тогда HA может его переинициализировать и настройка на работу в Coded PHY (Long Range) собьется. Ожидать официальной поддержки в интеграции “Bluetooth” нет никакой возможности. Выбранный автором API “Bleak” не позволяет управлять PHY адаптера и не предвидится никакой поддержки BLUETOOTH SPECIFICATION Version 5.0 от 2016 года.
Проверить адаптер на совместимость возможно с помощью команд:
Установка вариантов PHY в btmgmt работает не совсем корректно (в некоторых вариантах имеются ошибки). Но и с помощью этой программы возможно установить необходимые PHY.
Для этого необходимо:
Вывести текущие установки PHY:
К вариантам 'Selected phys' добавить опции ‘LECODEDTX’ и ‘LECODEDRX’:
Для установки PHY через API в bluez смотреть /doc/mgmt-api.txt.
Или через hci_send_cmd(). Пример для Python (неполный и не совсем корректный):