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

Should the nRF51822 be used if there are heavy ADC requirements?

We need to sample all 8 ADC channels for random 1ms pulses to record amplitude data from in real time. How much will that impact the bluetooth performance if it needs to freeze the cpu in order to transmit? Will that shut down the bluetooth function for the interim unless we freeze the data streams incoming from the adc? Am I confused about this tradeoff?

  • Hi

    The bluetooth stack (BLE softdevice) has highest interrupt priority and the ADC can not interrupt the BLE softdevice. It is the softdevice that can block the CPU and keep the CPU from handling ADC sampled data. So ADC sampling has some sampling freqency limitation but ADC sampling will have no effect on the BLE performance.

    The limitations of sampling frequency for the current second revision nRF51 hardware is discussed on this thread. From that discussion, the sampling frequency is limited to around 500Hz with the current nRF51 hardware.

    The upcoming nRF51 third revision hardware will however allow at least 4kHz sampling frequency, i.e. the BLE softdevice will block the CPU for maximum 250 microseconds. The third revision nRF51 hardware is to be released within the next few weeks.

    The nRF51 has 8 analog input channels, so sampling from 8 ADC channels should be possible. However, if you need high accuracy ADC, the nRF51 internal ADC is perhaps not the optimal choice. The maximum ADC resolution is 10 bit. Look at the nRF51822 PS document in order to realize the accuracy of the ADC.

    Some ADC examples are available on Nordic's Github.

    Update It is possible to use radio notifications to know when to sample. Then you get an event from the softdevice at a predefined time before the BLE radio event starts and at the end of the radio event. You might also consider to use the Timeslots API where you can ask the softdevice for certain timeslots of a predefined length between radio events. The application is then guaranteed the time interval that is asked for without interrupt from the softdevice. Timeslot API and radio notifications are both documented in the S110 Softdevice Specification

  • Hi Stefan,

    May I ask where to find out how long the CPU will be blocked? You say the latest revision will be blocked for 250 microseconds. Will it say this in the Soft Device specification? As I am doing a university project I have to cite the document that says this info, it's not that I don't trust you ;)

Related