Hi Andreas, No, I don’t think that combination would make sense. One option I forgot to mention is the bt_mesh_suspend() & bt_mesh_resume() APIs. You could try suspending mesh operations (advertising

#bluetoothmesh #bluetooth

Hi Vivek, As far as I know, the BT_HCI_MESH_EXT option is for HCI vendor extensions which haven’t been implemented yet. However, BlueZ doesn’t require or even support them, so this should be a non-iss

Hi Andreas, There’s nothing in the standard that prohibits it, but it will reduce the efficiency of the mesh network. The mesh advertising bearer is designed in such a way that assumes the nodes to be

#bluetoothmesh #bluetooth

Hi, We are excited to announce the release of Zephyr 2.2.1, the first maintenance release of Zephyr 2.2. This is primarily a bug fix release, concentrating on security vulnerabilities and issues affec

Hi, We are excited to announce the release of Zephyr RTOS version 2.2.0! Major enhancements with this release include (but are not limited to): * We added initial support for 64-bit ARMv8-A architectu

Hi Zephyr developers, We have now tagged Zephyr 2.2.0-rc3, i.e. we’re getting close to the final release. We’re currently at 15 medium priority bugs and no high priority bugs, so the release criteria

Hi Zephyr developers, We have now tagged the second release candidate for Zephyr 2.2: 2.2.0-rc2. We’re currently at 0 high priority bugs and 21 medium priority bugs. This is already close to the requi

Hi Mayank, You might get lucky with disabling hardware flow control, however this standard HCI transport officially requires it (see Vol 4, Part A section 3 in Bluetooth Core Specification 5.2). Yes,

#uart #samples #ble #hci #nrf52480

Hi Zephyr developers, The the first Zephyr 2.2 release candidate (v2.2.0-rc1) has been tagged. All required features scheduled for the 2.2 release are now merged into master. As of now we are in the s

Hi, I’d like to remind everyone of the current release schedule for the next Zephyr release, i.e. version 2.2: - The feature merge window is open for roughly two more weeks, closing on February 7th. A

Hi Ryan, What do you mean by a “Host application”? A Bluetooth host application? Using what APIs? That’s a bit confusing. hci_uart is for cases where the Bluetooth controller and host are on different

Hi, The samples/boards/nrf52 folder was recently renamed to samples/boards/nrf https://docs.zephyrproject.org/latest/samples/boards/nrf/mesh/onoff-app/README.html Johan

Hi Venkatesh, hciconfig uses a legacy ioctl kernel interface which is only able to retrieve the public address of a controller. nRF controllers do not come with any public address by default, which is

#hci #ble #nrf52 #nrf52840

Hi Rahul, There’s a preliminary pull request to add this feature, but it’s not yet merged upstream: https://github.com/zephyrproject-rtos/zephyr/pull/17729 Were you asking for provisioner support as a

Hi, There’s also a log_strdup() API to deal with this issue. Johan

Hi Robert, You could try using BT_LE_ADV_OPT_ONE_TIME with bt_le_adv_start(). That should ensure that the stack doesn’t automatically restart advertising after a disconnection event. Johan

#ble

Hi Paul, All application-level messaging with mesh is always in the context of models. I’d suggest familiarising yourself with the Mesh Model Specification to see if any of the standard models suits y

#bluetoothmesh

Hi Kai, The API to get information on a connection is bt_conn_get_info(). Out of the parameters you mentioned you can get at least get the interval, however DLE or PHY information is not currently exp

Hi Billy, That depends on your application and the source of the faults. All the stack requires is for you to keep track of the fault history. You could do that e.g. with a simple u8_t array like the

#bluetoothmesh #zephyrbluetoothmesh

Hi, The Zephyr mesh health server leaves fault registration up to the application, however you do need to register a bt_mesh_health_srv_cb struct which includes callbacks for retrieving the faults, cl

#bluetoothmesh #zephyrbluetoothmesh