Fast, accurate ADC

[akis]

I was thinking of coupling an ADC module/chip to my various Arduino boards to be able to do a lot of things, eg a distortion analyzer. I imagine you sample for a few seconds (as much as RAM will allow) and then you send the RAM to the Arduino and then you write some code to calculate how far you're off the ideal sine curve. As an example.

For that the ADC module should have on-board crystal and RAM to buffer the samples because the communication with the Arduino would be rather slow. Has anyone done anything similar?

[Buriedcode]

Whilst I haven't heard of such a arduino shield I'm sure someone has done it somewhere.  Often for something that requires a relatively fast ADC, for say - a portable oscilloscope, people often turn to FPGA's, using their on-board RAM and the logic for controlling the ADC.  Using an arduino for something like that can work, but it depends on the specs - sample rate, resolution, and what you're planing *exactly* to do with the data.  I have seen a few oscopes using an 8-bit AVR, with a parallel ADC clocking samples into SRAM, but those projects are probably a decade old now.

For light signal processing such as checking for sine wave distortion, I would have thought most would skip over the 8-bit arduino to something more powerful, with little extra cost. You'll have to match the measure waves amplitude and frequency if you want a very simple comparison, but having the facility for 16/32-bit multiplication would make life easier.

[T3sl4co1l]

I doubt you'd be able to write it successfully with Arduino libraries, but the ATmega is capable of acquiring at 100, maybe 200 kSps and could write out to an attached parallel SRAM buffer.

Analyzing the buffer will take quite a bit longer, as there's little onboard RAM to handle intermediate calculations.  There is a hardware 8x8 multiply which is very convenient, but so much cranking is required to compute an FFT that you might spend several seconds computing a buffer of fractional-seconds length.

For both operations, you'd need hand optimized assembly.  Which isn't at all hard to do, on such a simple architecture as AVR.  But it's a rather daunting task if you only know Arduino right now.

Tim

[akis]

I doubt you'd be able to write it successfully with Arduino libraries, but the ATmega is capable of acquiring at 100, maybe 200 kSps and could write out to an attached parallel SRAM buffer.

Analyzing the buffer will take quite a bit longer, as there's little onboard RAM to handle intermediate calculations.  There is a hardware 8x8 multiply which is very convenient, but so much cranking is required to compute an FFT that you might spend several seconds computing a buffer of fractional-seconds length.

For both operations, you'd need hand optimized assembly.  Which isn't at all hard to do, on such a simple architecture as AVR.  But it's a rather daunting task if you only know Arduino right now.

Tim

Thinking aloud:

Supposing we only wanted to present say 10 cycles, and say the waveform was at 200KHz, and say we were sampling at 2MHz, we'd need 100 samples in total, times 16 bits, that's like 200 bytes of data to transfer and analyze.

The math is easily done by the arduino libraries (I mean the C libraries and float emulation if needed). If it took, say, 1 second to do the calcs, you would have a screen refresh of 1 sec. Not bad.

I was thinking I could make a small distortion analyzer and add it to my other existing arduino modules that also do other things. I presume all I need is a ADC module with some sort of serial interface, two wire, three wire, and maybe some RAM to allow it to go ahead and sample into its own RAM asynchronously.

/thinkng aloud

[Buriedcode]

So you'll be checking for distortion using the time domain directly?  The most convenient way for audio would be a delta-sigma stereo ADC, and FFT in a 32-bit uC.  That of course requires great accuracy, but unless you're just after a ballpark percentage, I don't see how using a handful of samples per cycle will give you an accurate idea of distortion.

Another (lengthy) way would be to sample the signal for its frequency - assuming its a single frequency - and amplitude, then using a DDS to generate a precise version.  Match the phase and invert, add it to the input, and whatever you have left is the difference.

[akis]

I do not need to check for distortion in real time - it could be seconds after the event and I only need to check say once every so often. Currently using an LM567 which is in real time.

