Using the ADC with the S110 SoftDevice

A good place to start with getting to know how to use the ADC with the S110 SoftDevice is by using one of the BLE ADC code examples provided on Nordic's Github page, where BLE examples have the "ble_" prefix.

Sampling frequency limitations

During a BLE transmission event the CPU will be blocked. This will limit the sampling frequency of the ADC. The ADC will be able to process up to 50 k samples per second but the SoftDevice will block the CPU during a radio event and limit the ADC sampling frequency. This is because the ADC has only one RESULT register and the CPU must extract data from the RESULT register before sampling again, otherwise the value in the RESULT register will be overridden. The length of time the CPU is blocked is different between the 2nd IC revision and the 3rd IC revision of the nRF51 Series chips.

nRF51 3rd revision hardware limitations

For the 3rd revision nRF51 hardware, maximum CPU blocking time is approximately 500 microseconds which enables ADC sampling frequencies of at least 2 kHz. See the S110 Softdevice Specification v2.0, sections 12.3.1 and 12.3.2 for the CPU blocking times for advertising and connection respectively. However, the shorter CPU blocking time of the 3rd revision hardware is actually enabled by the S110 SoftDevice v7.1.0. By default the CPU is blocked during an entire BLE radio event, and unblocking must be performed manually as described here in order to obtain the 2 kHz sampling frequency. With S110 8.0.0+ the CPU is however unblocked by default. When the CPU is blocked the maximum sampling frequency is 150 Hz-1 kHz, depending on the amount of data sent over the BLE link. S110 v7.1.0 is compatible with both 2nd revision and 3rd revision hardware, so CPU blocking configuration of the S110 v7.1.0 is set to the longer blocking time by default.

nRF51 2nd revision hardware limitations

For 2nd revision hardware, the CPU will be blocked for approximately 0.8 - 6.0 ms when the SoftDevice is enabled. The exact length of time depends on how many packets are sent in each BLE connection event. If sending one packet per connection event, then the CPU is blocked for about 1 millisecond which limits the ADC sampling frequency to around 1 kHz. If sending 6 packets per connection event, then the CPU is blocked for about 6 milliseconds which will limit the ADC sampling frequency to around 150 Hz.

Table 30 in the S110 SoftDevice Specification v1.3 indicates how long the CPU is blocked when 2nd revision hardware is used. However, table 30 is only an estimate and you really need to know the value of the below parameters as well:

  • Packets sent per connection interval
  • Number of bytes in each packet
  • Master 32 kHz clock accuracy
  • Slave 32 kHz clock accuracy
  • Connection interval
  • Slave latency

When you want to obtain the shortest CPU blocking period of the SoftDevice you should set connection interval to 7.5 ms, slave latency to zero, and transfer as few packets as possible in each connection interval.

When the connection interval is 7.5 ms, the master and slave 32 kHz clock accuracy have very little effect on the length of the CPU blocking period. However, it has a large effect when connection interval is, for example, 4000 ms and/or when slave latency is high.

This means if you send or receive only one packet per connection interval, you should be able to process ADC samples with 1 kHz frequency (if you choose connection interval of 7.5 ms and no slave latency). However, if you send or receive 2 packets per connection interval, you will most likely need to decrease the sampling frequency to 500 Hz.

Anonymous
  • Thanks for this most excellent post..

    As a follow up I wanted to let the readers know that the non concurrent operation (blocking) of the CPU and Radio has been eliminated. They can operate concurrently with the new XLR3 version of the device.

    The new development kit is also out with that version of the device mounted on it. It comes with a nRF51422 mounted hence it can run all the protocols / stacks Nordic offers.

  • Good post.

    It's worth mentioning that if you're lucky enough to have first generation silicon that you're supporting, pay VERY close attention to the Product Anomalies Notifications. Specifically, be sure to switch-off both the ADC and front-end in between samples if you're developing a BLE product.

  • Nice blog, it is very informative. Thank you.