Can I copy the ESB code from SDK v3.3.0-preview3 into SDK v2.9.0, and then get the functionality in esb_ptx_ble & esb_prx_ble?
Is there any way to achieve it quickly?
Can I copy the ESB code from SDK v3.3.0-preview3 into SDK v2.9.0, and then get the functionality in esb_ptx_ble & esb_prx_ble?
Is there any way to achieve it quickly?
Hello,
Not sure I understand what problem you are trying to solve here, there should be ESB example projects for the nRF52840 in both the nRF Connect SDK releases you are referring to.
Can I copy the ESB code from SDK v3.3.0-preview3 into SDK v2.9.0, and then get the functionality in esb_ptx_ble & esb_prx_ble?
There may be some api changes, but for most part I would expect it should be pretty straight forward possible yes.
Kenneth
Hello,
Using nRF Connect SDK v3.3.0, one device runs esb_ptx_ble and broadcasts 2 packets of data every 5-10ms, with 15 devices running esb_prx_ble，esb rx interval 7300ms，rx window 15ms， 30 seconds is a receiving cycle, and failure to receive a packet of data within the cycle is considered a failure; After running 15 devices for a few days, occasionally one device experiences dozens of consecutive cycles without receiving data. Why is that?
Hello,
For the device that occasionally experience dozens of consecutive cycles without receiving data, is the device in a BLE connection or is it advertising at the time? What is the connection or advertisement interval at the time?
Kenneth
I don't have any good reason why this occurs no.
What you can try is to measure the current consumption using a Nordic PPK2, and also toggle some gpios in your application (one pin when OK, and one pin when fail), for instance when you are actively in ESB RX mode, and check if you can see based on the current consumption if it may be that the application is doing something else at the same time as you should be receiving based on the current consumption when you fail to receive. The Nordic PPK2 can measure current and monitor up to 8 digital pins at the same time.
Kenneth
Hi,
Thank you very much！
Is it possible that this is caused by the cumulative error of the low-speed crystal oscillator (20ppm)?
Leo Mo
Hi Leo,
I assume you have some algorithm that adjust wakeup interval to ensure that the expected packet is received in the middle of the wakeup period. But if the wakeup window is 15ms, I would expect you should always be able to receive a packet that is transmitted every 5-10ms even without any adjustment to the wakeup interval.
Kenneth
Hi Leo,
I assume you have some algorithm that adjust wakeup interval to ensure that the expected packet is received in the middle of the wakeup period. But if the wakeup window is 15ms, I would expect you should always be able to receive a packet that is transmitted every 5-10ms even without any adjustment to the wakeup interval.
Kenneth
