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]

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));
    }

[AHaug]

Hi Leo,

Leo Mo said:

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? 

There is a payload discrepancy, it is just very small.

Looking at your snippet, this stems from your code snippet mainly. As you can see in the image, the period where you do TX differs from the 3 images, but the sleep time in between each operation is so large compared to the Tx window that it is hard to notice. Measure this window instead of the pause to see the actual difference of the TX time.

 

Roughly summarized what each cycle is

1. A rise to a ~3 to 4 mA plateau that sits there for a while.
2. Two short spikes up to ~16 mA (the actual radio TX).
3. Back down to near zero.

The payload is the only part of the transaction that scales with size.

• On-air payload at 2 Mbit/s: 8 B ≈ 32 µs, 16 B ≈ 64 µs, 32 B ≈ 128 µs. Which is very small in the almost 2ms timescale of the selection view
• Fixed per-packet cost that doesn't change with size: TX ramp-up (~40 µs fast, ~130 µs legacy), preamble + address + PCF + CRC (~35 to 45 µs on air), and with ACK enabled the turnaround to RX to catch the ack.

The time between the packs you queue up is governed by esb_config.retransmit_delay, not by payload length. In the NCS samples that is typically ~600 µs. Three packets at that spacing is your largest contributor to on-air time, and it's identical whether each is 8 or 32 bytes.

Is this test set up to do initialization every time before each pack? If this is not a test case, then the following might improve the time used for preparation in between each burst.

• Move esb_initialize() out of the loop. Re-initializing every iteration reconfigures the radio and can force an HFCLK cold start. The initialization is the plateau you see in between each TX
• Don't esb_disable() between bursts unless you need the radio released, since disabling can drop HFCLK and you re-pay the crystal ramp next time.

Kind regards,
Andreas