The ZEBRA RFC (see RFC: https://github.com/zephyrproject-rtos/zephyr/issues/23465) is a feature proposal for a simple way to add secure authentication between two Bluetooth devices. ZEBRA is not part

#ble

Yes previously I posted same issue, but iam not creating any threads in my application

#ble #nrf52840

But i'm not using any threads in my application, did you mean ble created threads

#ble #nrf52840

You can use nRF sniffer found here: https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE And check the wireshark logs for advertising interval and channels. If

#ble #hci #nrf52480 #samples #uart

Hi Vinayak, Thank you for the support. I have created the GH issue for the same https://github.com/zephyrproject-rtos/zephyr/issues/23319 Thanks, Mayank

#ble #hci #nrf52480 #uart

Hi Narendar, Please create a github bug report, with details on how to build your application and reproduce the issue. You may share a branch in the GH issue if that is faster for me or others to repr

#ble #nrf52840 #uart

Hi Johan, Should i go with the Hardware flow control as enable to solve the buffer flow issue ? Not using HWFC could have any other adverse effect? As my current implementation is based on flow contro

#uart #samples #ble #hci #nrf52480

In version 1.14.1, there appears to be a race condition when updating an indication value. It results in a BUS FAULT, which occurs because a pointer becomes null. Here are the Zephyr ATT print message

#ble #nrf52480

OK I was create a github issue. thank you.

#ble

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 Mayank, I am surprised to say this doesn't appear to be covered in the MCUboot documentation. David, did I miss it somewhere? Mayank: you need at least three pins connecting the i.MX and nRF chips:

#ble #hci #nrf52480 #uart

Hi Carles, Thanks for the tip. I would be really surprised that I already have a stack issue, as the application is still very simple... Nevertheless it can't harm to have this option enabled. Br, Fra

#ble #nrf52

Hi all, Solved... It looks like when BT_GATT_CCC is set in the service MACRO define, it takes not 1 but 2 indices to advance as also there is automatically a descriptor char added if you need to acces

#ble

Hi Mayank: I had a similar requirement, also without a button on the same Nordic chip. I simply copied this file into my project, and called smp_svr_init() from my main() after bluetooth was up and ru

#ble #hci #nrf52480 #uart

Hi Q1 – no, this mens that higher part of BLE stack runs on HCI client which has no access to nRF52840 flash at all. Q2 – mcuboot serial recovery or your proprietary protocol which can share common ua

#hci #nrf52480 #ble #uart #samples

In the current implementation, BLE HCI_EVENT is processed on a dedicated RX_THREAD and called back in the same context. I want to handle HCI_EVENT (eg advvertise_report) directly in my thread. Is ther

#hci #nrf52840 #ble

Thanks Adam, I have upgraded zephyr to latest version (2.1.0) using west update. Now with the configuration of my application as well as mcuboot, i reached at the stage where i can upload the signed a

#ble #bluetoothmesh #nrf52840 #uart

Thanks Jamie, Here, I would like to point out the exact setup that i'm trying DFU on. I have One custom board which has imx6ul processor, I'm having one BLE controller on board which is connected to p

#nrf52840 #ble #bluetoothmesh

Hello! I have had some progress so far. I tried the same configuration setup on the NRF52-PCA10040 dev kit with the HCI-UART sample and everything seems to work as expected. Although I do not necessar

#ble #hci #nrf52480

In my application, I need to use the nrf52840 for both BLE (as the controller) and ShockBurst. Specifically, it's the nrf52840 on the nrf9160 if it matters. I'm using the zephyr BLE stack and things a

#shockburst #ble #nrf52840