Hello all,
New to the site but a long time follower of Dave and the EEVBlog.
I am brain storming a possible design for an interesting project that involves measuring the slew rates from 100 op-amps.
The conundrum I'm running into is the stage after the measurements are taken (not necessarily making the measurements themselves):
How would one go about (simultaneously) sending the measured data from 100 op amps to some sort of storage for later processing?Is there a protocol or scheme that would allow this?
(Parallel (FPGA) vs. Serial (I2C, SPI, etc))
Since there are limits to the amplitude of the input voltage and frequency limits of whatever op amp in question is being measured for slew rate, let's just try to to keep this simple and focus on how to send the data. Preferably a test bed that is somewhat low cost yet reasonably accurate. Raspberry Pi, Arduinos, chaining multiple ADCs, etc are all fair game. Outside the proverbial black-box is encouraged.
Interested to see what other's thoughts were.
Thanks in advance,
Ray
Why do you need to send 100 measurements simultaneously ? you say that taking the measurement is sorted, I think your sending of data will be closely linked to this? so say for example you are using a micro-controller to measure the slew rate (time to rise from 0 to a given voltage?) that uC will obviously have the result recorded at the instant it happens, you then need some sort of master device to request the data from each measurement subsystem.
Ideally I want it measured simultaneously to compare how each op amp performs with the same given input (volt & freq) and do comparison on certain sample sizes to eventually determine variances (manufacturing tolerances, etc). Having the measurements taken simultaneously allows the comparison of each sampled measurement to be consistent with time. One clock cycle, one measurement taken on all op amps....10uS window I may want n samples from each op amp to build up unique waveforms from the data gathered.
A uC normally would interface through some sort of bus (and interrupt controller) limited not only to the available GPIO but also the sample rate and how fast the uC can process data (writing to memory via DMA is an option...) Not to mention most of the common protocols found on cheaper uCs incorporate serial interfaces, so there is inherent latency involved with each measurement unless the sample rate is increased to compensate. This is where the dilemma lies.
Sorry I'm confused, which part of the process are we actually talking about, I thought you had measurement sorted. I'd assume not being an analogue expert that you say put a pulse on the input of the op amp and measure the time it takes for the output to pass a certain voltage threshold, hence work out the V/S, whatever you use to do that and what you use depends on your accuracy will ultimately have that number stored in the short term. We don't really know what your overall goal or setup is, if we don't know how you are taking the measurement in the first place and what is collecting all of that data and how you are processing it from there the how you transmit the 100 measurements is not anything any one can help with. I expect that depending on the speed of acquisition you want you may have to have dedicated hardware for each amp or if you use something fast enough one "front end" could handle more than one amp.
It would make a lot more sense to measure the op amps one a time. Slew rate is measured with a simple stimulus (step or sine wave).
It would make a lot more sense to measure the op amps one a time. Slew rate is measured with a simple stimulus (step or sine wave).
This. For a large number of op-amps it could be automated. A single ADC could be used with a huge multiplexer to select the correct channel.
If you had to do this simultaneously on 100 then consider 100 analog
switches each with a hold cap on their output, to function as a S/H.
Then use mux to ADC to make the measurement value. Add OpAmp for
each channel if you want S/H to present Hi Z to each measurement
node.
There are issues such as drop, charge injection errors from Mux and ADC, so
that brings to bear the need to describe what type of accuracy do you need,
relative or absolute, and resolution of measurement, and rate of measurement
and ......
Regards, Dana.
Using a large MUX to do 100 DUTs with essentially a single measurement system is rather extreme. Depending on the needed throughput It might be a better idea to have a separate system for a much small number of DUTs - down to one per DUT.
So my guess would be more like 4 or 8 identical sub systems systems to handle something like 30 or 15 DUTs - or the other way around.
Combining the data from many parallel units can be done in different ways. At least the slew rate measurement is usually fast, so the tendency is to have a considerable data rate. So it likely takes a rather fast interface - so not I2C, maybe a kind of SPI, ethernet, maybe GPIB, maybe a kind bus (thus more lines in parallel) similar to an old computer system. It could be something like a master getting the data from the measurement parts one at a time, or maybe over a few channels in parallel.
For the data format you are likely on your own - so choice are open from binary date for lower rate to ASCII coded (e.g. SCPI like) for easier debugging.
If you really want to do it in ultimately parallel way I'd personally use 100 SPI ADCs with shared CLK, CS and MOSI and 100 individual MISOs.
You can then trigger (usually CS going low) and read them all at once in perfect synchronicity.
Multiplexing from parallel to individual reading is usually done after the event.
I have done it for 16 and 32 channels.
What sort of slew rate are you going for? Modern opamps can go up to 20000V/µs in which case windowed comparators or time-of-flight converters are probably better way of doing it.
Leo