interfacing an ADC (LTC1408-12) with PC

ote:

nel ADC connected with USB to a PC would be quite adequate, since the camer a movement is much too slower than the USB latencies.

It's also slower to correct errors; so, better to get more accuracy first.

ation.

xity of calculations since it becomes an overdetermined system). The noumbe r of mics is related to the configuration you are using. at the beginning i will try do it with four mics and in future i will try to raise the number of mics.

hen i will.

You should be able to do it with the 200Mhz PIC32MZ with up to 1M group sam ples per second. (The group could be 24 or 48 channels). The point is tha t when you detect something, you can stop the samplings and go back to proc ess the samples in buffer.

The MZ is not yet available; so we are building with the MX. MZ should be a drop in replacement when ready.

Email me "Edward dot Ming dot Lee at gmail dot com" the research paper as w ell. At least we can agree or disagree on the same basis.

The whole process (localization > calcualtions > camera movement) should take 1 second, with 8ksps (125ms to get 1000 samples) this means that i have 875ms for the rest.

Noise is not a problem(Theoretically), using the Phase transform removes amplitude information from the generalized cross correlation function.

If your LTC1408 has an SPI interface, it will be compatible with nearly any MCU eval board you can find. The real question is what eval board can you find with the LTC1408 on it. Does LT make one? They often do.

Here you go...

$150! That's a bit steep.

Just to be clear, I am talking about two eval boards. One with an MCU on it and one with the ADC on it. You just wire them together. You will also need some analog between the mics and the ADC for amplification and anti-alias filtering. Have you considered that?

Since the ADC eval board is so expensive and you may need to roll your own analog board anyway, maybe you will want to design a board with everything on it. Or at least one with the ADC and analog that interfaces easily to an MCU board.

Yes, i did. the microphones come with amplifiers so no amplification needed. I will make low pass filters to remove aliasing its not a big deal.

If i may ask, why do i need two eval boards as you have said? cant i just wire the output of the filters to the ADC and then connect the output of the ADC to the eval board with the MCU on it (with ground, Vdd and other connenctions)?

Please take responsibility of your quotes as well. Google messes you up do esn't mean you have to mess up everybody else.

e up to 100ksps and i can get a lower sampling rate by using the CONV and S CK pins.

e rest is choosing the right chip to do the processing, i have not checked any DSP chip to do that and i thought of using the PC(thats why i asked abo ut that).

al board?

ontrol two servo motors without any issues but untill that i will try to wo rk it with the PC.

The ARM Cortex M4 has DSP like capabilities with near single cycle MAC fun ctionality. But there are some low cost DSP chips as well. TI is a great DSP supplier too.

n correctly).

the LTC1408-12. Im sure it wont be a problem, if so then i will consider u sing a DSP chip.

any MCU eval board you can find. The real question is what eval board ca n you find with the LTC1408 on it. Does LT make one? They often do.

on it and one with the ADC on it. You just wire them together. You will a lso need some analog between the mics and the ADC for amplification and ant i-alias filtering. Have you considered that?

ed. I will make low pass filters to remove aliasing its not a big deal.

e output of the ADC to the eval board with the MCU on it (with ground, Vdd and other connenctions)?

If you get a decent micro, you don't need external ADC chip. Most micro co mes with at least 16 channels of 10 to 12 bits ADC. They can match what yo u can get externally, unless you need more than 12 bits.

Yes, you can wire it as you say, but what you have described has the ADC chip hanging in air on wires. Don't you want to have your chip on a board? Are you planning to build a board for it? If not, you can buy an eval board for the ADC for $150. Or are you really going to solder wires directly to the chip?

Is there something I don't understand?

btw, when you post with Google groups quoted text gets double spaced for some unknown reason. I'll leave it up to you to fix that or trim what you don't want to read.

Don't confused "channels" with ADCs. Often there is only 1 or possibly two ADCs on an MCU which is multiplexed across many inputs. If simultaneous sampling is important you won't get very far with that. There are ways around the problem involving sample and hold circuits but why bother when a single ADC chip will do just as well if not better.

o comes with at least 16 channels of 10 to 12 bits ADC. They can match wha t you can get externally, unless you need more than 12 bits.

wo ADCs on an MCU which is multiplexed across many inputs. If simultaneous sampling is important you won't get very far with that. There are ways aro und the problem involving sample and hold circuits but why bother when a si ngle ADC chip will do just as well if not better.

