Hallo Zephyr community, Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex. I also see that the random address remains the same af

#nrf52832

Hi Carles, Thanks for the feedback. It seems the Qt QLowerEnergyController object selects the first valid address different from the zero address for addressing the HCI controller/adapter. In my case

#nrf52832

Hi Carles, Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727) although I think different parties are to blame, I'm still not sure who is doi

#nrf52832

Hi Carles, Thanks a lot, I hope soon a proper answer can be given, nevertheless progress is made and it just to know if this is normal behaviour. Best regards, Frank

#nrf52832

Hi there, For me using the Nordic's nRFConnect smartphone app is very useful in the debug process. My experience so far is when the public address of the HCI controller is set as 00:00:00:00:00:00 the

#nrf52832

Hi, For advertising I don't use the hcitool cmd, however I think a fast and easy check can also be done by using either the bluetootctl or the btmgmt tool. So after executing the bluetoothctl you can

#nrf52832

Hi, No problem. Good to hear your issue is solved. Using the zero address as public address is not really an issue however nobody so far can explain if it is normal that the BlueZ stack uses the "rand

#nrf52832

Hi icephyr, I think 2 things are mixed up here in this topic, my problem with the ZERO address as public address was not related to advertising but rather why the Bluez takes the random address as add

#nrf52832

Hi Jamie, Thanks for your explanation. However for me it remains a riddle (and probably a bug), why the BlueZ implementation selects the random address as HCI adapter address when the public address i

#nrf52832

Hi Community, Carles, Without having looking into the details for the HCI_UART implementation when using Zephyr RTOS as SW platform for implementing the BLE controller on Nordic HW, the SoftDevice is

Hi Carles, Great! Thanks for your confirmation on my observations regarding the Nordic SoftDevice and the Zephyr implementation. I think for a BLE host (central role) implementation we will forward fo

Hi Carles, In the document: https://www.zephyrproject.org/building-a-qualified-ble-controller-with-zephyr-os-1-9/ at the end this is mentioned: “Note that Nordic’s qualification will only cover the BL

Hi Carles, Probably all is here for the qualification process, correct? : https://www.bluetooth.com/develop-with-bluetooth/qualification-listing Just wondering do we have extra concerns should we rely

Hi Luiz Augusto von Dentz, Thank you very much for your reply. This should give me sufficient direction to go further. The idea for our BLE central oriented platform (two boards solution) is to run on

Hi icephyr, I'm far from a Zephyr BLE expert, but I had this process in mind what could be a solution. As Nordic doesn't store a public BLE device address in flash I would try to implement the followi

#nrf52832

Sorry Joe, I will no longer this. Thanks for reporting it. Frank

#nrf52832

Hi Akash, Maybe have also a look at this example: https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/README.html Best regards, Frank

#nrf52832 #zephyrbluetoothmesh

Hi Zephyr community, bluetooth Mesh fans, I played around with the Zephyr Mesh OnOff applic running on a Nordic nRF52 board. https://docs.zephyrproject.org/1.13.0/samples/boards/nrf52/mesh/onoff-app/R

Hi all, Vikrant, Thanks for your feedback. However the issue if you can call it an issue, is that the BL Mesh OnOff sample applic sets by default a minimum 1 second delay before publishing the state o

Hi Akash, I think you better have a look at these links (as well): https://www.zephyrproject.org/zephyr-project-announces-openthread-first-thread-protocol-implementation-integrate-zephyr-rtos/ https:/