ESB "Hiccup"

[gSook]

I am currently working on a project in which I want to transmit audio wirelessly from one nRF chip to another. Currently I am using the nRF Dongle to act as the transmitter and a nRF-DK board as the receiver. I have finally gotten them to talk to each other through ESB, and the transmitter is currently sending a digital sine wave table out to the receiver which is then using SPI to interface with an external DAC. The problem lies in these "hiccups" that occur periodically, and while the frequency of the wave is something I can control, I can't seem to get rid of these hiccups. I am new to the Nordic development environment and I don't have much experience in the ESB protocol, and so I'm not sure if it's a hardware limitation, an acknowledgement issue, or something that I've overlooked in my code. At some point, the transmission will live in an SAADC callback function. That version works in terms of the signal path, but is experiencing the same problem that is outlined here. The problem is shown below, and here is my initialization of ESB, along with the transmission. Any help is greatly appreciated!

uint32_t esb_init( void )
{
    uint32_t err_code;
    uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};
    uint8_t base_addr_1[4] = {0xC2, 0xC2, 0xC2, 0xC2};
    uint8_t addr_prefix[8] = {0xE7, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8 };

    nrf_esb_config_t nrf_esb_config         = NRF_ESB_DEFAULT_CONFIG;
    nrf_esb_config.protocol                 = NRF_ESB_PROTOCOL_ESB_DPL;
    nrf_esb_config.retransmit_delay         = 100;
    nrf_esb_config.bitrate                  = NRF_ESB_BITRATE_2MBPS;
    nrf_esb_config.event_handler            = nrf_esb_event_handler;
    nrf_esb_config.mode                     = NRF_ESB_MODE_PTX;
    nrf_esb_config.selective_auto_ack       = true;
    nrf_esb_config.payload_length           = 2;
    nrf_esb_config.retransmit_count         = 1;

    err_code = nrf_esb_init(&nrf_esb_config);

    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_0(base_addr_0);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_1(base_addr_1);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_prefixes(addr_prefix, NRF_ESB_PIPE_COUNT);
    VERIFY_SUCCESS(err_code);

    return err_code;
}

int i = 0;

    while (true)
    {
        tx_payload.data[0] = SineWave[i] & 0xFF;
        tx_payload.data[1] = SineWave[i] >> 8;
        tx_payload.noack = true;
        nrf_esb_write_payload(&tx_payload);

        i++;

        if (i >= 80)
        {
            i = 0;
        }

        nrf_delay_ms(50);
    }

 

[ovrebekk]

Hi 

As a general rule I would suggest using longer packets, and a higher number of retransmits, to ensure more efficient and reliable communication. 

Still, if you are only sending a packet every 50ms, and experiencing regular repeated interruptions, then it points to a more critical issue. 

Are you logging the ESB callbacks on the TX side to see if you are receiving TX failed interrupts or not?

Do you have any interrupts in the system running at the highest priority, other than the ESB library?
The ESB library is not designed to allow other interrupt at priority 0, and unfortunately this is the default priority if you don't change it to something else. 

Could you try to add a sequence counter to the ESB payload? 
This could be as simple as an 8-bit counter that you increment for every packet. 

Then it is very easy to spot reception issues on the RX side, such as dropped or repeated packets. 

Best regards
Torbjørn

[gSook]

Thank you for your quick response! 

I have tried to initialize the logger, but for some reason, I cannot seem to get it working on this project (only in other project files). I have tried adding a sample counter to the payload, but since I cannot print it out to the log, I cannot see the sample number in real time. 

For the transmitter, is it possible to use the log even though it is just the nRF Dongle? I figured I would only be able to use it on the DK board for the reception side. 

On the reception side, currently the SPI interrupt priority is at 0, and the ESB is at default, so I will go ahead and change that. 

[ovrebekk]

Hi 

Any chance you could send me your code so I can have a look at it? 

If you do please just zip the project folder, including project and source files (you might want to remove temporary build files though). 

Then I can take a look at it here and try to figure out why logging isn't working, and also if I can spot any other issues that could affect reliability. 

If you don't want to share your code in a public case just let me know, and I will make the case private. 

I would also need to know which SDK version you are using. 

Best regards
Torbjørn

[gSook]

That is very appreciated thank you so much!

I am using version 17.1.0 of the SDK. 

Here is the zipped project file:4174.ses.zip

[ovrebekk]

Hi

The project files alone doesn't help me much, I would also need the source files (main.c for instance). Could you include this as well?

Best regards
Torbjørn

[gSook]

I actually got the transmission to work properly! I am inputting a full swing sine wave (1.65 V DC offset with a 1.65 V amplitude) on the transmitter side and receiving it on the other end (again sending the data through SPI to an external DAC). The new problem I am experiencing is not the repeated interruptions, but the speed of the output wave. Once the input wave goes past around 3 Hz, it appears very digitized on the output. Right now my ADC is sampling every millisecond. If you have any suggestions that would be appreciated!

[ovrebekk]

Hi

It sounds odd that more than 3Hz would be a problem, if you are sampling at 1000Hz. 

Have you checked on the receiving end that you are getting all the samples? 
If you count the samples over time you can check if you receive the expected 1000 samples pr second. 

Are you doing any buffering on the receiving side to handle any inconsistency in timing or minor delays that could happen over the wireless link?

Also, is the DAC set up to play a 1000 Hz samplerate signal properly? 
If the output appears digitized it could just be that the appropriate filtering is not applied, to remove any frequency components above 500 Hz (half the sampling frequency, as per the Nyquist theorem). 

Best regards
Torbjørn