How do I sample the ADC FAST!!!

11 Feb 2013

Hi Guys,

I have been working on an application where I attempt to determine an impact position on a window, on basis of the output of four piezo elements on the window.

I have built a custom daughterboard with a set of amplifiers and comperators, triggering the interrupts on the MBED. When an interrupt is triggered an timer is read into a buffer and I can get precition down to the microsecond.

But I cant seem to get consistent results when I knock the glass with my hand, a screwdriver or throwing a small ricebag. The times measured by the interrupts vary alot

I have therefore tried to channel the signal into the ADC as well, for further analysis.

This is inspired by: http://www.waterloolabs.com/#!episode-02/cgue & https://decibel.ni.com/content/docs/DOC-6126

I have written a polling program that sample the inputs, and I can definitely see a signal. But the resolution is too low to do any meaningful analysis of data.

How would I get the ADC sample 4 analog inputs at the 200khz it should be capable of?

Kind regards

Jesper Taxbøl

12 Feb 2013

Jesper Taxbøl wrote:

How would I get the ADC sample 4 analog inputs at the 200khz it should be capable of?

The user manual says as follows;

Features
• Input multiplexing among 8 pins.
• 12-bit conversion rate of 200 kHz.

There is only one ADC unit, so the max conversion rate for 4 inputs is 50 kHz each.

12 Feb 2013

Hi Yoshi,

Thanx for your reply, :)

Can that be reached through polling alone?

People are talking about burst modes and DMA setup of the ADC.

Honestly I havent measured what speed i reach now, but it seems somewhat low.

Kind regards

Jesper

12 Feb 2013

Hi Jesper,
I'm not an ADC expert.
But, I read the max conversion rate is 200 kHz for the single input from the manual whatever your reading method is, pollong or DMA.

12 Feb 2013

Interesting concept. With interrupts you say you have us resolution (at 4000m/s, 4mm resolution). With a 50kHz ADC resolution is only 8cm. You also have to correct for the phase offset of 20us between each channel. So your timer approach seems to be the better solution but are you sure you can actually capture the timer with that resolution? Taking into account latency and multiple interrupts arriving at more or less the same time? I think for further improvements, either with ADCs or timers you will need to add extra hardware.

12 Feb 2013

I am not aware of the timing of the interrupts.

We are using four comperators to detect if the signal is above a threshold and four others to detect if they are below a threshold. These signals are then fed into the mbed's interrupts and run the following code:

void inter(int i)
{
    //Disable input interrupt from that channel
    interrupts[i*2+0]->rise(NULL);
    interrupts[i*2+1]->rise(NULL);
    
    //If it is the first sample start timer
    if(++results == 1)
    {
        t.start();
    }
    
    //Pickup timer value
    times[i] = t.read_us();
    
    //If it is the fourth sample report timing and reset
    if(results >= NUM_INPUTS)
    {
       report();
       reset();       
    }
}

Any insight on improving timing here would be very welcome. :)

Jesper

12 Feb 2013

I don't know either, can't find a latency specification. The QEI library speaks about 2us for an ISR that has at least the complexity of your ISR. I think 2us is quite fast but if you get 4 or even 8 interrupts close to each other the uncertainty is considerable. You could improve a bit by omitting the lower threshold interrupt but after that I don't see any improvement without hardware capturing.

12 Feb 2013

BTW. you could set an output once you get an interrupt, this will give you an indication of the latency (at least if you have a two channel scope or logic analyser).

12 Feb 2013

The samples we get through our measurements, with 1 meter between sensors vary between 300 - 3000 cycles. (which we assume is microseconds)

What puzzles us is that the speed is very dependent on what we hit the surface with.

We initially assumed the speed of sound to be relatively constant, but that assumption does not seem to hold.

Perhaps it is the structure of our surface that plays us a trick. We assume the direct line of sight route a signal would travel hits sensors before reflections arrive. But that seems not to be the case!?!?

Our sensors are plain piezo elements shown here: http://dx.com/p/zx-18t9a1-18mm-piezo-transducer-sound-discs-w-leads-5-pcs-148144

Thans for your input :)

Jesper

12 Feb 2013

We actually did measure the interrupts and the timing seemed fine (very fast). We suspect the physics in the surface or sensors to be the root cause.

12 Feb 2013

Well, physics is not really my domain. The 300us is consistent with 1m and 4000m/s, the 3000us is obviously not. I think the 4000m/s is for a longitudinal wave, inside the pane. When you hit the glass with something soft you may instead get a transversal wave. Soft objects may not give longitudinal waves because the frequency is too low and instead induce only lateral movement of the pane. For acoustic waves to travel inside the pane (the pane acting as a waveguide), the frequency has to be in the order of MHz.

12 Feb 2013

Graff KF. Wave motion in elastic solids. This book treats the theory of waves in planes, lots of maths though