About esb_ptx_ble & esb_prx_ble.

[Leo Mo]

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?

[Kenneth]

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

[Leo Mo]

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?

CONFIG_CONN_INTERVAL_MIN=990  //ms

CONFIG_CONN_INTERVAL_MAX=1010

CONFIG_CONN_LATENCY=6

Is it phase entanglement? Or is it another question? How can I solve it?

[Kenneth]

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 

[Leo Mo]

It is in a BLE connection.

CONFIG_CONN_INTERVAL_MIN=990  //ms

CONFIG_CONN_INTERVAL_MAX=1010

CONFIG_CONN_LATENCY=6

[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

[Leo Mo]

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

[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

[Leo Mo]

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

[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

[Leo Mo]

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

[AHaug]

Hi Leo,

Kenneth is currently on PTO. I will follow up this case and get you an answer to the latest question, but I will need a little while to get up to speed here.

I'll get back to you before the weekend.

Kind regards,
Andreas

[Leo Mo]

Hello AHaug,

Thanks!
Another question is why sending 8 bytes, 16 bytes, and 32 bytes takes about the same amount of time? Is it time-consuming to prepare before sending? 

config ESB_MPSL_TIMESLOT

    bool "ESB on MPSL Timeslot [EXPERIMENTAL]"

    select EXPERIMENTAL

    depends on MPSL

    depends on !ESB_NEVER_DISABLE_TX

    depends on !SOC_SERIES_NRF53

    help

      This option configures the ESB to use the MPSL Timeslot API as middleman in radio access.

      It allows multiple protocols to be used concurrently. Using the Timeslot API can increase

      number of retransmissions, reduce ESB packets delivery rate, and cause the delay of

      retransmissions to vary.

config ESB_NEVER_DISABLE_TX

    select EXPERIMENTAL

    bool "Never disable radio transmission stage"

    help

      This option changes the radio behavior so that the

      transmitter remains IDLE between transmissions instead of being disabled.

      This is applicable only when the packet is not acknowledged. Otherwise,

      the radio emitter needs to be turned off to enable the radio receiver.

      This reduces delay between consecutive transmissions but consumes more energy.

ESB_MPSL_TIMESLOT and ESB_NEVER_DISABLE_TX cannot be set to y at the same time.
Is there any way to reduce the preparation time before launch.

while (1) {
        
	    err = esb_initialize();
	    if (err) {
		    LOG_ERR("ESB initialization failed, err %d", err);
		    return 0;
	    }


        tx_payload.length = 32;
        for (int i = 0; i < 3; i++) {
               tx_count += !esb_write_payload(&tx_payload);
        }
        while (!esb_is_idle());
        k_sleep(K_MSEC(100));
        esb_disable();
        seq_num++;
        tx_payload.data[6] = seq_num & 0xFF;
        tx_payload.data[5] = (seq_num >> 8) & 0x7F;
        tx_count = 0;

        k_sleep(K_MSEC(1000));
    }