Thanks for the feedback. I will go ahead and create an issue on github to describe the issue and show what I have tried so far. Thanks! Brian

#samples

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 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

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

Hi there, It looks like some of the modules are missing. Can you make sure you have run “west update” in the working tree? Carles

#samples

Hello, "Jukka Rissanen" <jukka.rissanen@...> wrote: For reference, there already exists a ticket for this feature: https://github.com/zephyrproject-rtos/zephyr/issues/2336 , so interested

#networking #samples

Thanks Marc, I have verified that and it is fine. As mentioned in the previous mails, I am suspecting on the changes that I have made in the file "zephyr/subsys/net/l2/ethernet/ethernet.c". Although,

#nrf52840 #samples

"Alberto Escolar Piedras (ALPI)" <ALPI@...> writes: You're right, of course. I looked at the output itself without seeing the "warning" prefix. This is building and running fine (apart from the

#samples #adc

On Linux the script zephyrproject/tools/ci-tools/scripts/check_compliance.py -c commit_range checks all that for you. I also got the script running on Windows too once with a couple hacks. Marc From:

#samples #microbit #robot