Yes, there is only one or two (have to check on this) ADCs, but you can sam ple it at 1M samples / second. So, you can effectively simultaneously samp le at more than 150 KHz of 6 channels with a small phase offset. Data are stored in circular buffer upto 512K bytes.

You cannot pull and store data fast enough with external chip.

What you call "small" may or may not be small to the algorithm.

I have no idea why you say that, SPI can run at up to 20 Mbps on many devices. That is more than twice as fast as the LTC1408 the OP is interested in (600 kSPS * 14 bits = 8.400 Mbps). Running at 48 kSPS for each input gives another factor of 2 margin. I don't see the problem.

Also, the ADCs built into MCUs are often very noisy yielding less than

Make that 120 microseconds for 8 kHz, then recalculate. 10^3 scale error propagating.

Forgive me, i didnt notice that, the quoted text is hidden.

I will start looking for the right mico.

I dont intednd to let wires hang in the air of course, but $150 is too much, i will look for another solution.

The quoted text is hidden, i didnt pay attention to that.

cro comes with at least 16 channels of 10 to 12 bits ADC. They can match w hat you can get externally, unless you need more than 12>

y two ADCs on an MCU which is multiplexed across many inputs. If simultane ous sampling is important you won't get very far with that. There are ways around the problem involving sample and hold circuits but why bother when a single ADC chip will do just as well if not better.

sample it at 1M samples / second. So, you can effectively simultaneously sample at more than 150 KHz of 6 channels with a small phase offset. Data are stored in circular buffer upto 512K bytes.

The phase offset is fixed and predictable. You can adjust it in the algori thm for proper compensations.

Not with the RPi. It only make sense to use the LTC1408 directly on the RP i bus. But the OP already determined that the RPi cannot pull data out of it fast enough. If he need to add a micro anyway, why not just use the mic ro's ADC?

ices. That is more than twice as fast as the LTC1408 the OP is interested in (600 kSPS * 14 bits = 8.400 Mbps). Running at 48 kSPS for each input gives another factor of 2 margin. I don't see the problem.

Perhaps the problem is with the RPi.

effective bits. Sometimes 10 bits is a stretch. The LTC1408 has 14 bits of which likely 13 are useful. LTC usually does a pretty good job with the ir parts, but the data sheet should be consulted for ENOB at the sample rat e being used.

True if you need more than 12 bits. But if the critical issue is timing, y ou can over-sample it rather than more accuracy. Over 12 bits will be diff icult with internal or external ADC.

"Predictable" maybe. Depends on how the ADC is triggered. If by software then the delays will have a lot of jitter. Since you are talking about "most micros" you can't say how the ADC sample is controlled or anything about the ADC specs. I believe I mentioned somewhere that most MCU ADCs are very poor only giving 10 ENOB if you are lucky.

All ADCs are not alike and putting one on an MCU means it will have much poorer performance.

Not sure where you got this. I can't find where the OP says the rPi won't work fast enough. Besides, there is no need to run the raw ADC data through the rPi. He has mentioned using a DSP for the signal process so the rPi is superfluous. The ADC should interface directly to the DSP which should have a high speed SPI port on it.

Can you substantiate this?

Noise is noise. You seem to ignore that ADCs never give a full n bits. Consider any ADC on an MCU as 10 bits until you are proved wrong by the figures or better, your own test data. An MCU makes digital noise which interferes with the on chip ADC. It is also subject to any board noise. An external ADC can have separate supplies and be much more noise free. The ADC the OP is considering will give *much* better performance than an MCU ADC... possibly as much as 3 bits better ENOB.

Then there is the issue of the MCU being superfluous if the OP is using a DSP.

Maybe you could review how you see this design shaping up? There have been a lot of posts and I think things have changed from the starting point. I believe you have been talked out of using a PC as not practical from a real time point. But I see you discussing MCUs but also DSPs in addition to an rPi.

I believe you only need one processor in the system. You can possibly use a capable MCU for the signal processing or you may need a DSP chip, but that depends on your algorithm. Or you can simply use the MCU as a data collector which passes large blocks of data on to a PC where you can program your algorithms more easily.

When you say you will look for another solution, do you mean a different ADC chip? The LTC1408 can be put on your own board very inexpensively if you are willing to spend the time to do that. Heck, I might be interested in doing this myself.

So where does this look like it is heading at the moment?

