High Sample Rate with ADC and SoftDevice [closed]

chrisabruce gravatar image

asked 2013-10-01 01:33:14 +0100

Petter gravatar image

updated 2014-09-23 11:07:20 +0100

I am trying to sample the ADC every 2ms. I notice lots of slowness with BLE advertising and typically can't connect to device over BLE when sampling. I am using PPI, configuring, and starting before the softdevice is enabled.

  1. Should nRF51822 be capable of reading ADC every 1ms to 2ms reliably?

  2. Should I move all the PPI configuration to after the softdevice is enabled and be using the sd_ppi functions?


Edit: Headline, format, added tags.

edit retag flag offensive reopen delete report spam

Closed as "the question is answered, right answer was accepted" by Petter Myhre at 2014-09-24 11:25:48 +0100

Why do you need to read ADC value every 1ms? Sounds overkill. It should not change between couple of minutes or more. And what tasks do you do in the ADC interrupt? The typicals SDK examples send the new battery level through ble_bas service notification. But if you are still in advertising mode, it should take a lot of time for anything.

Sébastien Despont ( 2013-10-01 06:42:50 +0100 )editconvert to answer

5 answers

Sort by » oldest newest most voted
stefanbirnir gravatar image

answered 2013-10-01 11:55:49 +0100

updated 2013-10-01 12:49:58 +0100

Hi Chris

I have attached an adc example which samples voltage on an input pin while the S110 softdevice is enabled. You should be aware of that you need to set the priority of the ADC interrupt explicitly to LOW. Also, PPI channels 8-15 are blocked by the softdevice, as stated in table 6 in the S110 Softdevice Specification v1.1, so using them for the application will cause conflicts with the softdevice. Use only PPI channels 0-7 for the application.

You should also be aware of that during BLE transmission, the CPU will be blocked, therefore limiting the sampling frequency of the ADC. The ADC itself will be able to process up to 50k samples per second but the CPU will be blocked for ca 0.8 - 6.0 ms when the softdevice is enabled, depending on the amount of data you are sending over the BLE link.

Table 12 in the S110_Softdevice_Specification_v1.1 states that throughput is up to 120kpbs for sending data from a client. However, when you send 32-40 kbps you would have to select 7.5ms connection interval and send 2 packets per connection interval. The CPU will be blocked for the whole transmission time of the 2 packets and that will block the CPU for about 1.6 ms. Sampling with 1kHz will not work because the ADC only buffers one sample and overwrites it when sampling again. The CPU is simply not available to process the ADC data every 1 millisecond.

Table 10 in the S110_Softdevice_Specification v1.1 indicates how long the CPU is blocked in respect to what you are sending many packets in each connection interval. The thing is that the length of the blocking period also depends on several factors:

The CPU blocking time in table 10 is therefore not very accurate because you really need to know the value of the above parameters, so the table is more of an estimate. However, when you want to obtain the shortest CPU blocking period of the softdevice you should set connection interval to 7.5ms, slave latency to zero and transfer as few packets as possible in each connection interval.

When connection interval is 7.5ms the master and slave 32kHz clock accuracy has very little effect on the lenght of the CPU blocking period. However, it has great effect when connection interval is e.g. 4000 ms and/or when slave latency is high.

So, to be brief, if you send or receive only one packet per connection interval, you should be able to process ADC samples with 1kHz frequency, given that you choose connection interval of 7,5ms and no slave latency. However, if you send or receive 2 packets per connection interval, you will most likely need to decrease you sampling frequency to 500 Hz.

You can configure your PPI channels directly before initializing the softdevice or use the sd_ppi functions if you choose to initialize the PPI channels after you initialize the softdevice. Again, only use PPI channels 0-7 for the application.


edit flag offensive delete publish link more

The sample looks great. One thing I noticed is that your sample is using app_timer, is that any better/worse than using PPI?

Chris ( 2013-10-01 12:10:20 +0100 )editconvert to answer

