Hi, Difference between packet number 85 and 87 is 29969 us, and Between packet number 87 and 88 is 24963. This is 20 ms +/- 10 ms random delay as per BT spec. There are other advertisers in your log.

Hi Paul, I have some related fixes here, hope you can re-run your tests. https://github.com/zephyrproject-rtos/zephyr/pull/6149 Summary, the improvement to continuous scan had regression, introducing

1. Correction, values in UICR are at fixed location, changing them is not needed on every power up of the board.That said, after a change, a power cycle is need for h/w to load the new values. And yes

Hi Anupam, Your changes to list out the PHY commands as supported is welcome, please send a PR to upstream repo. Nordic chip do not own any Bluetooth device address space, no public addresses and the

Hi Paul, I do not have visibility to your code, in terms of how you are starting the advertisements, if you stop and start them too close you will see the behaviour as you observed. As I cannot infer

Hope you are doing it “only once per board’s life time” else you could be degrading the flash. Hence, my advice is to use nrfjprog to make the change "only once" per each board or use the design in so

1. Advertising Interval too short and out of spec: Sometimes the interval between 2 transmits of the Friend Poll is under 20ms (even tho it is set to 20ms). I measured intervals of just 7ms. [vich] Ar

Hi Vikrant and Neves, I have submitted a PR that will correctly “disable” Coded PHY support in nRF52840, in turn avoiding the PPI channels 14 to 19 and hence usable by pwm_nrf5_sw.c implementation. Us

Your main.c uses pwm_nrf5_sw.c driver which has conflict with BT features on nRF52840... I do not see use of NRF_PWM0 in you main.c, of course, yes your code in the devzone does, hope you get some hel

Hi Vikrant, As i said, there is possible overlap of PPIs with BT Controller. PPI channel 16 and 17 overlap with Code PHY feature in nRF52840. I will try to send a PR wherein you could (correctly) disa

Hi Vikrant, I have run the upstream fade_led sample on nrf52840-PDK, I see no regression, the brightness changes every second (up and then down so on). I advice you to debug your implementation as I h

Hi Vikrant, Please try the PWM without the BT Controller included. There could be some PWM regression due to changes in controller implementation. That said the nrf5_sw driver is software variant desi

Hi Paul, FYI. The below two PRs should be merged soon into upstream master, could you please re-run your analysis and let me know if there has been any improvement? Improved radio utilization in conti

Every event has a 1.5ms preparation/idling, hence you are right 1.5ms of 10ms or 15% missed adv reports. The reason for 10ms was to reduce the radio idling when advertising event would overlap in time

Its: fs_file_t my_zfp; // no * please; and fs_open(&my_zfp,"mesh.prv"); // & please J That said, I am not expert on FS! -Vinayak

Hi Paul, There is no support for P1 yet in the gpio_nrf5.c implementation. Where do you get the idea of P2? There is only P0.0 to P0.31 and P1.0 to P1.15 in nRF52840. And only P0 in nRF52832. If you a

Hi Erwan, 1. IPSP support requires “host” L2CAP CoC feature that was added in BT 4.2. A Controller supporting BT 4.0 shall suffice, as HOST will do L2CAP fragmentation before sending the packets to HC

Hi Paul, I ran a continuous scanning on my working copy just now, with Debug pins enabled, and see no reason why the scan window should be varying. Please let me know the application you are using and

Hi Prasanth, My bad. Yes, Zephyr OS on CC2650 SoC is supported with GPIO. But the open source BLE “controller” implementation currently only supports Nordic SoCs. So, the answer is, unless a controlle

Hi Prasanth, 1. ARM Cortex M0 architecture is fully supported in Zephyr. Regarding the Dialog SOC, I don’t see existing support. You can contribute by starting here http://docs.zephyrproject.org/porti