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?
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 Kenneth,
Now the RX interval is fixed at 7.3 seconds and the RX window is 15 milliseconds. In theory, there are 4 chances to receive data in 30 seconds, but now the phenomenon is that some devices cannot receive data for tens of minutes in a row, which is very strange. I am adding debugging IO to monitor where problems occur.
Leo Mo
Hi Leo,
You can try to reset the radio using the POWER register, write 0 then 1, and then re-configure the radio:
https://docs.nordicsemi.com/r/bundle/ps_nrf52840/page/radio.html?section=register.POWER
Kenneth
Hi Leo,
You can try to reset the radio using the POWER register, write 0 then 1, and then re-configure the radio:
https://docs.nordicsemi.com/r/bundle/ps_nrf52840/page/radio.html?section=register.POWER
Kenneth
Hi Kenneth，
Thanks！
Yes, I can do that, but the key point is when to re-configure the radio, because TX devices only broadcasts data when a critical event occurs, so RX devices can only re-configure the radio when a error code occurs. Currently, I will reset MCU when an error code occurs.
By the way, why does the ESB of nRF Connect SDK v3.3 no longer have the options of 125Kbits and 250Kbits?
Leo Mo
