Hello, I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch. Everything works fine now except for reading RSSI on connected device. HCI commands were

Novello, The address space at the moment is fixed in Zephyr. A feature to fuzz the initial stack pointer is available (CONFIG_STACK_POINTER_RANDOM) to provide some unpredictability at runtime, but

Hi all, We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig

Hi all, Tomorrow we will have another API discussion call. Details on how to

Hi Johan, Awesome, thanks for the info !!

Hi Vikrant, There has been discussion of doing a qualification listing (perhaps two, one for the core host stack and another for Mesh) for LTS releases under the name of the Linux Foundation, but as

Hello and happy Friday, This is the 4 May 2018 newsletter tracking the latest Zephyr development merged into the mainline tree on GitHub. An HTML version is available

HI Aaron, This PDF may help developers who want to go with Zephyr #BluetoothMesh. https://www.zephyrproject.org/wp-content/uploads/sites/38/2018/03/openiot_zephyr_lts_what_and_why.pdf But following

Hi, We all look forward that the zephyr project bluetooth mesh can be used on a real project. Before that, we want to know those question's answer. Thanks. vikrant8051 <vikrant8051@...>

Hi, What will be status of #BluetoothMesh in #LTS v.1.12.0 release ? Will it be released as #Qualified stack ? As of now, we can't save Provisioning, Configuration & other real time data (eg. message

Hi, It was bug from my side & I've resolved it. Now everything is working as expected. Excuse me for that !!

Hi to all, cd $(zephyr_base) git fetch origin pull/7283/head:BlueZMeshctl git checkout BlueZMeshctl I execute above commands & re-build samples/bluetooth/mesh & try to provision it using BlueZ 5.49

Hi all, I am trying to test an nRF52840 as a USB HCI using the Zephyr hci_usb sample project. I'm running into an issue in which devices I attempt to connect to will disconnect themselves after about

Hi Steve, Thanks for testing. Could you also please add some sort of "tested to be working" comment in the PR to help it get merged? It'd indeed be interesting for someone to analyze the difference.

Hi Johan, Works for me. Provisioning completes on samples/bluetooth/mesh and connects for configuration. The identity connection had previously failed. It's curious that the SILabs provisioner

Hi Steve, That's a good catch. I'm sorry for not realizing it earlier. I've uploaded an untested pull request that attempts to fix this. Could you try it

Hi, I had a chance to look at this further. More at the bottom. It doesn't appear that bt_mesh_proxy_identity_enable() gets called in prov.c:proxy_data(). The earlier call to bt_mesh_provision()

Hi Roman, you need to update boards pinmux.c file to add the I2C pins. You could check olimexino_stm32 board's pinmux file for

MCU is this https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1 Using this board

Describe better your environment. Which board (and no MCU) are you using? Based on the http://docs.zephyrproject.org/boards/arm/nucleo_f103rb/doc/nucleof103rb.html it seems that the i2c_1 that it