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.

  • 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.

Reply
  • 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.

Children
No Data
Related