ch, i will look for another solution.

Maybe the Beaglebone

It's a single board Linux PC. It has 8 12bit 125ns ADCs. They're not simult aneous sampling like the LT part. I don't know how much of an issue that wo uld be. They're not differential either but you can work that out with Opam ps. An advantage is there is a big community that will help you make it go. You might still be able to use octave/matlab for the math, while having a single board for a 'realer' time system.

micro comes with at least 16 channels of 10 to 12 bits ADC. They can match what you can get externally, unless you need more than 12>

bly two ADCs on an MCU which is multiplexed across many inputs. If simulta neous sampling is important you won't get very far with that. There are way s around the problem involving sample and hold circuits but why bother when a single ADC chip will do just as well if not better.

an sample it at 1M samples / second. So, you can effectively simultaneousl y sample at more than 150 KHz of 6 channels with a small phase offset. Dat a are stored in circular buffer upto 512K bytes.

gorithm for proper compensations.

e then the delays will have a lot of jitter. Since you are talking about " most micros" you can't say how the ADC sample is controlled or anything abo ut the ADC specs. I believe I mentioned somewhere that most MCU ADCs are v ery poor only giving 10 ENOB if you are lucky.

I also mentioned the specific micro PIC32MX/Z. For this micro, the ADC dat a are stored into static ram buffer by micro-code. No firmware or software involved. The sampling intervals are very regular and predictable, much m ore than software polling of external chip.

e RPi bus. But the OP already determined that the RPi cannot pull data out of it fast enough. If he need to add a micro anyway, why not just use the micro's ADC?

t work fast enough. Besides, there is no need to run the raw ADC data thro ugh the rPi. He has mentioned using a DSP for the signal process so the rP i is superfluous. The ADC should interface directly to the DSP which shoul d have a high speed SPI port on it.

devices. That is more than twice as fast as the LTC1408 the OP is interest ed in (600 kSPS * 14 bits = 8.400 Mbps). Running at 48 kSPS for each inp ut gives another factor of 2 margin. I don't see the problem.

The OP said: "It has no analog inputs so an ADC must be used, i didnt know about the sim ultaneous sampling ADCs so i thought of using 6 separate ADCs but due to th e SPI latency at the RPI my project wont work in real-time applications. "

Ok just to clear some points (i didnt mean to confuse any one but everyone is giving me choices and as someone once said "there are many ways to skin a cat" i really appreciate all those opinions but they confused me as well ).

My priority was to do everything with the RPI only, but i didnt know before that it has no analog inputs, then i decided to use an ADC to continue my project with the RPI. I didnt know that some ADCs feature simultaneous samp ling and no one has tried to implement more than one ADC on the RPI (actual ly there is only one topic about that on the RPI forums she tried to connec t two MCP3202 ADCs to the RPI and with BIT BANG she managed to do simultane ous sampling but the latency was high about 100sec) if i do what she did wi th 6 MCP3202 chips then i will need about 330sec according to her and thats not acceptable.

I looked for other ADCs and i found the LTC1408-12 which was perfect for me , but still i couldn't do it with RPI due to the latency of its SPI (accord ing to someone i wont get more than 20K transaction/sec) so i decided to do it with pc so i posted about it here.

I will do the following, I will buy the LTC1408-12 and a MCU which can cont rol the servos in addition to acquiring data from the LTC1408-12 and the pr ocessing and thats it.

microphone array(with amplifiers) > low-pass filters > LTC1408-12 > MCU > s ervos

Ok, so you are planning to use an MCU, but not the rPi and no DSP? That is more clear.

How do you plan to mount the LTC1408? Do you expect to roll your own PCB? Something else to think about is using multiple ADCs which are all controlled to sample simultaneously. Perhaps you can find an ADC eval board for a price you prefer. The LTC1408 is a bit pricey anyway. Do you know the specs you need from an ADC?

Do you have a handle on the processing power you will need? That will likely determine the range of MCU you can use. Also, the servo controls may put requirements on the MCU you use. What is that interface like?

Just to be clear, SPI is a serial interface which allows you to chain multiple devices and control them simultaneously as if they were one large device. I expect this is the fastest way to use SPI on the rPi, It is likely to be faster than using one ADC with six inputs since each transaction is performed on all the devices at once.

You might want to take another look at the rPi. If the existing SPI driver has too much latency I'm sure you aren't the only person impacted. Perhaps others are working this problem.