Also, why do you start and stop the hfclk? static void adc_sampling_timeout_handler(void * p_context) { uint32_t p_is_running = 0; sd_clock_hfclk_request(); while(! p_is_running) { //wait for the hfclk to be available sd_clock_hfclk_is_running((&p_is_running)); } nrf_gpio_pin_toggle(NRF6310_LED_2); //Toggle LED2 to indicate start of sampling NRF_ADC->TASKS_START = 1; //Start ADC sampling } void ADC_IRQHandler(void) { /* Clear dataready event */ NRF_ADC->EVENTS_END = 0; /* Write ADC result to port 2 */ nrf_gpio_port_write(NRF_GPIO_PORT_SELECT_PORT2, NRF_ADC->RESULT); nrf_gpio_pin_toggle(NRF6310_LED_3); //Use the STOP task to save current. Workaround for PAN_028 rev1.5 anomaly 1. NRF_ADC->TASKS_STOP = 1; //Release the external crystal sd_clock_hfclk_release(); }

Chris ( 2013-10-01 12:11:42 +0100 )editconvert to answer
stefanbirnir gravatar image

answered 2013-10-01 12:46:19 +0100

Hi Chris

The application timers use the RTC1 timer in the background. When using application timers, you need to share your timing with other periodic tasks that are also using application timers. Also, the application timers are setting software interrupts that may introduce latency. For real time sampling it would be best to use TIMER1 or TIMER2 directly with PPI channels to trigger the ADC sampling. You could also use RTC1 directly if you are not enabling the application timers. RTC0 and TIMER0 are blocked by the softdevice.

It is chosen in this example to use the external 16MHz crystal for the ADC sampling because that will guarantee that the accuracy of the ADC will be within specification. You can use the internal 16MHz RC clock but then the accuracy is no longer guaranteed. The accuracy of the internal RC is much lower than of the crystal. However, when using the external crystal, current consumption will be higher since it takes longer to start up the crystal than the RC, see tables 16 and 18 in the nRF51822 PS v1.3. In short, use the external crystal for maximum accuracy, use the internal RC for lowest current consumption.

edit flag offensive delete publish link more
s2alexan gravatar image

answered 2013-10-12 17:07:12 +0100

updated 2013-10-12 17:39:25 +0100

Hi Stefan,

This sample was very helpful to me - thanks. When you wrote about "accuracy of the ADC" are you referring to the accuracy of when the ADC samples, or the measurement error of the ADC?

Also, why do we need to set the priority of the ADC interrupt explicitly to LOW? Is this to solve the problem Chris had where he can't connect to device over BLE when sampling the ADC?

And one more question - I have some ADC samples that need high accuracy (so I'll use the external crystal), and some that don't (so I'll use the internal RC). Is it necessary to check if the crystal is running before stopping it, like this:

        uint32_t p_is_running = 0;
        if (p_is_running)

Or is it fine to just call sd_clock_hfclk_release() all the time, regardless of whether it's actually running or not?

edit flag offensive delete publish link more

Hi Stefan The accuracy which I am refering to is according to the ADC specfication in table 38 in the nRF51822 PS v1.3. This specification applies to accuracy of perceived ADC output when applying a known voltage source to the ADC input. You need to set the priority of the ADC interrupt to LOW in order to be able to call a softdevice function, starting with sd_. Otherwise you will get a hard fault. The example has been working fine just by calling sd_clock_hfclk_release and sd_clock_hfclk_request directly. While the softdevice is enabled it has control over the 16MHz crystal. Any sd_ function is a wrapper function implemented in the softdevice which should not allow the application to do any undesirable things to peripherals that the softdevice is in control of. So the method introduced in the example should be just fine.

Bastiaan ( 2013-10-16 12:40:37 +0100 )editconvert to answer

Hi Stefan The accuracy which I am refering to is according to the ADC specfication in table 38 in the nRF51822 PS v1.3. This specification applies to accuracy of perceived ADC output when applying a known voltage source to the ADC input. You need to set the priority of the ADC interrupt to LOW in order to be able to call a softdevice function, starting with sd_. Otherwise you will get a hard fault. The example has been working fine just by calling sd_clock_hfclk_release and sd_clock_hfclk_request directly. While the softdevice is enabled it has control over the 16MHz crystal. Any sd_ function is a wrapper function implemented in the softdevice which should not allow the application to do any undesirable things to peripherals that the softdevice is in control of. So the method introduced in the example should be just fine.

Guest ( 2013-10-16 12:40:37 +0100 )editconvert to answer
wld91 gravatar image

answered 2014-02-10 16:47:44 +0100


I don't have any experience developing code for nrf51822, but I want to buy a evaluation kit and start developing. Currently I'm working with atmega328, but I want to try making my app work on a nrf51822.

I have a pulse sensor that triggers an interrupt every 2ms reading a value on ADC, so as far as I read that can't be done on the nrf?


edit flag offensive delete publish link more

Hi Vlad Well, as mentioned previously, this depends on the amount of data you want to send in each connection interval. If you only need to send 1 or two packets per connection interval then you should be able to read the ADC every 2 milliseconds. So if you need to send ~20 kbps or less in one direction, then you should be able to sample every 2 ms (500 Hz).

Stefan Birnir Sverrisson ( 2014-02-11 09:26:50 +0100 )editconvert to answer
petermj gravatar image

answered 2014-03-26 13:14:47 +0100

I note that it is not possible to use the ARM core to 'sample' the ADC value regularly enough, BUT Is it possible to use the EasyDMA in the SPIS devices?

My proposal:

The ADC would be set to capture a value using the PPI and its START task and a timer, this gives the regular sample, but not the ability to 'save' the value before it is overwritten.

To 'save' the data, the SPIS could be set to loop back upon itself, with the TXDPTR set to the ADC result address, and the MAXTX set to 1 for 8-bit samples and 2 for 10 or 9 bit samples. The RXDPTR would then be set to a normal RAM address with a normal buffer size for example 256 to capture 256 8-bit samples.

Then you connect the MOSI and MISO pins, and the SCK to a suitable clock source (maybe the Master's clock, and then finally connect the CSN to a GPIO that is triggered using the PPI to make a suitably long chip enable signal.

I know this is convoluted, but the SPIS is the only memory bus master other than those used by the SoftDevice. Is this a feasible, if awkward, solution to regular sampling whilst the SoftDevice is enabled?

It would be useful to have some feedback to this proposal to help me make my product selection as the ADC capability is one of the nRFs key features (aside from its Bluetooth capabilty).


Peter Myerscough-Jackopson

edit flag offensive delete publish link more


Hi Peter Thanks for your proposal. I think your proposal is very good. I can not see why this should not work. I see this as a timer that is enabled with three compare registers: One compare register triggers the ADC sampling, i.e. CC[0] -> PPI[0] -> ADC->START Second compare register triggers SPI TX, i.e CC[1] -> PPI[1] -> GPIOTE[1]. GPIOTE[1] is gonfigured for a GPIO pin that is looped to the SPIS CSN pin. If you were doing 8-bit sampling, you would perhaps have this compare register trigger 25us after triggering the first compare register as it takes 20us to sample with 8-bit resolution. Third compare register creates the SPI clock by toggling a pin that is looped to SPIS SCK pin, i.e. CC[2] -> PPI[2] -> GPIOTE[2]

Stefan Birnir Sverrisson ( 2014-03-27 20:05:50 +0100 )editconvert to answer

Peter, Did you ever try this out? I am very interested to see if it worked. The toggling of the GPIO pin to create the clock seems rough? Using the proposed clk generator what is the maximum frequency that can be produced stefan? I guess you could have the compare value be 2 clock cycles causing a toggle every two cycles. This would result in a 16/4 = 4MHZ clk?

Lucas ( 2014-07-18 20:45:36 +0100 )editconvert to answer

I began to set it up, but when I started looking around for a suitable accelerometer, my sensor of choice atm, I found that most had limited analog bandwidth OR only had a digital output. I am keeping my eye on this capability in case I wish to capture from an analog microphone, but my current plans mean I haven't pushed this further. I think I had a schedule in the comparator that @ 0 cycles triggers the ADC @ (X - the time it takes to transfer the ADC value), enables the SPI transfer(raises the SPIS EN/CS) @ X resets the counter, disables the SPI transfer(raises the SPIS EN/CS) where X is the sampling period in cycles This takes 3 or 4 PPI event connections to perform regular sampling, and could be grouped if you so wish. If you get anywhere further it would be great to hear ...(more)

Peter Myerscough-Jackopson ( 2014-07-21 10:59:51 +0100 )editconvert to answer

Unfortunately, I have not tried this out yet. Currently, Nordic's technical support is low on staff because of summer vacations so I will have to try this at a later point. Another option to obtain a higher ADC sampling rate is to wait for the third revision nRF51 hardware which will have the CPU blocking during BLE radio event released. It's release is scheduled in the fall. It should be 100% drop-in and software compatible with nRF51 rev 2. You should contact your Nordic's sales representative for more specific release schedule for rev 3.

Stefan Birnir Sverrisson ( 2014-07-21 11:04:02 +0100 )editconvert to answer

Stefan, I will attempt to implement and keep you posted. To make it work I think I will need to use 2 times, several PPI's, and the ADC. I think that the clock must be generated using one dedicated timer, and the timing for adc conversion and spi must be done using another timer. Of course, this implementation is clunky and will use increased power. I look forward to the rev3. Could you explain a little more about the current implementation and how it will be changed for my understanding? Right now a ble_evt is a background task (of highest priority) and therefore block out all other interrupts from interrupting it? Is the ble_evt a software interrupt or a hardware interrupt? Also, where can i find code for working with the timer peripherals. Does nordic have any documents outlining restricted priority levels for peripherals?

Lucas ( 2014-07-22 17:51:49 +0100 )editconvert to answer

The stack generates software interrupts with priority 2 to signal the application of events. So to make a peripheral interrupt handler (e.g. ADC interrupt handler) have higher priority than any BLE callback events you must set the priority of your peripheral interrupt handler to 1 (i.e APP_IRQ_PRIORITY_HIGH). However, when a peripheral interrupt handler has priority APP_IRQ_PRIORITY_HIGH, you can not call any softdevice function from the peripheral interrupt handler, starting with sd_*. You can realize the priority structure in S110 Softdevice Specification v1.2, section 10.2. For nRF51 rev 2, the CPU is blocked during the whole radio event. For nRF51 rev 3, the CPU should be available after each transmitted packet. I expect this to allow 5kHz-10kHz maximum sampling rate for the ADC, but we will have to see what the actual specification for rev 3 reveals.

Stefan Birnir Sverrisson ( 2014-07-23 10:37:06 +0100 )editconvert to answer

Stefan, After reading the data sheet more thoroughly it is not clear to me how this will be possible. "As long as the semaphore is available the SPI slave can be granted multiple transactions one after the other. If the CPU is not able to reconfigure the TXDPTR and RXDPTR between granted transactions, the same TX data will be clocked out and the RX buffers will be overwritten." My interpretation of this is that everytime chip select is toggled RXPTR and TXPTR will start pulling from their original memory location. This is ideal for the TXPTR, but not the RXPTR. Essentially, this transaction will overwrite the first element in the RX buffer over and over with the adc value put out from the TXPTR.....

Lucas ( 2014-08-06 06:57:30 +0100 )editconvert to answer

Stefan, I am also confused about your previous statement. "For nRF51 rev 3, the CPU should be available after each transmitted packet. I expect this to allow 5kHz-10kHz maximum sampling rate for the ADC, but we will have to see what the actual specification for rev 3 reveals." If the CPU becomes available after each transmitted packet and each packet is ~1ms long wouldn't that yield a 1kHz sampling rate? My company is in the process of making serious architectural decisions and this information is extremely important.

Lucas ( 2014-08-06 07:01:37 +0100 )editconvert to answer

Lucas, although I have not done the work, using the SPIS unit you would configure the RX to be many samples long, and the TX to be just a single sample long from one ADC location. The PPI would then enable the transfer of just one ADC measurement, by pulsing the SPIS CS/EN pin for just a single transfer period. This would mean the RX transfer would receive one measurement, but not complete, whilst the TX would send one measurement. The RX transfer would therefore slowly fill up the buffer it is given for its transfer, whilst the TX would repeatedly read the ADC result register location. I hope this helps in clarifying the concept of using the SPIS to achieve regular sampling. The rev3 silicon will not require the SPIS to achieve higher sampling rates 5-10kHz, but as Stefan says we are only guessingwaiting in that regards. Peter

Peter Myerscough-Jackopson ( 2014-08-06 11:24:11 +0100 )editconvert to answer

Peter, That is how I would try to configure it as well. But every time the CS/EN pin is pulsed I believe it resets the write address of the RX_Buffer back to RX_PTR. The same is true for the TX_BUFFER and TX_PTR. This is my interpretation of the data sheet. Perhaps we could get a member of nordic to provide some input about this transaction.

Lucas ( 2014-08-06 16:43:52 +0100 )editconvert to answer

In another post I saw that instead of pulsing the CS/EN pin, they were enabling the clock signal for a set number of transitions. The number of clock pulses were counted using one of the counters, that way the behaviour of reseting the TX_PTR and RX_PTR would only happen when the end of their respective buffer was reached.

Peter Myerscough-Jackopson ( 2014-08-06 17:38:36 +0100 )editconvert to answer

Thanks for your comment Peter. I believe this brings our idea of using the SPIS for ADC sampling back to life. Can you point us to this post you are mentioning. I will work on setting this up on my side today.

Stefan Birnir Sverrisson ( 2014-08-07 09:12:51 +0100 )editconvert to answer

Peter, I believe you can enable the clock for a set number of spi byte transmissions. However, the TX_PTR and RX_PTR will both increment every-time a transmission is made. If you set MAXTX to 1 and attempt to let the spi go for multiple transactions a spi overrun error will be thrown. My interrpretation of the data sheet is that in this scenario RX_PTR and TX_PTR will be incremented an controlled in an identical way. There is no way to make RX_PTR go through a 100 byte buffer and TX_PTR read from a single memory location.

Lucas ( 2014-08-07 16:43:09 +0100 )editconvert to answer

Your theory is correct Lucas. I have actually set up the example and tried this. I managed to clock out just one byte at a time, which is triggered each time by an ADC->END event. I sample 13 times and then set the CSN high to trigger a SPIS->END event. In the SPIS->END interrupt handler I read out the data in RXDPTR. Every time a byte is clocked out on MISO, both RXDPTR and TXDPTR are incremented. If I set MAXTX = 1 the ADC->RESULT is read once and all subsequent bytes sent out on MISO are the ORC overread character. Anyway, this was a nice try gentlemen, but I think my attempt for making this work stops here unless you have some additional suggestions.

Stefan Birnir Sverrisson ( 2014-08-07 16:58:56 +0100 )editconvert to answer

Stefan, thank you for attempting. It looks like my only options are to wait for REV 3 and hope for the best. Or add a dedicated ADC with built in FIFO into my system, but I really don't want to do that haha.

Lucas ( 2014-08-07 17:13:11 +0100 )editconvert to answer

One final attempt at getting regular sampling working could be to use the SPIS for getting the data from the ADC, and then reading the data back into the UART. It looks like the UART can be configured for no parity and hardware flow control OR event based flow control, and it has a FIFO with space for 6 values. This means that the current limit of one guaranteed sample every 1700 μs (588Hz), is raised to 6 samples in that period(3529Hz), and if the future rev3 doesn't quite make it to 10kHz this method would allow the rate to be multiplied by 6 allowing for 5-10kHz to be easily achieved. One last attempt......?

Peter Myerscough-Jackopson ( 2014-08-07 17:25:07 +0100 )editconvert to answer

In retrospect it looks like the UART requires start and stop bits, but the waveforms are not in the pdf.

Peter Myerscough-Jackopson ( 2014-08-07 18:06:09 +0100 )editconvert to answer

A final comment would be to Stefan. I know Nordic are creating a rev3, but if there is ever a rev4, then a possible idea to enable full utilisation of the ADC using the SPIS loopback method could be achieved if the RESULT register was 'mirrored' / 'repeated' on a contiguous set of addresses. For example if the same RESULT register was accessible at 0x508 and additionally in the range 0x600-0x700, then setting the SPIS to read from 0x600 - 0x700 and controlling the clock as we have been expertimenting with would enable the ADC to be read 40 times without the CPU. It would allow the 50kHz ADC to be controlled by the CPU with a control rate of 1.25kHz. Looking at the NRF_ADC_Type there are actually 700 free register locations in the block after the RESULT register and they could all be set to mirror the RESULT register if ...(more)

Peter Myerscough-Jackopson ( 2014-08-08 11:24:50 +0100 )editconvert to answer

The above idea shouldn't alter the ADC hardware significantly just the address decode for the RESULT register. Given that rev3 should enable 5-10kHz sampling, 5-10 contiguous addesses would enable the ADC to be run at its maximum of 50kHz.

Peter Myerscough-Jackopson ( 2014-08-08 11:27:21 +0100 )editconvert to answer

Thanks for your suggestion Peter. Your suggestion with the UART RX connected to the SPIS MISO pin could be difficult. The UART requires a low signal start bit and high signal stop bit. I do not realize how the start bit could be generated before the actual data.

Stefan Birnir Sverrisson ( 2014-08-08 16:29:37 +0100 )editconvert to answer

Question Tools



Asked: 2013-10-01 01:33:14 +0100

Seen: 7,075 times

Last updated: sep. 23 '14