Data acquisition microcontroller approach

Question

I'm prototyping a data acquisition device which interfaces with 64 discrete inputs; 32 analogue and 32 digital (user-configurable as either ON/OFF measurement or frequency/duty measurement). I'm targeting a maximum sample frequency of 1000Hz per channel, so 64,000 samples per second across the device.

I'm currently prototyping with a generic ARM-based embedded Linux device (Raspberry Pi, Beaglebone, etc.). Analogue inputs are read and serialised by SPI-based ADCs, with the digital inputs interfacing directly with the device's GPIOs and read via sysfs.

I'm finding that the time to measure all 64 channels within a GUI-based Linux OS is too long and presents enormous amounts of jitter (execution time of a single sample of all 64 channels can range from <1ms to ~10ms). I'm currently experimenting with different threading approaches, but I believe the core issue is trying to execute time-sensitive readings within a non-RTOS environment.

As such, I'm contemplating introducing a dedicated DAQ microcontroller into the design, which will interface with the 64 inputs, store intermediate readings in a buffer, then routinely pass the data to the OS (via one of the standard high speed interfaces).

My questions are as follows:

1. Is there any point continuing with the Linux-based acquisition approach for a 64ksps requirement? Even if I could manage the sampling rate, I believe the jitter would still make this option untenable.
2. If the microcontroller approach is sound, can you recommend a make/model?

Answer 1

64 ksps is nothing for a Pi, should be good on Beagle too, but not in userspace.

Jitter might be troublesome even in kernel mode, at least on SPI where the SPI master is allowed it's own queue. On GPIO it should not be an issue as long as you do it carefully. Would be easier with parallel DACs and GPIO I believe, but then hobbyist boards usually don't have that many pins.

A viable approach seems to be writing the data acquisition in a kernel module and forwarding it via the IIO subsystem. IIO has features which allow forwarding a circular buffer of samples to userspace but I have not used them myself (only used read on request).

Another approach is SoCs which have both a Cortex-A and a microcontroller, like the Sitara present in Beagle Black or some SoCs in the i.MX series. Take a look at PRUDAQ - the only active component outside BBB is the ADC. The advantage of this approach is that the two processors share their RAM making transmission easier.

Answer 2

We have recently benchmarked PIGPIO and RPi.GPIO python libraries, with regards to the accuracy of reading inputs at different frequencies, on the Raspberry Pi 3b.

The PIGPIO library has a very good accuracy up to 20 KHz. At 64 KHz it's accuracy was measured at about 70%.

There is a chance that your approach is possible on the Raspberry 4, though we haven't bench marked it yet.

Answer 3

I love RPi so long as you don't need timing resolution better than about 50us. My experience (even using C and PigPio) about a year ago was that you can easily get about 15-20us of timing uncertainty even on GPIO's. Probably due to OS stuff going on.

So the question is not only about getting enough samples per second, but jitter and how synchronous your sampling needs to be.

If you want better timing resolution, I think either bare metal or an RTOS on a microcontroller is the way to fly. With good device selection and hardware design, you can have timing resolution easily better than 1us. As for family - choose your poison. I've had good experiences with both PIC32MX and STM32 families. Having 32 ADC channels (not necessarily 32 ADC's) is obviously a big factor.

Alternatively you could design your own IO board for an RPi of course. There are plenty of multichannel ADC's with SPI/I2C interfaces that you could use. Custom hardware could alleviate timing uncertainty.

That's about as complete an answer as I think I can risk, without more info about timing requirements, whether the inputs all need to be sampled at the same moment, and so on.