Can we go back to the FPGA you mentioned a while ago? Is that something easy to use? Is an FPGA some sort of glorified MCU with much more RAM (capabilities) and I/O ports and ADCs and DACs and so on? And you can program it and upload code to it and debug and so on?

[T3sl4co1l]

Thinking aloud:

Supposing we only wanted to present say 10 cycles, and say the waveform was at 200KHz, and say we were sampling at 2MHz, we'd need 100 samples in total, times 16 bits, that's like 200 bytes of data to transfer and analyze.

MHz?!  I was thinking audio, 20kHz max...

100 samples isn't much to get a good idea on the noise and harmonics of a signal.  I'd like to see at least as many samples as 2^ENOB of desired accuracy (or ENOB/2, not sure exactly).  May still be enough to get an idea though.

But...

I do not need to check for distortion in real time - it could be seconds after the event and I only need to check say once every so often. Currently using an LM567 which is in real time.

If you only need to check a signal's average level, and by "signal" I mean a very particular frequency (namely, a harmonic of another also very particular fundamental frequency), then you can do even better:

You can do equivalent time sampling, at a rate determined by the desired accuracy (you're getting a statistical sampling here), any fluctuations in frequency (in other words, the bandwidth of that signal), and the desired refresh rate.

If you need a refresh rate of two seconds, an accuracy of 16 bits, and narrow bandwidth, then for a 12 bit ADC, you need 256 samples averaged for 16 ENOB, and so the minimum sample rate is 128 Sps.  The maximum bandwidth will be 64Hz then.  The samples need to be synchronized to whatever the source signal frequency is, and you can use a DDS to generate the sin/cos terms to correlate the samples against (thus generating a single-bin FT).

Can we go back to the FPGA you mentioned a while ago? Is that something easy to use? Is an FPGA some sort of glorified MCU with much more RAM (capabilities) and I/O ports and ADCs and DACs and so on? And you can program it and upload code to it and debug and so on?

FPGAs are discrete logic, integrated in programmable-chip form.  The programming is usually fixed (i.e., you configure the general "fabric" to be a particular digital logic circuit), and any additional configuration you want, has to be accommodated by implementing muxes and registers and such -- just as you'd draw up a discrete digital logic circuit to do it.  (Dynamic (on-the-fly) reconfiguration can be done, but I don't think there are any simple tools to do it.  I've only seen research projects about it.)

FPGAs are not, in general, MCUs.  They are much more general than that.  However, you can implement simple state machines that execute a complex but limited series of operations, much faster than an MCU can do it; or you can put together a few more state machines, and synthesize a full-on MCU as such (for example, 8051 cores are freely available).

Higher end devices (SoCs) have a variety of hardware already built on chip, including MCUs, communication PHYs, MACs, etc.

Most include useful pin and clock functions, like PLLs, pin drive strength settings (including controllable pull-ups/downs, tristate and such), priority routing for global clocks, block RAM, etc.

Tim

[akis]

What I am really looking for is a more powerful MCU, something in the 32 bit or 64 but area with more RAM, on board and DRAM support, and lots of other I/O support like digital and analog etc. I have got an STM32 board maybe it's time to see what it can do better than the old Atmega328,

[Fungus]

I was thinking of coupling an ADC module/chip to my various Arduino boards to be able to do a lot of things, eg a distortion analyzer. I imagine you sample for a few seconds (as much as RAM will allow) and then you send the RAM to the Arduino and then you write some code to calculate how far you're off the ideal sine curve. As an example.

For that the ADC module should have on-board crystal and RAM to buffer the samples because the communication with the Arduino would be rather slow. Has anyone done anything similar?

Get an ARM chip instead. Seriously.

I'm a massive 8-bit AVR fan but even I can see there's some jobs Arduinos simply aren't suitable for. This sounds like one of them.

(Unless by "Arduino" you mean one of those ARM-based Arduinos, in which case carry on...)

[Zad]

Raspberry Pi + Stereo Audio ADC board. Job jobbed.

e.g. https://www.pi-supply.com/product/cirrus-logic-audio-card-for-raspberry-pi-a-and-b/
Manual and schematics here: https://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/cirrus_logic_audio_card

Be aware, they say it may not be Pi 2 compatible, but I'm sure someone with hardware abilities will be able to hack it to work.

[Buriedcode]

I wasn't talking about analyzing in real-time, just in the time domain - that is, you sample a few cycles of the signal, store samples in a RAM buffer, then read them off and do your processing.  By 'time-domain' I meant actually comparing the samples to a fixed sine table. 

This is opposed to the frequency domain, whereby you get many samples and perform an FFT to see the harmonics, which you can then use to calculate how much power they have compared to the fundamental.  An ARM core would help a great deal and as you're not after a refresh rate of <500ms an M0, or M3 will do.  THese can do FFT rather well, but lack the extra DSP instructions of the m4 which speeds things up.  The advantage of an FFT is you can see the harmonics and their individual amplitude, also there are many FFT libraries written for above MCU's. You'll have access to much more information about the signal and improvements/additions would be straight forward.  The downside is it grows in complexity rather quickly.

I've already mentioned an (almost) purely analogue approach which would be a bit of a one trick pony as it would have to track the signals amplitude, and frequency in order to generate a 'perfect sine' of that.

[T3sl4co1l]

I wasn't talking about analyzing in real-time, just in the time domain - that is, you sample a few cycles of the signal, store samples in a RAM buffer, then read them off and do your processing.  By 'time-domain' I meant actually comparing the samples to a fixed sine table. 

In other words, a correlation -- which is the definition of a DFT, for a single bin.  Which as I noted earlier, can be done at pretty much any sample rate you like, above a fairly lax minimum (as long as you resolve the samples into the correct equivalent time slots).

Tim

[coppice]

I wasn't talking about analyzing in real-time, just in the time domain - that is, you sample a few cycles of the signal, store samples in a RAM buffer, then read them off and do your processing.  By 'time-domain' I meant actually comparing the samples to a fixed sine table. 

In other words, a correlation -- which is the definition of a DFT, for a single bin.  Which as I noted earlier, can be done at pretty much any sample rate you like, above a fairly lax minimum (as long as you resolve the samples into the correct equivalent time slots).

Tim

A DFT for a single bin is a quadrature correlation, not a simple one. A simple correlation can give any old result, depending on the arbitrary phase relationship of the two signals. isn't life complex?

[T3sl4co1l]

Oh yeah... I forgot to add that, you'll probably want to correlate sin and cos terms at the same time, so you get both phases, not just "any old thing"... 

Tim

[akis]

I have not done this before but I could sample/capture points on a curve store them in RAM and then analyse them how I see fit. If the signal is a single fixed frequency I do not need to sample all my samples from the same cycle, it can be alternate cycles, therefore even a slower sampling rate will do. Then you assemble an array of samples and relative time. You then compare to the output of a sin() function which is the theoretical 0% distortion and see how much you differ by. Of course this requires that the signal is perfectly fixed in amplitude, frequency and other characteristics for as many cycles as it has taken you to form a complete sample.

For example if you are sampling at 10Ksps and the frequency is 200KHz, it would require 10ms to take 100 samples and it would require that the signal stays perfectly fixed for 2,000 cycles!

I have inside a half dozen "Maple Mini" boards, unused so far, they use the ARM STM32F103 - I have read through the datasheet looks really powerful compared to the Atmega328. But I have not learned how to use it yet.

[Raj]

i can't suggest an adc but I do suggest using pc parallel port for recording

[Fungus]

i can't suggest an adc but I do suggest using pc parallel port for recording

Your PC has a parallel port?? 

[Raj]

Not only pararell,but serial and tmp header too :p

[Dave]

Even Enhanced Parallel Ports (EPP) are only able to do up to 2MBps. This ain't gonna work, cap'n!