ESB "Hiccup"

RE: ESB "Hiccup"

ovrebekk — Tue, 26 Apr 2022 08:30:11 GMT

Sorry for the slow response, I have been out of office for the last couple of weeks.

In order to check if the noise is caused by the ADC itself you could try to enable oversampling, and see if the noise is reduced?

Theoretically every doubling of the oversampling (corresponding to increasing the oversampling setting by 1) should reduce the ADC noise by half a LSB.

You can change the oversampling setting through the NRFX_SAADC_CONFIG_OVERSAMPLE parameter in sdk_config.h. Try a value of 4 for instance, and you should see a reduction of noise of about 2 LSB compared to an oversample setting of 0.

Best regards
Torbjørn

RE: ESB "Hiccup"

gSook — Mon, 11 Apr 2022 05:45:00 GMT

So the noise is not being injected at the input, as this is also happening with a function generated wave going through the ADC. I can post the ADC config here however, to see if there is something I can change in that.

void saadc_init(void)
{
    ret_code_t err_code;
    nrf_saadc_channel_config_t channel_config =
        NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);

    err_code = nrf_drv_saadc_init(NULL, saadc_callback);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_drv_saadc_channel_init(0, &channel_config);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_drv_saadc_buffer_convert(m_buffer_pool[0], SAMPLES_IN_BUFFER);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_drv_saadc_buffer_convert(m_buffer_pool[1], SAMPLES_IN_BUFFER);
    APP_ERROR_CHECK(err_code);

}

void saadc_sampling_event_init(void)
{
    ret_code_t err_code;

    err_code = nrf_drv_ppi_init();
    APP_ERROR_CHECK(err_code);

    nrf_drv_timer_config_t timer_cfg = NRF_DRV_TIMER_DEFAULT_CONFIG;
    timer_cfg.bit_width = NRF_TIMER_BIT_WIDTH_32;
    err_code = nrf_drv_timer_init(&m_timer, &timer_cfg, timer_handler);
    APP_ERROR_CHECK(err_code);

    /* setup m_timer for compare event every 20us */
    uint32_t ticks = nrf_drv_timer_us_to_ticks(&m_timer, 40);
    nrf_drv_timer_extended_compare(&m_timer,
                                   NRF_TIMER_CC_CHANNEL0,
                                   ticks,
                                   NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK,
                                   false);
    nrf_drv_timer_enable(&m_timer);

    uint32_t timer_compare_event_addr = nrf_drv_timer_compare_event_address_get(&m_timer,
                                                                                NRF_TIMER_CC_CHANNEL0);
    uint32_t saadc_sample_task_addr   = nrf_drv_saadc_sample_task_get();

    /* setup ppi channel so that timer compare event is triggering sample task in SAADC */
    err_code = nrf_drv_ppi_channel_alloc(&m_ppi_channel);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_drv_ppi_channel_assign(m_ppi_channel,
                                          timer_compare_event_addr,
                                          saadc_sample_task_addr);
    APP_ERROR_CHECK(err_code);
}

void saadc_sampling_event_enable(void)
{
    ret_code_t err_code = nrf_drv_ppi_channel_enable(m_ppi_channel);

    APP_ERROR_CHECK(err_code);
}

RE: ESB "Hiccup"

ovrebekk — Fri, 08 Apr 2022 11:34:20 GMT

I assume you have tested that this noise has nothing to do with the radio transmission, and is actually present on the sampled signal before it is transmitted over the air?

Have you tried to measure the analog signal with an oscilloscope to see if the noise is present on the input, or if it is somehow added by the sampling process itself?

There are various external and internal factors that could affect noise on the input. Since this is more of a hardware question I would recommend opening a new ticket, explain the problem, and include the schematic design of your board so we can check if it looks good.

The complete ADC configuration could also be helpful. One way to check if the noise is caused by the ADC itself is to enable oversampling on the ADC, and see if the noise is reduced.

Best regards
Torbjørn

RE: ESB "Hiccup"

gSook — Fri, 08 Apr 2022 00:37:08 GMT

I ended up fixing the speed issue (it was slowed down due to logging, so taking all unnecessary code out drastically improved the output waveform), but now we are faced with noise on the output. While I can hear the tone that is being transmitted, there is underlying noise that seems to get even worse when I connect ground to the ADC of the transmitter side (ideally no sound at all). I currently have the ADC resolution set to 14 bit and I am removing the bottom 4 bits in order to combat ADC noise. Is there anything else that you think could be causing the problem or that I should look into?

RE: ESB "Hiccup"

ovrebekk — Tue, 05 Apr 2022 09:14:44 GMT

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

RE: ESB "Hiccup"

gSook — Mon, 04 Apr 2022 19:54:32 GMT

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!

RE: ESB "Hiccup"

ovrebekk — Mon, 04 Apr 2022 10:26:38 GMT

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

RE: ESB "Hiccup"

gSook — Fri, 01 Apr 2022 04:08:12 GMT

That is very appreciated thank you so much!

I am using version 17.1.0 of the SDK.

Here is the zipped project file:devzone.nordicsemi.com/.../4174.ses.zip

RE: ESB "Hiccup"

ovrebekk — Thu, 31 Mar 2022 07:31:02 GMT

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

RE: ESB "Hiccup"

gSook — Wed, 30 Mar 2022 00:28:32 GMT

I have not been able to get logging functioning on the RX side. Even when I have enabled logging in the config file for both UART as well as RTT. Is there something else I need to enable?

I will try the counter approach and update with any findings.

RE: ESB "Hiccup"

ovrebekk — Mon, 28 Mar 2022 10:36:34 GMT

Getting logging working through USB on the nRF52840 dongle is possible, but it is not straight forward unfortunately, and it is not natively supported in the SDK.

Jimmy Wong wrote a blog about this a while ago:
https://jimmywongiot.com/2019/10/25/how-to-use-the-nrf52840-dongle-pca10059-as-development-board/

You could try following that blog, but be aware that the software examples he uses are quite old at this point (made for v15 of the SDK).

It would be easier if you have a J-Link programmer or an nRF52840DK available, but this requires additional hardware that you might not have access to.

A third option is to output UART logging on one of the available pins on the dongle, and connect it to some kind of serial to USB converter, but in this case you need to ensure that the voltages are compatible.

What about logging on the RX side?
Have you not been able to get this working either?
For the DK's there are several options for handling logging, such as RTT or UART.

Regarding the sample sine wave, could you try to send a simple counter value instead?
This should look like a sawtooth if you analyze it like an audio sample, and might be a more intuitive way to figure out what is happening with the signal.

Best regards
Torbjørn

RE: ESB "Hiccup"

gSook — Fri, 25 Mar 2022 16:06:47 GMT

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.

RE: ESB "Hiccup"

ovrebekk — Fri, 25 Mar 2022 10:17:51 GMT

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