Simultaneous multichannel Sampling

Projects General Guidance
1

Hello there. I am in need of aid in regards to simultaneous sampling of analogue inputs.
Please note that I am relatively uneducated on high data rate applications.

I would like to create a project able to sample multiple (up to 60 analogues channels in groups of 6)
at a rate of 1000Hz with a 16 bit resolution. The reason why they should be in groups of 6 is because I would like to use tri-axis accelerometers each of which has two outputs per axis.

The sampled data should then be gathered and transferred to my computer via usb.

For simplicity I will just refer to one group of 6 inputs as "Channel".

-My Initial Idea of making a Channel is to use one micro-controller (SamD21) with an adc (ADS8586S) for example.

The micro-controller would extract the data and either store it or write it to a buffer, where a secondary micro-controller could read it and combine the samples with data from other Channels to send it via usb connection to my computer.

Here is where my problems start already.

  1. Unfortunately I am having problems coming up with a good concept of buffering the data so that the secondary mcu can do its part without interfering with the first mcu. I thought about using a fifo to do so, however I have never worked with them before and would like to confirm that this is the best method and ask what I need to look for in such a component.

Additionally, I think that if an adc exists that employs an output buffer which can sample 6 channels at 16bit+ with a sample rate of >1000Hz it would make sampling a lot easier.

  1. The amount of data is most likely too much to handle for one secondary mcu and If possible I would like to know some alternatives.

Please correct me when I am wrong or going in the wrong direction here with my ideas.
I am also open to completely different concepts.

Thank you all in advance.

2

I think we need to understand what accelerometers you are using, or planning to use. I've never hard of an accelerometer that output analog values.

3

Your a/d requirement is far beyond an arduino in number of channels and resolution . You will need some significant external hardware to achieve this.

If you really need 'simultaneous ' sampling you can't use a mux. and will need 60 adc's, or perhaps 60 sample and hold devices , a mux and a fast adc. These exist.

Not a trivial problem.

NI do some good instrumentation packages - but not cheap.

Allan

4

Be aware that some "simultaneous sampling" schemes use a sample and hold per channel and those are mux'ed to one ADC. There is always some "droop" in the sample and holds as it takes time to read the channels. Read the fine print.

5

PaulS:
I think we need to understand what accelerometers you are using, or planning to use. I've never hard of an accelerometer that output analog values.

Thank you for your response. Unfortunately I currently have no further information on the sensors as they will be provided to me as some point soon.

I hope that we could still try to tackle my problem regarding the simultaneous sampling of data.

allanhurst:
Your a/d requirement is far beyond an arduino in number of channels and resolution . You will need some significant external hardware to achieve this.

If you really need 'simultaneous ' sampling you can't use a mux. and will need 60 adc's, or perhaps 60 sample and hold devices , a mux and a fast adc. These exist.

Not a trivial problem.

NI do some good instrumentation packages - but not cheap.

Allan

I was planning of using 1x 32 bit mcu in combination with 1x 16bit 6 channel adc at a 1000Hz.
And repeat this combination in parallel 10x. In my mind, using external interrupts on the mcu's should
in theory cause simultaneous capture of all of the channels.

I believe my problem is combining that information after the first mcus have all taken their samples.
If possible I would like to make them push the data into seperate fifos where I could extract the data
one seperate mcu. however I think that may be too much for one mcu to handle.

groundFungus:
Be aware that some "simultaneous sampling" schemes use a sample and hold per channel and those are mux'ed to one ADC. There is always some "droop" in the sample and holds as it takes time to read the channels. Read the fine print.

I already feared that the advertised 'simultaneous sampling' sounds too good to be true but as long as I can sample each of the channels at ~1000Hz I am already content. I was hoping that there would be an adc witha high sample rate that employs a build-in buffer to make sampling easier but I have yet to find a valid option.

Thank you all for your replies :slight_smile:

6

Look through the major manufacturer's offerings

eg TI's ADS1158 - 16-Bit, 125kSPS, 16 channel.

There's a lot of choice.

Allan

7

How much is your time worth, considering that you can buy such things off the shelf? Especially considering your admission that you have no experience with high throughput data collection.

For example, here is an 8 channel, 16 bit, 50 kS/s/channel ADC that plugs directly into a PC USB port.

