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

Hi Tommy, It’s always the responsibility of the host to set the random address. When you do a combined build of Zephyr (both controller and host) the FICR address will be used. However, if you’re runn

Hi Lucas, (added zephyr-devel back to CC since this info may benefit others as well) No, that’s normal. It means you used the configuration client API without requesting it to wait for the response me

#bluetoothmesh #zephyrbluetoothmesh

Hi Lucas, It looks like you’ve enabled CONFIG_BT_SETTINGS, but are not calling settings_load() in your app. It might explain the behaviour you’re seeing, since you’re effectively leaving the stack par

#bluetoothmesh #zephyrbluetoothmesh