This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF51822 Audio Application & Compression

Hello,

I am working on an application that involves sampling audio data ~8KHz. I have a few questions

  1. The real time clock module has a maximum interrupt frequency of 32768/5 = 6554 Hz. Is there another mechanism to achieve a slightly greater interrupt frequency ~8KHz using the RTC? Or will I need to move to the Timer/Counter. Does nordic provide support for the Timer peripheral like it does for the RTC?

  2. Considering the BLE throughput limitation of the Iphone 5s = 4KB/s I will need to compress the audio data before transmission. Is nordic aware of any codec that works well on the Cortex M0 core of the NRF51822?

Lucas

Parents
  • Hi Lucas

    Is the RTC interrupt handler limited to 32768/5 Hz? I haven't heard of that before. The interrupt handler is executed perhaps 3-5 microseconds after the RTC event is triggered and will perhaps take a few microseconds to execute, given your code in the handler is relatively short, so there should be plenty of CPU time available for the RTC interrupt handler to execute with 8kHz frequency or even up to 32kHz frequency.

    Is perhaps something else in your code that is using CPU time, thereby limiting the CPU time left for the RTC interrupt handler. Is your code execution in the RTC interrupt handler perhaps taking a long time to execute, thereby limiting the sampling frequency. Also, if you have softdevice enabled it will limit your sampling rate since the CPU is blocked for 1ms-6ms during a BLE radio event.

Reply
  • Hi Lucas

    Is the RTC interrupt handler limited to 32768/5 Hz? I haven't heard of that before. The interrupt handler is executed perhaps 3-5 microseconds after the RTC event is triggered and will perhaps take a few microseconds to execute, given your code in the handler is relatively short, so there should be plenty of CPU time available for the RTC interrupt handler to execute with 8kHz frequency or even up to 32kHz frequency.

    Is perhaps something else in your code that is using CPU time, thereby limiting the CPU time left for the RTC interrupt handler. Is your code execution in the RTC interrupt handler perhaps taking a long time to execute, thereby limiting the sampling frequency. Also, if you have softdevice enabled it will limit your sampling rate since the CPU is blocked for 1ms-6ms during a BLE radio event.

Children
  • Stefan,

    For the reasons you mention my interrupt handler is

    nrf_adc->events_end = 0; nrf_adc->events_end = 0;

    That is the only thing in the the handler.

    Also, it does appear that the frequency is limited to 32768/5 Hz. Nordic developers have done a good job to include error codes in their api, and the limit was not hard to identify.

    if ((timer_id >= m_node_array_size) || (timeout_ticks < APP_TIMER_MIN_TIMEOUT_TICKS))
    {
        return NRF_ERROR_INVALID_PARAM;
    }
    

    #define APP_TIMER_MIN_TIMEOUT_TICKS 5

    The CPU blocking does though a bit of a wrench into my plans. However, sampling at 8KHz and being block for 1ms-6ms every 30ms (Our minimum connection interval) may produce sufficient quality audio . I will not know until I try entire system. However, what is the best solution to the RTC. Can I use the timer/counter?

  • Also,

    What decides the 1-6. The number of packets in the TX buffer?

  • Stefan,

    I am interested in finding out more about this proposed solution devzone.nordicsemi.com/.../

    See the last comment in the above thread apparently left by you. Would this really work? Has it been tested do you have code examples for the proposed functions that are necessary to get it working. I think this is my best option moving forward. I think this code would be helpful to the community as a whole. Additionally, I wouldn't mind handing over some of my embedded compression stuff to nordic if other customers are interested in audio application. I've made some improvements & 4x compression is possible.

  • Thank you for pointing out the exact code that limits the frequency to 32768/5 Hz. I actually did not realize that. I guess it has to do with the RTC delay/jitter specification described in sections 18.1.8 and 18.1.9 in the nRF51 Series Reference Manual and the way the application timer is implemented. I did not realize you were using the application timers actually. For higher frequency you could of cource use a TIMER peripheral instead but that will cost you up to ~1mA of extra current consumption.

    The thing that decides the CPU blocking time is how many packets you send in a BLE connection event and how many payload bytes are present in each packet. Shortest blocking time is when no payload is sent from peripheral or central. Longest blocking time is for maximum throughput in both directions, i.e. 6 packets sending and receiving, each with 20 bytes.

  • Stefan, Thank you for the information. This will be extremely useful moving forward. Where is it documented how much power each peripheral uses when active? Lucas

Related