Hi Vinayak, My current need is to be able to change the power setting through a config variable, as I have done outside the zephyr system. I am investigating power-range compromises

Hi Vinayak, My current need is to be able to change the power setting through a config variable, as I have done outside the zephyr system. I am investigating power-range compromises

I'd like to put in a vote for changing the TX power at runtime. Our use case would be making the TX power less during advertisements and then increasing it once the connection is

Vikrant, Sure, I will send a PR for that one as soon as I can (tomorrow maybe). Regards, Vinayak

Hi Vinayak, As of now, I need build time configuration option to change Tx power. It will be great, if we could do it by editing prj.conf. Thank You !!

Hi Vikrant and Abderrezak, Please elaborate on your applications' use case for Tx power change. Do you want to use a build time custom Tx power setting or runtime dynamic update to Tx Power? As there

Hi All, I have the same issue. This is clearly an app variable imho. Thanks Abderrezak On 6/4/2018 9:45 AM, vikrant8051 wrote:

Hi all, I wanna use #NVS to save #BluetoothMesh Models states. As per current implementation, #BluetoothMesh stack is using #FCB for persistent storage. If I use #NVS (with default setting) along

Hi, If anyone want to edit tx power of #nRF52840_PDK, then have to edit two file .. 1) $zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c: L5882 2) $zephyr/subsys/bluetooth/controller/ll_sw/ll_test.c:

Hi Daniele, Thanks for the suggested change. Instead of sending a patch through the mailing list, could you open a pull request? It makes it simpler to discuss the change and it will be included

Hello everyone, Playing around the permanent storage of bluetooth settings, I think I found an issue in the settings subsystem. Enabling the CONFIG_SETTINGS_FS option If I restart my device after the

Hi Andy, commit 43553da9b2bb9e537185695899fb5184c3b17ebe Author: Andy Ross <andrew.j.ross@...> Date: Thu May 31 11:13:49 2018 -0700 kernel/sched: Fix preemption logic The

Vikrant8051 <vikrant8051@...> wrote: I was pointed to this on IRC. The symptom you've got there sounds a lot like a scheduler mistake that got fixed yesterday, where ostensibly-pended threads

Hi Léonard Sweet. I did the port to the Adafruit Feather M0 Basic Proto. Let me know if I can help with the port for the SODAQ board. Perhaps a simple solution could be to just add a sample

Hi, I've created new PR https://github.com/zephyrproject-rtos/zephyr/pull/8101. It is basically modified version of samples/bluetooth/mesh as well as inspired from

Hi, I commented line no. 3318 of subsys/bluetooth/host/hci_core.c i.e. // BT_ASSERT(buf); And after that everything is working perfectly normal. Thanks !!

+ Krzysztof +Piotr From:<devel@...> on behalf of Ryan Erickson <ryan.erickson@...> Date: Thursday, 31 May 2018 at 23:58 To: "devel@..." <devel@...> Subject: [Zephyr-devel] Serial Wire Output (SWO)

Hi Carles, Thanks a lot for the pointers! After digging around a bit, I found a hack that allows to block the current thread until an ACK was received: * I reduced CONFIG_BT_ATT_TX_MAX to 1 * After

I had a look around and couldn't find any support for SWO? Is it supported? If not, are there plans to add SWO console output similar to how you can use RTT instead of the UART?

Hi Vikrant, OK in that case I will try to run the onoff mesh app to see if I can reproduce at all. Thanks for the help in debugging this. Carles From: users@... <users@...>On Behalf Of