NRF51822 Audio Application & Compression

RE: NRF51822 Audio Application & Compression

Stefan Birnir Sverrisson — Thu, 24 Jul 2014 09:29:08 GMT

If you however use the softdevice things are done pretty much automatically for you. When you enable the softdevice you specify which low frequency clock source you want to use. The softdevice also automatically enables the external high frequency crystal when the radio is enabled.

RE: NRF51822 Audio Application & Compression

Stefan Birnir Sverrisson — Thu, 24 Jul 2014 09:25:40 GMT

There are two clock sources in the system, low frequency 32kHz clock and high frequency 16MHz clock. You can see in table 28 in the nRF51822 PS v2.0 what clock source each peripheral requires. For both high and low frequency clocks you can select either internal RC oscillator or external crystal. High frequency external crystal is mandatory for any radio communication, Low frequency external crystal is optional but is the best choise for low power application. You have to enable the low frequency clock explicitly and specify if you wish to use internal RC or external crystal as the low frequency clock source. If you do not explicitly enable a high frequency clock, the internal RC is automatically enabled when any peripherals require a 16MHz clock, and it is disabled again when no peripheral require it. You must however explicitly enable the 16MHz external crystal clock source

RE: NRF51822 Audio Application & Compression

Lucas — Wed, 23 Jul 2014 14:42:53 GMT

Stefan,

One last clarification. Does the nrf51822 manage clock selection for the user? If the radio is being used it will use the 16MHZ X0SC? Otherwise it will use RC? Enabling and disabling of clocks in not left up to the user it is handled demand based by the nrf51822?

RE: NRF51822 Audio Application & Compression

Stefan Birnir Sverrisson — Wed, 23 Jul 2014 07:31:29 GMT

You can see the current consumption of a TIMER peripheral in the nRF51822_PS v2.0, sections 8.13, which is 30uA. However, the TIMER needs 1.2V regulator and 16MHz clock source (either RC or external crystal (XOSC)) and that will consume extra 880uA or 810uA respectively, see table 27.

RE: NRF51822 Audio Application & Compression

Lucas — Tue, 22 Jul 2014 15:43:45 GMT

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

RE: NRF51822 Audio Application & Compression

Stefan Birnir Sverrisson — Mon, 21 Jul 2014 09:06:23 GMT

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.

RE: NRF51822 Audio Application & Compression

Lucas — Fri, 18 Jul 2014 18:37:02 GMT

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.

RE: NRF51822 Audio Application & Compression

Lucas — Fri, 18 Jul 2014 14:42:10 GMT

Also,

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

RE: NRF51822 Audio Application & Compression

Lucas — Fri, 18 Jul 2014 14:36:06 GMT

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?

RE: NRF51822 Audio Application & Compression

Stefan Birnir Sverrisson — Fri, 18 Jul 2014 11:45:50 GMT

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.

RE: NRF51822 Audio Application & Compression

Lucas — Wed, 16 Jul 2014 21:17:41 GMT

removed from post