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?

[Leo Mo]

Hi AHaug,

Is there any new progress on this issue?

Kind regards,
Leo Mo

[AHaug]

Hi Leo,

The action is on your end.See

AHaug said:

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.

and

AHaug said:

• 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

[Leo Mo]

Hi AHaug,

PTX works normally.

After running for 7-10 days, some PRX devices may experience a phenomenon where they cannot receive data for several consecutive hours. Their power supply is a regulated power supply.

PRX has an RX window of 8ms and an RX interval of 4 seconds. Each cycle calls esb_initialize() and esb_disable() to conserve power.

Kind regards，

Leo

[AHaug]

Lets take a step back to the original question.

You mention that you want to cherrypick a feature from NCS 3.3.0-preview3 into NCS 2.9.0. What stops you from migrating the project to 3.3.0? I know that Kenneth has said that he believes it is technically possible to do this, but I need to understand more about your project and what this feature is. Can you link to the specific PR with the feature you want to add?

There might be an issue for the concurrent BLE + ESB in 3.3.0 (i.e the api you link to), which requires a different nrfxlib than the one used in 2.9.0. What is the version of nrfxlib in the 2.9.0 version of your project? 

I'm not sure how you've added the features you're asking for from ESB/ MPSL to your 2.9.0 project. Could you explain this?

Kind regards,
Andreas

[Leo Mo]

Hi AHaug,

Thank you very much!

I have completely abandoned the ESB+MPSL solution (my own code) in nRF Connect SDK v2.9.0.

The solution I'm currently using is nRF Connect SDK v3.30's esb_ptx_ble (8dBm, 1Mbps, BLE peripheral) & esb_prx_ble (BLE peripheral).

 const struct esb_config config = {
        .protocol           = ESB_PROTOCOL_ESB_DPL,
        .mode               = APP_ESB_RX_MODE ? ESB_MODE_PRX : ESB_MODE_PTX,
        .event_handler      = event_handler,
        .bitrate            = ESB_BITRATE_1MBPS,
        .crc                = ESB_CRC_16BIT,
        .tx_output_power    = ESB_TX_POWER_8DBM,
        .retransmit_delay   = 600,
        .retransmit_count   = 0,
        .tx_mode            = ESB_TXMODE_AUTO,
        .payload_length     = CONFIG_ESB_MAX_PAYLOAD_LENGTH,
        .selective_auto_ack = true,
        .use_fast_ramp_up = IS_ENABLED(CONFIG_ESB_FAST_SWITCHING)
    };

	err = esb_init(&config);

I have completely abandoned the ESB+MPSL solution (my own code) in nRF Connect SDK v2.9.0.

The solution I'm currently using is nRF Connect SDK v3.30's esb_ptx_ble (8dBm, 1Mbps, BLE peripheral) & esb_prx_ble (BLE peripheral).

The latest test setup is: 1 esb_ptx_ble, 15 esb_prx_ble, all esb_prx_ble & esb_prx_ble peripherals connected to a single BLE central. PTX broadcasts 3 packets every 5-7ms; the PRX RX window is 8ms, the RX interval is 4000ms, and each 30-second interval is considered a receive cycle (approximately 7 RX window openings). Receiving one packet within a cycle is considered a successful reception. All RX devices are powered by the same regulated power supply (3.3V, 1A), and the devices are arranged in a star topology. The TX and RX devices are 40 meters apart, indoors, with no obstructions.

For low power consumption, `esb_disable` and `esb_init` are called every RX cycle (8ms + 4000ms).

An Arduino (connected to the computer via USB) is used to monitor whether an IO operation on the RX device flips within 30 seconds (a flip indicates at least one data packet has been received). After 7-10 days of operation, 1-2 RX devices may experience periods of 5-10 hours without receiving data.

Kind regards，
Leo Mo

[Edvin]

Hello Leo,

Andreas is currently tidyign up, and will be out of office for a couple of weeks, so he asked if I could look into your ticket. 

One thing I struggle to understand:

Leo Mo said:

I have completely abandoned the ESB+MPSL solution (my own code) in nRF Connect SDK v2.9.0.

The solution I'm currently using is nRF Connect SDK v3.30's esb_ptx_ble

Does this mean you are using NCS (nRF Connect SDK) v3.3.0, or are you using v3.3.0's ESB inside your NCS v2.9.0?

Leo Mo said:

An Arduino (connected to the computer via USB) is used to monitor whether an IO operation on the RX device flips within 30 seconds (a flip indicates at least one data packet has been received). After 7-10 days of operation, 1-2 RX devices may experience periods of 5-10 hours without receiving data.

Perhaps I just hasn't read the entire post properly, but you have got your setup working, but after a while, some devices experience a long time when they do not receive any messages (5-10 hours), and then they start picking up messages again? Or do you reset the devices, and then they start picking up messages again? Or what do you observe?

Best regards,

Edvin