0
\$\begingroup\$

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?
\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you Jan, that was a very informative response. I'm reading into IIO at the moment, this is a new concept to me, but certainly seems like a viable option. I'll actually be migrating to an i.MX device in the near future, so I'll bear that in mind as well. \$\endgroup\$
    – jars121
    Jun 6 '18 at 7:49
  • \$\begingroup\$ @jars121 in particular the 6 SoloX has a Cortex-M4F included in the SoC. 6UL or 6ULL should have one too but I'm not too sure. There should also be something in 7 or 8 series but I don't know about that. \$\endgroup\$ Jun 6 '18 at 10:21
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.