High Sample Rate with ADC and SoftDevice

[Chris]

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?

Thanks!

Edit: Headline, format, added tags.

[Peter Myerscough-Jackopson]

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

Yours,

Peter Myerscough-Jackopson

[Stefan Birnir Sverrisson]

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]

[Lucas]

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?

[Peter Myerscough-Jackopson]

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 back from you, but as I had done no programming wth the nRF51 prior to this suggestion it was not an easy first task.

[Stefan Birnir Sverrisson]

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.

[Lucas]

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?