Your choice is to start collecting data in a few days, or spend a few months getting something to work.

8

Yes, I agree that you can spend months learning how to do this or just buy the thing. It's not a unique requirement.

I should think that if you care about the 1kHz sample rate then you should also care about the simultaneity of the samples. If you are looking for data at that high resolution then it becomes really significant if one channel at the end of the chain is 500us away from the first one.

The next question is how are you ensuring that the accelerometers don't give you signal frequencies higher than this? Aliasing of frequencies above the Nyquist frequency is a big problem with these kinds of measurements.

I've created a system using ADXL345 digital accelerometers to do 400Hz sampling on groups of 4. I guess that it could be ramped up to higher frequencies. My Arduino had a lot of other time-sensitive work to do at the same time, so I expect that my system could handle that frequency if it didn't have to do anything else. I just trusted the ADXL345 internal clocks to stay in sync for my measurement period by just starting them all in the same nanosecond. I would not expect the basic ADXL345s to stay acceptably in sync more than a few seconds at 1kHz.

9

allanhurst:
Look through the major manufacturer's offerings

eg TI's ADS1158 - 16-Bit, 125kSPS, 16 channel.

There's a lot of choice.

Allan

Thank you for your response. I've been looking at TI and mouser for good components. And I certainly think
those devices are a good fit. I just want to weigh my options on the best way to progress. for example, I
would like to know if there are ADCs with a output buffer not unlike a fifo buffer that allows the connected
mcu to transfer the data in bulk and perform other tasks while the ADC is preparing the next batch.

jremington:
How much is your time worth, considering that you can buy such things off the shelf? Especially considering your admission that you have no experience with high throughput data collection.

For example, here is an 8 channel, 16 bit, 50 kS/s/channel ADC that plugs directly into a PC USB port.

Your choice is to start collecting data in a few days, or spend a few months getting something to work.

Thank you for your concern and I realize that this may take quite a while before I can get it working as
described, however I am very interested in learning how to do this.

MorganS:
Yes, I agree that you can spend months learning how to do this or just buy the thing. It's not a unique requirement.

I should think that if you care about the 1kHz sample rate then you should also care about the simultaneity of the samples. If you are looking for data at that high resolution then it becomes really significant if one channel at the end of the chain is 500us away from the first one.

The next question is how are you ensuring that the accelerometers don't give you signal frequencies higher than this? Aliasing of frequencies above the Nyquist frequency is a big problem with these kinds of measurements.

I've created a system using ADXL345 digital accelerometers to do 400Hz sampling on groups of 4. I guess that it could be ramped up to higher frequencies. My Arduino had a lot of other time-sensitive work to do at the same time, so I expect that my system could handle that frequency if it didn't have to do anything else. I just trusted the ADXL345 internal clocks to stay in sync for my measurement period by just starting them all in the same nanosecond. I would not expect the basic ADXL345s to stay acceptably in sync more than a few seconds at 1kHz.

I realize that simultaneous sampling in this application is critical and that there will be a delay between the samples. In my mind, I am trying to mitigate that problem by pairing 1x mcu and 1xADC per 6 analogue channels. Each mcu is then called by an external interrupt, at the same time, to trigger taking 1 sample
from each channel via the connected adc. Then that data needs to be paired with the other samples taken from the other mcus. Which will be done by a separate micro controller.

I believe the main problems that I will have with this are that the sampling/writing process needs to be complete before then next interrupt is called, limiting the maximum sampling frequency and that there would still be a delay between the initial and final sample between each of the 6 input channels.

I would be perfectly fine with reducing the number of channels per ADC to reduce the delay between the samples eve further. Also, I am not against using digital sensors instead of analogue sensors if that gives me a better temporal resolution. But in this case I think I would run into similar problems and sill need
to manage bundling of the data so that i can send it to my computer.
send it to my computer.

I have attached an image of the general layout that I had in mind :slight_smile:

General Layout.jpg
General Layout.jpg651×548 45 KB

10

for example, I would like to know if there are ADCs with a output buffer not unlike a fifo buffer that allows the connected mcu to transfer the data in bulk and perform other tasks while the ADC is preparing the next batch. You could do that with a DMA to transfer ADC samplings to a buffer without core clock cycles.

Unless you have one MCU for one ADC channel, the 60 ADC samplings will not be processed exactly at the same time.

If you transfer data thru an USB 2.0, data rate can be really fast > 849 KBytes/s with an arduino DUE.

With oversampling ( times 256) and some lines of code, you can obtain 16-bit ADC samplings from 12-bit ADC samplings. Since a DUE can sample up to 1 Msps, you could do that with only :slight_smile: 20 DUEs for 60 ADC channels... Good luck

11

You can't make an oversampled 12-bit adc into an accurate 16-bit adc unless the 12-bit one is accurate to 16 bit.

Not +/- 1/2 LSB at the 12 bit level, but +/- 1/32 bit.

Silk purse out of sow's ear? Not this time..

Allan

12

Read this .pdf from Silicon Labs and see if this is sufficiently accurate for your project:

13

You can't make an oversampled 12-bit adc into an accurate 16-bit adc unless the 12-bit one is accurate to 16 bit.

In order to correct your misunderstanding, please study the application note linked in reply #11 (for one example among many). You simply trade sampling speed for resolution.

14

ard_newbie:
for example, I would like to know if there are ADCs with a output buffer not unlike a fifo buffer that allows the connected mcu to transfer the data in bulk and perform other tasks while the ADC is preparing the next batch. You could do that with a DMA to transfer ADC samplings to a buffer without core clock cycles.

Unless you have one MCU for one ADC channel, the 60 ADC samplings will not be processed exactly at the same time.

If you transfer data thru an USB 2.0, data rate can be really fast > 849 KBytes/s with an arduino DUE.

With oversampling ( times 256) and some lines of code, you can obtain 16-bit ADC samplings from 12-bit ADC samplings. Since a DUE can sample up to 1 Msps, you could do that with only :slight_smile: 20 DUEs for 60 ADC channels... Good luck

While it would be great if I could "bundle" the input channels I understand that they would have a slight
time delay. And that I would need one mcu per adc to archive simultaneous capture. It would be great if
there was a cheap arduino compatible mcu that employs a 16-bit adc so I would not have to use an external
one, however I would like to refrain from buying 20 DUEs. Do you think one of the teensy boards would
be sufficient? I think 3.2 has 2x16 bit adc.

Other than that would it be possible to use an ATSAMD21G18A-MUT in combination with an AMC1106E05DWVR.

Regarding the USB connection, wouldn't it make more sense to bundle the sampled data from all the
channels and send all at once or at least once per channel than having 20 usb cables connected to the computer even via hub?

The oversampling Idea does sound intriguing and good to know as an alternative, I would like to focus on 16-bit adc first if possible.

15

I must confess, I don't know the teensy... I can only suggest 3 * 16-bit 1KHz equivalent ADC channels per DUE as long as the sampling frequency remains under 1 Msps.

To communicate between the DUEs, IMO the easiest way is Serial (Serial, Serial1, Serial2, Serial3 and Serial4 (yes, you can have Serial4)). The fastest way to communicate between 2 DUE could be SPI with TurboSpi Library (42 MHz).

Anyway your project is far from standard and would deserve some serious study, particularly for the amount of data to transfer between MCUs and your PC in order to draw a relevant solution.

BTW, a DUE has become an affordable 32-bit Cortex M3 (~ $15)

16

Read this .pdf from Silicon Labs and see if this is sufficiently accurate for your project:

That's fine if the +/- 1/2 LSB is random on successive reads (ie noise) , but not (as is likely ) it's systemic eg the 12 bit adc always reads 1/2 lsb high.

Allan

17

Klagemauer:
Hello there. I am in need of aid in regards to simultaneous sampling of analogue inputs.

Here is where my problems start already.

  1. Unfortunately I am having problems coming up with a good concept of buffering the data so that the secondary mcu can do its part without interfering with the first mcu. I thought about using a fifo to do so, however I have never worked with them before and would like to confirm that this is the best method and

Maybe a dual port RAM will solve that issue; it has a write side and a read side that are independent.

18

sterretje:
Maybe a dual port RAM will solve that issue; it has a write side and a read side that are independent.

Thank you, I am currently trying to look into it.
Also, I thought about using the MCU itself as buffer and copying data from it via direct memory access.